Nothing else in a cloud migration should start before a single responsible lead has approved a current assessment of every workload in scope. Where that approval is missing, the work proceeds on unverified beliefs about dependencies, and the first sign of trouble arrives after cutover, when recovery is slowest and most visible.
This page lays out the order a cloud migration takes, from the assignment of responsibility and the assessment through to the checks that continue after go-live. It spells out the evidence each step should leave behind and the thresholds that decide whether a workload proceeds, waits or is refused. Read it if you run a migration batch, chair a change board, or control the budget for one. The pages on assessment, cost and platform choice go deeper on each area; this one keeps to the order the work takes.
1. Assign responsibility and approve a current assessment for every workload
Assign one responsible lead who can speak for the application, its data and the business process behind it. Complete the workload assessment before any migration approach is chosen. The NHS Cloud Centre of Excellence guidance on choosing a cloud migration strategy says a workload assessment is an essential tool to structure and communicate your application transformation roadmap, and that the approach selected affects migration effort, benefit and long-term running cost. Log dependencies, data classification, downtime tolerance, failure modes, clustering support and the method used to push configuration changes.
Google Cloud's guidance on validating a migration plan tells teams to finish the assessment before going further, and to check how fresh the inventory is, what downtime a workload can absorb, where redundancy exists and how changes reach production. Close the step when one responsible lead has approved the assessment and that approval is on file. A workload missing either stays out of the batch.
2. Give every migration step a tested rollback and a maximum run time
Write the rollback procedure, the trigger that begins it, and the longest time the step may run before rollback starts. Google Cloud recommends a rollback strategy for each step of the plan, reviewed and tested on a schedule, with a maximum allowed execution time after which teams begin rolling back. CACI's 2026 guide to cloud migration risks makes a rollback plan a requirement of every batch and advises moving workloads in stages with clear objectives instead of in a single attempt.
Rollback is where plans most often fall short: teams rehearse the move and never rehearse the return. Close the step when the rollback has been exercised outside production, the trigger can be watched on a dashboard, and the maximum run time appears in the plan. A step whose return path has never been run is not ready to schedule.
3. Reproduce the migration at small scale and inject faults
Build a proof of concept that repeats the migration on a small scale, then break it deliberately: cut network connectivity, take a dependency offline, degrade performance, deliver the same message twice. Google Cloud's guidance says to simulate failures and inject faults in a non-critical environment, and to iterate through several proofs of concept until the success criteria are met. Close the step when a log shows each failure mode, the recovery observed and any gap that remains. The full migration waits until the responsible lead accepts those gaps or closes them.
4. Design identity, data protection and network controls before production traffic moves
Classify data, define least-privilege roles, enable encryption in transit and at rest, configure logging, and choose regions against legal and contractual obligations. CACI's guide identifies misconfigured identity and access management as a leading root cause of cloud incidents and recommends security built in from the start, shared responsibility and governance that is enforced. F1 Group's 2026 guidance for Microsoft environments treats sovereignty as a decision taken workload by workload, taking in legal obligations, supplier contracts, processing locations, backup design and recovery requirements. Close the step when the security lead confirms that roles, encryption, logging and region choices match the assessment. Production traffic waits while any item remains unverified.
5. Put cost and governance controls in place before the first production resource
Agree tagging, budgets, cost responsibilities and a review rhythm before anything is provisioned. CACI's 2026 guide reports that organisations spend on average 14% more than planned on migration and that 38% of migrations run more than three months behind, while 84% of organisations struggle to control cloud spend (CACI). F1 Group's research found that 80% of UK mid-market firms met unexpected costs during public cloud migrations. Cost control belongs in the plan from the first sprint; retrofitting it after go-live leaves you paying for waste you cannot trace to a workload. Close the step when every resource is tagged, every budget has an alert with a responder assigned to it, and a licence review is complete.
6. Move in small batches with progressive rollout and a defined pause point
Group workloads by dependency instead of by department, and move the lowest-risk group first. Use canary deployment, feature flags, or a small share of live traffic. Google Cloud recommends gradual rollouts that keep each change small, and alerting the development and operations teams responsible for both the source and target environments before a batch begins. Close the step when each batch has a go-live decision, a rollback trigger, approvers listed in the plan and a period of closer support. The next batch starts only after the previous one keeps to its performance and error-rate baseline.
7. Verify recovery, performance and compliance after go-live
Capture a baseline before the move, then test restore and failover against the agreed recovery time and recovery point objectives. Review access, policy results and supplier documentation. F1 Group's guidance says backup and disaster recovery belong to each application, with business leads agreeing how much data loss and downtime they will accept, and restoration proven against those targets. Close the step when the post-go-live pack contains a completed restore test, performance measured against the pre-migration baseline, and an access review with no critical findings left open. A migration is finished only when it can show recovery.
Two thresholds gate every batch:
- Recovery time objective under one hour: the workload needs a failover tested to complete within that window before production traffic moves to it.
- Unsupported runtime dependency: the workload stays out of production until the dependency is remediated or the responsible lead logs acceptance of the risk.
Treat both as minimums. The executive sponsor needs responsibility and cost settled at steps 1 and 5 before anything else is approved, and every batch needs its rollback exercised at step 2 before a cutover window is booked. Work the sequence in order; a shortcut taken early tends to surface in the post-go-live pack, when the restore test does not pass.
