Go-live & adoption
Cutover runbook
The actual switch — minute-by-minute, with role assignment, freeze window, communication and an explicit roll-back button. A good cutover is boring; that is exactly the goal.
Updated May 18, 2026
Go-live · 5.4
Why this matters now
Cutover is the moment when all the preparation comes together. Improvising here costs days, not hours. A good runbook feels overly detailed — until someone at 02:14 in the morning has to make a decision under pressure and the script tells them exactly what to do.
What do you deliver?
Runbook
Step-by-step script with times, actions, owners and validations.
Role assignment & war room
Who sits where, who calls who, physical or virtual war room.
Roll-back criteria
Which situation triggers reverting, who decides, how you do it.
Communication matrix
What you communicate internally and externally, when, via which channel.
Key questions
- 1When — weekend, holiday period, Friday evening? What is the quietest window with the least impact?
- 2Freeze window — from which moment can no more changes be made in source systems? How do you communicate that?
- 3Role assignment — cutover lead, tech lead, communication, business validator, sponsor on-call? A back-up per role.
- 4Steps — for every action: what do you do, how long does it take, who executes, which check validates success?
- 5Decision points (gates) — after which steps can you proceed and what are the criteria? Who signs off?
- 6Roll-back procedure — concretely described, tested in dry run. Which actions, how long does it take, what is the point of no return?
- 7Communication — user message beforehand, status page during, "everything is live" message after. Per channel and language.
- 8External parties — Gfacility implementation consultant, IdP supplier, hosting, possibly M365 tenant admin: who is on standby, on which escalation line?
- 9Smoke tests right after go-live — which 10-15 scenarios do you run to gain confidence that it works?
- 10Security — service accounts, API keys, OAuth secrets — who holds them, how do you store them safely over the weekend?
Template — Runbook (excerpt)
| Time | Step | Owner | Validation | Roll-back? |
|---|---|---|---|---|
| Fri 18:00 | Communication "freeze start" | PM | Email sent, intranet banner | N/A |
| Fri 19:00 | Source system in read-only | Source admin | Manual write test fails | Reset to read-write |
| Fri 19:30 | Final delta export | Tech lead | Counts ≥ expected | Re-run script |
| Fri 20:30 | Migration script production | Tech lead | Logs clean, count matches | Snapshot restore |
| Fri 22:00 | Activate SSO + integrations | IT-Identity | Test account login | SSO config rollback |
| Fri 23:00 | Smoke tests (15 scenarios) | Business validators | 14/15 PASS | Decision per scenario |
| Sat 00:00 | Go/no-go gate 1 | Cutover lead | Sponsor signs | → Roll-back |
| Sat 09:00 | Champions test on-site | Champions | Issue log ≤ 5 P2 | — |
| Sun 18:00 | Communication "live Mon 8:00" | PM | Email + Teams + intranet | — |
| Mon 08:00 | Hypercare officially started | Hypercare lead | Hotline open | — |
| … | … | … | … | … |
Template — Roll-back criteria
Trigger 1 — Data quality
Difference > 2% in totals between source and target after migration. Roll-back decision within 30 min.
Trigger 2 — SSO fails
> 5% of test accounts cannot log in. Roll-back unless workaround within 60 min.
Trigger 3 — Smoke test fails
> 3 of 15 scenarios fail. Do not pass any go/no-go gate. Problem analysis + decision.
Point of no return
Saturday 12:00 — after that, roll-back is no longer feasible without losing the weekend's work. Decide before that moment.