The cutover-state matrix that decides what is open, closed or in-flight at T-0; the freeze calendar and hour-by-hour runbook, including the NetSuite-specific constraint that Oracle's release train cannot be postponed to suit your go-live weekend; four-corner reconciliation in forensic detail, with the specific NetSuite report paired against its D365 equivalent; proving D365 posting profiles reproduce NetSuite's per-item posting accounts before cutover, not after; multi-subsidiary elimination; tolerances, sign-off and rollback; and the RACI, triage and staffing model that carries the programme through hypercare.
Chapters 1 and 2 of this domain built the programme and the engine that moves the data. This chapter is about the day itself — the hours when NetSuite goes read-only and D365 opens for business — and the weeks immediately after it, when the numbers either hold up or they do not.
Every migration touches transactions that are neither fully open nor fully closed at the moment of the freeze — a shipment made but not yet invoiced, a purchase partially received, a production order still in progress.
Each wave in the T-0 to T+18h block is not simply "run and move on" — it closes only when its own reconciliation gate passes (row counts, sum-of-amount, sum-of-quantity and key-coverage deltas all within tolerance, exactly as chapter 2 described for a dry run). A wave with an unresolved reject does not unblock the next one;
The reconciliation that closes the cutover compares four independent totals, not one:
The hardest reconciliation in the whole cutover is not a subledger agreement — it is proving that D365's posting profiles reproduce what NetSuite's per-item posting accounts actually did.
Tolerances. $0.01 per entity per period is the default reconciliation tolerance for both the R1 invariant and the four-corner check. Anything larger must be investigated and either eliminated or accepted with a documented, signed adjustment journal — a tolerance breach is never silently widened to make a gate pass.
Mapped onto a generic programme's test taxonomy, the engine's own validation looks like this: unit tests run on every transform module on every pull request; string/SIT-equivalent coverage comes from nightly end-to-end integration tests against a synthetic dataset, plus weekly reconciliation tests against a frozen NetSuite sandbox…
Hypercare inherits the same three-tier defect severity model used throughout cutover: Severity 1 (data integrity, financial impact) blocks and demands a same-day fix; Severity 2 (high-volume but recoverable) is fixed forward at the next planned pass;
Cutover succeeds or fails on reconciliation, not on the runbook — the runbook only exists to get every wave to its own gate in the right order, with the right state classification for whatever is in flight when the freeze lands.