A cloud migration checklist should identify what moves, who authorises the switch, how data stays consistent and what happens if acceptance checks fail. Rehearse the cutover and recovery procedure using representative conditions. Infrastructure being available is not sufficient evidence that the business service is ready for users.
Let’s plan your cloud migration cutover.
Bring your workflow, constraints and open questions. We’ll help you define the scope and work through the next decision.
Start with a service boundary and an accountable owner
Write the scope in operational terms: which users and workflows move, which dependencies remain elsewhere, and which records are authoritative during each stage. Record the interruption the business can tolerate and any deadlines that make the proposed window unsuitable.
Check that the migration team can access the source and target, including identity, networking, deployment, databases and observability. Resolve permissions before the migration window. A credential request raised during cutover can turn a reversible step into an extended outage.
Create a cutover runbook that can be executed
| Stage | Required check | Decision owner |
|---|---|---|
| Assessment | Inventory, dependencies and unsupported components reviewed | Service owner |
| Rehearsal | Timed copy, validation and recovery exercised | Migration lead |
| Before switching | Backup, change controls and communications confirmed | Go/no-go authority |
| Data transition | Write ownership and final synchronisation verified | Data owner |
| User switch | Representative journeys and access checks pass | Business representative |
| Stabilisation | Monitoring, reconciliation and support coverage active | Operations lead |
| Retirement | No remaining consumers or required recovery dependency | Service owner |
Give each runbook step an expected result, maximum wait and escalation contact. Record actual times during rehearsal so the final plan reflects observed work rather than an optimistic sequence of headings.
Define rollback before accepting new writes
Switching traffic back is not necessarily a complete rollback. If users have created records in the target, returning to an older source may lose or conflict with those changes. Specify how post-switch writes will be preserved, reconciled or deliberately blocked during a controlled validation period.
Separate failures that justify rollback from defects that can be corrected in place. Name the decision deadline and the person who can authorise it. If a step is effectively irreversible, document the recovery procedure and its consequences instead of promising an instant reversal.
Test business behaviour after the switch
Use an agreed test identity and authorised records. Verify sign-in, permissions, an important transaction, attachments, scheduled work and an integration outcome. Compare resulting data with expected values. Keep evidence of the checks and unresolved differences.
Monitor long enough to cover the business cycles that matter, including overnight jobs where relevant. Do not decommission the source simply because the first browser check passed. Retain it only under an explicit access, cost and retirement plan.
Common migration questions
Is zero downtime always possible?
It depends on application design, replication and dependency constraints. Agree an evidence-based interruption target after assessment and rehearsal.
Does a successful backup prove rollback will work?
No. Restore access, compatibility, recovery time and post-backup writes also matter. Demonstrate the recovery path in the agreed environment.
Use the migration cost inventory before budgeting, and bring the service boundary and transition constraints to a cloud migration planning call.