The S/4HANA Migration Reality Check

S/4HANA migrations are the most complex system changes in the SAP ecosystem. They are also among the most consistently underestimated. Projects that budget six months run for eighteen. Projects that estimate minor custom code changes find hundreds of critical issues. Understanding what a migration actually involves — before the statement of work is signed — is the only way to avoid becoming a cautionary tale.

The Readiness Assessment Is Not Optional

Every S/4HANA migration should begin with a formal readiness assessment using SAP's tools: the Readiness Check for SAP S/4HANA (available on SAP for Me / SAP ONE Support Launchpad) and the Simplification Item Check. These tools analyse your existing system and produce a categorised list of what needs to be addressed before migration can proceed.

The readiness assessment output is not a to-do list — it is a project scoping input. The items it identifies require effort estimates, owner assignments, and dependency sequencing. Teams that begin a migration without completing this step consistently discover scope they did not account for, well into the project timeline.

Run the readiness check in a development or quality system first to understand the landscape before running it in production. The results are system-specific and depend on your installed add-ons, active business functions, data model customisation, and custom code volume.

The Simplification List

SAP's Simplification List documents every change between ECC and S/4HANA that affects existing functionality. It covers deprecated tables, changed data models, removed transaction codes, and replaced business processes.

The simplification list for a typical ECC 6.0 system is long. Some simplification items are handled automatically by the migration tool. Many require manual preparation — data archiving, configuration changes, code adaptations, or business process redesign. The simplification list should be reviewed item by item against your active configuration. Not every item applies to every customer; the impact depends on which modules and business functions you use.

Finance simplification (the merge of FI and CO in the Universal Journal, and the migration to the new Asset Accounting) is consistently the area that surprises projects. If your Finance processes have been heavily customised, allocate proportionally more assessment effort to the Finance simplification items.

Custom Code Impact

The custom code impact assessment uses the ABAP Test Cockpit (ATC) with the S/4HANA compatibility check configuration, or the SAP Cloud ALM custom code analytics. The tool identifies custom programs that use deprecated function modules, removed database tables, replaced transaction codes, or patterns that are incompatible with S/4HANA's changed data model.

Typical findings fall into three categories. Critical findings are code that will not function after migration — it references tables or APIs that no longer exist. These must be remediated before the migration. Warning findings are code that still works but uses deprecated approaches — it should be remediated but is not a blocker. Info findings are opportunities for modernisation.

The volume of critical findings in a typical ECC system with significant custom development is almost always larger than project teams expect. A system with 2,000 custom programs commonly has 300-500 critical findings. Each finding requires a developer to analyse it, assess the impact, identify the replacement, and test the fix. Budget for this realistically.

Data Volume Management

S/4HANA migration requires the source system's data to meet HANA sizing constraints. If your ECC system has grown organically over 15 years, it likely contains significant volumes of data in tables that will be restructured or merged during migration.

Data volume management (DVM) before migration achieves two things: it reduces migration time (a smaller dataset migrates faster) and it removes obsolete data that would otherwise be carried into the new system. Use the Archiving Workbench (SARA) to identify archivable objects and archive them before starting migration preparation.

Tables that typically warrant archiving before migration: FI documents (BKPF/BSEG), CO line items, MM movement documents (MSEG), and change document tables (CDHDR/CDPOS). The S/4HANA Universal Journal migration in particular performs much better on smaller BKPF/BSEG datasets.

Timeline Realities

A realistic timeline for a mid-size ECC to S/4HANA migration (one or two major application areas, moderate custom code) is 12-18 months from project kickoff to production go-live. Large, highly customised systems with complex integrations and global rollout scope run 18-36 months.

The phases that are most commonly underestimated are: the readiness assessment and remediation phase (finding everything is fast; fixing it takes time), the custom code remediation phase (especially for companies that did not apply a code freeze before starting), the integration testing phase (S/4HANA changes the data model in ways that affect every downstream integration), and the parallel payroll and finance validation phase (reconciling the new Universal Journal to historical reporting takes longer than expected).

Factor in a contingency of 20-30% on top of the bottom-up estimate. S/4HANA migrations consistently find complexity that was not visible during assessment. The contingency is not pessimism — it is recognition of how these projects actually behave.

The SUM Procedure

The technical migration uses the Software Update Manager (SUM) in its DMO (Database Migration Option) variant for combined OS/DB migration and SAP upgrade in one step, or in the standard mode for in-place upgrade on HANA.

SUM runs in phases: preparation, preprocessing, downtime-minimised processing (which can run in the background while the system is still live), and the actual downtime phase where the system is taken offline for the final technical migration steps. The downtime-minimised phases can run for days or weeks on large systems. The actual technical downtime window for the final phase is typically 8-48 hours depending on data volume and hardware.

Plan the SUM run in a sandbox before attempting it on production. The first SUM run on an unprepared system almost always encounters issues that require either configuration changes or SUM rerun. Running it in sandbox first identifies these issues without production pressure.

What Goes Wrong

The most common failure mode is inadequate testing. S/4HANA changes fundamental data models that underpin every process in the system. End-to-end business process testing — not just technical smoke testing — is required. Projects that go live after unit testing but without integrated business process testing discover critical issues during or after go-live.

The second failure mode is integration underestimation. Every system connected to SAP is affected by the S/4HANA migration to some degree — the IDoc structures change, the BAPI interfaces change, the RFC-callable functions change. Inventory all integrations before the project starts, not during it.

The third failure mode is organisational: the business withdrawing from the project after the initial workshops. S/4HANA migration requires sustained business involvement throughout the project, not just at the start. Key users need to be available for configuration validation, testing, and training. Projects where the business delegates entirely to IT consistently produce systems that work technically but fail to support the processes the business actually runs.

> Editorial note: S/4HANA versions and migration tools evolve rapidly. This guide reflects general migration concepts applicable to ECC to S/4HANA migrations. Specific tool behaviour, simplification items, and migration procedures depend on your source release, target release, and installed add-ons. Always verify against current SAP documentation and engage an experienced migration team.