Your ERP Go-Live Won't Fail on the Software. It Will Fail on the Data.
The most underestimated workstream in any ERP project is the one nobody wants to own — and it's where the money quietly leaks out.
By Rodolfo Kong | ARMKU LLC | May 2026
I once watched a go-live unravel three weeks after the celebration. The new system was fine. The training was fine. The consultants had packed up and sent their final invoice. Then the warehouse team tried to ship against a purchase order and the quantities didn't match. Then a customer was billed twice. Then a vendor showed up under three slightly different names, each with its own balance. Nobody had touched the software. The software was doing exactly what it was told. The problem was what we had carried into it.
That is the part of an ERP project almost everyone underestimates, and it has very little to do with the technology you pick. You can run Odoo or SAP or NetSuite — the platform is rarely the thing that sinks you. What sinks you is the box of records you drag from the old world into the new one without stopping to ask whether those records were ever true.
The lie we tell ourselves at kickoff
Every ERP project starts with the same quiet assumption: "Our data is mostly clean. We'll just move it over." I have never once seen that assumption survive contact with reality. The customer master has dead accounts from 2014. The item list has four spellings of the same SKU. Three departments have been keeping their own shadow spreadsheets because they stopped trusting the system years ago. None of that is a software problem. It is a data problem wearing a software costume.
And here is the uncomfortable truth: the new ERP doesn't fix bad data. It accelerates it. A clean system makes good decisions faster and bad decisions faster, because it trusts what you fed it. Migrate garbage on Friday and you get automated, beautifully reported, fully integrated garbage on Monday.
What the data actually says
This isn't a hunch from one bad week. The numbers back it up, and they're worth sitting with.
According to Panorama Consulting's 2025 ERP Report, more than a quarter of organizations exceeded their implementation budget — and when you look at why, technical and data issues land in the top three causes at 34%, right alongside underestimated staffing (38%) and scope creep (35%). The average implementation in that study runs around $450,000. A third of the projects blowing past that number are doing it, in part, because the data was harder than anyone admitted at kickoff.
Zoom out from the project to the business and it gets worse. Gartner's research puts the cost of poor data quality at an average of $12.9 million per year, per organization — a figure from its 2020 study that the industry still cites today because nothing has made it smaller. And MIT Sloan Management Review, working with Cork University, estimates companies lose 15 to 25% of revenue annually to bad data. That's not a reporting inconvenience. That's a quarter of your top line walking out the door because the numbers underneath the decisions can't be trusted.
Now put those two facts side by side. Data quality is already costing you every single day. An ERP migration is the rare moment you have everyone's attention, a budget, and a deadline to actually fix it — or the moment you pour the existing mess into a faster machine. Most projects choose the second one without ever deciding to.
The operator's read
After enough of these, you stop seeing data migration as an IT task and start seeing it as the real project. The configuration, the workflows, the training — those are knowable. They have a finish line. Data is the part with no bottom until you go looking. It is also the only part that, done wrong, keeps billing your customers twice long after the consultants are gone.
The teams that get this right treat migration as its own project with its own owner, not a checkbox in week ten. The teams that get it wrong treat it as a copy-paste and find out — three weeks after the party — that copy-paste was never the job.
The operational translation
If your go-live is on the calendar, here is where I would put the energy, in order:
- Profile before you plan. Pull a real count of duplicates, blanks, and dead records in your masters now, before anyone commits a migration date. You cannot schedule what you haven't measured.
- Cleanse in the old system, not the new one. Fixing data after cutover means fixing it under production pressure, with live transactions on top of it. Clean at the source while the stakes are lower.
- Dry-run the full migration — twice. Load into a test environment, then reconcile record counts and control totals against the source. If the dry run surprises you, that surprise was free. The one at go-live is not.
- When a field is uncertain, leave it blank. A null you can see and fix beats a confident-looking wrong value you'll never catch. Silent beats wrong, every time.
- Reconcile after cutover like you mean it. Tie out open balances, inventory, and AR/AP against the legacy system before you trust a single report.
None of this is glamorous. None of it shows up in the demo. All of it is the difference between a go-live you celebrate and a go-live you survive.
If your ERP project is on the horizon — or already wobbling — the data migration is the conversation worth having early, not the one you patch at 2 a.m. during cutover weekend. That's exactly the work we do with clients at ARMKU: making sure the system you switch on is fed something worth trusting. If that's on your mind, let's talk before the date gets set.