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 data that no standard object covered, 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
Credit where it is due. The S/4HANA Migration Cockpit, whether you reach it through the older LTMC transaction or the newer Fiori app depending on your release, solves real problems and solves them properly:
- Structure and validation. Each standard migration object knows the target structure and its mandatory fields. You get errors at simulation rather than at load, which is worth a great deal.
- Simulate then transfer. The two-step flow lets you run a scope repeatedly and see what would fail without committing anything. This is the feature that makes iteration possible at all.
- Several transfer routes. Files for small scopes, staging tables when you want to push data in from your own pipeline, and direct transfer from an SAP source when your release supports it.
- Value mapping. Old code to new code, held in the tool, reusable across runs.
For a clean scope on standard objects, it is a good tool and you should use it. The question is never whether to use it. It is what proportion of your scope it covers.
The frontier: standard objects and everything else
Standard migration objects cover the main master data and open items: materials, business partners, cost centres, bills of materials, open purchase orders, stock. If your data fits them as delivered, the work really is filling templates.
Three things routinely fall outside, and none of them is exotic:
Custom fields on standard objects. Twenty years of an ECC estate means Z-fields on the material master, appended structures, and fields that were added for one plant and then used everywhere. The Cockpit can be extended for these through the Migration Object Modeler, but extending an object is development work with its own testing, not template filling. Each extended object is a small project.
Data with no standard object at all. Classification and characteristics, long texts, document attachments, batch and serial number history, custom Z-tables that carry real business logic. Some can be handled through other SAP mechanisms, some need a custom migration object built from scratch, and some need a different tool entirely. What they have in common is that nobody counts them when the estimate is made, because they do not appear in the object list you were looking at.
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.
Where the template stops and development begins
The practical test, and one you can apply during scoping rather than in month four:
For each migration object in scope, can the data be loaded with the object as delivered, with no field extension and no pre-processing beyond format conversion?
Count the objects that pass. That is your template work. Everything else is development, and it should carry a development estimate, a development test cycle and a development contingency.
In the programmes we have seen, the proportion that passes cleanly ranges from roughly a third to two thirds. It is almost never everything, and it is almost never nothing. What matters is that the two categories are budgeted differently, because they behave differently: template work scales with the number of records, development work scales with the number of exceptions.
Value mapping is not arbitration
This is the misunderstanding that costs the most, so it is worth being precise.
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?
No tool resolves that, because it is not a data problem. It is a business decision that happens to be expressed in data. The Cockpit will happily load both records, and it will be right to: they are both valid.
This is why the share of records needing a human decision has to be measured during the audit and planned as its own workstream. It is the line that moves the date, and it is invisible to any tool-based estimate.
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.
What they do not do is decide. A profiling tool tells you that 9,000 material records are probable duplicates with a similarity score. Turning that into 9,000 correct decisions still requires the site engineers who know which part is actually in the machine. The tool’s contribution is to group the candidates and present them with their usage and stock; the decision stays where it always was.
Treating a preparation tool as a substitute for that work is the same estimating error as treating the Cockpit as a substitute for development. Both tools do their job. Neither does the job nobody assigned.
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 connection to tooling is direct: the Cockpit validates against the target structure, so it catches structural violations. It does not catch semantic ones. A cost centre that loads successfully into a structure that no longer means what it meant is a green line in the transfer log and a wrong number in the first month-end close.
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 in scope and mark each one as delivered-as-is, extended, or custom. The second and third categories carry development estimates.
- List the data with no object: classification, long texts, attachments, custom tables. Decide for each whether it is migrated, archived or dropped, and record the decision.
- 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.