The Complete Cloud Migration Checklist for 2025
Moving to the cloud is still one of the highest-leverage infrastructure decisions a growing company can make — but the failure rate for DIY migrations remains stubbornly high. This is the checklist we use for every enterprise engagement.
Why Most Cloud Migrations Underperform
The promise was simple: move to the cloud, cut costs by 30%, and deploy faster. The reality for most organizations? A 6-month overrun, a 40% cost overage, and an architecture that's less scalable than what they started with.
After leading over 80 cloud migrations, we've identified the patterns that separate successful transformations from expensive disasters. This checklist covers every phase.
Phase 1: Pre-Migration Assessment (Weeks 1–3)
Application Portfolio Analysis
Before anything else, you need a complete, accurate picture of what you're migrating. This sounds obvious — it's routinely skipped.
Catalog every application: owner, version, dependencies, current performance metrics, and business criticality. Classify each application across two dimensions: technical migration complexity (1–5) and business risk if disrupted (1–5). This matrix determines your migration wave sequence.
High risk + high complexity applications migrate last. Low risk + low complexity migrate first — they're your learning opportunities.
Dependency Mapping
The single most common cause of migration failures is undocumented dependencies. Run network traffic analysis tools for 2–4 weeks to capture actual communication patterns between systems. Document every dependency: APIs called, databases accessed, file shares mounted, ports used.
Applications with circular dependencies or tightly coupled databases require special architecture consideration before migration — not during.
Total Cost of Ownership Modeling
Build a detailed TCO model comparing: current fully-loaded infrastructure costs (hardware, power, cooling, facilities, staff) vs. projected cloud costs (compute, storage, networking, licensing, managed services). Include migration costs and a 12-month optimization runway.
If the 3-year TCO doesn't show at least 20% savings, investigate before proceeding. Either the model is wrong or a different cloud strategy is needed.
Phase 2: Architecture Design (Weeks 3–6)
Migration Strategy Selection (The 7 Rs)
For each application, choose a migration strategy:
Retire: Decommission applications with no active users (you'll find more than expected).
Retain: Keep on-premise — typically regulatory, latency-sensitive, or heavily customized licensed software.
Rehost (Lift & Shift): Move as-is to equivalent cloud instances. Fastest, but captures the least value.
Replatform: Minor optimization during migration (e.g., move to managed RDS instead of self-managed MySQL).
Repurchase: Switch to a SaaS alternative (e.g., Salesforce instead of custom CRM).
Refactor: Re-architect for cloud-native patterns (containers, serverless, managed services). Highest effort, highest long-term value.
Re-engineer: Complete rebuild. Rare — only for applications that are fundamentally incompatible with cloud architecture.
Landing Zone Design
Your cloud landing zone is the foundational account structure, networking, security, and governance configuration that all workloads will run within. Getting this right before migrating anything is critical — retrofitting it later is painful.
Define: account structure (prod/staging/dev separation), network topology (VPC design, transit gateway, on-premise connectivity), IAM strategy, logging and monitoring baseline, and cost allocation tagging taxonomy.
Phase 3: Migration Execution
Wave Planning
Execute migrations in waves of 3–5 applications. Complete a wave, validate, document lessons learned, then proceed. Never migrate more applications in parallel than your team can monitor and roll back simultaneously.
Wave 1 should be low-risk internal tools. Wave 2 introduces customer-facing systems with low traffic. Final waves address business-critical, high-traffic applications.
Cutover Strategy
Every application needs a documented cutover runbook with: step-by-step instructions, estimated duration, rollback procedure with trigger criteria, and communication plan for stakeholders.
The two most common cutover strategies: Big bang (migrate everything at once during a maintenance window — appropriate for small, simple applications) and Parallel run (run old and new environments simultaneously, with traffic gradually shifted — required for business-critical applications with no tolerance for extended downtime).
Post-Migration Validation
Define success criteria before migration, not after. For every application: performance benchmarks (response time, error rate, throughput), data integrity validation queries, security compliance checks, and cost validation against TCO model.
Don't declare a migration complete until all criteria are met and the application has run stable for 5+ business days.
Phase 4: Optimization (Months 3–12)
Right-Sizing
The most common cloud cost mistake: migrating with instance sizes that match on-premise server specs, not actual utilization. Cloud monitoring will show you that most migrated workloads run at 15–25% CPU/memory utilization.
Run your workloads for 4–6 weeks on initial instance sizes, then right-size based on p99 utilization data. Average savings: 25–40% of compute costs.
Reserved Instance and Savings Plan Purchasing
After right-sizing, commit to 1-year reserved instances for steady-state workloads. This alone typically saves 30–40% vs. on-demand pricing. Analyze your usage patterns carefully before committing — unused reservations waste money.
FinOps Practice
Establish a continuous cloud cost governance practice. Weekly cost anomaly reviews. Monthly optimization sprints. Quarterly architecture reviews. Assign cost ownership to engineering teams, not just finance.
The organizations that achieve and sustain 30%+ cost savings vs. on-premise all have a dedicated FinOps function — whether internal or outsourced.
The Checklist Summary
Pre-migration: Application portfolio catalog, dependency mapping, TCO model, landing zone design, rollback procedures documented for every application.
Execution: Wave-based sequencing, parallel run for critical systems, validation criteria defined before cutover.
Post-migration: Right-sizing at week 6, reserved instance purchasing at month 3, ongoing FinOps governance.
Cloud migration is not a project — it's a transformation. Organizations that treat it as a project get the infrastructure moved. Organizations that treat it as a transformation build a competitive capability that compounds over years.
Marcus is a certified AWS Solutions Architect and Google Cloud Professional who has led 80+ cloud migrations. He specializes in financial services and regulated industries.