Cloud migration cutovers
Keep one cutover record everyone can follow
During a migration window, conflicting status reports create avoidable risk. Record the current phase, evidence and decision owner in one shared run log.
In this article
Start with the actual state
At the beginning of the window, confirm the reviewed runbook version, participants and required access. Record which environment owns writes and whether any prerequisite remains unresolved.
Do not mark a prerequisite complete based only on an earlier rehearsal. Credentials, network rules and replication health can change before the live window.
Use explicit timezones in the schedule. A team working across Australian states and overseas support locations should not have to infer what a bare time means.
Record evidence as steps finish
Each consequential step should identify its owner, completion time and verification result. Link to relevant dashboards or controlled logs instead of pasting large volumes of sensitive output.
Distinguish started, completed and verified. A data-transfer process can finish while reconciliation is still pending.
If a step fails, record the observed state before deciding the next action. Repeating a command without knowing whether it partly succeeded can create a second problem.
Protect the decision checkpoints
Pause at the agreed boundary before enabling target writes. Confirm the source fence, final data state and business checks required at that point.
After new writes begin, make the changed recovery policy visible. Participants must not independently route traffic back under the assumption that the old environment remains current.
Assign one decision owner for the overall proceed or recover action. Technical owners provide evidence for their components, but the service needs a coordinated decision.
Close with an operational handover
Record the final authoritative environment, unresolved issues and observation responsibilities. State which old resources remain available and why.
Include held queues, temporary access and scheduled jobs that require follow-up. An application can appear healthy while a forgotten paused worker accumulates hours of work.
Publish the next review time and escalation route to the team responsible for support. The run log should let an engineer arriving after the cutover understand the current system without reconstructing a long chat history.
Primary sources
AWS: creating migration runbooksReferences checked 11 September 2026.