Data & Integrations
Data conversion: the part everyone underestimates
Why data conversion sinks more go-lives than any other workstream, and how to run it as a reconciliation you keep passing instead of a load you run at the end.
By David Apollon/May 7, 2026, updated July 17, 2026/9 min read
Error rate by mock cycle should fall by half or better each time
The bar I hold: under 2% on the final mock, with Finance reconciling control totals to the dollar.
- Mock 1find the breakage15 to 25%
- Mock 2fix root causes6 to 10%
- Mock 3prove control2 to 4%
- Final mockthe gateunder 2%
- Cutoverthe last mock, rerunabout 0
The short version Judge conversion by what reconciles, because almost anything will load. Rehearse it in mock cycles until the error rate is under 2%, and give the cleanup to the business, with a named owner and a date for every data domain.
Every large program has a workstream that gets the attention: the integration build, or the reporting dashboards the steering committee loves to demo. Data conversion is almost never that workstream. It sits in a corner of the plan, owned by someone junior, measured by a count of objects instead of by whether the numbers are true, and assumed to be a mechanical exercise the integrator will handle near the end.
That assumption is how go-lives die. In 25 years on large ERP programs I've watched conversion sink more launches than every glamorous workstream combined, and it nearly always happens the same way, slowly at first and then all at once.
The outside numbers point the same way. Gartner expects more than 70% of recent ERP initiatives to miss their business goals by 2027, and puts the cost of poor data quality at $12.9M a year for the average organization. One of the largest public ERP programs, the Navy ERP, ran 22 months late, and the U.S. GAO's audit named legacy data conversion.
70%+
of recent ERP initiatives Gartner expects to miss their business goals by 2027
$12.9M
a year, Gartner's cost of poor data quality for the average organization
22months
late on the Navy ERP, where the GAO's audit named legacy data conversion
The biggest mistake I see is treating conversion as one big load at the end, rehearsed maybe twice and prayed over. It should be a rehearsal you run again and again until the performance is boring.
Result sheet: Mock 1Gate: under 2% on the final mock
Mock 1 find the breakage
Error rate15 to 25%
Result Records reject, balances don't tie, and mappings you were sure of turn out wrong.
Every mock conversion is a dress rehearsal, and its job is to fail in useful ways. The first one will be ugly. Each pass surfaces the problems while you still have time to clean the source, refine the mapping and tighten the reconciliation, instead of discovering them at two in the morning on cutover weekend.
Conversion is dangerous because it never announces itself
An integration that fails throws an error. A misconfigured business process fails a test, and someone logs a defect. Conversion just slips. A reconciliation that's "98% there" stays at 98% for weeks, and everyone treats the last 2% as a rounding error when it's the thing that will keep you up the night before go-live.
The slippage compounds because conversion depends on everything else being finished. You can't load until the configuration is stable, the field mappings are locked, and the business has decided what's in scope. So conversion gets squeezed to the end of the schedule, inherits every upstream delay, and then has to be perfect on the most compressed timeline of the program, at the point where there's no runway left to fix anything.
Your legacy data is dirtier than you think
Everyone nods when they hear that, and almost nobody believes it. The dirt has been building up for 15 or 20 years while no one was looking, and I've never once seen a source system as clean as its owners claimed. I see the same list on every program:
- Duplicate customers and suppliers: three records for the same entity, each with a different spelling and a slice of the transaction history.
- Terminated employees still flagged active, because someone updated payroll but never the HR record.
- Cost centers and GL accounts retired years ago that still carry open balances nobody will claim.
- Addresses that were never validated, free text where there should be structure, and country codes that don't exist.
- Open items on the AR ledger that were settled outside the system and never cleared.
The new system won't save you from any of it. A modern ERP is faithful to a fault: it loads exactly what you hand it. Feed it a terminated employee marked active and you now have a clean, well-architected, fully supported system with a terminated employee marked active. You've spent millions to reproduce your old mess on a new platform.
Result sheet: Mock 2Gate: under 2% on the final mock
Mock 2 fix root causes
Error rate6 to 10%
Result Rates fall this fast because you attack root causes between mocks, at the source, with an owner.
Dashed outline: the cycle before
The business owns the data
This is where programs hand off the one thing they can't afford to outsource. The business owns data quality: not the integrator, not IT and not the conversion lead.
The integrator
can build the pipeline and run the loads
IT
can stand up the environments
The business
is the only one who can decide whether two customer records are the same company, whether a dormant cost center should be archived or migrated, or whether an open item is a real receivable or a ghost
Those are judgment calls about what the data means, and they belong to the people who live with the consequences.
Cleansing is a business problem with a deadline. It needs named owners per data domain, a backlog with dates, and the same governance you'd put on any other critical path item. When a program leaves cleansing for the technical team to sort out, the decisions don't get made, and the business inherits the mess on day one and acts surprised. Give it an owner and a deadline, or accept that you've decided not to clean it.
Result sheet: Mock 3Gate: under 2% on the final mock
Mock 3 prove control
Error rate2 to 4%
Result Tie-out is a steering committee metric now, and every variance left has an owner.
Dashed outline: the cycle before
If it doesn't reconcile, it hasn't been converted
Loading data is the easy part. Anyone can run an inbound and watch a success count climb. The work that tells you whether you've converted anything is proving that what landed in the target matches the source of truth, row for row and balance for balance.
Every variance gets explained and signed off by someone who owns the number. If you can't reconcile it, you've only moved it. Finance teams that skip this step spend their first 3 months after go-live chasing balances that should have been chased in a test cycle.
Convert early and convert often
Run mock conversions on a real schedule, with real volumes, against a real reconciliation. Count the rejects. Track the tie-out percentage as a program metric and put it in front of the steering committee next to the build status. A program on its fourth mock with reconciliation at 99.8% is in control. A program planning its first full load 3 weeks before go-live is gambling, whatever the slide says.
The shape matters more than the numbers. A flat line means you're rerunning the load without fixing the data, and a curve that isn't converging puts the date at risk even when the status report is green.
Result sheet: Final mockGate: under 2% on the final mock
Final mock the gate
Error rateunder 2%
Result Under 2%, with Finance reconciling control totals to the dollar.
Dashed outline: the cycle before
Hold a real data-readiness gate, and make the production conversion your final mock, run one more time.
Data-readiness gate Confirmed in writing before the production load runs
If the first clean reconciliation on your program happens on cutover weekend, you built the plane in the air.
Result sheet: CutoverGate: under 2% on the final mock
Cutover the last mock, rerun
Error rateabout 0
Result Nothing turns up on the night that the mocks didn't already find.
Dashed outline: the cycle before
It all comes due on cutover weekend, under a clock
On cutover weekend the final load runs for real, with the business waiting to transact Monday morning. If you've rehearsed honestly, it's the boring night you earned. If you haven't, the surprises you never rehearsed arrive with no time left to absorb them.
The converted data doesn't stop at the ERP boundary, either. Your reports read from it and your data warehouse is fed by it. Downstream systems (banking, tax, consolidation, and the dozen integrations that assume the data is right) all inherit whatever you loaded.
A reconciliation error you wave through on Sunday becomes
Bad conversion reaches the entire downstream estate, and most of it won't show up until the first close.
Nobody throws a party for clean data, and there's no demo for a trial balance that ties, which is exactly why conversion gets underfunded. You can pay for it in test cycles, where it's measured in rejects and tie-out percentages, or after go-live, where it's measured in your finance team's credibility.
Go deeper: the full field guide, Data conversion and integrations: the workstream that decides your go-live, covers scope decisions, mapping design, integration sequencing, and cutover in depth, with a free pre-cutover readiness toolkit (PDF).
Put independent eyes on your program.
If you're betting tens of millions on an ERP program, a candid second opinion is the cheapest insurance you'll buy.