Quick answer: ERP data migrations usually fail because of decisions, not software. Nobody owns the data, reconciliation starts too late, duplicates and bad bills of materials are loaded as they are, test loads are rehearsed too few times, and nobody signs the numbers off. The software can load almost any file you give it, which is the problem: it loads the mess faithfully. The fix is mostly work you can start 8 to 12 weeks before cutover.
This guide is about what goes wrong, how to spot it early and what to do about it. I'm a consultant who sells a readiness review for exactly this problem, so weigh my view with that in mind. Everything below is also usable without me.
Every data object needs a named person who can decide. Which of two duplicate customers survives? Which supplier terms are right? Does that dormant item migrate? If the answer is "the project team will sort it out", the questions pile up until cutover week, when nobody has the authority or the time. Start with a master data ownership matrix and fill every row with a name.
If you only compare old and new after the final load, any difference is a crisis. Agree the control totals first: stock quantity and value, open order value, customer and supplier balances, and trial balance. Then check them on every test load, not just the last. A difference you can see in test load one is a task. The same difference at cutover is a delay.
Years of customers, suppliers and items entered by different people produce duplicates, inconsistent units of measure, missing mandatory fields and records nobody uses. A new ERP is often stricter than the old one, so the load rejects them or, worse, accepts them and creates a mess you now own. See finding duplicate records in Excel and part numbering for manufacturing for the practical side.
BOMs and routings are the data manufacturers trust least and need most. Quantities that were never updated, phantom components, routings with obsolete operations and times nobody believes feed straight into costing, planning and shop-floor instructions. If you load them as they are, the new system will plan and cost wrongly, but with more confidence.
Physical stock, system stock and the ledger are often three different numbers. Cost data adds a fourth: the standard or average cost that values the stock. If you load stock at quantities nobody has counted, or values finance can't recognise, your opening balances start in dispute. Agree the stock take date, the valuation basis and who signs the final figure. The finance data migration sign-off pack is built for this.
Which sales orders, purchase orders and jobs migrate, which close out in the old system and which are re-entered? Without a rule, you load half-received orders, part-shipped orders and jobs with partial costs, and the new system cannot process them cleanly. Decide the rule by object and date, and test it.
The first test load is almost always a disaster, and that is normal. It only turns into a problem when there are not enough loads after it to fix what it found. Each rehearsal should finish with a reconciliation and a list of fixes, and the next load should prove that they worked. Time the load as well: a cutover weekend that depends on a load nobody has timed is a guess.
If nobody signs the numbers off, anyone can reopen them. A real sign-off names who signs, what they sign against (the reconciliation, not a feeling) and what happens when a difference is found. Without it, the go-live decision becomes a negotiation on the day.
Sales, margin, backlog and stock value are defined in the old system, often in spreadsheets and old reports. The new system defines them differently, so the numbers don't match after go-live and people stop trusting the system. Agree the definitions and the key reports before cutover, and check that the new system can reproduce them. The post go-live reporting reconciliation checklist covers what to compare.
Two or three of these is normal. Five or more means you should act now. The ERP data readiness check scores them in about five minutes, with nothing sent anywhere.
The ERP data migration checklist covers the same ground as a document you can work through, and the readiness scorecard gives you a spreadsheet version.
If your data is in reasonable shape and you have people with the time to do the steps above, you may not need outside help, and I'd rather you did it yourselves. A review earns its cost when nobody has the time, the sources are messy, or you want an independent view before committing to a cutover date. My Data Readiness Review is a fixed 5 to 10 day piece of work. The deliverables are a source inventory, a data quality issue register, a reconciliation checklist, an owner matrix and a prioritised fix plan.
I led the data migration on a £4m programme that consolidated four legacy ERP systems onto one Infor LN cloud instance for a 220-user manufacturing group, which reported £1m additional revenue and £300k annual savings. The case study has more.
As early as you can, and no later than 8 to 12 weeks before cutover. Data ownership, duplicate clean-up and reconciliation rules take longer than the technical load, and they depend on people who also have a day job.
Unowned decisions. When nobody is named to decide which duplicate wins, which open orders migrate or which stock figure is right, the questions surface at cutover instead of weeks earlier.
There is no magic number. Plan for enough rehearsals that the last one loads cleanly, reconciles to finance and is signed off by the data owners. Two clean rehearsals in a row is a sensible bar for a manufacturer, but your scope may need more.
It can't guarantee success, but it finds the problems while there is still time to fix them. The Data Readiness Review is a fixed 5 to 10 day piece of work that produces an issue register, a reconciliation checklist, an owner matrix and a prioritised fix plan.
Tell me where you are in the plan and I'll say whether a review would help or whether you can do the work yourself. Book a 30-minute data risk call.