Ask a steering committee why an ERP go-live slipped and you will hear about scope or testing. Look closer and the root cause is almost always data: masters never cleaned, duplicates that multiplied under a new key, and balances that will not reconcile to the cent. Configuration demos well and gets the budget, so data work stays invisible until the dress rehearsal exposes it, with no room left to recover. In a financial institution a wrong balance cascades into customer impact and regulatory exposure. Run migration like an auditable supply chain, and aim for zero surprises, not zero defects.
Programs fail on data, not configuration
Ask a steering committee why an ERP go-live slipped and you will hear about scope, testing, or change management. Look closer and the root cause is almost always data: masters that were never cleaned, duplicate customer records that multiplied under a new key structure, open balances that would not reconcile to the cent, and historical transactions nobody could vouch for. Configuration is visible and demos well, so it gets attention and budget. Data work is invisible until the dress rehearsal exposes it, which is exactly why it gets under-budgeted, staffed thinly, and left to the final weeks when there is no room left to recover.
In a financial institution the stakes are sharper. A customer record with a wrong risk flag, a sub-ledger that no longer ties to the general ledger, or a reference table with stale product codes does not just annoy a user; it drives incorrect statements, breaks regulatory reporting, and triggers remediation that costs more than the migration itself. The antidote is to stop treating migration as a one-time load and start running it like a controlled, auditable supply chain with checkpoints, evidence, and named owners, where data is a product that is owned, measured, and proven before it ships.
Run this way, migration stops being a single high-risk event and becomes a rehearsed, reversible sequence. The teams that sleep on cutover night are not the ones with zero defects; they are the ones who saw their defects in a dress rehearsal, fixed them, and re-proved the fix at full volume. Everything below is built to move the surprises earlier, into rehearsals where they are cheap, and out of go-live, where they are not.
Gate the migration, wave by wave
Define explicit quality gates by domain and refuse to promote data that has not cleared them. A gate is not a status meeting; it is a set of numbers that either pass or do not, owned by the business, not the program. Load in waves, starting with masters, then open balances, then recent transactions, so that each layer rests on data that has already been proven. Run at least two full-volume dress rehearsals with timed runbooks, because a load that works on a 5% sample tells you almost nothing about the one that has to complete inside a Saturday-night window. The table below shows the shape of a gated plan and the objective evidence that lets a wave pass.
| Wave | Data scope | Quality gate | Reconciliation evidence | Promote when |
|---|---|---|---|---|
| 1. Masters | Customers, suppliers, chart of accounts, items | 98% completeness, zero duplicate keys, validation rules pass | Record counts and checksums vs source | Class-A defects at zero |
| 2. Open balances | GL opening balances, AR and AP aging | Trial-balance parity to the cent | Sub-ledger to GL tie-out signed by finance | Variance is 0 basis points |
| 3. Recent transactions | Open POs and SOs, in-flight postings | Referential integrity to loaded masters | Open-item counts and value reconciliations | Exceptions logged and owned |
| 4. Reference and pricing | Tax codes, pricing conditions, risk flags | Rule coverage 100% on active records | Sample audit vs authoritative system | Business owner sign-off |
| 5. Dress rehearsal | Full-volume replay of waves 1 to 4 | Timed runbook within cutover window | End-to-end evidence pack, checksums, exception log | Two clean full-volume runs |
Consider a mid-market bank migrating 1.2 million customer records and 40 million ledger lines. The first dress rehearsal exposed a 7 basis-point unreconciled variance in AR aging, traced to a currency-rounding rule applied inconsistently at the source. Because the gate blocked promotion, the defect was fixed and re-proven at full volume rather than discovered on day one. That is the difference a gate makes: a rounding rule becomes a rehearsal finding instead of a customer-statement incident. The second rehearsal then timed the full replay end to end and confirmed the cutover fit inside its window with the deltas replayed cleanly. Because every wave carried signed evidence, the go decision was a five-minute confirmation of numbers rather than an argument, and the rollback trigger, an unreconciled variance above 5 basis points, was never in doubt about what it meant.
Run data like a product
- Name a data product owner for each domain (customers, suppliers, chart of accounts, items) and hold them to published completeness, duplicate, and validation thresholds.
- Document golden sources and end-to-end lineage before you build a single transform, so every field traces to an authoritative system.
- Execute at least two full-volume dress rehearsals with timed runbooks, and burn defects down by severity and domain, blocking promotion on any open Class-A defect.
- Build reconciliation packs that finance and operations sign: trial-balance parity, sub-ledger to GL, AR and AP aging, inventory valuation, open orders, and tax codes.
- Define rollback triggers as hard numbers, such as unreconciled variance above a set basis-point threshold, and rehearse the switchback so the team is confident to use it.
Failure modes and the controls that prevent them
- Late discovery of dirty data in the final weeks. Fix: start profiling in week one and publish weekly quality trends so decay is visible early.
- Scope creep on historical data. Fix: migrate only what is needed to run and archive the rest with defined retrieval SLAs.
- Manual reconciliations at 2am on cutover night. Fix: automate the core checks and practice the runbook at full scale before go-live.
- Ambiguous ownership when a defect surfaces. Fix: have the CFO and CIO jointly enforce named data product owners and sign-off criteria.
- A cutover with no way back. Fix: pre-define rollback triggers and keep a blue-green parallel-run option for the highest-risk processes.
Before you call go or no-go
- Every domain has a named data product owner and published quality thresholds.
- Two full-volume dress rehearsals have run inside the cutover window with timed runbooks.
- Reconciliation packs (trial balance, sub-ledger to GL, AR and AP aging) are signed by business owners.
- Rollback triggers are expressed as objective thresholds and the switchback has been rehearsed.
- Open Class-A defects are at zero and every exception is logged and owned.