Cutover, reconciliation and hypercare

The migration engine from chapter 2 only earns its keep on one night: the cutover weekend. This module covers the cutover-state matrix, the hour-by-hour runbook and its Workday-specific freeze constraints, four-corner financial reconciliation, the Worktag and in-flight Business Process hazards unique to this source, rollback, test strategy, governance and the hypercare model that follows go-live.

What you will be able to do

• Build a cutover-state matrix for a Workday Financial Management object set, including in-flight Business Processes as their own class
• Sequence an hour-by-hour cutover runbook that accounts for Workday's release-calendar constraint
• Run four-corner financial reconciliation and explain the Worktag-specific hazard inside it
• Apply rollback trigger criteria, the point of no return, and restart semantics correctly
• Design a hypercare model with staffing, triage tiers and exit criteria for a Workday-sourced cutover

Introduction

Chapter 2, The migration engine and operational hardening, built the machine: extractor, canonical model, transformer, loader, reconciler, hardened against fifteen operational risks.

The cutover-state matrix

CutoverState is the canonical entity for in-flight residuals. It is not a dumping ground for awkward transactions; each state has an allowed policy and a designated D365 landing mechanism.

Freeze calendar, blackout window and the hour-by-hour runbook

The freeze calendar has two blackout windows, and they are not symmetric. Workday is read-only from T-0 until the end of the programme — there is no plan to reopen it. D365 is read-only from T-0 until T+23h, opened only once the final reconciliation is green and sign-off is captured. Everything in between runs to a fixed offset timeline:

Load waves and the reconciliation gate

Chapter 2 introduced the eight dependency-ordered waves the loader executes: static masters, operational state, in-flight residuals, and financial opening, each gated before the next begins.

Four-corner reconciliation, the Worktag problem and the Business Process problem

Four-corner reconciliation, in the finance sense used for gate sign-off, means four specific report-to-report comparisons, each with a named report on both platforms:

Tolerances, sign-off, evidence pack and rollback

The evidence pack contains the same reconciliation shape for every wave: wave, canonical_concept_id, workday_object_name, d365_entity_name, workday_count, silver_count, gold_count, f365_count, delta_count, workday_sum_amount, f365_sum_amount, delta_amount, tolerance, gate_status, run_uuid and policy_commit_hash.

Test and validation strategy

Layer the test strategy the way the engine itself is layered. Engine-owned tests run continuously before cutover ever begins: unit tests per transform module on every change, integration tests nightly against a synthetic Workday dataset, and reconciliation tests weekly against a frozen Workday sandbox extract.

Governance and hypercare

Hypercare opens the moment cutover closes at T+24h, and it has its own shape: a dedicated support lead staffs the first weeks, working the same three-tier defect severity model as cutover itself, with two additions specific to this source system — the RED-classified Business Process queue is worked through and reauthored in D365 during…

Knowledge check

Summary

Cutover is where every earlier chapter's design choices get tested against a clock. The cutover-state matrix, the runbook, the reconciliation and the hypercare model are not separate concerns — they are one continuous chain from "what is true in Workday at freeze" to "what is true in D365 six weeks after go-live."