Moving workloads from on-premises infrastructure to the cloud is one of the most complex, high-stakes IT projects an organisation undertakes. A structured approach - phased discovery, risk analysis, wave planning, and rigorous testing - is the difference between a successful migration and a multi-month recovery effort. This guide covers the full migration lifecycle from initial discovery through post-migration optimisation.
On this page
The 6-Phase Migration Journey
- 1
Phase 1: Discovery & Current State Assessment
Catalogue all assets, applications, and dependencies. Build a complete inventory of what runs where. Understand data volume, network topology, and performance baselines.
- 2
Phase 2: Portfolio Analysis & 7R Classification
Classify every workload using the 7Rs (Rehost, Replatform, Refactor, Repurchase, Retire, Retain, Relocate). Define your migration waves based on interdependencies and risk.
- 3
Phase 3: Landing Zone Design & Build
Design your target cloud architecture: account structure, VPC/network design, IAM policies, security baselines, monitoring, and compliance controls. Build and test the foundation before migrating anything.
- 4
Phase 4: Migration Execution (Wave by Wave)
Execute migrations in waves starting with low-risk, non-production workloads. Use automated migration tools. Keep wave sizes small to limit blast radius.
- 5
Phase 5: Validation & Business Sign-Off
Verify migrated workloads meet performance SLAs, security requirements, and functional requirements. Run parallel operation before decommissioning on-prem.
- 6
Phase 6: Optimisation & Governance
Right-size instances, implement cost anomaly detection, enforce tagging policies, enable cloud-native services (managed DBs, serverless, auto-scaling) to reap cloud-native benefits.
Phase 1: Discovery Checklist
Migration Wave Planning
Wave planning sequences workloads based on complexity, risk, and interdependencies. Tightly coupled applications must move together in the same wave. Start with low complexity and low business criticality to build team confidence.
| Wave | Workload Type | Typical Approach | Duration | Example Workloads |
|---|---|---|---|---|
| Wave 0 - Pilot | Non-production, isolated workloads | Rehost (Lift & Shift) | 2–4 weeks | Dev/test environments, internal tools |
| Wave 1 - Low risk | Stateless or low-traffic production apps | Rehost / Replatform | 4–8 weeks | Static web apps, lightweight APIs, monitoring tools |
| Wave 2 - Medium risk | Business apps with moderate criticality | Rehost with testing | 6–10 weeks | CMS, internal portals, file servers |
| Wave 3 - High risk | Core business apps, customer-facing | Rehost + parallel run | 8–16 weeks | ERP, CRM, main web applications |
| Wave 4 - Complex | Data platforms, databases, real-time systems | Replatform / Refactor | 12–24 weeks | Databases, data warehouses, event streaming |
Wave 0 - Pilot
- Workload Type
- Non-production, isolated workloads
- Typical Approach
- Rehost (Lift & Shift)
- Duration
- 2–4 weeks
- Example Workloads
- Dev/test environments, internal tools
Wave 1 - Low risk
- Workload Type
- Stateless or low-traffic production apps
- Typical Approach
- Rehost / Replatform
- Duration
- 4–8 weeks
- Example Workloads
- Static web apps, lightweight APIs, monitoring tools
Wave 2 - Medium risk
- Workload Type
- Business apps with moderate criticality
- Typical Approach
- Rehost with testing
- Duration
- 6–10 weeks
- Example Workloads
- CMS, internal portals, file servers
Wave 3 - High risk
- Workload Type
- Core business apps, customer-facing
- Typical Approach
- Rehost + parallel run
- Duration
- 8–16 weeks
- Example Workloads
- ERP, CRM, main web applications
Wave 4 - Complex
- Workload Type
- Data platforms, databases, real-time systems
- Typical Approach
- Replatform / Refactor
- Duration
- 12–24 weeks
- Example Workloads
- Databases, data warehouses, event streaming
Wave | App Name | 7R Strategy | Target Service | Dependencies | Migration Date | Owner | Status --------|------------------|-------------|--------------------------|--------------|----------------|--------------|-------- Wave 0 | Dev environment | Rehost | AWS EC2 + EBS | None | 2026-05-01 | DevOps Lead | Planning Wave 1 | Company website | Replatform | S3 + CloudFront (static) | None | 2026-06-01 | Dev Lead | Not Started Wave 2 | HR portal | Rehost | EC2 + RDS PostgreSQL | AD/LDAP | 2026-07-15 | IT Manager | Not Started Wave 3 | ERP system | Rehost | EC2 + EBS (multi-AZ) | HR portal | 2026-09-01 | CTO | Not Started
Migration Execution Checklist
Post-Migration Validation Checklist
Why Migrations Fail - Top 8 Reasons
- Insufficient discovery: Missing application dependencies leads to broken integrations and forced rollbacks.
- No landing zone: Migrating into an unstructured cloud environment creates security and governance debt from day one.
- Over-ambitious wave scopes: Large waves mean large blast radius when issues occur. Keep waves small.
- Licensing surprises: BYOL vs new licences for Windows Server, SQL Server, or Oracle can double costs if unplanned.
- Network throughput underestimated: Large data volumes over insufficient links extend migration windows by weeks.
- No parallel run period: Cutting over immediately without parallel operation removes the safety net.
- Skills gap: Teams without cloud experience make configuration mistakes that are expensive to find post-migration.
- Missing rollback: No documented, tested rollback procedure turns any problem into a major incident.
What’s next?