The hour-by-hour mechanics of go-live for a Business Central migration — what freezes and when, the final delta capture, four-corner reconciliation with source subledger-to-GL verification before extraction and target verification after load, the signed opening-position reconciliation, a T-minus timeline table, rollback and source reactivation, hypercare staffing and severity ladder, and the role-release model that carries the programme to handover.
What you will be able to do
Build a cutover-state matrix showing what is open, closed, or frozen at every stage
Read the T-offset timeline from BC freeze through hypercare exit
Explain the four-corner reconciliation and the specific BC report paired with each D365 report
State precisely what rollback means before, during, and after the blackout window
Describe hypercare staffing, severity ladder, exit criteria, and role release
Explain why Dimension Set ID must never be used as a target business key during cutover validation
Introduction
Cutover is the window when the programme's design decisions become operational facts. The company decision matrix, the posting-group crosswalk, the dimension mapping, the party identity resolution, the inventory opening strategy — all of these remain reversible until the cutover window opens.
The cutover-state matrix
At any moment during the cutover window, every stakeholder must know: can I still post in BC? Is D365 accepting data? Which wave is running? The cutover-state matrix provides this in a single table.
The T-offset timeline
The timeline below is a reference design. Actual durations must be validated by Mock 3 at production volume.
Four-corner reconciliation
Before any extraction, the programme must verify that BC is internally consistent:
The Dimension Set ID pitfall in cutover validation
This warrants explicit treatment because it is the most common technical error in BC-to-D365 reconciliation design.
Go/no-go criteria
The go/no-go decision is made by the project board at T+23h. It is binary — Go or No-Go — based on seven gates:
Rollback: what it means and when it stops
Rollback is trivial: do nothing. BC continues operating normally. D365 production has only initial configuration, which can be wiped via environment restore.
The hypercare model
Hypercare exists because defect volume and severity are elevated in the weeks after cutover: users encountering new processes, integrations running at production volume for the first time, and period-end processes executing for the first time in D365.
Knowledge check
Summary
Cutover transforms programme decisions into operational reality through a governed sequence of freeze, extraction, wave-by-wave loading, four-corner reconciliation, go/no-go decision, and hypercare. The blackout window is volume-dependent and must be proven by rehearsal.