Two Paths Lead to S/4HANA, and They Are Not Interchangeable
SAP offers two fundamentally different routes from ECC to S/4HANA, and choosing between them shapes nearly every other decision in the program. System conversion carries your existing configuration, custom code, and historical data forward into the new platform using SAP's conversion tooling. New implementation starts from a clean S/4HANA system and rebuilds processes, often informed by SAP's best practice content, then migrates only the data you choose to bring across. Neither path is inherently better; the right choice depends on how much of your current ECC configuration still reflects how the business actually wants to operate.
What System Conversion Actually Preserves
System conversion keeps your transaction history, existing customizations, and years of accumulated configuration intact, which matters if your ECC system reflects processes that work well and would be expensive to rebuild from scratch. It generally takes less time than a new implementation because you are not redesigning processes, and it avoids a full data migration project since history moves with the conversion. The tradeoff is that conversion also carries forward technical debt, workarounds, and configuration that may no longer match how the business actually operates, unless you deliberately clean it up as part of the project.
What New Implementation Lets You Rebuild
New implementation gives you a genuine opportunity to simplify processes, retire custom code that is no longer needed, and adopt S/4HANA's standard capabilities instead of replicating old workarounds. This path suits organizations that have grown through acquisition, accumulated significant configuration debt, or want to standardize processes across multiple business units that currently run differently. The cost is a heavier project: business process workshops, a deliberate data migration strategy, and more organizational change management since users are learning new ways of working rather than a new interface on familiar processes.
Custom Code and Historical Data Change the Calculation
A landscape with a large custom code footprint often points toward system conversion, since rebuilding every custom object from scratch in a new implementation adds significant time and cost. Conversely, if a code review finds that much of the custom development exists to work around limitations that S/4HANA no longer has, that same footprint can argue for a new implementation instead. Data retention requirements also matter: industries with long regulatory retention windows may lean toward conversion so historical transactions remain queryable in the live system rather than an archive.
Selective Data Transition Sits Between the Two Extremes
SAP's selective data transition approach lets organizations combine elements of both paths: converting configuration while selectively migrating only the historical data that still matters, or restructuring specific organizational elements that a straight conversion cannot change. This hybrid path suits companies that like their overall configuration but need to fix specific structural issues, such as a chart of accounts that no longer fits the business or a company code structure left over from a past divestiture. It typically costs more to plan than either pure path but avoids paying for a full rebuild you do not need.
The Questions That Should Actually Drive the Decision
Before choosing a path, get honest answers to a few questions: how much of the current configuration still matches how the business wants to operate, how large and necessary is the custom code footprint, how important is preserving line item history in the live system, and how much organizational appetite exists for process change alongside a technology change. A short technical and process assessment, run before the decision is locked in, is far cheaper than discovering the wrong path was chosen after the project is already underway.