New software is the visible part of an ERP project. Moving the old data into it is where projects get hurt. Migrations rarely fail because of technology. They fail because of untested assumptions about the data.
Why migrations go wrong
- The data means different things to different people, and the meaning is not written down.
- Duplicates, blanks and inconsistent formats that the old system tolerated break the strict rules of the new one.
- Only the final load is tested, so the first real run happens on launch day.
- There is no agreed way to prove the numbers match, so disputes begin after go-live.
- The old system stays in use while the project runs, so the data keeps changing.
Decide scope first
- Open transactions and current balances always move.
- Master data moves after cleaning: customers, vendors, items, prices.
- History either moves or is archived read-only. Decide by rule, for example the last two fiscal years.
- Inventory moves as of a count date, with quantities by location.
A rehearsal-based method
- Profile every source: counts, blanks, duplicates, odd values. Decide what to clean, what to drop and what to keep.
- Map each field explicitly, including how old codes translate to new ones, and build an ID crosswalk. The business signs off on the mapping.
- Define merge rules for duplicates before loading, not while loading.
- Write the migration as repeatable scripts, not manual steps.
- Run it on a copy and reconcile against control totals.
- Fix the causes of mismatches in the scripts and run again. Two full rehearsals is a good minimum.
- Plan the cut-over: a freeze window, a final delta load and a rollback point.
Control totals to reconcile
- Customer, vendor and item counts.
- On-hand quantity and value by item and by location.
- Open sales order and purchase order lines and values.
- Receivable and payable aging by customer and vendor.
- Trial balance at the cut-over date.
Name the people who sign off
Finance signs the balances, operations signs stock and open orders, and the project owner signs the go decision. Agree the roles and the checklist before the first rehearsal.
The reconciliation test that counts
Run a month-end close in the new system in parallel with the old one. If the two produce the same reports, the migration is sound.
When to roll back
If reconciliation fails on the day and the difference cannot be explained, roll back and reschedule. Going live on numbers you cannot defend costs more than a delay.