The cutover-state matrix, the freeze calendar and hour-by-hour go-live runbook, four-corner financial reconciliation with named JDE programmes and D365 reports on both sides, the F0902-versus-F0911 source-of-truth hazard, carry-over of open orders, work orders, fixed assets and Job Cost, the honest rollback-is-forward-fix position, SIT/UAT/mock-cutover test strategy, cutover RACI and a tiered hypercare model through to handover to run.
Chapters 1 and 2 built the programme and the engine. This chapter is about the week either validates or exposes both: the freeze, the load, the reconciliation, and the weeks of hypercare that follow before anyone can honestly say the cutover worked.
Not every object migrates the same way. Deciding, object by object, whether something moves as an open balance, as full history, as an open transaction, or is abandoned in a read-only archive is a governance decision, not a technical one, and it has to be made and signed off before extraction logic is built.
A freeze calendar is the schedule of what stops changing, and when. A runbook is the minute-by-minute sequence of what happens once it has. Both need an owner, a written trigger for every step, and a rehearsed duration, not an estimate.
Four separate reconciliations, each comparing a named JDE source to a named D365 report, have to close before hypercare can be considered anything more than hope. "Close" here means an explicit, signed variance of zero (or an explained, approved rounding tolerance) for every corner, by every company in scope — not a total that looks…
Open sales and purchase orders (F4211, F4311) carry across at remaining quantity, not original order quantity, for any order already partially shipped or received — the customer or supplier experiences continuity of a live commitment, not a re-keyed order with a new number.
Every steering committee asks what the rollback plan is. The honest answer has two very different halves depending on timing.
System Integration Testing proves the engine itself: extractor, canonical registry, transformer, loader and reconciler run cleanly against fixture data — including the deliberately planted edge cases from chapter 2 — in a non-production D365 environment.
Cutover governance is deliberately narrower than programme governance. The steering committee that met monthly during design and build now needs a channel that can make a binding go/no-go call inside minutes, not weeks, so the RACI below trades breadth for speed: fewer roles, each with sharper accountability, and every decision point…
Hypercare should step down on evidence, not on a date fixed before anyone knew how the cutover would go.
The cutover-state matrix — open balance, full history, open transaction, or abandoned — has to be agreed object by object, and signed off by functional leads, before extraction logic exists. The freeze calendar and runbook turn go-live from an event into a rehearsed sequence of named, owned, timed checkpoints from T-72h to T+24h.