It depends primarily on payroll complexity and country footprint. Full cloud (Employee Central plus EC Payroll) gives the cleanest end state, lowest long-term cost and full innovation — it suits organisations with simpler or fewer country payrolls and a genuine appetite for cloud. The side-by-side model keeps EC as the HR core while retaining your proven SAP on-premise payroll (or H4S4), fed by standard EC-to-ERP replication; it de-risks the single hardest part of any migration and is often the right call for complex, highly localised, multi-country payroll. Many large organisations start side-by-side and migrate payroll to the cloud in a later phase once the core is stable. We assess your payroll landscape specifically and recommend the model that fits your risk profile — this decision is an output of our assessment, not a starting assumption.

A focused Employee Central core migration for a single country or a mid-size organisation typically runs 4–7 months. Adding EC Payroll with proper parallel runs extends timelines because parallel cycles must span at least two to three real pay periods, plus reconciliation — payroll almost always sets the critical path. A full multi-country programme with talent modules, EC Payroll and several integrations is usually a phased effort of 12–24 months. The variables that move timelines most are the number of payrolls, data quality in the legacy system, the volume of custom infotypes, and organisational readiness for change. We size every migration specifically in the assessment phase rather than quoting a generic number — but the single biggest driver is almost always payroll complexity.

Both need explicit decisions — this is exactly the work of the mapping and design phase. Custom (Z-) infotypes rarely map one-to-one; each is assessed to determine whether it becomes a generic object (MDF) in Employee Central, folds into a standard EC object, is replaced by a better-designed cloud construct, or is retired because it is no longer needed. For historical data, few organisations migrate all of it — carrying decades of effective-dated records into a new system adds cost and risk for limited value. A common pattern is to migrate current and recent effective-dated records into EC for operational use, and retain deeper history in an archive or the legacy system in read-only mode for reference and compliance. We define a clear data-retention scope with you early, so the migration carries what the business actually needs rather than everything by default.

Through parallel payroll runs — the single most important control in any payroll migration. Before cutover, we run the new payroll and the legacy payroll on the same input data across multiple pay cycles and reconcile the results line by line, employee by employee, to the cent. Any difference is investigated and resolved in the test environment — a wage type calculating differently, a tax rule mapped incorrectly, a retroactive scenario handled differently in the new engine. Only once parallel runs match for consecutive cycles do we approve payroll cutover. This is why payroll migrations take longer than core HR migrations: the parallel-run period is deliberately not rushed, because a payroll error that reaches real employees is the one outcome no migration can afford.

Migration is the best opportunity you will get to improve, and a straight lift-and-shift usually wastes it. Employee Central works differently from on-premise HCM — it is effective-dated, object-based, workflow-driven and configured through business rules rather than heavy custom development. Replicating every legacy workaround into the cloud simply inherits old compromises in a new system. Our approach is fit-to-standard first: we adopt SuccessFactors standard processes wherever they meet the need, and reserve configuration for genuine business-specific requirements. That said, improvement has to be balanced against scope and timeline — trying to redesign every HR process at the same time as migrating creates risk. We help you distinguish the improvements worth making during the migration from those better handled as continuous improvement after go-live, so the programme stays deliverable.