T-Minus: mock loads, reconciliation and the cutover runbook
The six-step Migration Cockpit flow, the mocks and the dry run with their acceptance thresholds, three levels of reconciliation, extraction patterns by source system, and the T-0 runbook hour by hour.
The Migration Cockpit flow
The same six steps for every object, every mock and the final load:
| Step | What happens | Who |
|---|---|---|
| 1 Extract | A legacy extract per object in the cockpit template | Customer data owners |
| 2 Map | Fields and values to TRANXACT entities, accounts, dimensions | Migration Conductor + key users |
| 3 Validate | Mandatory fields, duplicates, references, totals | Cockpit rules |
| 4 Trial load | Into a non-production tenant, repeated per mock | Migration Conductor |
| 5 Reconcile | Counts, hash totals, TB and sub-ledgers vs legacy | Finance controller |
| 6 Cutover | Freeze, final load, sign-off at T-0 | Countdown Owner |
Loop until clean. Rejected records go back to the data owner with the cockpit’s reason code, and the next mock re-runs the whole object. Nothing is fixed by hand in the target tenant.
Every run is logged in the cockpit — who loaded what, when, how many records, how many rejected. That log is the audit trail the finance controller signs against.
Mock loads and the dry run (proposed default)
| Run | When | Scope | Target | Accept when |
|---|---|---|---|---|
| M1 | T-10 → T-9 | All objects, first full load | Find mapping and data-quality issues | All objects load; rejects below 5% and assigned |
| M2 | T-7 → T-6 | All objects, cleansed data | Prove reconciliation | Zero TB delta; sub-ledgers tie; rejects below 0.5% |
| Dry-run cutover | T-4 → T-3 | The full runbook, timed, from a fresh extract | Prove the timings | Zero delta; duration inside the window; runbook updated |
| Rehearsal data | T-2 → T-1 | Rehearsal tenant from the dry-run data | A real business day | The rehearsal passes |
| Final | T-0 | Frozen legacy, final extract | Go-live | Zero delta; the controller signs |
Time every step of the dry run against the runbook. If it does not fit the cutover window, reduce scope — period data to T-Plus, for example — rather than extend the window. A dry run that does not reconcile is a fix list, not a slipped date.
Reconciliation: arithmetic, not opinion
| Level | The proof |
|---|---|
| 1 · Counts and hash totals | Records extracted = loaded + rejected, per object; hash totals on key numeric fields (amounts, quantities) |
| 2 · Trial balance | For every account, entity and dimension: legacy balance − TRANXACT balance = 0, line by line |
| 3 · Sub-ledgers | AR ageing, AP ageing, stock valuation and the asset register each equal their GL control account |
| Account | Legacy balance | TRANXACT balance | Delta | Status |
|---|---|---|---|---|
| 1100 Bank – operating | 1,284,550.20 | 1,284,550.20 | 0.00 | OK |
| 1200 Trade receivables | 3,902,114.75 | 3,902,114.75 | 0.00 | OK |
| 1400 Inventory | 2,450,009.10 | 2,449,909.10 | 100.00 | CHECK |
The delta formulas in the Toolkit’s reconciliation sheets turn red on any non-zero value. The finance controller signs only when every line is zero, or explained and approved.
Extraction patterns by source system (proposed default)
Each source system has its own sheet in the Project Plans workbook with its extraction, mapping and reconciliation steps built in. Product names are their owners’ trademarks and are used for illustration only.
| Source | Extraction method | Watch-outs |
|---|---|---|
| SAP | Standard reports (FBL1N / FBL5N, MB52, S_ALR TB), SE16 table extracts | Company codes vs entities; profit centres to dimensions |
| Oracle | Standard reports, SQL extracts from GL / AP / AR / INV | Multi-org; flexfield segments to dimensions |
| Microsoft | Data management export, configuration packages | Financial dimensions; posting groups |
| NetSuite | Saved searches, CSV export | Subsidiaries; custom segments |
| Sage | Reports and CSV export | Nominal codes; departments |
| QuickBooks / Xero | Report export and API | Classes / tracking categories; simple chart of accounts |
| Tally | XML / Excel export of ledgers and vouchers | Ledger groups; GST data |
| Salesforce (CRM) | Data loader / report export | Accounts, contacts, opportunities, quotes only |
| HCM / payroll | Reports / API | Employee YTD; pay elements; confidentiality |
| Spreadsheets and custom systems | Cockpit templates filled directly | No validation at source; extra cleansing |
Confirm extract access for every source in pre-flight. A source that can only be extracted by a third party needs that party booked for M1, M2, the dry run and T-0.
The cutover runbook, T-0 (illustrative timings)
| Time | Step | Owner | Check |
|---|---|---|---|
| T-1 18:00 | Last legacy transactions; business freeze announced | Countdown Owner | Comms sent |
| T-1 18:30 | Legacy period close; final TB and sub-ledger reports | Finance controller | Reports archived |
| T-1 20:00 | Final extract per object into cockpit templates | Data owners | Counts logged |
| T-1 21:00 | Final Migration Cockpit load in the dry-run sequence | Migration Conductor | Rejects = 0 |
| T-0 02:00 | TB and sub-ledger reconciliation | Finance controller | Delta = 0 |
| T-0 06:00 | Integrations switched to production endpoints | Ops Pilot | Test messages OK |
| T-0 07:00 | Legacy set read-only; users enabled; go-live comms | Flight Lead | Logins OK |
| T-0 ≈ 11:00 | First invoice posted in production | Key user, sales | KPI recorded |
Every runbook step has a named owner, a planned duration and a rollback note. The Toolkit sheet calculates planned end times and the variance against the dry run.
Values marked proposed default are the methodology’s recommended starting points. Confirm each one per engagement; the contract, order form and SLA prevail.