Ask what an ERP data migration involves and you get an answer about volumes: how many records, how many years, how many systems. Volume is the part that is easy to estimate, and it is almost never what decides the schedule.
Migration effort tracks data quality, not record count. A million clean transaction rows move in an afternoon. Four thousand item masters that disagree with each other can hold a go-live for a quarter.
Master data is where it breaks
Transactional history is usually well-formed. It was written by a system, in a fixed shape, and it balances because the old system would not have accepted it otherwise. Master data is different: it was typed by people, over years, across sites, under deadline. Nothing validated it against anything.
The failures repeat across manufacturing and distribution engagements:
- The same material under several codes. One plant calls it one thing, another calls it something else, procurement has a third code from a supplier catalogue. Consolidated stock is then wrong in a way no report reveals, because each site's own numbers look right.
- Units of measure that do not reconcile. Kilograms in stores, tonnes in planning, pieces or coils in dispatch, with conversion factors held in someone's head or in a column that was never maintained. Every valuation downstream inherits the error.
- Vendor and customer masters missing what the new system requires. No tax registration, addresses in a single free-text field, duplicates created because search did not find the existing record. The old system tolerated it; a system that files returns cannot.
- Opening stock that has never matched the physical count. The gap was absorbed for years by a monthly adjustment nobody questioned. A migration makes it a number that has to be explained.
- Rules encoded as exceptions. A customer category with different rounding, a tax treatment changed in a prior year and implemented as a special case. These live in the data rather than the documentation, and they surface as mismatches.
None of this is a discipline failure. It is what happens when a system is used for a decade by people whose job is to keep material moving, not to keep a database normalised.
Why it is found late
The uncomfortable pattern: the first dry run is often the first honest test anyone has ever run against the data.
Before that point, the assessment is based on what the incumbent system reports about itself — and it reports confidently, because it has no reason to flag inconsistencies it was never asked to check. Nobody has previously had to make stores agree with finance to the rupee, so nobody has previously discovered that they do not.
That timing is the whole problem. Found in discovery, poor master data is a scoping input: a cleansing workstream, priced, with an owner. Found in month five, the same finding is a schedule overrun, and it arrives in a steering meeting rather than a proposal.
Profile before you quote
The fix is unglamorous and cheap. Pull a real extract early — not a sample the client prepares, the actual table — and count:
- Duplicate rate on item, vendor and customer masters, matched on description rather than code
- Null rate in every field the new system will make mandatory
- Unit-of-measure consistency for the same material across sites
- Whether opening stock reconciles to the ledger today, before anything moves
- How many distinct codes resolve to the same physical thing
Days of work. It changes the estimate, and it changes it before anyone has committed to a date.
Bring less history than you are asked for
The instinct is to move everything. It is usually wrong.
Open items and balances must come across — they are live. Closed history generally does not need to live in the new schema. It can sit in a read-only archive that satisfies audit and statutory retention without constraining the data model of a system that will run for the next decade.
The cost of bringing it is not storage. It is that every migrated year is a year that has to be reconciled, and reconciliation is the part that consumes the schedule. Moving ten years of closed transactions means proving ten years of them.
Reconciliation is the deliverable
Row counts prove nothing. A migration can move every record and still be wrong — wrong valuation, wrong open balances, a rounding rule applied differently.
What proves correctness is a reconciliation report a finance lead is willing to sign: closing balances, stock valuation and open items agreeing line by line between old and new, with every difference explained rather than netted off. Explained is the operative word. A difference that reconciles to zero in aggregate while individual lines disagree is two errors cancelling, and they will not stay cancelled.
This is why the parallel run matters more than the cutover weekend. Running both systems and diffing every record daily surfaces the undocumented behaviour while there is still time to decide what to do about it.
What it looks like when it goes right
The steel processing group we rebuilt around its actual order-to-dispatch flow had five systems and a wall of spreadsheets, and a finance team that chased production every month for numbers that never matched stores. That disagreement between stores and finance is the data-quality problem, stated in operational terms rather than technical ones.
Eleven months, eight engineers, and the outcomes were measurable in the places the data had been wrong: month-end closing from nine days to two, and a 31% reduction in stock discrepancies. Closing time fell because the reconciliation that used to happen manually every month stopped being necessary — not because anyone worked faster.
The discovery phase for that engagement was four weeks on the shop floor before a single module was proposed. Watching material actually move is also how you learn which codes the operators treat as the same thing regardless of what the master says.
The short version
- Estimate from data quality, not record count.
- Profile a real extract before quoting, not after.
- Migrate open items; archive closed history.
- Make the reconciliation report a signed deliverable, not a status update.
- Parallel-run long enough to find the rules nobody wrote down.
Every one of these is cheaper than the alternative, and the alternative is finding out in month five.