Cutover phases: a complete breakdown
The six phases of a cutover, in order, with time markers, owners, goals, and go/no-go gates. Covers preparation, dress rehearsal, T-1 readiness, the cutover window, post-cutover validation, and hypercare.
A cutover runs in six phases, in order, with an explicit go/no-go gate between each. The phases are: pre-cutover preparation, dress rehearsal, T-1 readiness review, the cutover window, post-cutover validation, and hypercare.
This page covers each phase with its time marker, goal, owners, key activities, output, and the gate that must be passed before proceeding to the next.
Definition
The phases of a cutover are the sequenced stages of the cutover process, from preparation through stabilization. Phases exist to make the cutover plan resilient under fatigue — at each transition, a defined gate forces a decision, so judgments are made deliberately rather than by drift.
The six phases at a glance
| # | Phase | Time | Goal |
|---|---|---|---|
| 1 | Pre-cutover preparation | T-14 to T-2 | Confirm readiness, freeze the source system |
| 2 | Dress rehearsal | T-7 | Surface failure modes against a production-like environment |
| 3 | T-1 readiness review | T-1 | Final executive go/no-go before the cutover window |
| 4 | Cutover window | T-0 | Move from source to target, validate, open to users |
| 5 | Post-cutover validation | T+0 to T+1 | Confirm the new system operates correctly under real load |
| 6 | Hypercare | T+1 to T+14 | Stabilize, resolve incidents fast, keep rollback open |
The whole cutover spans roughly four weeks. The visible “go-live” moment lives inside phase 4. See cutover vs go-live for why those two terms are not the same thing.
Phase 1 — Pre-cutover preparation
Time: T-14 to T-2
Goal: Confirm readiness. Lock down the source system. Eliminate scope ambiguity.
Primary owner: Cutover lead
Key activities:
- Finalize the cutover plan and circulate to all streams
- Freeze configuration changes on the source system
- Communicate the cutover window to end users and downstream system owners
- Confirm rollback environment readiness
- Confirm on-call rotation for the cutover window plus 48 hours hypercare
- For ERP cutovers: confirm transport queue is empty and stable
- For data migrations: confirm source-system schema lock
Output: A finalized runbook, an empty change queue, a communicated date, and a confirmed on-call schedule.
Go/no-go gate to phase 2:
- Plan reviewed and signed off by all stream leads
- Source-system change freeze in effect
- Communications sent
- Rollback environment ready
If any item is unconfirmed, the dress rehearsal cannot begin.
Phase 2 — Dress rehearsal
Time: T-7
Goal: Execute the full cutover sequence end-to-end against a production-like environment, with the actual team, at the actual time of day. Find what will go wrong.
Primary owner: Cutover lead, with all stream leads executing their own activities
Key activities:
- Refresh non-production environment from latest production snapshot
- Execute the cutover sequence end-to-end on the real clock
- Time-stamp every task start, end, and decision
- Capture deviations in a debrief log
- Update the runbook live during the rehearsal — not from memory afterward
- Exercise at least one full rollback (the rollback path is the rarer one and the higher-risk one)
- Produce an action list with owners and dates
Output: A debrief log, an updated runbook, and an action list closed before T-1.
Go/no-go gate to phase 3:
- Dress rehearsal completed end-to-end
- Total elapsed time fits the cutover window with ≥30% buffer
- All action items either closed or with an explicit waiver from the cutover lead
- Rollback procedure exercised and verified
See the cutover rehearsal pillar for the full taxonomy of rehearsals.
Phase 3 — T-1 readiness review
Time: T-1 (the day before the cutover window opens)
Goal: A final, deliberate go/no-go decision by the executive sponsor and the cutover lead, in writing.
Primary owner: Cutover lead presents; executive sponsor decides.
Key activities:
- Confirm all prerequisites complete
- Verify the most recent production backup taken and validated
- Confirm rollback environment ready
- Confirm war-room and Slack channels staffed and tested
- Re-confirm on-call rotation
- Run the formal go/no-go decision meeting
Output: A signed go/no-go decision recorded in the runbook.
Go/no-go gate to phase 4:
- Go decision recorded
- All readiness criteria met
- No outstanding action items from the dress rehearsal
If the decision is “no-go,” the cutover slips. If the decision is “go,” the window opens at T-0.
Phase 4 — Cutover window
Time: T-0 (a few hours to a few days)
Goal: Move from source to target. Validate. Open to users.
Primary owner: Cutover lead, coordinating all streams in real time.
Key activities, in order:
- Lock source system — block all user access
- Take final backup snapshot of the source
- Execute final data migration / synchronization
- Validate row counts and checksums between source and target
- Run smoke tests on the target system
- Business sign-off — key users validate critical workflows
- Cut DNS / load-balancer / integration endpoints to point at target
- Open the new system to users — go-live moment
Each activity carries a defined rollback trigger. If any trigger fires, the cutover lead has a pre-decided escalation path: pause, recover, or roll back to source. Decisions are not made fresh at 03:00 — they are exercised from the plan.
Output: Users on the new system. Source system locked but still recoverable.
Go/no-go gate to phase 5:
- All validation gates passed
- Business sign-off recorded
- DNS / load-balancer cutover confirmed
- No open critical incidents
- Cutover lead’s decision to proceed to validation phase
Phase 5 — Post-cutover validation
Time: T+0 to T+1 (first 24–48 hours after go-live)
Goal: Confirm the new system is operating correctly under real user load and real transaction volumes.
Primary owner: QA lead and business stream lead, with infra lead on standby
Key activities:
- Monitor real user transactions through the new system
- Reconcile any final data discrepancies between source and target
- Confirm integrations are flowing correctly
- Confirm batch jobs, ETLs, and reporting pipelines are running
- Capture and triage early-life issues
- Keep the rollback option open
Output: A validated production system. A triage list of post-cutover issues with assigned owners.
Go/no-go gate to phase 6:
- No outstanding critical defects
- All scheduled batch jobs completed successfully
- Business stream confirms the system is usable for primary workflows
Phase 6 — Hypercare
Time: T+1 to T+14 (typically two weeks)
Goal: Stabilize. Resolve incidents fast. Maintain rollback readiness through D+3, then transition to standard support.
Primary owner: Cutover lead, transitioning to standard support team near end of phase
Key activities:
- Stand up a dedicated hypercare support channel
- Triage and resolve incidents within agreed SLA (hours, not days)
- Daily stand-up: open issues, resolution status, sentiment
- Maintain rollback readiness through D+3
- Decommission source-system access at end of hypercare (typically D+14)
- Run a lessons-learned retrospective and capture into the runbook for the next cutover
Output: A stable production system. A decommissioned source. A retrospective document.
Gate to “cutover complete”:
- No critical incidents in the final 72 hours of hypercare
- Source-system decommissioning plan approved and executed
- Retrospective complete, action items assigned to the next program
Why the gates matter
The single biggest predictor of cutover failure is gate erosion — a phase whose go/no-go criteria are met “mostly” rather than completely. Erosion at phase 2 (dress rehearsal) shows up as a runaway phase 4. Erosion at phase 3 (T-1 readiness) shows up as a midnight rollback decision the team is not ready to make.
The gates exist to make those decisions ahead of time, while the team is rested. Honor them.
Phase ownership at a glance
| Phase | Lead owner | Supporting streams |
|---|---|---|
| 1. Preparation | Cutover lead | All |
| 2. Dress rehearsal | Cutover lead | All — executing real tasks |
| 3. T-1 readiness | Cutover lead | Executive sponsor decides |
| 4. Cutover window | Cutover lead | Infra, data, QA, business |
| 5. Post-cutover validation | QA lead + business stream | Infra on standby |
| 6. Hypercare | Cutover lead → support team | Infra, support |
See cutover activities & responsibilities for the full RACI breakdown per activity.
Generate a phased plan
The cutover plan template generator produces a plan with all six phases, time-marked, with owners and rollback triggers per activity. Free, no signup, downloadable as Markdown.
Related
- What is a cutover? — definition and scope
- Cutover vs go-live — where the go-live moment sits inside phase 4
- Cutover rehearsal: the complete guide — phase 2 in detail, plus the other rehearsal types
- Cutover activities & responsibilities — RACI for every activity across the six phases
Frequently asked questions
- How many phases are in a cutover?
- Six. Pre-cutover preparation, dress rehearsal, T-1 readiness review, the cutover window, post-cutover validation, and hypercare. Each phase has a defined goal, owner, output, and go/no-go gate that must be passed before proceeding to the next.
- What is the first phase of a cutover?
- Pre-cutover preparation, typically running from T-14 to T-2. It includes finalizing the runbook, freezing source-system configuration, communicating to users, and confirming on-call coverage for the cutover window and hypercare.
- What happens during the cutover window?
- The cutover window is the operational transition itself — typically a weekend. It includes locking the source system, taking a final backup, executing the data migration, validating row counts and checksums, running smoke tests, business sign-off, the DNS/load-balancer cutover (go-live), and opening the new system to users.
- How long does the hypercare phase last?
- Typically two weeks (T+1 to T+14). Hypercare is the intensive monitoring and rapid incident-response period immediately after go-live, during which the rollback option is kept open and bug fixes are turned around within hours.
- What is a go/no-go gate?
- A go/no-go gate is a checkpoint between two cutover phases where the cutover lead must confirm explicit criteria are met before proceeding. Failing a gate triggers either a delay, a rework, or — at the cutover window itself — a rollback.
- Can cutover phases run in parallel?
- Activities within a phase often run in parallel — that is why each phase has multiple owners. The phases themselves do not. Each phase must complete its go/no-go gate before the next begins. This sequencing is what makes the cutover plan resilient under fatigue.