Phase 5: Cutover
Switch users and traffic from the old system to the new one in a controlled, timed sequence, with a clear decision to proceed and a tested way back.
What this phase achieves
- Make an explicit, recorded go / no-go decision before anything changes.
- Run the switch from a timed runsheet with named owners for every step.
- Change DNS and routing with before and after values recorded.
- Know in advance what will trigger a rollback and who decides.
- Have support staffed and ready the moment users start work on the new system.
What to do, in order
- 1
Prepare the runsheet
Turn the runbook into a Cutover runsheet: every task in order, with planned start time, duration, owner, verification step and a column for the actual time. Include the steps people forget: freezing changes in the source, final incremental sync, disabling old forwarding rules, re-enabling scheduled jobs, and sending the "you are live" message.
- 2
Agree the rollback plan
Write the Rollback plan before the go / no-go meeting. Name the triggers (for example "mail flow not working one hour after the MX change" or "the application fails its smoke test"), the person who decides and the exact backout steps. Flag steps that cannot be reversed, such as a one-way cross-tenant move or deleting source data, and put them as late as possible. Microsoft advises keeping the source environment available so you can revert DNS and restore previous configuration if critical issues cannot be resolved.
- 3
Hold the go / no-go meeting
Walk through the Go / no-go checklist with each lead: sync status, validation results, UAT sign-off, approved change, DNS access tested, rollback ready, support roster staffed, communications sent. Every item must be a clear yes. Record the decision and who made it. The cutover go/no-go checklist is a worked example for Microsoft 365.
- 4
Run the bridge call
Open a bridge call (voice or chat) for the cutover window and use the Bridge call agenda: roll call, checkpoints at each major step, a single person calling the next step, and fixed decision points where you either continue or invoke rollback. Keep one person writing the timeline as it happens.
- 5
Freeze and final sync
Stop changes in the source where possible: set the old file share to read-only, put a website into maintenance mode or freeze content edits, stop writes to the source database or shut down the source VM after final replication. Then run the final incremental sync and confirm it completed. Microsoft describes both a planned-downtime approach and a near-zero-downtime approach based on replication for workload cutovers.
- 6
Switch DNS and routing
Change the records listed in the network and DNS worksheet and record the old and new value and the time of each change in the DNS cutover record sheet. Examples: MX, Autodiscover and SPF for a mailbox move (see change MX records and the DNS and email cutover guide); A or CNAME records for a website; IP addresses, load balancer targets or firewall rules for a VM. Check propagation from more than one location.
- 7
Smoke test and verify
Run a short set of agreed checks straight after the switch: send and receive external mail, open files from the new library and from a synced client, sign in from a phone, load the home page and submit a form over HTTPS, start the migrated application and run a transaction. For website launches, work through the Website launch checklist.
- 8
Declare live or roll back
At the final decision point, the decision maker declares the cutover complete or invokes the rollback plan. Announce the outcome to staff using the prepared message and tell them where to get help.
- 9
Start hypercare
Staff the service desk and floor support according to the Hypercare roster, with clear escalation to the migration engineers. Expect sign-in prompts, Outlook profile issues, missing mapped drives and bookmarks pointing at old addresses. Keep the source system available, read-only, until the close phase confirms it is no longer needed.
What you produce
| Deliverable | Free template |
|---|---|
| Timed cutover tasks with owners and actuals | Cutover runsheetXLSX |
| Recorded go / no-go decision | Go / no-go checklistDOCX |
| Rollback triggers, decision maker and steps | Rollback planDOCX |
| DNS before and after values | DNS cutover record sheetXLSX |
| Support roster and escalation path | Hypercare rosterXLSX |
| Bridge call structure and decision points | Bridge call agendaDOCX |
| Website launch checks | Website launch checklistDOCX |
Before you move to Close
Tick these off with the project sponsor. If any are not true, stay in this phase.
Roles in this phase
| Role | Responsibility |
|---|---|
| Cutover manager | Runs the bridge call and the runsheet and calls each step. |
| Decision maker (usually the sponsor or delegate) | Makes the go / no-go and live or rollback decisions. |
| Migration engineers | Execute technical steps and report verification results. |
| DNS and network administrator | Makes and records DNS, firewall and routing changes. |
| Business testers | Run smoke tests and confirm critical processes work. |
| Service desk lead | Runs the hypercare roster and escalates issues. |
| Communications lead | Sends the go-live or rollback message to staff and, if needed, customers. |
Common mistakes and how to avoid them
Go / no-go as a formalityGive every lead a real veto and record the decision. If something is not ready, postponing is cheaper than rolling back.
No defined rollback triggerAgree the conditions and the decision maker in advance. Deciding under pressure at 2 am leads to waiting too long.
Irreversible steps early in the runsheetPut one-way steps, such as deleting source data or completing a one-way move, as late as possible, after verification.
DNS changes without a recordExport the zone before you start and record every change. You cannot roll back what you did not write down.
Switching off the source too soonKeep it read-only until the close phase. Users often find missing items in the first days.
Everyone on the bridge talking at onceHave one person calling steps and one person writing the timeline.
Questions
When should a cutover happen?
When users are least affected and your team and vendors are available to support. Weekends and evenings are common, but make sure support is staffed for the first working day afterwards.
How far in advance should I lower DNS TTLs?
At least as long as the current TTL before the change, so caches expire. See the how-to on lowering TTLs and your DNS host documentation.
What is the difference between the runbook and the runsheet?
The runbook explains how to do each technical procedure. The runsheet is the timed sequence of tasks for the cutover window, with owners and actual times.
When is it too late to roll back?
After a one-way step such as deleting source data, or when new data written to the target would be lost. Mark that point on the runsheet and make the final decision before it.