Cloud migration done right can transform your infrastructure. Done wrong, it is an expensive, downtime-filled disaster. This playbook covers the planning, execution, and validation you need to migrate safely.
Why Cloud Migration Projects Fail
The cloud migration failure rate is embarrassingly high — Gartner estimates that through 2024, over half of cloud migration projects experienced significant delays, cost overruns, or performance degradation. The common thread: treating migration as a pure technical project rather than a business transformation requiring careful planning, testing, and change management.
The Assessment Phase: Know Before You Go
Application Portfolio Analysis
Catalogue every application in your estate. For each: document the technology stack, dependencies, integration points, data volumes, performance requirements, and business criticality. This is tedious but essential. Surprises discovered during migration cost 10× more to resolve than surprises discovered during planning.
Dependency Mapping
Applications that appear independent often have hidden dependencies — shared databases, file system paths, network shares, hardcoded IP addresses. Use discovery tools (AWS Migration Hub, Azure Migrate, or Cloudamize) to map actual network traffic. What applications talk to what, on which ports, at what volumes?
The 6Rs Migration Framework
Rehost (Lift and Shift)
Move the application as-is to cloud VMs with minimal modification. Fastest to execute, delivers modest cost savings (10–20%), sets the foundation for optimisation. Appropriate for applications where re-architecture is not justified by business value.
Replatform (Lift and Reshape)
Move to cloud with targeted optimisations: swap self-managed MySQL for RDS, replace a file server with S3, use a managed container service instead of self-managed Kubernetes. More effort than rehost, but eliminates significant operational overhead.
Refactor / Re-architect
Redesign the application to fully leverage cloud-native capabilities: serverless functions, managed services, auto-scaling. The highest ROI option long-term, but requires the most time and skill. Reserve this for your strategically important, high-traffic applications.
Retire, Retain, and Repurchase
Not every application needs to move to cloud. Some should be retired (sunset legacy applications serving no current business purpose). Some should remain on-premises (latency-sensitive industrial control systems, data sovereignty requirements). Some should be replaced with SaaS alternatives.
The Migration Execution Phases
Phase 1: Foundation (Weeks 1–4)
Establish your AWS Landing Zone — VPC architecture, IAM policies, security baselines, logging and monitoring infrastructure, and cost management tooling. Never start migrating workloads into an unstructured AWS account. The Landing Zone is your cloud foundation — get it right.
Phase 2: Pilot Migration (Weeks 4–8)
Migrate one or two non-critical, low-complexity applications. The purpose is not to save money — it is to build team capability, validate your tooling, and discover what your assessment phase missed. Every pilot migration reveals surprises. Better to discover them on a non-critical app.
Phase 3: Wave Migration
Migrate applications in dependency-ordered waves. Applications with no dependencies migrate first. Applications that depend on already-migrated services migrate second. The final wave includes your most complex, most critical, most interdependent applications.
Zero-Downtime Cutover Strategies
Blue-Green Deployment
Run old (blue) and new (green) environments in parallel. Switch DNS when green is validated. Rollback is a DNS switch back. Works best for stateless applications where data sync is not required.
Strangler Fig Pattern
Route specific features or API endpoints to the new cloud environment while the legacy system remains operational. Incrementally migrate traffic until the legacy system is strangled. This is the lowest-risk approach for complex monolithic applications.
Post-Migration Optimisation
Migration is not completion — it is the beginning. Right-size instances based on actual cloud usage metrics (not on-premises sizing). Implement Reserved Instances or Savings Plans for predictable workloads (40–60% cost reduction). Enable auto-scaling and eliminate idle capacity. The real TCO benefits of cloud emerge 6–12 months after migration, not immediately.
Expert insights on AI, software engineering, and digital transformation from the TechGeneses team of engineers and strategists.