The riskiest moment in an ERP migration is the day you switch everything over at once. The software is rarely the problem. The problem is the plan around it — the cutover that leaves no way back, the data nobody had time to check, and the people who use the system every day finding out how it changed after it changed.
Most of the de-risking happens before any go-live date is set. What follows is the practical work that keeps a migration moving without putting the business on hold while it happens.
A report nobody believes is worse than no report.
Why big-bang cutovers stall
A single overnight cutover assumes every part of the new system is ready on the same weekend — finance, inventory, procurement, reporting, and the integrations feeding all of them. In practice they are never ready together. One module slips, and because there is no fallback, the choice narrows to going live with a known fault or postponing the entire programme.
That is how rollouts stall. The date moves, confidence drops, and the work that was finished starts to age before it is ever used. A migration you can live through is one where a delay in one area does not hold the other areas hostage.
Phasing and parallel running
Phasing breaks the move into stages you can complete, verify and absorb one at a time — by module, by site, or by business unit. Each phase has a smaller blast radius and a clear point where you decide to proceed or hold.
Parallel running takes that further. For a defined period, the old and new systems run side by side on the same transactions, and you compare the outputs. It costs effort — people are doing the work twice — but it is the most honest test you can run, because it checks the new system against reality rather than against a script. Agree in advance what a clean parallel run looks like, so the decision to cut over is a measurement, not a feeling.
- Phase by module, site or business unit — never all at once
- Define an explicit go / hold decision at the end of each phase
- Run old and new in parallel until the numbers agree
- Keep a tested rollback route for as long as it is affordable
The data work people underestimate
Moving data is the part of the budget that quietly doubles. The records in your current system carry years of habit — duplicate suppliers, part numbers that mean different things in different teams, opening balances that were adjusted by hand and never explained. None of that surfaces until you try to load it cleanly somewhere else.
Reconciliation is where this is settled. You agree the figures that must match exactly on both sides — trial balance, open orders, stock valuation, customer and supplier ledgers — and you do not sign off a phase until they do. Plan for several passes: an early one to expose how dirty the data really is, and later ones to prove it has been fixed.
In our experience the data work is the single most under-scoped task in a migration, and the one that decides whether the timeline holds. Treat it as a workstream with its own owner and its own milestones, not as something the cutover weekend will somehow absorb.
Involve the people who actually use the system
The team in the warehouse, the accounts clerk, the person who closes the month — they know the edge cases that no requirements document captured. Bring them in while decisions are still open, not at training a week before go-live. They will tell you which reports are load-bearing, which workarounds the old system quietly depended on, and where a small change breaks a daily routine.
Their involvement also decides whether the new system is trusted. A report nobody believes is worse than no report, because people go back to their spreadsheets and you lose the single source you were trying to build. Earning that trust is slow, and it belongs in the plan rather than after it.
Keep the business running through the change
The business does not pause for your project. Orders still ship, the month still closes, customers still call. A migration plan that ignores this turns the go-live weekend into a crisis.
So plan around the calendar, not against it. Avoid period-end and peak trading for cutovers. Write down who has the authority to halt, what the rollback steps are, and how long the old system stays available as a reference. Decide what good enough to go means before the pressure is on — the threshold is far easier to hold when it was agreed in the cold light of planning.
None of this removes the risk. It makes the risk visible, owned, and small enough to carry.