Cutover
Cutover is the controlled transition from the current way of working to the new one. It covers the period from the start of the change freeze to the point at which the new system is processing live work and the old one is no longer the system of record. It is executed against a timed runbook with defined decision points.
Cutover is a window, not an event. It usually begins before the go-live date — with a freeze, a final round of preparation and the last full data extract — and ends after it, once verification has passed and the business has confirmed it is working in the new system. The go-live moment sits inside it.
What it contains
The activities that make up a cutover are broadly the same across systems, whatever the technology.
| Stage | What happens |
|---|---|
| Freeze | Changes to the source systems, configuration and reference data stop, so that what is migrated matches what was tested |
| Preparation | Environments confirmed, access provisioned, backups taken, the bridge and the rota stood up |
| Final extract and load | The last data migration run, at full volume, against the frozen source |
| Reconciliation | Record counts and control totals compared against agreed tolerances, and signed off |
| Deployment | Release of the application, interfaces and integrations into production |
| Technical verification | Smoke tests and interface checks confirming the system is up and connected |
| Business validation | Named business users completing a defined set of real transactions |
| Switch | Live processing moves to the new system; the old one becomes read-only or is decommissioned on a later date |
| Comms and handover | Notification that the system is open, and the start of the post-go-live support arrangement |
Each stage carries an owner, a planned duration and a checkpoint. The Cutover Runbook & Hypercare Pack holds these as a timed task list with the post-cutover period attached.
How it is used
Cutover is planned backwards from the moment the business needs to be working in the new system. The available window is fixed by the business — a weekend, a quiet period, a month end — and the sequence has to fit inside it with contingency left over. That constraint is what drives the rehearsal: if the timed run takes longer than the window allows, the plan changes rather than the window.
Within the window, progress is tracked against planned start times rather than percentages. The recurring question at each checkpoint is whether the sequence is still inside its contingency, and whether the next irreversible step should be started. The cutover plan guide covers the sections that surround the sequence itself.
Where it goes wrong
Cutovers fail on time, not on tasks. The sequence is usually correct and the durations are optimistic, so the delay accumulates quietly through the night and is only visible when a decision point arrives with no contingency left. Timings taken from a full-volume rehearsal rather than from estimates are the difference.
The second failure is an unenforced freeze. A configuration change made in the source system after the final extract produces a reconciliation break that takes hours to find. The third is the absence of a defined point of no return, so at 4am nobody can say whether rolling back is still an option. The fourth is treating cutover as finished at deployment, with no business validation before the system is opened to users.
Related terms
See also cutover plan, cutover runbook and go-live.
Questions
Is cutover the same as go-live?
No. Go-live is the point at which the new system starts being used for real work. Cutover is the whole controlled transition around it, including freeze, migration, verification and the switch.
How long does a cutover take?
It is bounded by the window the business can give up. The duration that matters is the one measured in a full-volume dress rehearsal, not the estimate in the plan.
What is a phased cutover?
A transition done in stages — by site, region, business unit or module — rather than in one window. It reduces the size of each event but extends the period in which two systems run in parallel.
Who runs a cutover?
A named cutover manager, working from the runbook, with a single bridge and a defined escalation path. Decision authority for go, no-go and rollback is agreed before the window opens.