SAP data migration: where the standard toolchain stops
The data migration line in the budget was two months. The reasoning behind it was reasonable and, in the room, unanswerable: SAP ships a migration tool, the tool has templates for the objects we need, so the work is filling templates.
Nine months later, the thing that had consumed the schedule was not the templates. It was the 140 fields that had no template, the classification attributes and relationships that were not covered by the objects available for that scope, and the discovery that “value mapping” in the Cockpit means a lookup table, not a decision about which of two suppliers is the right one.
The tool was not the problem. The estimate was, because it was built on what the tool does rather than on what the migration needs.
What the Migration Cockpit genuinely does well
The S/4HANA Migration Cockpit provides migration objects and guided processing. Its available interfaces, objects and features depend on the edition, release and transfer approach:
- Structure and validation. Standard objects describe the supported target fields and use SAP application checks. Simulation can expose errors before loading, within the checks supported by that object.
- Simulate then transfer. Where simulation is supported, it lets you check a scope without committing the migration. A successful simulation does not guarantee that the transfer will succeed.
- Transfer approaches. Depending on the release and edition, data can be supplied through files or staging tables, or transferred directly from supported SAP sources. Check the approach supported by each object.
- Value mapping. Old code to new code, held in the tool, reusable across runs.
Check the simulation exclusions as part of that assessment. For example, SAP documents a Characteristic object whose simulation excludes change-number processing and dependencies; those features can still fail during transfer after a successful simulation. This is an object-specific limit, not a reason to skip simulation. Source: SAP S/4HANA 2021, Migration Objects, Characteristic, page 126.
For supported objects, the Cockpit provides a useful starting point. The scoping question is how much of your required data and behaviour it covers.
The frontier: standard objects and everything else
Standard migration objects cover many master-data and opening-data needs: products, business partners, cost centres, bills of materials, open purchase orders and stock, depending on the release and approach. Even when a template fits, source preparation, mapping, reconciliation and business acceptance remain part of the work.
Three areas need separate assessment:
Custom fields and extensions. An ECC estate may contain Z-fields, appended structures and plant-specific additions. Some target custom fields are supported through key-user extensibility: SAP documents automatic inclusion of supported Product custom fields in the migration template after the object is updated. Other additions require modeler configuration, mapping changes or custom development. Estimate the actual route and test it; a field extension is not automatically a development project. Source: SAP Public Edition Product, Custom Fields and Additional Standard Fields.
Required features beyond an object’s coverage. Classification and characteristics are not universally absent from the standard catalogue: SAP provides Characteristic (CHARACT) and Object classification (CLF_OBJ), with documented scopes and prerequisites. Long texts also have standard support for some business objects, including the Product follow-on object described in the documentation above. Check the required attributes, relationships, attachments and history against the exact object version. A remaining gap may need an extension, another supported interface, a custom object or an archive decision.
Volume behaviour. A scope that simulates comfortably at 20,000 records does not necessarily transfer comfortably at 2 million. This is not a defect, it is a property of any load, and it is the reason a dry run at real volume is not optional. Discovering the transfer window at cutover is the classic way to turn a working migration into an outage.
Separate standard preparation, configuration and development
The practical test, and one you can apply during scoping rather than in month four:
For each object and required feature, what is supported as delivered, what can be configured, and what needs custom development?
Record those categories separately. Standard preparation includes extracting and mapping values. Configuration covers supported extensions and settings. Development covers gaps requiring code or a custom interface. Each category needs appropriate testing and reconciliation.
In the programmes we have seen, roughly a third to two thirds of the objects could be used without extension. That is an observation from those scopes, not a ratio to apply to your programme. Budget the remaining configuration and development from the required features and rules. Volumes also affect extraction, loading and reconciliation; exception effort depends on the decisions required, not just the number of flagged records.
Value mapping is not arbitration
Two different activities need separate owners and estimates.
Value mapping answers: this source code corresponds to that target code. Plant 1000 becomes plant FR01. Unit of measure ST becomes PCE. It is a lookup, it is deterministic, and the Cockpit holds it well.
Arbitration answers a different kind of question: these two material records describe the same physical part with different numbers, different units and two suppliers each listed as sole source. Which one survives, and who says so?
A tool can apply an approved selection rule or route the case for review. It cannot establish the intended business outcome from structural validity alone. If both records meet the target checks, both may load even when the business needs one shared part.
This is why the share of records needing a human decision has to be measured during the audit and planned as its own workstream. That work can move the date and needs an explicit estimate alongside the tool configuration.
What data preparation tools do not replace
The same logic applies one level up. SAP’s data quality and preparation tooling, and the equivalents from other vendors, are genuinely useful: they profile, they flag, they enforce rules at scale.
If a profiling tool flags 9,000 material records as probable duplicates, that does not mean 9,000 business decisions. Group the candidates into review cases, attach their usage and stock, and separate cases covered by approved rules from those requiring an engineer’s judgement. Size the arbitration work from those cases and their complexity; retain the affected record count for traceability.
Preparation tools can automate agreed rules and organise reviews. The plan still needs owners for unresolved cases and evidence that the resulting decisions preserve the intended business meaning.
The S/4HANA specific: the schema moved
One last thing that makes SAP migrations different from a like-for-like ERP move. S/4HANA is not ECC with a faster engine. The universal journal, the material document tables and the business partner model change what a valid record is, which means data that was correct in the source can be rejected or, worse, accepted with a different meaning. That is a separate subject and it has its own article.
The Cockpit and its application interfaces check structure and supported application rules. They cannot, by acceptance alone, establish that every transformation preserves the intended source meaning. A cost centre mapped to an existing but incorrect target parent may pass the available checks. Compare the intended mapping, reconcile the loaded values and test the affected business processes.
What to do with this before you commit a date
Three things, in order, and all of them before the estimate is signed:
- List every object and required feature, with the target edition, release and migration approach. Separate standard preparation, supported configuration and custom development.
- Record the actual coverage gaps and simulation exclusions. For each, decide how it will be transferred, tested, archived or excluded. Do not infer absence from an object name alone.
- Measure the arbitration volume in the audit, in decisions rather than records, and get a weekly rate agreed with the business.
None of this makes the Migration Cockpit less useful. It makes the estimate correspond to the work. The full sequence, from audit through cutover, is in the ERP data migration guide.