Data Migration Is Where ERP Projects Actually Die

The demo goes beautifully. The training sessions go well. Then someone tries to move eight years of transaction history out of four systems that never agreed on what a customer ID was. Data migration is consistently where ERP implementation plans make contact with organizational reality — and where the gap between what was promised and what’s possible becomes impossible to ignore.

Data migration occupies a specific place in the ERP implementation failure story: it’s the problem that everyone knows about and almost no one budgets for adequately. Implementations routinely allocate 10–15% of the project budget to data migration and then spend 30–40% of it in reality.¹ The underestimation isn’t ignorance. It’s optimism that doesn’t survive contact with the actual data.

What the data looks like before migration

The starting point for almost every ERP migration is messier than the implementation scope document assumes. Business data accumulates over years in systems that were configured by different people with different conventions. Customer names are entered differently across systems. Account codes were renumbered at some point and the old codes were never cleaned up. Transactions were posted to summary accounts rather than detailed ones because someone was in a hurry. The description fields contain freeform text that was meaningful to the person who entered it and is meaningless to anyone trying to use it for categorization.

Beyond the quality issues, there are structural issues. The data model in the old system and the data model in the new system rarely map cleanly. A CRM that stores contacts and companies as a flat list doesn’t translate directly into an ERP that expects a formal party hierarchy. A billing system that generates invoice numbers with a different format than the target system creates a choice: migrate the old numbers and manage two numbering conventions in the new system, or renumber and lose the traceability to the old records.

The three categories of migration risk

Data migration risk generally falls into three categories.

The first is completeness risk: the risk that records are missed in the migration and the new system opens without a complete picture of outstanding obligations, open invoices, or historical transactions. Completeness is validated by comparing counts and totals between source and target — but this works only if the source data is reliable enough to produce meaningful counts and totals.

The second is accuracy risk: the risk that records migrate but migrate incorrectly — wrong amounts, wrong accounts, wrong period assignments, wrong customer associations. Accuracy is validated by sampling, but sampling catches errors proportional to the sample size, and a 10% sample that finds no errors doesn’t guarantee the remaining 90% are clean.

The third is cutover timing risk: the risk that the migration itself takes longer than planned, leaving a window between when the old system is frozen and when the new system is live. Every day in that window is a day when financial transactions can’t be processed normally, which is potentially a day the business can’t invoice, collect, or pay. Cutover timing plans that seem conservative often aren’t, because they assume data quality and technical performance that the actual migration doesn’t deliver.²

What good migration planning looks like

The single most important practice in data migration is starting early. Not “start the migration in the last three months of the project” — start the assessment in the first month. What exists in the source systems? What is the quality? What is the expected effort to clean, transform, and load it? The answers to those questions inform the scope, the timeline, and the budget in ways that can’t be recovered if the assessment happens late.

The second most important practice is establishing a clear definition of “good enough.” Perfect migration is not achievable in any reasonable timeline. The question is: what level of historical accuracy, at what level of completeness, is adequate for the business to operate effectively from day one? The answer differs for transaction history (where some age limits on what gets migrated are often appropriate), for open items (where completeness is critical), and for master data (where quality directly affects operational effectiveness).

Organizations that define these thresholds explicitly, test against them during migration dry runs, and communicate the expected starting state to users land in a much better position than those who discover the quality issues on go-live day.

Sources