Cloud migration failures are expensive. A 2024 Gartner study found that 30% of cloud migrations go over budget, and 25% result in unplanned downtime. The root cause in nearly every case is insufficient pre-migration planning — not technical problems with the cloud platform itself.
This checklist covers the 12 critical steps you must complete before moving a single workload to AWS, Azure, or Google Cloud. Follow it and you significantly reduce the risk of the most common and costly migration problems.
Why Cloud Migrations Fail
Before the checklist, it's worth understanding the failure modes:
- Underestimated data migration complexity: Moving terabytes of data with minimal downtime is harder than it looks.
- Unidentified dependencies: Application A depends on Application B, which depends on a shared database — and nobody documented it.
- Licensing surprises: On-premise software licences often do not transfer to cloud VMs without additional fees.
- Scope expansion: "While we're at it, let's modernise this app too" — modernisation mid-migration dramatically increases complexity and risk.
- Inadequate rollback planning: When something goes wrong (and something always goes wrong), no clear path back means prolonged outages.
The 12-Step Pre-Migration Checklist
Step 1: Define Clear Business Objectives
Before selecting a cloud platform or migration strategy, document what you are trying to achieve. Cost reduction? Disaster recovery capability? Scalability for growth? Exiting a data centre lease? Different objectives lead to different migration approaches. Fuzzy objectives lead to fuzzy outcomes.
Step 2: Conduct a Complete Asset Inventory
You cannot migrate what you haven't catalogued. Produce a full inventory of every server (physical and virtual), application, database, network device, and integration. Tools like AWS Migration Hub, Azure Migrate, or third-party tools like CloudEndure or Turbonomic can automate discovery. Do not rely on CMDB entries alone — they are almost always out of date.
Step 3: Assess Each Workload for Cloud Readiness
Apply the 7 Rs framework to each application: Retire, Retain, Rehost (lift-and-shift), Replatform, Repurchase, Refactor/Re-architect, or Relocate. This assessment determines the migration strategy and effort for each workload.
Step 4: Map Application Dependencies
This is the step most teams underinvest in. Use network traffic analysis tools (AWS Application Discovery Service, Azure Service Map, or tools like Dynatrace) to automatically map which applications communicate with which others, including all ports and protocols. Undiscovered dependencies cause the most critical migration failures.
Step 5: Review Software Licences
Check every licensed software product in your inventory for cloud portability terms. Microsoft, Oracle, and IBM in particular have complex cloud licensing rules. Some products require a new licence for cloud VMs; others include Software Assurance or mobility rights. Get written confirmation from vendors before migrating.
Step 6: Define Data Classification and Compliance Requirements
Identify which data is sensitive, regulated, or subject to data residency requirements. For Indian companies: RBI guidelines require financial data to be stored in India. Healthcare data has different requirements. GDPR applies to any data about EU citizens. Confirm your chosen cloud region and data handling practices comply before migration.
Step 7: Design Your Target Cloud Architecture
Do not replicate your on-premise architecture in the cloud — it is expensive and defeats many of the cloud's benefits. Design a cloud-native target architecture with appropriate use of auto-scaling groups, managed services (RDS instead of self-managed databases, etc.), VPC design, IAM policies, and security groups. This design should be reviewed by a cloud architect before migration begins.
Step 8: Estimate and Optimise Costs Before You Migrate
Use the AWS Pricing Calculator, Azure Pricing Calculator, or Google Cloud Pricing Calculator to model your expected monthly cloud spend. Compare this against your current infrastructure costs including hardware, data centre space, power, and staffing. Then right-size your instance selections — do not simply replicate on-premise VM sizes in the cloud.
Step 9: Plan Your Network Connectivity
Decide how your cloud environment will connect to on-premise systems during and after migration. Options include site-to-site VPN (lower cost, higher latency), AWS Direct Connect / Azure ExpressRoute (dedicated, low latency but more expensive), or hybrid architectures. Plan your DNS strategy — how will internal and external DNS records be updated during cutover?
Step 10: Build Your Security Baseline
Before any workloads arrive, implement your cloud security foundation: IAM roles and least-privilege policies, security groups and network ACLs, CloudTrail / Azure Monitor logging enabled, encryption at rest and in transit configured, and a SIEM integration planned. Security configuration is much harder to retrofit after workloads are running.
Step 11: Create a Detailed Migration Wave Plan
Sequence your migrations intelligently. Start with non-critical, low-complexity workloads to build your team's confidence and identify process issues before they affect critical systems. Group dependent applications in the same migration wave to avoid split states. Define clear cutover windows, rollback criteria, and communication plans for each wave.
Step 12: Test Your Rollback Procedure
Before the first production migration, run a full rollback drill in a non-production environment. Document exactly how you would revert a migrated workload to on-premise if something goes wrong during cutover. Know your RPO (how much data you can afford to lose) and RTO (how long you can be down) for each critical system, and verify your rollback procedure meets those requirements.
Choosing Your Migration Strategy
Lift-and-Shift (Rehost): Move virtual machines to cloud equivalents with minimal changes. Fastest path to cloud, lowest risk during migration, but misses many cloud-native optimisation opportunities. Good for legacy applications you plan to retire within 2–3 years, or as an interim step before modernisation.
Replatform: Make targeted cloud-optimised changes without full re-architecture — for example, moving from self-managed MySQL to Amazon RDS or Azure Database for MySQL. Modest effort, meaningful operational benefit.
Refactor/Re-architect: Redesign applications as cloud-native, microservices-based, or serverless. Highest effort and risk, but delivers the greatest long-term benefit in scalability, resilience, and operating cost. Best for applications that are strategic to your business and will be actively developed.
Post-Migration Validation
After each migration wave, before you decommission on-premise infrastructure:
- Run full functional testing of all migrated applications
- Validate performance benchmarks match or exceed on-premise baselines
- Confirm all integrations are working correctly
- Verify backup and monitoring are active
- Monitor for at least 30 days before decommissioning the source environment
Cloud migration done well is transformational. Done poorly, it is a multi-crore lesson in preparation. Our Cloud & DevOps team has migrated dozens of organisations to AWS and Azure, and we bring a structured, risk-managed approach to every project. Talk to us about your cloud migration requirements.