Across the 41 stalled implementations we have been called into, data that turned out to be worse than anyone knew was the primary cause in 24% of them. That sample skews toward severe failures — people call us when a project is already in trouble, not when it is merely uncomfortable — and the full method is on the failure-modes page. The number is not the interesting part anyway. The timing is.
In almost every one of those cases the problem was found during the load. Not during selection, not during the diagnostic, not during design. During the load, which is to say after the contract was signed, after the design was agreed, and after a go-live date had been communicated to people who would be annoyed by it moving. This is the shape ERP data migration risk always takes: the danger was never in the software, it was in master data nobody had verified.
Why it surfaces so late
Looking properly at your own data is unglamorous, unbudgeted and mildly humiliating, and no phase of a typical implementation forces anyone to do it. The diagnostic looks at process. The design looks at the target state. Both are conversations about how things ought to work, and neither requires anybody to open the customer master and count how many rows have a country code that is not a country. That is a data cleansing question, not a design question, and nothing before the load forces anyone to ask it.
The load is the first activity that cannot proceed on assumptions. It reads every row. It is also, by design, the last activity before go-live, which means the first honest look at the data happens at the exact moment there is no schedule left to absorb what it finds.
Every implementation plan contains a step where the data is finally examined. In most plans that step is called "cutover".
What actually gets found
Rarely anything exotic. The recurring set, in rough order of how often we see it:
- Duplicate parties that were never duplicates in the old system, because the old system let two records share a name and the new one enforces a key. Merging them is a business decision about which history is real, not a technical one, and it needs someone who can make it.
- Balances that tie in aggregate and not in detail. The trial balance is fine. The sub-ledger supporting it contains entries nobody can attribute. This is the one that turns a two-week load into a two-month one.
- Fields used for something other than their name. A memo field carrying routing instructions, a customer reference holding a project code. Every one of these is a rule that exists only in somebody’s head and has to be discovered by asking.
- History that was migrated once already and carries the scars of that migration — truncated descriptions, dates defaulted to the migration date, a currency column that means two different things either side of a cutover in 2019.
The fix is a destructive dry load, early
The intervention is not better tooling and it is not a longer cleansing phase. It is moving the discovery forward, and the only reliable way to do that is to load everything into a throwaway environment before the design is agreed — not a sample, not the master data, everything, including the transactional history nobody intends to bring across. Treat it as the point where legacy data migration risk gets priced honestly, instead of discovered for free at cutover.
It will fail. That is the point. The failures are a list, the list is the real scope, and having it in week three rather than week twenty-six is the entire value of the exercise. The environment is then deleted, which is what makes it safe to be careless in.
Three things make it worth doing properly rather than as a formality:
- Load the history, even the history you plan to leave behind. The decision to leave it behind is usually revisited once someone from finance discovers what "we will keep it in the old system" means in practice for an audit.
- Count the rows that fail, and keep the count. A cleansing effort with no baseline cannot be shown to have worked, and "the data is much better now" is not a statement anyone should accept before a cutover.
- Give every failure class an owner with a name. The duplicate-customer question is not a data question and cannot be closed by whoever is running the load.
What this costs us to say
A destructive dry load adds two to four weeks to the front of an engagement and produces nothing a buyer can look at. It is the least attractive thing we propose, it makes our timelines longer than the ones we are quoted against, and we have lost work over it.
We propose it anyway, because the alternative is not a faster project. It is the same discovery at a worse moment, which is what the 24% is a record of.
If you are earlier than that — still choosing — the diagnostic questions we ask are in the requirements guide, and what implementations actually cost, from 63 quotes we were shown, is in the pricing study. Neither substitutes for testing go-live readiness against your own data before the schedule locks you into a date.
The same underlying sample shows up elsewhere in how we think about implementations: what happens when nobody can decide stalls a schedule just as reliably as bad data does, what an agent structurally cannot do inside a ledger once it is live, the reference-call questions that would have surfaced a customisation problem before you signed, and why closing faster runs into the same kind of discipline problem after go-live.
The same discipline shows up elsewhere once the data is finally being moved: deciding who owns a field once systems can both write to it, treating a chart of accounts migration as more than an export-and-import exercise, building a rollback condition into the cutover plan rather than just a go-live date, and noticing when a quick custom field quietly becomes system design.