Cloud migration sounds straightforward on paper: move your applications and data from on-premises infrastructure to the cloud. In practice, it’s one of the most complex undertakings an enterprise IT team will manage — and one of the most consequential when done poorly.

Failed cloud migrations share common characteristics: inadequate discovery, underestimated complexity, insufficient security planning, and unrealistic timelines. This guide outlines a structured approach to avoid those pitfalls.

Phase 1: Discovery and Assessment

You cannot migrate what you don’t understand. The discovery phase is the foundation of every successful migration.

  • Application inventory: Catalog every application, its dependencies, its data volumes, and its performance characteristics
  • Dependency mapping: Understand how applications communicate with each other
  • Licensing assessment: Some on-premises licenses don’t transfer to cloud; identify and budget for gaps
  • Technical debt identification: Applications running on end-of-life OS or middleware need attention before migration

The 7 Rs of Cloud Migration

Every application in your portfolio fits into one of these migration strategies:

  1. Rehost (Lift and Shift) — Move as-is with no changes. Fast but misses cloud-native benefits
  2. Replatform (Lift, Tinker, and Shift) — Minor optimizations without architectural changes (e.g., moving to managed database)
  3. Repurchase — Replace with a SaaS alternative (e.g., replace on-prem CRM with Salesforce)
  4. Refactor / Re-architect — Re-design for cloud-native. Highest cost, highest long-term benefit
  5. Relocate — Move infrastructure to cloud with same tools (e.g., VMware Cloud)
  6. Retain — Keep on-premises for now (regulatory, latency, or complexity reasons)
  7. Retire — Decommission applications that are no longer needed

“Most enterprises start with rehost for speed, then systematically re-architect their most important workloads once they’ve built cloud operational muscle. This phased approach consistently outperforms big-bang re-architecture.” — AWS Migration Practice

Phase 2: Foundation and Landing Zone

Before migrating any workloads, establish your cloud foundation:

  • Account structure: Multi-account strategy with clear environment separation (dev, staging, prod)
  • Networking: VPC design, connectivity to on-premises (Direct Connect or VPN), DNS architecture
  • Identity and access: Federate with existing identity provider, implement least-privilege baseline
  • Security controls: Logging, monitoring, guardrails, and compliance baselines
  • Cost management: Tagging strategy, budgets, and alerting from day one

Phase 3: Migrate in Waves

Organize applications into migration waves based on complexity, business criticality, and dependency chains:

  1. Wave 1 — Quick wins: Non-critical, standalone applications with no complex dependencies
  2. Wave 2 — Core systems: Internal tools and moderately complex workloads
  3. Wave 3 — Critical workloads: Revenue-generating and customer-facing applications
  4. Wave 4 — Complex/legacy: Applications requiring re-architecture or significant remediation

Common Migration Mistakes

  • Skimping on the assessment phase — Unknown dependencies cause the most migration failures
  • Ignoring security until after migration — Security must be designed in from the start
  • No cloud FinOps practice — Without cost governance, cloud bills often shock organizations
  • Treating migration as a one-time project — Cloud optimization is ongoing, not a destination

A well-executed cloud migration is transformational — it changes not just where your workloads run, but how your team operates, deploys, and iterates. Invest in the foundation and the migration pays dividends for years.