A good cutover is uneventful. That's the goal. The drama should happen in rehearsal, not on the night of go-live — which means cutover planning is really rehearsal planning, decision-criteria planning, and communication planning disguised as a single checklist.
The four phases of cutover planning
1. Cutover design
Define exactly what "cutover" means for your implementation: which environment gets promoted, what data migrates, which integrations flip over, and which legacy system (if any) gets decommissioned or run in parallel. Write this down as a sequence of steps with owners and durations — not a paragraph of prose.
2. Rehearsal
Run the cutover sequence at least once, ideally twice, in a non-production environment that mirrors production as closely as possible. Time every step. The rehearsal's real purpose is finding the steps that take three times longer than anyone estimated — that always happens, and it's much cheaper to discover during rehearsal than during the live event.
3. Go-live execution
The live event should be a checklist read-aloud, not a discussion. Anything requiring judgment calls should have already been decided during design and rehearsal.
4. Stabilization
The 5-10 business days after go-live where the team is on high alert for issues, hypercare support is active, and rollback is still technically on the table if something is fundamentally broken.
Change freeze: protecting the target you're cutting over to
Declare a change freeze on both the source and target environments starting a set number of days before cutover — typically 3-5 business days for a mid-size implementation. No configuration changes, no "quick fixes," no urgent enhancement requests during the freeze. Every exception should require documented executive sign-off, and exceptions should be rare enough that requesting one feels like a big deal.
Field note: the most common cause of a failed cutover isn't a technical defect — it's an unauthorized configuration change made "just to fix one thing" during the freeze window, which then interacts badly with the migration scripts.
Rollback criteria: decide before you need them
Every cutover plan needs explicit, pre-agreed rollback criteria — the conditions under which the team aborts and reverts, rather than pushing forward and hoping. Waiting to define these criteria until the middle of a live cutover means making a high-stakes decision under pressure with an audience watching.
Define rollback criteria for:
- Data migration integrity — what error rate or record-count mismatch triggers a stop
- Integration health — which failed connections are showstoppers vs. tolerable
- Time box — the latest point in the maintenance window you can still roll back cleanly
- Decision authority — exactly who has the power to call a rollback, and their backup
The go-live checklist
A practical, phase-ordered checklist for the cutover window itself:
- Confirm change freeze has held — no unauthorized changes since the last rehearsal.
- Final data backup / snapshot taken and verified restorable.
- Communications sent: cutover start notice to all stakeholder groups, including expected downtime window.
- Legacy system access restricted or set to read-only, per cutover design.
- Data migration executed and record counts reconciled against source.
- Integrations re-pointed to production endpoints and smoke-tested.
- Core workflow smoke tests run by business representatives, not just IT.
- Go/no-go decision made against pre-agreed rollback criteria.
- Go-live communication sent, with hypercare contact information.
- Hypercare monitoring begins — dashboards, ticket queues, and daily check-ins scheduled.
ClearPath PM's ServiceNow Cutover & Go-Live Checklist is built around exactly this sequence, with pre-cutover, cutover-day, and post-cutover tasks pre-loaded — available now for $3.99 as an instant download.
Communication: say more than "we're live"
Cutover communication should answer three questions for every audience: what's changing for me, when exactly does it change, and who do I contact if something looks wrong. Send this at least a week before cutover, again 24 hours before, and once more at go-live confirmation. Silence during a cutover window creates far more support tickets than the cutover itself.
A minimal communication cadence that works
Teams often over-plan the technical cutover and under-plan the messaging around it. A dependable cadence needs only four touchpoints: an initial notice roughly one to two weeks out describing what's changing and why, a reminder 48-72 hours before the freeze begins, a final confirmation immediately before the cutover window opens, and a closing message once the system is confirmed stable. Each message should be short enough to read in under a minute — a wall of technical detail gets skimmed and ignored.
Hypercare: the job isn't done at go-live
Staff a hypercare period — typically one to two weeks — with elevated support coverage, a dedicated triage channel, and daily stand-ups reviewing open issues against the RAID log (see our RAID log guide). Set a clear exit criteria for hypercare: a defined ticket volume threshold or elapsed time, agreed with the sponsor in advance, so "we'll wind it down when things feel calm" doesn't become the plan.
The pattern behind cutovers that go smoothly
Across implementations, the cutovers that stay boring share the same trait: nothing about the live event required a new decision. Every rollback threshold, every communication, every sequencing question was resolved during design and confirmed during rehearsal. The live event becomes an execution exercise, not a decision-making one — which is exactly the point. If your team is debating judgment calls during the maintenance window, that's a sign the planning phase needs another pass, not that the team needs to move faster under pressure.