ERP
Run the Migration Three Times Before You Trust It
A migration that has been rehearsed once has been tested under conditions that will never recur. The third run is where the real defects surface.
Migration plans usually allow for one dress rehearsal. That is enough to prove the scripts execute and nowhere near enough to prove the data is right. The first run finds the crashes, the second finds the mapping errors, and the third finds the problems that only appear at full volume with real history.
What each run is for
• Run one — does it complete? Expect failures on encoding, field lengths, required fields and referential integrity.
• Run two — is it correct? Reconcile totals, spot-check records, and have business users look at their own data.
• Run three — is it operable? Full volume, timed end to end, executed by the people who will actually do it on the night.
The third run is the one that gets cut for schedule reasons, and it is the one that tells you whether your go-live window is realistic.
Reconcile on control totals agreed in advance
Decide with finance and operations, before the first run, exactly which totals must match and to what tolerance. Record counts by entity, sum of open receivables, sum of inventory value by location, count of active suppliers. Agreeing the target afterwards turns every discrepancy into a negotiation.
A migration signed off on a sample has been tested on the records that happened to be easy.
Migrate history deliberately, not by default
'Bring everything across' is a decision made by not deciding. Closed transactions from eight years ago inflate the load window, complicate the mapping and are often better served by keeping the legacy system readable for a period. Decide per entity how much history has an actual use, and write down who asked for it.
Test the reverse case too
Rehearse the rollback. If the load fails at hour six of a nine-hour window, what happens? A documented, tested path back to the legacy system is what lets you make a calm decision at 3am instead of pressing on because there is no alternative.
Freeze the mapping, then freeze it again
Every change to a field mapping invalidates the runs that preceded it. Track mapping changes as versions and require the reconciliation to be re-run after any change to a financial field. Otherwise the sign-off refers to a migration that no longer exists.
Our third rehearsal found the defect that would have broken go-live: a supplier with two active bank records that only conflicted once we loaded a full history rather than a sample.
Reconciling by control totals rather than eyeballing records is the difference between a rehearsal and a demo. We agreed the totals with finance in advance so there was no arguing about the target afterwards.
Timing the run is the bit people skip. Ours took nine hours in rehearsal, which meant the go-live weekend plan was fiction until we optimised the two slowest loads.