Cloud Migration Checklist: Plan, Move and Optimise
A step-by-step cloud migration checklist for AWS, Azure and Google Cloud: assessment, the 6 Rs, security, cutover planning and cost optimisation.
Northwind Studio Engineering
Editorial Pod
Before You Start
A cloud migration succeeds or fails in planning. Moving servers is the easy part; understanding dependencies, data and people is the hard part. Use this checklist whether you are moving to AWS, Microsoft Azure or Google Cloud.
Phase 1: Assess
- Inventory every application, database, scheduled job and integration.
- Map dependencies between systems, including the undocumented ones.
- Record current performance, availability and monthly cost as a baseline.
- Identify compliance requirements such as data residency, HIPAA or PCI DSS.
- Agree the business goal: lower cost, better resilience, faster releases or retiring a data centre.
Phase 2: Choose a Strategy for Each Application
The widely used "6 Rs" framework:
- Rehost: lift and shift with minimal change. Fastest, but keeps old inefficiencies.
- Replatform: small changes such as moving to a managed database.
- Refactor: redesign for cloud-native services. Most effort, most long-term benefit.
- Repurchase: replace with a SaaS product.
- Retire: switch off what nobody uses.
- Retain: keep on-premises for now.
For tightly coupled legacy systems, an incremental approach such as the Strangler Fig pattern reduces risk.
Phase 3: Build the Landing Zone
- Account or subscription structure, separated by environment.
- Identity and access management with least privilege and single sign-on.
- Network design, encryption defaults and logging.
- Infrastructure as code (for example Terraform) so environments are reproducible.
- Budgets and cost alerts from day one.
Phase 4: Migrate
- Start with a low-risk application to prove the process.
- Replicate data continuously before cutover to keep downtime short.
- Automate deployments with a CI/CD pipeline. See our DevOps and CI/CD service.
- Write a cutover runbook with a rollback plan and named owners for each step.
Phase 5: Validate
- Compare performance against the baseline.
- Run functional, security and failover tests.
- Confirm monitoring, alerting and backups work as expected.
- Get sign-off from business owners.
Phase 6: Optimise
- Right-size instances based on real usage.
- Use autoscaling and managed services to reduce idle capacity.
- Consider commitment discounts once usage is stable.
- Review costs monthly and tag every resource by owner and environment.
Common Mistakes
- Migrating without a dependency map.
- Underestimating data transfer time for large databases.
- Leaving old infrastructure running and paying twice.
- Treating security as a final step instead of a design input.
Our cloud architecture and migration team plans and executes migrations with zero-downtime cutover strategies.
Frequently Asked Questions
How long does a cloud migration take?
A single application can move in weeks. A full data-centre exit usually takes several months and is done in waves.
Will moving to the cloud reduce my costs?
It can, but only with right-sizing, autoscaling and active cost management. A pure lift and shift sometimes costs more at first.
Which cloud provider should I choose?
Choose based on your team's skills, the managed services you need, compliance requirements and existing licences. All three major providers are capable.
How do I avoid downtime during migration?
Replicate data continuously, test the cutover in rehearsal, and switch traffic gradually with a tested rollback plan.