Dirty Data Is What Actually Sinks ERP Go-Lives

Ask a room of executives why their last ERP project struggled and you'll hear a lot about change management and consultants. Ask the people who were actually there at the cutover and they'll usually say the same thing, quietly: the data. Data migration is the least glamorous part of an ERP program and, in my experience, the part that most reliably decides whether go-live is a celebration or a scramble.

The reason is simple. A beautifully configured system fed garbage produces garbage, faster and more confidently than the old system ever did. Duplicate vendors, customers with three slightly different names, open items that were closed years ago, cost centers nobody recognizes — all of it flows into the shiny new platform and immediately undermines trust in it. Once finance stops trusting the numbers, adoption collapses regardless of how good the software is.

Start earlier than feels reasonable

The most common mistake is treating migration as a late-stage technical task — something the integration team handles in the final weeks. By then it's too late to do the real work, which is cleansing. Cleansing isn't a script you run the night before cutover. It's months of profiling the data, finding the duplicates and the gaps, deciding what to keep, and getting the business to make judgment calls a machine can't.

And those judgment calls need business owners, not just IT. Whether two customer records are really the same entity, whether a dormant account should carry over, how far back to bring transaction history — these are business decisions with real consequences, and they can't be delegated to whoever wrote the migration code. When I kick off a program, I want data owners named on day one, from finance and operations, who'll live with these calls. If nobody will own the data, that tells me something worrying about the project before we've even started.

Move less than you think you need

A liberating principle: you probably don't need to migrate nearly as much as instinct says. There's a strong pull to bring everything over "just in case," but every record you migrate is a record you have to cleanse, validate, and reconcile. Open balances and the master data you'll actively use — those must be pristine. Ten years of historical transactions can often live in an archive you can query if you ever need it, rather than cluttering the new system and multiplying your migration risk.

Then there's reconciliation, which is non-negotiable and eats more time than anyone budgets. After you load data into the new system, you have to prove it matches the source — that balances tie out, that record counts reconcile, that nothing silently dropped or doubled. This is tedious and it is essential. A go-live where the opening balances don't reconcile to the closing balances of the old system is not a go-live. It's the start of an investigation.

Run at least a couple of full mock migrations before the real one. Each rehearsal surfaces problems — a broken mapping, a data-quality issue, a reconciliation gap — while they're still cheap to fix. Teams that rehearse walk into cutover weekend calm. Teams that wing it discover on Saturday night that a field they never checked is empty for forty percent of records.

Clean data isn't the exciting part of an ERP program. It's just the part that determines whether the rest of the work pays off.