Every object, every mock and the final load go through the same six steps: extract (customer data owners), map (Migration Conductor and key users), validate (the cockpit’s rules), trial load into non-production (Migration Conductor), reconcile (finance controller), and cutover (Countdown Owner).
Loop until clean. A rejected record goes back to its data owner with the cockpit’s reason code, and the next mock re-runs the whole object. Nothing is ever fixed by hand in the target tenant — that would leave the audit trail describing a load that never happened.
| Run | When | Accept when |
|---|---|---|
| M1 | T-10 → T-9 | Every object loads; rejects below 5% and assigned |
| M2 | T-7 → T-6 | Zero TB delta; sub-ledgers tie; rejects below 0.5% |
| Dry-run cutover | T-4 → T-3 | Zero delta; duration inside the cutover window; runbook updated |
| Rehearsal data | T-2 → T-1 | The rehearsal passes |
| Final | T-0 | Zero delta; the controller signs |
Reconciliation is arithmetic
- Counts and hash totals: extracted = loaded + rejected, per object; hash totals on amounts and quantities.
- Trial balance: legacy balance − TRANXACT balance = 0 for every account, entity and dimension.
- Sub-ledgers: AR ageing, AP ageing, stock valuation and the asset register each equal their GL control account.
The Toolkit’s delta formulas turn red on any non-zero value, and the finance controller signs only when every line is zero, or explained and approved. The cockpit’s run log — who loaded what, when, how many records, how many rejected — is the audit trail they sign against.
Extraction depends on the source
Each source system has its own sheet in the Project Plans workbook. The patterns differ — standard reports and table extracts for large ERPs, saved searches or CSV exports for cloud accounting, XML or Excel exports of ledgers and vouchers for others, cockpit templates filled directly for spreadsheets — and so do the watch-outs: company codes versus entities, segments to dimensions, no validation at source in a spreadsheet. The guide has the full table by product.
The T-0 runbook (illustrative timings)
| Time | Step | Owner |
|---|---|---|
| T-1 18:00 | Last legacy transactions; freeze announced | Countdown Owner |
| T-1 18:30 | Legacy period close; final TB and sub-ledger reports | Finance controller |
| T-1 20:00 | Final extract per object | Data owners |
| T-1 21:00 | Final cockpit load in the dry-run sequence | Migration Conductor |
| T-0 02:00 | TB and sub-ledger reconciliation — delta = 0 | Finance controller |
| T-0 06:00 | Integrations to production endpoints | Ops Pilot |
| T-0 07:00 | Legacy read-only; users enabled; go-live comms | Flight Lead |
| T-0 ≈ 11:00 | First invoice posted in production | Key user, sales |
Every step has a named owner, a planned duration and a rollback note, and the Toolkit calculates planned end times and the variance against the dry run.
Calderwood’s M2 shows 1400 Inventory at 2,450,009.10 in legacy and 2,449,909.10 in TRANXACT: a delta of 100.00, flagged CHECK. The cause is one stock line rejected for a missing lot number. It goes back to the warehouse data owner with its reason code, and the next mock re-runs the whole stock object — nobody keys the line into TRANXACT by hand.
Try it Calderwood’s dry run reconciles to zero but takes 13 hours against an 11-hour cutover window, because the nine P1 period journals load slowly. What does T-Minus say to do?
Reduce scope, not extend the window: move the period data — the P1 journals — to T-Plus and load them after go-live, rather than stretching the cutover. A dry run that does not fit is a fix list, not a slipped date.