Migrating an existing system to the cloud is rarely the right framing. Successful migrations involve many decisions: which workloads, in what order, with what level of change. The "6 R's" framework (originally from AWS) provides vocabulary.
This page covers the strategies and which ones work in practice.
Move the workload to cloud with minimal changes. Same OS, same application, same architecture — running on cloud VMs instead of on-prem.
When it fits:
Trade-offs:
Most successful "we're going to the cloud" projects start with rehost for the bulk, then incrementally improve.
Rehost plus targeted improvements. Move to cloud and adopt some managed services without full re-architecture.
Common patterns:
When it fits: most migrations. Captures real value without full rewrite.
Significant code changes to take advantage of cloud-native patterns. Microservices decomposition, serverless adoption, event-driven architecture.
When it fits:
Trade-offs:
Replace the workload with a SaaS equivalent. Self-hosted CRM → Salesforce. Self-hosted email → Office 365.
When it fits: commodity workloads with mature SaaS alternatives. Rarely makes sense to re-host or refactor what you can buy.
Some workloads have no business value. The migration discovery surfaces them. Retire instead of migrating.
When it fits: every migration has these. The percentage varies but is rarely zero.
Some workloads stay where they are — at least temporarily.
When it fits:
A migration plan that doesn't include "retain" is unrealistic.
For a typical enterprise migration:
Catalog every workload. For each: which R? Often takes months.
Common output:
Set up account structure, networking, IAM, observability, security baselines. Don't migrate workloads until the landing zone is ready.
Migrate workloads in dependency order. Start with low-risk; build operational muscle.
After workloads run in cloud, find optimization wins:
Selective refactoring where it pays. Now you have cloud experience and a stable baseline.
The total timeline for a large migration: typically 2-5 years.
Promises modernization at the same time as migration. Misses deadlines; loses business cases. The rewrite-during-migration pattern has a poor track record.
Captures escape from on-prem but no cloud benefits. Cost goes up; complaints follow. Need a roadmap to capture value over time.
No plan; no architecture; no budget discipline. Costs spiral. Workloads run worse in cloud than on-prem because nobody designed for it.
Half-migration. Application is on-prem, database in cloud. Cross-region latency kills performance. Migrate together or design explicitly for the split.