Cutover planning is the difference between a migration that lands quietly over a weekend and one that becomes a fortnight of firefighting, apology emails and invoices nobody budgeted for. Everything before it — the business case, the landing zone, the test environments — is reversible. The cutover is not, unless you have written down exactly how to reverse it.
Most cloud migration programmes spend months on architecture and days on the cutover plan. That ratio is backwards. Architecture mistakes surface slowly and get refactored. Cutover mistakes surface at 03:00 on a Sunday with the finance system down, the supplier’s lead engineer on a train, and nobody willing to be the person who says “roll it back”.
This guide is a working cutover plan template for UK businesses. It covers the cutover strategies and when each applies, how to build a runbook people can actually follow, setting RTO and RPO, the data sync and the point of no return, the rollback plan in the detail it deserves, go/no-go criteria, rehearsals, cutover day itself and hypercare. It sits alongside our wider cloud adoption work and assumes the cloud migration business case and supplier selection are already done.
Table of contents
- What a cutover plan is and why it decides your migration weekend
- Cutover plan strategies compared: big bang, phased and parallel run
- How to build a cutover plan runbook people can actually follow
- Setting RTO, RPO and the cutover plan window
- Data migration and the cutover plan point of no return
- The rollback plan your cutover plan must contain
- Go/no-go criteria and the cutover plan decision meeting
- Rehearsing the cutover plan before the real weekend
- Cutover day: running the cutover plan under pressure
- Hypercare and closing out the cutover plan
- Common cutover plan mistakes that cost UK businesses money
- Frequently asked questions about the cutover plan
- References
What a cutover plan is and why it decides your migration weekend
A cutover plan is the hour-by-hour script for moving a live service from its current home to its new one, plus the conditions under which you stop and go back. It is an operational document, not a project plan, and it is written for people who will read it while tired.
The cutover is the only irreversible hour
Everything else in a migration programme has an undo. You can rebuild a landing zone, re-run a test, renegotiate a statement of work. Once you have repointed production traffic and users have started writing new data into the target platform, going back means losing that data or reconciling it by hand. A cutover plan exists to make that moment deliberate rather than accidental.
Cutover plan, migration plan and runbook are not the same document
The migration plan is the programme-level view: waves, dependencies, milestones, budget. The cutover plan covers one wave, one weekend, one service. The runbook is the numbered task list inside the cutover plan. Confusing the three is the most common structural failure — a Gantt chart with “Cutover” as a single three-day bar is not a cutover plan.
What a finished cutover plan must produce
A complete cutover plan answers seven questions without anyone needing to ask: what moves, in what order, by when, who does it, how we know it worked, what we do if it did not, and who decides. If your document cannot answer all seven for every step, it is a draft.
The cost of improvising it
An unplanned cutover rarely fails outright. It overruns. The window slips from twelve hours to thirty, the business opens on Monday against a half-migrated estate, and the team spends the next two weeks in an unplanned incident. The direct cost is contractor overtime; the real cost is the credibility of the programme.
Cutover overruns cluster around a small number of causes. The figures below are a planning heuristic drawn from common post-mortem themes rather than survey data — use them to decide where to spend rehearsal effort, not as a benchmark.
Cutover plan strategies compared: big bang, phased and parallel run
Before you write a single runbook step, choose the cutover strategy. It determines the length of the window, the shape of the rollback and how much of your team’s weekend you are spending.
Big bang cutover
Everything moves in one window. It is the cheapest to plan, the shortest to execute and the hardest to reverse. Big bang suits small, tightly coupled estates where partial migration would break integrations anyway — a single line-of-business application with its database, or a file server moving to SharePoint. It is a poor fit for anything with dozens of interdependent systems.
Phased cutover
Applications, sites or user groups move in waves. Each wave is smaller, so each rollback is smaller, and the team learns between waves. The trade-off is a period of hybrid running where data has to flow both ways, which is where most phased programmes actually spend their money. Budget for the integration layer, not just the moves.
Parallel run
Old and new run simultaneously, with the business using both and results compared until confidence is reached. It is the safest pattern and by far the most expensive — double licensing, double infrastructure and double the operational effort. Reserve it for systems where an undetected data error would be worse than an outage: payroll, billing, regulated reporting.
Blue-green and canary for cloud-native workloads
If the workload is already containerised or stateless, borrow from deployment practice. Blue-green keeps two identical environments and switches traffic at the router, which makes rollback a routing change rather than a restore. Canary releases move a small percentage of traffic first. Both give you a cutover plan whose reverse gear is measured in seconds, but they only work where state lives outside the application.
| Strategy | Downtime | Rollback difficulty | Relative cost | Best fit |
|---|---|---|---|---|
| Big bang | One long window | High | Low | Small, tightly coupled estates |
| Phased by wave | Several short windows | Medium | Medium | Large estates, many applications |
| Parallel run | Near zero | Low | High | Payroll, billing, regulated reporting |
| Blue-green | Seconds | Very low | Medium | Stateless or containerised workloads |
| Canary | None | Very low | Medium | High-traffic web services |
How to build a cutover plan runbook people can actually follow
The runbook is where a cutover plan stops being a strategy document and becomes an instrument. Write it assuming the person executing step 47 is not the person who wrote it, has been awake for fourteen hours, and cannot phone you.
The eight sections every runbook needs
A workable runbook has a fixed shape, and using the same shape every time means the team stops having to learn the document. The table below is the structure we use on client cutovers.
| Runbook section | What it contains | Failure it prevents |
|---|---|---|
| 1. Scope and systems in play | Exactly what moves and what does not | A forgotten integration discovered live |
| 2. Roles and contacts | Names, mobiles, deputies, supplier escalation | Twenty minutes lost finding who has the password |
| 3. Pre-cutover checklist | Backups verified, freeze in force, comms sent | Starting without a restorable backup |
| 4. Numbered task list | Step, owner, duration, dependency, verification | Steps run out of order or twice |
| 5. Go/no-go checkpoints | Named gates with written pass criteria | Drifting past the last safe exit |
| 6. Validation and smoke tests | Technical checks plus business sign-off scripts | Declaring success on a ping test |
| 7. Rollback procedure | Numbered reverse steps with their own timings | Improvising the undo under pressure |
| 8. Hypercare and handover | Support rota, known issues, exit criteria | A migration that lands with nobody owning it |
Write steps as verifiable actions
“Migrate the database” is a project task. “Run scripts/final-sync.ps1, confirm row count of dbo.Invoices matches source within zero variance, record the figure” is a runbook step. Every step in the cutover plan needs a verification that produces evidence — a number, a screenshot, a green check — because that evidence is what the go/no-go decision consumes.
Time-box every step and record the actuals
Give each step a planned duration and leave a column for the actual. Two things fall out of this. During rehearsal you learn which estimates are fantasy; during the live cutover the cumulative actual column tells you, in real time, whether you are tracking toward the rollback deadline or past it.
Name an owner and a deputy for every step
Ownership by team name fails. “Networks” cannot execute a step at 02:00; a named person with a mobile number can. Every step gets a named owner and a named deputy, and a good cutover plan is reviewed specifically for steps where the same individual is the owner of nine consecutive tasks.
Setting RTO, RPO and the cutover plan window
The window is not a technical constraint you discover. It is a business decision you take, and then engineer toward. Two numbers drive it, and both belong to the business, not to IT.
RTO and RPO are business decisions
Recovery time objective is how long the service can be unavailable. Recovery point objective is how much recent data the business can afford to lose. NIST SP 800-34 is the standard reference for defining both. If you have already worked through backup, disaster recovery and high availability, you have these figures; if not, agree them before the cutover plan goes any further.
Tiering your systems
Not everything deserves the same window. Tier the estate, and let the tier drive the cutover approach — that is how you avoid spending parallel-run money on a print server.
| Tier | Typical systems | RTO | RPO | Cutover approach |
|---|---|---|---|---|
| 1 — Critical | Order taking, payments, clinical | Under 1 hour | Near zero | Parallel run or blue-green |
| 2 — Business important | ERP, CRM, finance | 4-8 hours | Under 15 minutes | Weekend window, staged rollback |
| 3 — Operational | File shares, intranet, reporting | 24 hours | Under 4 hours | Big bang in a maintenance window |
| 4 — Deferrable | Archives, dev and test, print | Days | Days | Move whenever convenient |
Sizing the window from real throughput, not link speed
The single most common cutover plan error is sizing the data sync from the headline bandwidth figure. Real sustained throughput after protocol overhead, encryption and small-file penalties is routinely half the theoretical rate, and small files are dramatically slower than the same volume in large ones. Measure it during rehearsal on representative data, then plan against the measured figure.
Where a twelve-hour window actually goes
Teams consistently allocate too much of the window to the move and too little to proving it worked. The split below is a sane starting model for a Tier 2 application cutover; adjust it with your own rehearsal timings.
The change freeze
Freeze the source estate before the window opens and keep it frozen until hypercare ends. That means no releases, no firewall changes, no patching, no starter-leaver moves. Publish the freeze dates weeks ahead through your normal change process, because the freeze is the part of the cutover plan that other teams will forget.
Data migration and the cutover plan point of no return
Data is where cutovers overrun, and where they cause harm that outlives the weekend. An outage is embarrassing; silently corrupted or partially migrated data is a problem you find in the year-end audit.
Pre-seed, delta sync, final sync
The pattern that works is three passes. Pre-seed the bulk of the data days or weeks early. Run incremental delta syncs to keep the target warm and to measure real throughput. Then, inside the window with the source quiesced, run a short final sync. A cutover plan built on a single full copy inside the window is the classic reason a twelve-hour window becomes thirty.
Databases need their own strategy
For databases, log shipping or native replication into the target — AWS Database Migration Service and Azure Database Migration Service both support continuous replication — turns the cutover into a controlled failover rather than a restore. The runbook step is then “stop writes, wait for replication lag to reach zero, promote”, which takes minutes and is genuinely reversible right up to the promotion.
Reconciliation: prove the data arrived
Row counts, checksums, file counts and byte totals, financial control totals for the last closed period. Decide the reconciliation queries before the weekend, agree the acceptable variance in advance (for most finance data the answer is zero), and have a named business person sign the result. Reconciliation is the evidence your go/no-go decision runs on.
Declaring the point of no return
Somewhere in every cutover plan there is a step after which rollback stops being clean — usually the moment users begin writing to the target. Mark it explicitly in the runbook, in bold, with a timestamp field. Everyone in the room should know whether it has passed. Programmes that do not name this step discover it retrospectively, which is the worst possible time.
The rollback plan your cutover plan must contain
Ask to see a cutover plan and you will usually get a solid forty-step migration sequence with one line at the bottom reading “if issues, roll back to source”. That is not a rollback plan. It is a hope.
Rollback is not a bullet point
The reverse procedure needs the same treatment as the forward one: numbered steps, named owners, planned durations, verification at each stage, and a rehearsal. If restoring the source takes six hours and your window is twelve, then your real decision deadline is hour six, not hour eleven. Most teams have never worked out that number.
The three rollback patterns
| Pattern | How it works | Time to execute | Closes when |
|---|---|---|---|
| Traffic switch back | Repoint DNS, load balancer or router to source | Minutes | Users write to the target |
| Source resume | Unfreeze the untouched source, discard target | 1-4 hours | Source is decommissioned or changed |
| Restore from backup | Rebuild source state from the pre-cutover backup | Hours to days | Backup ages past the RPO |
| Reverse migration | Migrate data back from target to source | Days | Rarely viable — plan not to need it |
The rollback window closes, and you must say when
Write the rollback deadline into the cutover plan as a clock time, not a condition. “Rollback decision must be made by 04:00” is actionable at 03:55. “Roll back if we encounter serious problems” is not, because at 03:55 everybody is optimistic and nobody wants to be the one who called it. Naming the time in advance moves the decision from a judgement made under pressure to a rule agreed while calm.
Test the rollback, not just the migration
Rehearse the reverse path at least once, end to end, with the same people. This is the step almost everyone skips, and it is the one that finds the broken assumptions: the backup that restores but will not start, the licence that re-keys to the new hardware, the third party who cached your new endpoint and cannot revert for 24 hours.
Keep the source recoverable longer than feels necessary
Do not decommission anything on the Monday. Keep the source estate intact and restorable for the whole hypercare period, and keep the final pre-cutover backup for as long as your retention policy and the UK GDPR obligations you hold as a controller allow. The running cost of a few idle weeks is trivial against the cost of discovering a data gap in week three with nothing to recover from.
Go/no-go criteria and the cutover plan decision meeting
A go/no-go decision made on the day, by whoever is in the room, on the basis of general confidence, is not a control. It is theatre. The value comes from writing the criteria down beforehand.
Publish the criteria before the day
Criteria should be binary and evidence-backed: final sync completed with zero row variance, all Tier 1 smoke tests passed, named business approver signed the reconciliation, rollback confirmed still available, no P1 defects open. If a criterion cannot be answered yes or no from evidence, rewrite it.
Who is allowed to say no
One person holds the go decision — usually the business owner of the service, not the IT lead or the supplier. Several people hold a veto: the technical lead, the security lead, the named business approver. Write the names in the cutover plan. A veto that has to be escalated to find out whether it counts is not a veto.
The T-minus schedule
Working backwards from the window is what turns a cutover plan into something the wider organisation can align to.
| When | Activity | Exit criteria |
|---|---|---|
| T-6 weeks | Runbook drafted, roles named | Every step has an owner and a duration |
| T-4 weeks | Rehearsal 1, forward path | Measured timings replace estimates |
| T-3 weeks | Rehearsal 2, including rollback | Reverse path proven end to end |
| T-2 weeks | Change freeze begins, comms issued | Freeze approved through change control |
| T-1 week | Final rehearsal, go/no-go dry run | No open P1 or P2 defects |
| T-24 hours | Readiness call, backups verified | Restorable backup confirmed by test |
| T-0 | Window opens, runbook executes | Checkpoint gates passed in sequence |
Rehearsing the cutover plan before the real weekend
A rehearsal is not a test of the technology. It is a test of the document, the timings and the people. Treat the first run-through as data collection rather than a pass or fail exercise.
Rehearse against production-like data
A rehearsal against 5GB of sample data tells you nothing about a 5TB cutover. Use a restored copy of production, with production-representative file counts and record volumes, in an environment sized like the target. Anonymise where you must, but do not shrink the volume — the volume is the thing you are measuring.
What a rehearsal actually proves
It proves the runbook steps are in a workable order, the durations are real, the verification checks produce usable evidence, and the named owners can actually perform their steps with the access they currently hold. Missing permissions are the single most common rehearsal finding, and the cheapest one to fix in advance.
Measure each round
Count the issues each rehearsal finds and watch the curve flatten. A programme still finding a dozen new problems in the third rehearsal is not ready, whatever the calendar says. The pattern below is what a healthy sequence looks like.
Rehearse the people, not only the process
Run at least one rehearsal at the actual time of day the cutover will happen. Decision quality at 03:00 is not the same as decision quality at 14:00, and a plan that assumes otherwise has not been tested. It is also how you find out that your rollback depends on someone who will be twelve hours into a shift.
Cutover day: running the cutover plan under pressure
By the time the window opens, the thinking should be finished. Cutover day is execution and communication, and the failure modes are almost entirely organisational.
The three roles that must exist
A cutover manager runs the runbook and owns the clock — and does no technical work at all, which is the discipline most teams get wrong. A communications lead handles the business, users and any customer-facing message. Technical leads execute. Merging the first two roles into an engineer guarantees that either the clock or the comms is dropped.
One command channel, one status page
A single bridge call or channel, one status document, one clock. Side conversations are where a cutover plan quietly diverges from what is actually happening. Record decisions with timestamps as you go — you will want them for the post-implementation review, and if anything goes badly wrong you will need them for the incident response record.
Smoke tests and business validation are different things
Technical smoke tests confirm the service is up: the site responds, the database accepts connections, the scheduled job ran. Business validation confirms it is right: a real user raises a real order, the invoice totals match, the report reconciles. Only the second one justifies a go decision, and it needs business people rostered on, not just engineers.
Telling users and customers
Users need to know when the service goes down, when it comes back, what will look different, and where to report problems. Send that before the window, not during it. For customer-facing services, agree the external message and who signs it off in advance — drafting a customer notice at 02:00 is how a technical delay becomes a reputational one.
Hypercare and closing out the cutover plan
The cutover plan does not end when the service comes back up. It ends when the new platform is demonstrably stable and someone has formally taken it on.
The hypercare period
Run one to four weeks of elevated support depending on tier: extended hours, a dedicated triage channel, daily stand-ups, and the migration team still available rather than released to the next project. Agree the exit criteria for hypercare up front — a defect threshold and a stability period, not a date on a plan.
Decommissioning the source estate
Only once hypercare has exited, and in a documented sequence: stop, observe, then delete. Power off rather than delete first, wait out an agreed observation period, take a final archival backup, then remove. Retire licences and support contracts deliberately too, or you will keep paying for a data centre you no longer use — a point covered in more depth in our cloud migration cost guide.
The post-implementation review
Hold it within two weeks, while memory is fresh. Compare planned against actual timings step by step, list every issue and how long it took to resolve, and update the runbook template. On a phased programme this is what makes wave four cheaper than wave one, and it is the mechanism by which a cutover plan becomes an organisational asset rather than a one-off document.
Common cutover plan mistakes that cost UK businesses money
Most cutover failures are variations on a small number of themes, and all of them are cheaper to fix in the plan than on the night.
Treating it as a project management artefact
A cutover plan written to satisfy a governance checkpoint reads like a status report. Written to be executed, it reads like a checklist. If the document has more narrative than numbered steps, it will not survive contact with the weekend.
Scheduling against a business deadline
Cutting over the weekend before financial year end, or the night before a major campaign launch, removes your ability to roll back — because rolling back means missing the deadline anyway. Pick a window with genuine slack on the far side of it, and treat any date the business cannot move as a reason to go earlier, not later.
Forgetting the things that are not servers
DNS TTLs that need lowering days ahead, TLS certificates bound to old hostnames, allow-lists held by third parties, fixed IP addresses hard-coded in a partner’s integration, licence keys tied to hardware, and print queues. These items cause a disproportionate share of overruns because none of them belongs to the migration team.
Ignoring the run state
A service that migrates successfully and then has no monitoring, no alerting, no backup schedule and no named support owner has not really landed. Confirm the operational handover is complete as a numbered step in the cutover plan, not as an afterthought — this is exactly the gap that managed IT services and a defined support plan exist to close.
Letting the supplier own the plan entirely
Your implementation partner should write most of the technical detail. You must own the go/no-go criteria, the rollback deadline and the business validation, because those are decisions about your risk appetite. If the supplier’s cloud migration RFP response did not include a cutover and rollback approach, that gap will still be there on the night.
Frequently asked questions about the cutover plan
How long should a cutover plan be?
As long as the runbook needs and no longer. A single application cutover might be twelve pages with sixty numbered steps; a data centre exit wave might be sixty pages. Length is a symptom of scope, not of quality — what matters is that every step is verifiable and owned.
How far in advance should we write it?
Start the cutover plan at least six weeks before the window, because the rehearsal schedule needs that long. The first draft can be written as soon as the target architecture is stable; you will rewrite the timings after each rehearsal anyway.
Who should own the cutover plan?
A named cutover manager on the customer side, even when a supplier writes most of it. Ownership means holding the clock, the go/no-go criteria and the rollback decision — responsibilities you cannot delegate to the organisation being paid to complete the migration.
How many rehearsals are enough?
Two forward and one including rollback is a reasonable minimum for a Tier 2 system. Stop when a rehearsal produces no new significant issues and the measured timings are stable across runs, not when you reach a number in a plan.
What if we pass the rollback deadline and then hit a problem?
You fix forward, which is why the deadline exists: it is the moment you accept that fixing forward is the only option. Build that acceptance into the plan by having a named escalation path, a fix-forward contingency budget, and a degraded-service mode agreed with the business.
Should we cut over on a Friday night?
Friday night gives you the longest window but the worst support coverage, since vendor and third-party support is thinnest at weekends. For anything with heavy third-party dependency, a Thursday night cutover with Friday as a working contingency day is often the better trade.
Do we need one for a SaaS migration?
Yes, and often more than for infrastructure work. The technical steps are simpler, but the identity, data export, integration and user communication steps are not — as anyone who has run a file server to SharePoint migration will recognise. The cutover plan is where those non-technical dependencies get caught.
References
NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
NIST SP 800-145: The NIST Definition of Cloud Computing
NCSC: Using Cloud Services Securely
NCSC: Incident Management Collection
GOV.UK Service Manual: Moving Away From Legacy Systems
GOV.UK Service Manual: Deploying Software Regularly
GOV.UK: The Technology Code of Practice
Cyber Security Breaches Survey 2025
ICO: Controllers and Processors
Microsoft Cloud Adoption Framework for Azure
Azure Well-Architected Framework
Azure Well-Architected: Disaster Recovery
Azure Database Migration Service Overview
AWS Well-Architected Framework
AWS Well-Architected Reliability Pillar
AWS: Disaster Recovery Options in the Cloud
AWS Database Migration Service User Guide
AWS Application Migration Service
Google Cloud Architecture Framework
Google SRE Book: Monitoring Distributed Systems
Google SRE Workbook: Canarying Releases
Google SRE Book: Availability Table
Martin Fowler: Blue-Green Deployment
