Cloud migration checklist: 7 phases from assessment to optimization.

Before you start: define why

Cloud migrations go wrong when the goal is simply "move to the cloud". Write down the business reasons, such as exiting a data center, improving resilience, scaling faster or reducing operating effort, and how you will measure them. These reasons will guide every decision below.

Phase 1: Discover and assess

• Inventory applications, databases, servers and storage
• Map dependencies between applications, including batch jobs and integrations
• Record performance baselines and peak usage
• Review licensing, since some licenses don't transfer cleanly to the cloud
• Identify compliance and data-residency requirements
• Estimate total cost of ownership (TCO) for the target state

Phase 2: Choose a strategy per workload (the 7 Rs)

Each workload deserves its own decision. The commonly used "7 Rs" framework gives you the options:

• Retire: switch off applications nobody needs.
• Retain: keep some workloads where they are, for now.
• Rehost ("lift and shift"): move as-is to cloud virtual machines. This is fast but captures few cloud benefits.
• Relocate: move a virtualized environment to the cloud with minimal change.
• Replatform: make targeted changes, such as moving to a managed database.
• Refactor or re-architect: redesign for cloud-native services. This brings the most benefit and needs the most effort.
• Repurchase: replace with a SaaS product.

Phase 3: Build the landing zone

A landing zone is the secure, well-organized foundation that every workload will run on. Build it with infrastructure as code so it is reviewable and repeatable.

• Account or subscription structure for environments and teams
• Network design, connectivity to on-premise systems and DNS
• Identity and access management with single sign-on and least privilege
• Guardrails and policies, such as allowed regions and mandatory encryption
• Central logging, monitoring and alerting
• Cost tagging, budgets and alerts from day one
• CI/CD pipelines for infrastructure and applications

Phase 4: Plan migration waves

Group workloads into waves based on dependencies and risk. Start with a low-risk application to prove the process, then move to more critical systems. For each wave, agree on owners, a test plan, a cutover window and a rollback plan.

Phase 5: Migrate data and applications

• Use replication for databases to minimize downtime
• Validate data integrity with record counts and checksums
• Run functional, performance and security tests in the target environment
• Update integrations, DNS and configuration
• Document runbooks for operating the new environment

Phase 6: Cut over and validate

Rehearse the cutover at least once. On the day, follow the runbook, check against agreed success criteria and keep the rollback option open until you are confident. Plan a "hypercare" period of extra monitoring and support after each go-live.

Phase 7: Optimize continuously

Migration is the start, not the finish. Review costs and performance regularly:

• Right-size instances and switch off idle resources
• Use commitment discounts for steady workloads
• Move infrequently used data to cheaper storage tiers
• Adopt managed services where they reduce operating effort
• Track cost per product or team with tagging and dashboards (FinOps)

Common pitfalls

• Skipping dependency mapping and discovering hidden integrations during cutover
• Lifting and shifting everything, then being surprised by the bill
• Building environments by hand instead of as code
• Treating security and cost governance as a later phase
• No rollback plan

Getting help

Our cloud and DevOps team runs migrations to AWS, Azure and Google Cloud using this approach, and our managed services keep environments healthy afterwards. If you are planning a migration, talk to us about a cloud readiness assessment.

Frequently asked questions