System Cutover Template for Agile Teams

Schedule 1.5x your rehearsal time. If the rehearsal took 4 hours, schedule 6 hours. The extra buffer accounts for unexpected delays: slower data sync, network issues, team coordination overhead under real-stakes pressure. Starting too early is far better than running past your window. If the cutover finishes early, you can open traffic sooner.

The point of no return is the step after which rollback becomes significantly more difficult or impossible. Typically this is after data has been written to the new system by real users. Before this point, rollback is a configuration change. After it, rollback requires data reconciliation. Clearly mark this point in your runbook and make the go/no-go decision explicit before crossing it.

Off-hours whenever possible. Weekend early morning windows (01:00-07:00 local time) minimize both user impact and the volume of support tickets if something goes wrong. If off-hours are not possible (24/7 global service), choose the period with the lowest request volume based on your traffic patterns. Never schedule a cutover on a Friday afternoon.

Every person who has a step in the runbook, plus one communications lead, plus the cutover commander. Typically 6-15 people. Everyone else should stay out of the war room channel to keep signal-to-noise ratio high. Create a separate broadcast channel for status updates that observers can follow without contributing noise to the execution channel.

This is why you keep the old system running for 24-48 hours. If the problem is minor (cosmetic, non-blocking), fix it on the new system. If the problem affects data integrity or core functionality, evaluate rollback versus fix-forward based on the severity and estimated fix time. If rollback takes 30 minutes and the fix takes 4 hours, roll back. Communicate transparently with customers regardless of which path you choose.