Cutover window, four-corner reconciliation, and hypercare
The hour-by-hour mechanics of go-live — what freezes and when, the T-offset timeline, the reconciliation gate that closes each wave, four-corner financial reconciliation with actual reports and tolerances, AX-specific validation scenarios, go/no-go criteria, what rollback really means once the first transaction posts in D365, how an AX upgrade's rollback differs from a re-implementation's, and the hypercare model that carries the programme to handover.
What you will be able to do
Read and build a cutover-state matrix showing what is open, frozen, or loading at every stage
Trace the T-offset timeline from T-72h preparation through T+24h hypercare start
Name the four corners of financial reconciliation and the AX report paired with each D365 report
State what rollback means before, during, and after the blackout window — and why it stops being meaningful after the first D365 transaction posts
Distinguish the rollback story for an in-place upgrade from a reshape
Describe the hypercare model: staffing, severity ladder, exit criteria, and handover to run
Introduction
The cutover window is the programme's most constrained period. Everything the team has built, tested, and rehearsed converges into a fixed number of hours during which the organisation transitions from AX 2012 to D365 Finance and Operations.
The cutover-state matrix
The cutover-state matrix tracks, per object class and per stage, what is possible in each system. It replaces institutional memory with an explicit, auditable record.
The T-offset timeline
The T-offset timeline is the hour-by-hour runbook for the cutover window. All times are relative to T-0 (cutover start). The durations below are planning assumptions — each must be validated by mock cutover at production volume.
The reconciliation gate
Every wave ends with a reconciliation gate. The gate must pass before the next wave starts. This is not advisory — the engine (Route B) or the validation process (Route A) refuses to advance while the gate is in FAIL state.
AX-specific validation scenarios
In addition to the four-corner reconciliation, the following AX-specific scenarios must be validated during every rehearsal and at cutover:
Go/no-go criteria and rollback
The go/no-go decision is made at T+22h to T+23h by the programme director, with input from the migration lead, customer CFO, and customer programme sponsor. The decision is binary: go (open D365) or no-go (invoke rollback).
Mock cutovers: three rehearsals of increasing fidelity
Scope: subset of data (one legal entity, representative master data, one wave of open items). Purpose: validate extraction, transformation, and DMF submission mechanics. Catch format errors, entity-mapping gaps, and staging-validation failures early and cheaply.
The hypercare model
Hypercare is the time-boxed period of elevated support between go-live and formal handover to the run organisation. It is not business-as-usual support — it is a deliberately heavier, shorter model designed for the elevated defect rate and severity that characterise the weeks immediately after cutover.
Knowledge check
Summary
The cutover window is the programme's highest-risk period. Everything converges: the migration engine, the reconciliation discipline, the go/no-go governance, and the human judgment that decides whether to open D365 for business.