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.
On an undocumented legacy system, the audit carries more weight still: the profile of the values is the only specification that survived, and reading it back is most of the work.
05 Big bang, phased, or trickle: choosing your approach
Three cutover strategies exist, and the choice is usually made for the wrong reason: the one the programme plan already assumed. It is worth revisiting once the audit has told you what the data actually looks like.
One clarification before the comparison, because the two get conflated. What follows is about the cutover: when the old system stops and the new one starts. The structural decision comes earlier and is a different question, whether the data enters the target in the target's shape or in yours. That one constrains the cutover, not the reverse.
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 trickle migration keeps both systems live and moves data continuously until the source can be switched off. It is the least brutal and by far the most demanding: it requires bidirectional synchronization and a reconciliation rule for every field that both systems can write.
Comparing the three cutover strategies | Strategy | Typical duration | Rollback risk | Relative cost | Where it works | Where it breaks |
|---|
| Big bang | One cutover window, 24 to 72 hours, after months of preparation | High. Once the source is down, rolling back means restoring and losing the window | Lowest, provided nothing goes wrong | Single site, one source system, business that can genuinely stop for a weekend | Any volume discovered late. There is no second attempt, so an unmeasured scope becomes an outage |
| Phased | Several months, one wave per site, domain or data family | Contained. A failed wave is replayed without affecting the ones already live | Higher: two systems running in parallel, plus temporary interfaces | Multi-site groups, heterogeneous scopes, businesses that cannot stop everywhere at once | Strongly coupled data. If a bill of materials spans two waves, the split becomes artificial and costly |
| Trickle | Continuous, from a few weeks to over a year | Low per record, high on consistency. Both systems hold truth at the same time | Highest: bidirectional synchronization to build, run and eventually decommission | Continuous operations with no acceptable downtime, or a very long coexistence period | Fields both systems can write. Without an explicit arbitration rule, the two truths diverge silently |
06 Why tooling decides more than strategy
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: they are written once, tested on a convenient extract, and discover the real data on the worst possible day.
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. The practical test is simple: how many times can you run the full migration before go-live? With scripts, the honest answer is usually two or three. With a chain, it is as many as the schedule allows, and every run makes the next one cleaner.
That number is the single best predictor of how the cutover will go. A migration executed thirty times is a routine. A migration executed twice is a rehearsal that never got past the read-through.
07 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.
08 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, and the standard toolchain validates structure rather than meaning;
- 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.
09 What it costs, and what it prevents
Dedicated migration expertise runs between €200,000 and €1 million depending on scope. This is an order of magnitude drawn from our own engagements and from publicly reported programme costs, not a price list: the same ERP, migrated at two companies, can sit at either end of that range.
The variable is not the target system. It is the number of source systems to reconcile, the volume of records, and above all the share of that volume that needs a business decision rather than a rule. A scope where 95% of records pass on a deterministic rule costs a fraction of one where 30% need someone to arbitrate.
Against that, the other side of the ledger. Gifi lost roughly €117 million in revenue; Revlon could not fulfil $64 million in orders; Hershey missed Halloween. Those figures are public, and they describe companies that were not short of resources. The real cost of a failed migration puts the expertise well under 1% of the failure it is meant to prevent. That is the ratio of an insurance premium, except this insurance prevents the incident instead of reimbursing it.
A rough way to size your own case before any audit: count your source systems, multiply by the number of master data families you must migrate, and treat anything above fifteen combinations as the upper half of the range. It is crude, and it is still closer than a percentage of the ERP licence, which is how migration budgets usually get set. Our data migration services page sets out what is covered at each phase, and what is not.
10 One case, anonymised: 400,000 parts, two truths
An industrial group, four production sites, migrating a homegrown ERP and two site-level systems to a single S/4HANA instance. The integrator was in place, the functional design was signed off, and the data workstream was scheduled as a two-month task near the end of the plan.
What the audit found. The declared scope was 250,000 active parts. The extraction returned 412,000, because two sites had kept creating records in a legacy system everyone believed had been switched off in 2019. Of those, 61,000 were duplicates across sites: the same physical component with different codifications, different units of measure, and in 9,000 cases different suppliers listed as sole source. No single system held the truth, and no rule could pick a winner: only the site engineers could.
What was corrected. The deduplication was not automated, because it could not be. It was turned into an arbitration workflow: the chain grouped candidate duplicates, presented them with their usage and their stock, and routed each group to the site that owned the part. The engineering effort went into the routing and the audit trail, not into a matching algorithm that would have guessed wrong 9,000 times. In parallel, the unit-of-measure conversions were rebuilt as explicit rules rather than inferred from the target model.
Result. The arbitration took eleven weeks of part-time work from four site teams, which is the number nobody wanted to hear and the reason the go-live moved by one quarter. The migration itself ran twenty-eight full passes before cutover. Go-live weekend loaded 351,000 parts with 240 rejects, all of them qualified and replayed within the window. No production stoppage.
The honest reading of this case is not that the migration went well. It is that the two months allocated to data were wrong by a factor of five, and the audit is the only reason anyone found out while the date could still move.
11 Data migration checklist
The short version, in the order that matters. If you can answer all of these with a measurement rather than an estimate, your plan rests on something.
- Extract every source at full volume, including the systems people believe are switched off. Verify that belief rather than accepting it;
- Count what actually exists: records per family, duplicates within and across systems, orphaned objects, records violating the target model;
- Separate rule from arbitration. Quantify the share of records that need a human decision. This number drives the schedule more than the total volume does, and it belongs in the plan as its own workstream rather than inside a cleansing task;
- Name an owner per data family, on the business side, with the authority to decide. A migration blocked on arbitration is blocked on org chart, not on technology;
- Decide the history scope explicitly, against your retention obligations. An archive is usually ten times cheaper than a migration;
- Build a chain you can rerun, with per-record status and replay. Count how many full passes the schedule allows;
- Test on the real data, never on a sample. A sample validates your code; only the full set validates your rules. What each level of testing actually establishes is covered in what a passing test proves;
- Plan the delta. Source data keeps living until cutover day. The chain must absorb changes made after the last full pass;
- Run a dry run at real volume, with the cutover clock running, on the complete chain including the target load interfaces;
- Define the rollback decision before the window opens: who calls it, on what threshold, and by what time.