Why so many ERP migrations fail in production

Most migration projects are planned as a straight line: you scope, you build, you test, you switch over. On paper, it’s reassuring. In industrial ERP and PLM environments, that is precisely what makes them fail.

A migration isn’t finished when the code is written. It’s finished when it has been stabilized through execution.

The problem isn’t the target system

When a migration blows up at the end of a project, the instinct is to blame the target tool. In reality, the target system is rarely at fault. It’s the source data that holds the surprises:

• incomplete or outdated documentation;
• implicit business rules, never written down, sometimes contradictory;
• years of history with exceptions that were never handled;
• real volumes far above the estimates.

None of this shows up in a specification. It only appears at execution time, on real data.

Five causes that show up in every post-mortem

Projects differ; the failure mechanisms repeat. Five come up every single time:

1. The sacrificed audit. The project starts on assumptions because the data audit was reduced to a documentation review. Nobody ever measured the real scope.
2. Migration treated as a technical sub-project. Pushed to the end of the schedule, after configuration and development, it inherits every delay. It therefore discovers the problems last, when nothing is negotiable anymore.
3. Tests run on convenient samples. Five hundred clean parts sail through acceptance. The two million real records, with their duplicates and historical exceptions, never went through it.
4. The tunnel effect of the straight-line plan. Scoping, build, acceptance, cutover: each phase absorbs the previous one’s delay, and it’s always the confrontation with real data that gets pushed back. The tunnel opens at the worst possible moment: Go-Live.
5. A chain that can’t absorb corrections. A monolithic batch fails as a block: one blocking record, and you replay everything. Without a chain designed to isolate and replay errors, every late-discovered anomaly costs a cutover window.

The real risk: discovering it too late

The danger isn’t that discrepancies exist. There will always be some. The danger is discovering them in production, when there’s no room left to correct them and the cost of an error is at its highest.

The longer you postpone the confrontation with real data, the more invisible debt you accumulate. And that debt is paid in full on Go-Live day, in tens of millions of euros in the documented cases (Gifi, Revlon, Hershey’s, Haribo).

Flipping the logic

The alternative is to execute early, on real scopes, and to correct in a loop. Each run becomes a source of learning: it reveals edge cases, surfaces the implicit rules, and allows for gradual stabilization.

That is the principle behind the Run / Fix loops of our methodology: the migration system executes scope after scope, every discrepancy is analyzed, corrected, replayed. Reliability is built iteration after iteration, long before cutover.

How to recognize a migration that won’t fail

A few signs never lie, and they can all be checked well before Go-Live:

• the scope was measured on real data, not estimated in a workshop;
• complete runs are executing within the first weeks, on production data;
• every reject is located, qualified and individually replayable;
• a dry run at real volume has validated the chain end to end.

Going live is then no longer a leap into the void. It’s the last in a long series of executions that have already been mastered. For the full picture (scope, cutover approaches, costs), see our ERP data migration guide.

Complexity doesn’t disappear for all that. But it stops being something you endure: it gets mastered.