Cloud migration is one of the most complex undertakings in enterprise software. Done right, it unlocks elastic scalability, reduced operational overhead, and modern developer workflows. Done wrong, it creates costly downtime, data loss, and a team that's burned out and demoralized.
We've run cloud migrations for enterprises across manufacturing, healthcare, logistics, and fintech. Here's what we've learned.
The 6 R's of Cloud Migration
Every workload you migrate falls into one of six categories. Understanding which applies to each service dramatically reduces risk:
Rehost (Lift & Shift)
Move VMs as-is to the cloud. Fast and low-risk, but you miss out on cloud-native benefits. Good for legacy apps with imminent on-prem contract expiry.
Replatform
Minor optimizations without changing core architecture — e.g., moving from self-managed MySQL to RDS. Best ROI for most applications.
Refactor / Re-architect
Rebuild parts for cloud-native patterns — microservices, serverless, containers. High effort, high reward. Prioritize for growth-critical services.
Repurchase
Replace the application with a SaaS equivalent — e.g., moving from self-hosted CRM to Salesforce. Eliminates maintenance burden.
Retire
Decommission unused or redundant systems. Enterprises are often surprised how much 10–15% of their estate falls here.
Retain
Keep on-premises for now. Regulatory, latency, or licensing reasons. Revisit in 12–24 months.
Phase 1: Discovery & Assessment (Weeks 1–4)
Before moving anything, map your entire estate. Use tools like AWS Migration Hub, Azure Migrate, or CloudHealth to inventory every server, database, and dependency. The goal is a dependency map — a visual graph of what talks to what.
Critical lesson: Never start migration without a dependency map. The number one cause of unplanned downtime during cloud migrations is undocumented service dependencies discovered mid-migration.
Phase 2: Foundation & Landing Zone (Weeks 5–8)
Set up your cloud landing zone before migrating a single workload. This includes:
- Account structure and organization hierarchy (AWS Organizations / Azure Management Groups)
- Network architecture — VPCs, subnets, Transit Gateways, ExpressRoute / Direct Connect
- Identity — IAM, SSO, and directory integration
- Security baselines — GuardDuty, Security Hub, Defender for Cloud
- Logging and monitoring — CloudTrail, CloudWatch, Azure Monitor
- Cost management and tagging policies
Phase 3: Pilot Migration (Weeks 9–14)
Pick a low-criticality workload to migrate first. Not the most important system — something real, but with manageable blast radius if things go sideways. Run it in parallel with the on-prem version for 2–4 weeks before cutting over.
Phase 4: Wave-Based Migration (Months 4–18)
Organize remaining workloads into migration waves based on dependency groups. Typically 4–8 waves for a large enterprise. Each wave follows the same pattern: plan, migrate, test, cut over, validate, and decommission the on-prem equivalent.
Phase 5: Optimization (Ongoing)
Migration is not the finish line — it's the starting point. Post-migration, focus on:
- Right-sizing instances (often 30–40% cost savings available)
- Reserved instance and savings plan purchasing
- Moving from EC2 to containers or serverless where appropriate
- Implementing autoscaling policies
- Database performance tuning in the new environment
Common Mistakes That Derail Migrations
- Underestimating data transfer costs — Egress fees from AWS/Azure can be substantial. Plan your data transfer windows and routes carefully.
- Migrating without a rollback plan — Every wave needs a documented rollback procedure tested before go-live.
- Skipping the landing zone — Teams that skip foundation setup spend months retrofitting security and governance later.
- Treating migration as purely a technical exercise — Change management and team training are just as important as the technical work.
Planning a cloud migration?
Our cloud team has run migrations for enterprises across 8 industries. Let's build your migration strategy together.
Explore Cloud Services →