A migration is usually planned as an event: a cutover date, a freeze, a long weekend. Events are risky because everything is tested in one moment, with the business waiting. A calmer approach treats migration as a process in which the old and new systems run side by side until the evidence says the new one can be trusted.
The dual-run pattern
- Copy first — move historical data into the new system without changing the old one, and keep syncing changes while both run.
- Shadow the new system — send it the same inputs as the live system and compare outputs, without letting it affect customers or the ledger.
- Reconcile continuously — automated checks compare totals, counts and key fields between the two. Differences become a worklist, not a surprise at cutover.
- Cut over by slice — move one customer group, region or product at a time, with the ability to switch that slice back.
- Retire the old system last — only after a full business cycle, such as a month-end or year-end close, has passed cleanly on the new one.
What reconciliation should check
- Counts — records in versus records out, per entity type.
- Totals — financial sums, balances and quantities, to the cent.
- Samples — a random set of records compared field by field, including awkward ones: long names, missing values, old formats.
- Rules — outputs of key calculations compared on the same inputs, using the characterization tests recorded from the old system.
Decide the acceptable difference before you start. 'Zero unexplained differences' is a clear gate. 'Looks about right' is how migrations end up in a post-mortem.
Where AI helps
Language models are useful for the messy middle: mapping inconsistent field names, standardizing free-text addresses, flagging records that look malformed and explaining reconciliation differences in plain language. They propose; the reconciliation checks and a person decide. The result is a migration the business can watch, pause and trust, which is what lets it keep running while the change happens.