The hour-by-hour cutover runbook from T-72h to T+24h, the cutover-state matrix that says exactly what is open, closed or frozen at every stage, four-corner reconciliation against real IFS screens and D365 reports, and the governance and hypercare model that carries a programme from go-live to steady state.
Chapter 2 built the engine that moves and reconciles data. This chapter is about the weekend the engine actually runs for real — the moment IFS goes read-only, D365 goes live, and a programme has to prove, row by row and to the cent, that what left one system is what arrived in the other.
The cutover-state matrix is the operational checklist for the financial migration: for every category of data, what its IFS state is, how it loads into D365, and the specific reconciliation contract that must pass before the load counts as accepted. A representative slice:
Cutover runs inside a fixed 24-hour window: it opens with an IFS read-only freeze and closes with F&O open for production business. All eight waves execute sequentially inside that window, each gated by reconciliation. An example extract of the T-offset runbook:
Each wave in the runbook is not complete when its data lands — it is complete when its reconciliation gate passes. Every wave emits a reconciliation report, stored both as a Lakehouse table and a PDF artefact, with one row per canonical concept carrying the IFS count, silver count, gold count, F&O post-load count, the delta between IFS…
Four-corner reconciliation compares IFS source, the engine's own snapshots, and F&O's post-load state on four dimensions — row count, sum-of-amount, sum-of-quantity and key coverage — and it is worth naming the specific screens and reports on each side rather than leaving it abstract:
This is where an IFS-sourced migration diverges most sharply from migrations out of transaction-only source systems, because IFS's centre of gravity is project- and asset-centric — a heavier share of the customer's financial truth than usual is sitting inside work orders and project structures rather than plain AR/AP.
Rollback and restart are not the same tool, and conflating them under time pressure is one of the more expensive mistakes a cutover bridge call can make.
Chapter 2 covered the engine's own dry-run cadence (Dry 1/2/3). This is the customer-facing layer that sits above it, and it runs as a genuine ladder rather than a single event:
Cutover governance works because every workstream has an unambiguous accountable owner, not because a single steering committee tries to hold everything at once:
The cutover state matrix says what must be closed, frozen, migrated or manually handled. It is not a status slide; it is the load contract for the weekend.
Cutover weekend is where every earlier design decision gets tested against real numbers under real time pressure. The cutover-state matrix says, row by row, what is frozen, what is open and what reconciliation contract has to pass; the T-offset runbook turns that into an hour-by-hour choreography with named freezes and named gates;