Every large program has a workstream that gets the attention. The flashy integration build, the reporting dashboards the steering committee loves to demo, the org-design conversations that fill the room. Data conversion is almost never that workstream. It sits quietly in a corner of the plan, owned by someone junior, measured by a count of objects rather than by truth, and assumed to be a mechanical exercise that the integrator will handle near the end.
That assumption is how go-lives die. In 25 years of large ERP and Workday programs, I've watched conversion sink more launches than every glamorous workstream combined, and it almost always does it the same way. Quietly, then all at once.
And the numbers back up the scar tissue:
Conversion is dangerous because it never announces itself
Conversion is dangerous precisely because it doesn't announce itself. An integration that fails throws an error. A misconfigured business process fails a test and someone logs a defect. Conversion doesn't do that. It slips. A reconciliation that's "98% there" stays at 98% for weeks, and everyone treats the last 2% as a rounding error instead of 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 deliver perfection under the most compressed timeline of the entire program. It surfaces late by design, and late is exactly when you have no runway left to fix it.
Your legacy data is dirtier than you think
Here is the line everyone nods at and nobody believes: your legacy data is dirtier than you think. Not a little dirtier. Materially dirtier, in ways that have been quietly accumulating for fifteen or 20 years while no one was looking.
I have never once seen a source system that was as clean as its owners claimed. What I see instead is the same catalogue of sins 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, country codes that don't exist.
- Open items on the AR ledger that were settled outside the system and never cleared.
The new system will not save you from any of this. A modern ERP is faithful to a fault, it loads exactly what you hand it. If you feed it a terminated employee marked active, you now have a clean, well-architected, fully-supported system with a terminated employee marked active. You have spent millions to reproduce your old mess on a new platform, and you've done it faithfully.
Field tip: cleanse at the source, not in flight. Fixing a record in the legacy system fixes it everywhere it lives. Fixing it in the conversion rules is a patch. Fixing it after go-live, inside the new system, is the option that quietly becomes permanent. Start cleansing before the first mock, with a named business owner per data domain and a log reviewed weekly.
Conversion is reconciliation, not loading
This is the reframe that separates programs that make it from programs that scramble. Loading data is the easy part. Anyone can run an inbound and watch a success count climb. The real work, 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.
That means trial-balance to trial-balance. Subledger to subledger. Headcount to headcount. Open AR in the legacy system tied out, to the penny, against open AR in the new one. Not "looks about right." Reconciled, with the variances explained and signed off by someone who owns the number.
Data conversion isn't a task you finish. It's a reconciliation you keep passing until go-live, and the day you stop passing it is the day you stop being ready.
If you cannot reconcile it, you have not converted it. You've moved it. Those are different verbs, and the gap between them is where post-go-live finance teams lose their first 3 months chasing balances that should have been chased in a test cycle.
Convert early and convert often
The single biggest mistake I see is treating conversion as an event, one big load at the end, rehearsed maybe twice, and prayed over. Conversion is not an event. It's a rehearsal you run again and again until the performance is boring.
Every mock conversion is a dress rehearsal for the real thing, and its job is to fail in useful ways. The first one will be ugly. Records will reject, balances won't tie, mappings you were sure of will turn out wrong. That's the point. Each pass surfaces problems while you still have the runway to fix them, to clean the source, refine the mapping, and tighten the reconciliation, instead of discovering them at two in the morning on cutover weekend.
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 hold it up in 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.
Who owns the data
Let me be blunt about accountability, because this is where programs quietly hand off the one thing they can't afford to outsource. The business owns data quality. Not the integrator, not IT, not the conversion lead. The business.
The integrator can build the pipeline and run the loads. IT can stand up the environments. But only the business can decide whether two customer records are the same company, whether a dormant cost center should be archived or migrated, whether an open item is a real receivable or a ghost. Those are judgment calls about the meaning of the data, 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. When a program treats cleansing as something the technical team will sort out, two things happen: 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.
Field tip: the ownership fix costs nothing. On one program this year, finance and procurement loads kept failing during conversion. The software was fine. No single person owned the validation rules across the modules, so every team assumed another had it. We named one owner and gave each open item a date, and the failures stopped. The cheapest fix on the whole program.
Field tip: convert less. You do not have to bring everything. Default to open balances and active master data, and leave closed history in a read-only legacy archive that retention rules can govern. Every object you cut from scope is one less mapping to design, one less reconciliation to pass, and a smaller load on the one weekend where time is most expensive.
It all comes due on cutover weekend, under a clock
All of this comes to a head on cutover weekend, when the final load runs for real, under a clock, with the business waiting to transact Monday morning. If you've rehearsed honestly, this is the boring night you earned. If you haven't, this is where the unrehearsed surprises arrive with no time left to absorb them.
And the converted data doesn't stop at the ERP boundary. Your reports read from it. Your data warehouse is fed by it. Downstream systems, banking, tax, consolidation, the dozen integrations that assume the data is right, all inherit whatever you loaded. A reconciliation error you wave through on Sunday becomes a wrong number in a board pack, a failed bank file, a tax filing built on a balance that was never true. The blast radius of bad conversion is the entire downstream estate, and most of it won't show up until the first close.
Field tip: hold a real data-readiness gate. Before the production load runs, confirm three things in writing: cleansing reached the agreed level, every conversion package runs clean, and configuration is loaded. Then make an honest go or no-go call. The production conversion should be your final mock, run one more time. If the first clean reconciliation on your program happens on cutover weekend, you built the plane in the air.
Nobody throws a party for clean data. There's no demo for a trial balance that ties, no applause for a reconciliation that passes for the fifth time. That's exactly why it gets underfunded, and exactly why it's the cheapest disaster you'll ever prevent and the most expensive one you'll ever discover late. Pay for it in test cycles, where it's measured in rejects and tie-out percentages, or pay for it after go-live, where it's measured in your finance team's credibility. Those are the only two options. Choose the cheap one.
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).