Cutover is the few hours or days when you switch from the old system to the new one — and the riskiest moment of any migration. This guide defines the cutover window, compares big-bang vs phased approaches, and walks through the runbook, mock cutovers, delta replay, reconciliation gates and rollback that make go-live a non-event.
The cutover window is the controlled period when the source system is frozen, final data is migrated and reconciled, and the new system goes live. Everything before it is preparation; everything in it is irreversible without a rollback.
During cutover, the business typically can't transact in either system. That freeze is expensive, so the window is tightly planned and rehearsed. The goal is to compress it: extract and load as much as possible before the freeze, then handle only the delta (changes since the freeze) during the window, reconcile against gates, and authorize go-live — or roll back.
Two things separate smooth cutovers from disasters. First, rehearsal: a mock cutover (a full dress rehearsal against production-like data) surfaces timing, sequencing and data issues while they're still cheap. Second, gates: explicit reconciliation checkpoints with go/no-go criteria, so the decision to go live is based on evidence (balances match to the cent) rather than optimism.
The decisions that shape your cutover plan.
Everything moves in one window. Simpler to reason about and cheaper to run, but higher risk — all eggs in one window, with rollback as the only safety net.
Migrate by module, region or entity over several windows. Lower risk per window but requires coexistence and integration between old and new during the transition.
The freeze-to-go-live period. Plan its length from your data volumes and load/reconcile timings measured in the mock cutover, with buffer.
The changes made in the source between the data freeze and cutover. Capturing and replaying these is what keeps cutover balances correct.
A timed, full rehearsal on production-scale data. Run at least one; ideally two, with the final one a true dress rehearsal.
A documented, tested path back to the source if a gate fails. Define the point of no return explicitly.
A minute-by-minute plan with owners, timings and gates.
Stop transactions in the legacy system at the agreed time; communicate the blackout to all users and integrations.
Extract the final data and the delta since the pre-load freeze; stage and transform it for loading.
Run FBDI/HDL/REST loads into the live target in the sequenced order, with each step timed against the mock-cutover baseline.
Run automated reconciliation; compare trial balances, control accounts and counts to the source. Pass = continue; fail = remediate or roll back.
Validate critical business processes and switch over integrations and interfaces to the new system.
Make the go-live decision on evidence; open the new system to users and run a hyper-care war room for the first days.
The controls that turn go-live into a non-event.
Every step with an owner, expected duration, dependency and a tick-box. Ambiguity at 2am causes outages.
Mock cutovers on full-volume data reveal timing and sequencing problems while they're cheap to fix.
Reconciliation thresholds (e.g. zero variance on control accounts) decide go-live — not gut feel.
An untested rollback is a hope, not a plan. Rehearse it and define the point of no return.
Decide exactly how source changes during the freeze are captured and applied, or balances will drift.
Every user, integration and downstream system needs to know the blackout window and the go-live time.
The cutover window is the controlled period — often a weekend or a few days — when the source system is frozen, final data is migrated and reconciled, integrations are switched over, and the new system goes live. The business usually can't transact during it, so it's planned tightly and rehearsed in a mock cutover.
Big-bang moves everything in one window: simpler and cheaper but higher risk, relying on rollback if something fails. Phased moves by module/region/entity over multiple windows: lower risk per window but requires the old and new systems to coexist and integrate during the transition. Choose based on risk tolerance, integration complexity and how long you can sustain coexistence.
A full dress rehearsal of the cutover on production-scale data, executed against the real runbook and timed end to end. It surfaces sequencing, timing, performance and data issues before the real go-live. Most programs run at least one, and a final mock cutover as a true rehearsal.
Through delta capture and replay: changes made in the source between the data freeze and cutover are captured (via change-data-capture or timestamped extracts) and applied to the target during the window, so the go-live balances match the source exactly.
Explicit checkpoints in the runbook with go/no-go criteria — for example, zero variance on control accounts and matching record counts and trial balances. The cutover only proceeds past a gate when the evidence passes; otherwise the team remediates or rolls back.
It depends on data volume and the number of objects, but the aim is to compress it by loading most data before the freeze and handling only the delta in the window. The mock cutover gives you the real timings to size the window with buffer.
Tell us your scope, data volumes and freeze constraints. We'll help you design the runbook, reconciliation gates and a rehearsed, low-risk cutover.