Ask anyone who has lived through a failed ERP go-live what actually broke, and the answer is rarely the software. It is the data. Balances that do not reconcile, customers that exist twice, open purchase orders that were closed years ago, inventory quantities that nobody in operations recognises. By 2009 this was no longer a surprise — it was the most predictable failure in enterprise systems, and it remains so. Data issues are consistently cited among the most common causes of ERP failure, poor adoption and loss of trust in the system, and the reason is structural rather than technical.
Why Migration Is Always Underestimated
Migration looks like a technical task. Extract from the old system, transform to the new structure, load, reconcile. Vendors quote it as a workstream, project plans allocate it a few weeks, and the assumption is that the data is broadly fine because the business has been running on it. That assumption is the disaster. The business has been running around the data, not on it. People know that the third field in the customer record has meant something different since 2004. They know which cost centres are dead. They know that the quantity on hand for certain items is wrong and they check the shelf instead. None of this is written down, and none of it survives an automated extract. Three specific miscalculations recur: Cleansing is counted as an IT task. It is not. Deciding whether two customer records are the same entity, which open items are genuinely collectible, and which items should be discontinued requires people who understand the business — and those people already have full-time jobs. Volume is mistaken for effort. Loading ten million rows is easy. Deciding what the two thousand ambiguous ones mean is the work, and it does not scale with automation. History is scoped late. How many years of transactions come across, at what level of detail, and where does everything else live? Answering this in month seven turns a controlled migration into a crisis.
The Anatomy of a Migration Disaster
The failures follow a script. Discovery happens too late — typically during the first trial load, which is scheduled after design is locked, which means every data problem is now also a design problem. Ownership is unclear, so each dataset falls between the functional lead who owns the process and the IT team who owns the extract. Nobody signs anything off. Reconciliation is defined loosely: "the balances tie" without specifying at what level, against which report, with which tolerance and approved by whom. Then the trial loads get compressed. One rehearsal instead of three, run by the project team rather than the business, on a partial dataset. And the exceptions get deferred. Every migration produces records that will not load cleanly. Left for later, "later" becomes the week before go-live, when the decision is made by whoever is awake. The result is a system that technically works and that finance does not trust. That distinction matters enormously, because a system nobody trusts produces shadow spreadsheets within a month, and then you have paid for an ERP and kept the workarounds.
Profile and assign
Identify data problems and name the business owner for each dataset.
Set the criteria
Agree reports, totals, granularity, tolerances and approvers before loading.
Rehearse and reconcile
Use full-volume trial loads and business-led reconciliation.
Resolve and sign off
Close or explicitly approve owned exceptions before the cut-off.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What Good Looks Like
- Start data work before design, not after. Profile the legacy data in the first weeks: duplicates, nulls, orphans, invalid codes, records not touched in five years. The findings should shape the design, not collide with it.
- Give every dataset a business owner who signs off. A named person in finance owns the chart of accounts and opening balances; a named person in sales owns customer master. Their signature is a gate, not a formality.
- Cleanse in the legacy system wherever possible. It improves current operations, it is verifiable against a live process, and it means the transformation logic handles less mess.
- Decide history deliberately. Open items and current-year transactions in the new system; everything else in a read-only archive with documented access. Migrating ten years of history "to be safe" is the most expensive default in enterprise projects.
- Rehearse at least three times, with the business. Full-volume mock loads, each ending in a reconciliation performed by the people who will perform it for real. Rehearsal quality is the single best predictor of go-live quality.
- Define reconciliation precisely, in advance. Which reports, which totals, which level of granularity, which tolerance, who approves. Write it down before the first load.
- Treat exceptions as a workstream with a burn-down. Track them from the first trial load with an owner and a target date, not as a residual to be resolved under pressure.
- Freeze the legacy system meaningfully. Define the cut-off, restrict changes after it, and document every transaction created in the gap. Uncontrolled drift between extract and go-live creates differences nobody can explain afterwards.
Migrating Personal and Regulated Data
One further dimension has grown since 2009. Migration moves personal data, and it usually moves it into a new jurisdiction, a new provider's infrastructure, or both. That means checking where the new platform stores and processes data, whether test environments will contain real personal data (they should not, without masking), how long the legacy extract files survive on shared drives and laptops, and whether a cross-border transfer mechanism is required. For entities in the GCC and the EU, this is a compliance obligation rather than good practice — and migration files sitting unencrypted on a project share are one of the most common findings in post-implementation audits.
What Has Not Changed
AI tooling now helps with matching, deduplication and anomaly detection, and it genuinely reduces the manual burden. It does not change the underlying problem, because the hard questions are business decisions rather than pattern-matching ones: is this receivable collectible, should this cost centre exist, is this the same customer or two entities that share an address. Those answers come from people who understand the business. Budget for their time, name them in the plan, and start earlier than feels necessary. Every migration disaster is, in the end, a project that discovered its data too late to do anything but rush.
Common Questions
Why do ERP data migrations fail?
Because cleansing is scoped as a technical task and discovered late. The difficult work is deciding what ambiguous records mean, which requires business knowledge and time that projects rarely budget.
How much history should be migrated to a new ERP?
Usually open items and the current year, with older history retained in a read-only archive. Migrating many years of detail multiplies cost and reconciliation effort for benefits most organizations never use.
How many migration rehearsals are needed?
At least three full-volume mock loads, each followed by a reconciliation performed by the business users who will do it at go-live. Rehearsal quality predicts go-live quality better than any other factor.
Who should own data cleansing?
Named business owners per dataset — finance for balances, sales for customers, operations for items — with formal sign-off. IT owns the extract and load mechanics, not the judgement calls.
Migration Readiness Assessment — Outpace profiles your legacy data before design is locked, assigns real owners, and builds the reconciliation and rehearsal plan that keeps finance trusting the numbers after go-live.