01 What exactly is an ERP data migration?
An ERP data migration consists of transferring data from one management system to another: from a legacy ERP to S/4HANA, from a homegrown system to IFS, or from several merged instances into a single one. But the honest definition is more demanding. It means rebuilding a data estate inside a model that does not expect it.
Two workstreams must be distinguished, though schedules often conflate them. The system migration (install, configure, train) is carried by the integrator. The data migration (extract, transform, qualify, load) is a discipline of its own. It is almost always the one that derails the project, and almost never the one that gets attention first.
The reason is structural: the target system is new and documented, while your data has twenty years of history and is not. Migrations fail because of the source data, not the destination tool.
Migrating a technical repository (Windchill, 3DEXPERIENCE, Teamcenter) rather than a management system? Product structures follow different rules: see the PLM data migration guide.
02 The link that decides whether the project succeeds
The numbers are well known and keep repeating: Gifi and its roughly €117 million in lost revenue, Revlon unable to fulfill $64 million in orders, Hershey's missing Halloween, Haribo losing 25% of its gummy bear sales. The real cost of a failed migration runs into tens of millions. And none of these companies lacked resources.
What they lacked: control over their data and their execution. A wrong record in the old system is an inconvenience. The same wrong record, loaded into a new ERP that drives production, inventory and invoicing, becomes an operations incident. Migration is the moment when data debt falls due.
03 Which data to migrate, and which to leave behind
Migrating everything is as costly a mistake as migrating too little. Scope is decided by category:
- Master data (parts, bills of materials, customers, suppliers, chart of accounts): the heart of the job. It must be qualified, deduplicated and shaped to the target model. This is where the quality of the future system is decided;
- Open transactional data (in-flight orders, inventory, work in progress, unsettled postings): essential for business continuity, and the most sensitive to cutover timing;
- History: the temptation is to take everything "just in case". In most cases, a searchable archive costs ten times less than migration. And unqualified history pollutes the new system from day one.
04 Everything starts with an audit of the real data
Before deciding anything, you need to know what actually exists: effective volumes, duplicates, orphaned objects, diverging reference data, accumulated exceptions. The data audit is the phase everyone overlooks, yet it is the one that conditions all the others.
A serious audit extracts and profiles the entire source dataset, not a convenient sample. Its deliverable is a quantified map of the risk: what goes through as-is, what needs a rule, what requires a business decision. Without it, the project plan rests on assumptions. And assumptions are exactly what makes migrations fail.
05 Big bang, phased, or trickle: choosing your approach
The big bang cutover, where everything is migrated over a weekend, is the easiest to plan and the most dangerous to execute: zero room for correction once the source system goes dark. It is only reasonable if the migration has been proven at real volume, several times, before the day itself.
The phased cutover, by site, by domain or by data family, reduces unit risk. In exchange, you have to run two systems in parallel, with temporary synchronizations that carry their own cost.
The choice of approach matters less than the nature of the tooling. One-off scripts written for "the big day" survive neither iterations nor exceptions. An asynchronous migration chain, where each record moves, fails and is replayed individually, turns the migration into a repeatable system, whatever cutover strategy you pick.
06 The five phases of a controlled migration
Our full methodology details each phase; in short:
- 01 · Audit: measure the real scope, the volumes, the anomalies. Reality before assumptions;
- 02 · Build: build a configurable, traceable, repeatable chain. An industrial system, not scripts;
- 03 · Run / Fix: execute on real scopes, correct every discrepancy, loop until stable;
- 04 · Dry Run: the dress rehearsal, at real volume, across the complete chain;
- 05 · Go-Live: cutover happens once everything has already been proven. A controlled step, not a bet.
07 The pitfalls that cost the most
Five mistakes appear in virtually every post-mortem:
- Validating on samples. Five hundred clean records pass acceptance; the two million real ones, never tested, blow it up in production;
- Confusing valid data with qualified data. A record that is correct in the old system can violate the target model. S/4HANA is the textbook case: MATDOC, ACDOCA and the universal journal do not forgive unshaped reloads;
- Trusting native tools. Standard bridges move records, not structures. The Windchill to 3DEXPERIENCE case shows it: links, BOMs and lifecycles must be rebuilt, not copied;
- Discovering the volumes at load time. Early-project estimates are systematically understated; only measurement protects you;
- Freezing the code too early, the data too late. Data keeps living until cutover day: the chain must absorb the deltas, not suffer them.
08 What it costs, and what it prevents
Dedicated migration expertise runs between €200,000 and €1 million depending on scope. A documented fiasco runs into tens of millions: the expertise represents less than 1% of the cost of a failure. That is the ratio of an insurance premium, except this insurance prevents the incident instead of reimbursing it.
Duration follows the same logic: from a few months to over a year depending on volume and source quality. The audit is what makes the estimate reliable. Answers to the most frequent questions are on the methodology page.