Why Data Migration Sinks More ERP Projects Than Bad Software Does

A mid-size building products distributor set its ERP go-live date for a Monday in March. By the following Thursday, the CFO had pulled the plug and rolled the entire company back to the legacy system for six weeks. The software worked fine. The problem was that the customer master carried 4,300 records for what turned out to be roughly 2,600 actual customers, duplicates created over a decade of reps entering "ABC Corp," "ABC Corporation," and "ABC Corp." as three different accounts, each with its own pricing history, credit terms, and open balances that didn't reconcile. Nobody had assigned a single person to own cleaning that up before cutover, and it surfaced in production instead of in testing. That's not a software failure. That's a data migration failure, and it's the pattern that derails more ERP projects than any bug, outage, or vendor shortcoming ever does.

The three failure patterns

Garbage-in data nobody cleaned

Every legacy system accumulates a decade or more of small sins: duplicate customer and vendor records, item numbers that mean one thing in the warehouse and something slightly different on an old price list, inconsistent units of measure, addresses that were never updated after a customer moved. None of that data is dramatic enough on its own to justify a cleanup project while the legacy system is still limping along, until it all gets loaded into a new system that enforces referential integrity and validation rules the old spreadsheet-adjacent system never did. A duplicate customer record isn't just cosmetic once the new system starts calculating credit exposure or commission against two separate accounts that should have been one.

Ownership ambiguity between IT and the business

Ask most project teams mid-implementation who's accountable for data accuracy, and you'll get two different answers depending on whether you ask IT or the business side. IT typically owns the extraction, transformation, and load — the technical mechanics of moving data from system A to system B. But IT usually can't tell you whether "ABC Corp" and "ABC Corporation" are the same customer; only someone in sales or credit who's worked those accounts for years can make that call. When nobody explicitly assigns business-side ownership for validating that migrated data is actually correct, not just successfully loaded, the gap gets discovered by whoever hits it first in production, usually a customer, on an invoice, at the worst possible moment.

Underestimated timeline

Data migration gets scheduled like a technical task — a few weeks near the end of the project, after configuration is done and before go-live — when in reality data cleansing needs to start on day one, in parallel with everything else. A common project-plan mistake: treating "migrate the data" as one line item with a two-week duration, instead of recognizing it as a workstream that runs the length of the entire project, with cleansing starting in discovery, multiple test loads happening during configuration, and a final rehearsal cutover happening well before the real one. Teams that start data work in week one of a six-month project are in a fundamentally different risk position than teams that start it in week eighteen.

This is a governance problem, not a technical one

The instinct is to treat data migration as an IT deliverable that shows up on a project plan next to "configure approval workflows" and "set up user roles," one line among many, owned by the technical team, tracked like any other task. That's the mistake. Data migration risk needs to sit on the steering committee's own risk register, with an executive sponsor who reviews it directly, because the consequences of getting it wrong aren't technical, they're operational and financial. Wrong customer credit data means orders ship to accounts that shouldn't get credit. Wrong item costs mean margin reporting is wrong from day one. Wrong open-balance data means the first month-end close after go-live doesn't tie out, and finance spends weeks reconciling instead of closing the books.

A steering committee that treats data migration as "IT's problem to solve" finds out it was everyone's problem, at go-live, when it's most expensive to fix. A steering committee that treats it as a standing governance item, reviewed with the same seriousness as budget and timeline, catches the gaps while there's still time to slip the date instead of shipping known-bad data into production.

What leadership should actually own

None of this requires executives to learn field mapping or ETL tooling. It requires a small number of governance mechanisms, owned at the leadership level, that create visibility before go-live rather than after:

• Named business data owners per domain. One accountable person for the customer master, one for the vendor master, one for the item master, one for the general ledger and open-balance data, each with the authority to say "this record is wrong" and the responsibility to get it fixed, not just flagged.
• A data quality scorecard reviewed monthly by the steering committee. Simple metrics: percentage of customer records passing duplicate checks, percentage of items with complete required fields, count of open transactions still unmatched between old and new systems. Trending in the wrong direction two months before go-live is a signal to act, not a footnote in a status deck.
• At least one full mock cutover rehearsal, with a formal sign-off. Migrate real data into a test environment on the same timeline and process planned for the actual cutover, then have business owners, not just IT, validate the results and sign off before the real date is confirmed.
• A go/no-go gate tied to defined data quality thresholds, not just schedule pressure. Decide in advance what "good enough to go live" means numerically, for instance fewer than 0.5% of active customer records failing validation, and 100% of open AR and AP balances reconciled to the legacy system. Without a pre-agreed threshold, the go/no-go conversation degrades into "we're already behind, let's just go" under deadline pressure, which is exactly how the building products distributor ended up rolling back six weeks into production.

That rollback cost the distributor roughly seven weeks of dual-running both systems, a delayed month-end close, and a noticeable dent in the project team's credibility with the rest of the company, all avoidable with a mock cutover and a named data owner for the customer master three months earlier. The cost of a botched go-live rarely shows up as a single line item; it shows up as weeks of duplicated effort and downtime that's worth quantifying up front rather than discovering after the fact, which is exactly what a downtime cost calculator is useful for during project planning.

Signs the data workstream is already off track

A steering committee doesn't need to audit spreadsheets to know when data migration risk is building up. A handful of signals, visible from a status report alone, are worth pressing on directly rather than accepting at face value:

• The data migration line item on the project plan hasn't changed status in three consecutive weekly updates. Data cleansing is iterative work that should show visible progress week over week; a status that reads "on track" identically for a month usually means nobody's actually looking closely.
• No business stakeholder can name the current duplicate-record count for customers, vendors, or items. If that number isn't known, it isn't being measured, and if it isn't being measured, it isn't improving.
• The mock cutover keeps slipping. A rehearsal cutover getting pushed once is normal. Getting pushed twice, this late in a project, usually means the team already suspects the data isn't ready and is avoiding the moment that would prove it.
• "We'll clean it up after go-live" becomes a recurring answer. Some cleanup genuinely can wait. When it becomes the default answer to every open data question in the final month, it's a sign the timeline is driving the decision rather than the data quality bar the project agreed to earlier.

Any one of these on its own isn't necessarily a crisis. Two or more showing up in the same status cycle, close to a go-live date, is exactly the pattern that preceded the building products distributor's rollback, and exactly the point where a steering committee has genuine leverage to slip the date instead of absorbing the cost of a failed cutover.

None of this is a walkthrough of field-mapping mechanics or cutover scripting, that's a separate, tactical discussion. This is about the smaller number of decisions leadership actually needs to make: who owns the data, how its quality gets measured before go-live, and whether the team is willing to hold the date when the numbers say it isn't ready.