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. It’s the most expensive framing mistake of the project. S/4HANA is not ECC sped up. It’s a different data model, and it won’t tolerate being handed yesterday’s data as-is.

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 replaces MSEG and MKPF: stock movements no longer live in two separate tables but in a single material document. The old tables are now only compatibility views;
• ACDOCA, the universal journal, merges general ledger, controlling, and cost postings that used to be scattered across a dozen tables;
• BSEG, contrary to a widespread belief, does not disappear. It coexists with ACDOCA. Confusing the two means duplicating or losing postings during the reload.

None of this shows up on a functional checklist. It exists only in the target structure — and it’s the target structure that the data must be shaped to before it’s loaded.

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.

Validity is observed in the system of origin. Qualification is measured against the target model. These are two distinct questions, and only the second one decides Go-Live.

Qualifying is a per-record job

Qualifying data for S/4HANA isn’t done in bulk, on a massive export signed off in one pass. It’s done record by record, each one checked against the target’s rules, each one traceable.

This is exactly the logic of an event-driven architecture: each record is an event processed individually, with its own verdict. What passes moves forward. What fails goes to an error queue, gets diagnosed, corrected, replayed — without blocking the rest of the flow. In the end, you don’t deliver a batch you hope holds together. You deliver data where every single line has already been accepted by the target model.

The cutover then stops being a bet. It becomes the confirmation of what has already been proven, line by line.