S/4HANA is not ECC with a new name

Many teams approach the move to S/4HANA as a version upgrade: same scope, same logic, a faster engine. That framing can underestimate the effort and risk of the migration. S/4HANA is not ECC sped up. Its data model includes changes that require the mappings, transformations and migration controls to be checked.

You don’t load data into S/4HANA. You load data qualified for S/4HANA.

The schema changed where no one is looking

The screens look alike. The tables don’t. Three changes are enough to derail an unprepared cutover:

• MATDOC becomes the store for material documents previously held across MKPF and MSEG. Compatibility mechanisms preserve some legacy access paths; check their behaviour for the release and access method being used;
• ACDOCA, the universal journal, brings together general-ledger and controlling data previously spread across several structures;
• BSEG, contrary to a widespread belief, does not disappear. It coexists with ACDOCA: their roles and relationships must be reflected in migration checks.

SAP documents material-document storage in MATDOC and reconciliation checks between BSEG and ACDOCA.

Include these changes in technical and functional scoping. Define transformation and reconciliation rules for the transition scenario, release and interfaces being used. A data audit prepares that work from the start of the project.

Valid data is not qualified data

Data can be perfectly correct in ECC and unusable in S/4HANA. A stock movement that is consistent on the source side can violate a constraint of the material document. A balanced posting in the old chart of accounts may not project cleanly into the universal journal.

In this article, validity means acceptance by the source system. Qualification adds conformity with target constraints and preservation of the intended business meaning. A record accepted by the target can still carry a wrong unit, reference or accounting assignment.

Qualify each record and its relationships

Each record needs a traceable control result. That does not require a separate technical operation for every row: batch processing can apply the same controls. Related objects also need consistency checks across the document, structure or business process.

An event-driven architecture with tracking and replay can organise that work. Discrepancies are diagnosed, corrected or arbitrated, then replayed; dependent objects wait for the required prerequisites. An accepted load status remains partial technical evidence.

Before cutover, also reconcile transformed values, verify relationships and execute the affected business processes, then rehearse the chain within the planned window. These complementary checks are described in our article on migration testing levels. Go-live is decided from their results and the explicit treatment of remaining discrepancies.

This article is about the model. The tooling is a separate question, and the two get conflated in estimates: where the standard SAP toolchain stops covers what the Migration Cockpit validates, what it cannot, and why a structurally valid load can still be semantically wrong.

S/4HANA is one case of a wider problem. The scoping, the cutover strategies and the costs are covered end to end in the ERP data migration guide.