I have watched ERP programs pass every gate — process design signed off, integrations tested, users trained — and still miss the go-live. The cause was almost never the software. It was the data. Migration is the silent killer because it fails late, quietly, and in front of everyone.
Here is the pattern I keep seeing. The steering committee tracks build, test and training. Data sits in a spreadsheet owned by "IT" and turns green two weeks before cutover because someone loaded a file without errors. Nobody asked whether the numbers were right. On go-live weekend, the warehouse can't pick because units of measure are wrong, finance can't close because open items don't reconcile, and the CEO wants to know why a EUR 12M project just stopped shipments.
Why data is different from everything else
Every other workstream fails early and loudly. A broken integration throws an error in week three. A confused user raises their hand in training. Data does the opposite. A record can load cleanly and still be wrong — a duplicate vendor, a customer with a lapsed tax ID, a material with a phantom stock quantity. The system is happy. The business is not.
And the volume hides the risk. When you migrate 400,000 material master records, a 2% defect rate sounds acceptable. That is 8,000 broken records — enough to halt procurement across three plants. You do not feel it in a demo. You feel it on day one.
How I de-risk it
I treat migration as its own program with its own plan, not a task inside "cutover." Four things do most of the work.
1. Cleanse at the source, early
Cleansing is not a technical step you do the week before load. It is a business decision about what deserves to move. On my last program we started 20 weeks out and cut the legacy customer master by 38% — dead accounts, duplicates, test records nobody had deleted since 2009. Less data means less to fix, less to reconcile, and a faster load. The rule I give teams: if you would not re-create this record by hand tomorrow, it does not migrate.
2. Mock loads, repeated until boring
One migration rehearsal is a hope. I run at least three full mock loads into a production-like environment, on the real cutover runbook, timed with a stopwatch. Mock 1 is a disaster — expect a 15-20% failure rate and be honest about it. Mock 2 should halve it. By mock 3 you want under 0.5% and a load window you can trust. If you have never done a full dress rehearsal, you do not have a plan. You have a wish.
3. Reconciliation that a CFO would sign
"The load finished with no errors" is not proof. Reconciliation is. For every object I want a control total the business already trusts: number of open POs, total AR balance, inventory value by plant, headcount. Source versus target, to the cent, signed off by the person who owns that number — not by IT. If finance cannot tie the migrated trial balance back to the legacy one, you are not going live, regardless of what the project plan says.
4. Named business ownership
This is the change-management core, and it is where most programs quietly fail. Data quality is a business responsibility that gets outsourced to the project team because it is unglamorous. So I assign a named data owner per object — a real person in the business, not a role on a slide. They approve the cleansing rules, they sign the reconciliation, and their name is on the go/no-go. Ownership changes behavior. When the plant manager knows he personally signs off on inventory accuracy, the mystery stock gets investigated before cutover, not after.
The change-management angle nobody budgets for
Migration is not a data problem wearing a technical costume. It is a trust problem. On day one, thousands of people open a system they have never used and are asked to believe what it tells them. If the first stock figure they see is wrong, you do not lose one transaction — you lose confidence in the whole system. From then on people keep their old spreadsheets "just in case," and you have paid for an ERP that runs in parallel with the shadow IT it was supposed to kill.
Good data on go-live day is not a technical achievement. It is the first promise your new system keeps.
So I say the same thing in every steering committee now: put data on the front page of your status report, give it a name and a face, and rehearse the load until it is boring. Clean data will never win you applause on launch day — no one celebrates numbers that simply add up. But bad data will absolutely end the celebration, usually about an hour after the champagne is poured.
The projects that succeed are not the ones with the best software. They are the ones that treated migration as a leadership problem months before anyone typed a transaction.
Cédric Bignet is an AI & ERP Change Management expert at Novartis and founder of AInspire. He writes about change management, AI adoption and enterprise transformation.