Cloud migration strategies: the 7 Rs and how AWS, Azure and Google compare

Migration is a portfolio decision, not a single choice

Moving to the cloud is rarely one project with one approach. A typical estate contains web applications, databases, file shares, batch jobs, packaged software and a few systems nobody fully understands. Each of these deserves its own decision: move it as it is, change it, replace it, or leave it alone.

The three major cloud providers each publish guidance on making those decisions. Their vocabulary differs slightly, but the underlying options are much the same. This guide sets out each provider’s framing, maps them against each other, and then covers how to choose a strategy for each workload.

AWS: the 7 Rs

AWS Prescriptive Guidance describes seven migration strategies, known as the 7 Rs:

The same guide gives practical signals for each. Retain suits applications with data residency constraints, unresolved dependencies, recent on-premises upgrades or specialised hardware. Retire suits applications with little remaining business value or no recent usage.

AWS is direct about refactoring in large programmes: it calls refactor the most complex and costly strategy and does not recommend it for large migrations. Its advice is to rehost, relocate or replatform first and modernise once the application is running in the cloud, refactoring during migration only when the other options are unacceptable.

Microsoft: the Cloud Adoption Framework

Microsoft places migration inside the broader Cloud Adoption Framework (CAF), which organises Azure adoption into seven phases: Strategy, Plan, Ready, Adopt, Govern, Secure and Manage. Migration decisions belong in the Plan phase, and the landing zone that receives migrated workloads is built in Ready.

CAF’s guidance on selecting migration strategies lists eight options: retire, rehost, replatform, refactor, rearchitect, replace, rebuild and retain. It ties each to a business driver. For example, rehost is for minimal disruption with no near-term modernisation planned; replatform is for moving to PaaS with minimal code change; rearchitect is for unlocking cloud-native capabilities when components need to scale differently or be decomposed.

Two pieces of advice stand out:

• Don’t rehost problematic workloads. Rehosting carries existing performance, reliability and architectural problems into the cloud.
• Rehost only if the workload won’t need modernising soon. CAF suggests rehosting when you are confident the workload will stay in its current form for at least two years; otherwise consider refactoring or rearchitecting to avoid doing the work twice.

CAF also distinguishes refactor (improving code without adding features) from rearchitect (changing the architecture) and rebuild (redeveloping as a new cloud-native solution), a useful separation when estimating effort.

Google Cloud: assess, plan, deploy, optimise

Google’s Migrate to Google Cloud: Get started describes a four-phase migration path:

1. Assess the current environment: inventory, dependencies, total cost of ownership and performance benchmarks.
2. Plan the foundations: identity, organisation and project structure, networking, and the order in which applications will move.
3. Deploy workloads through a designed, repeatable process.
4. Optimise for performance, scalability, disaster recovery and cost once workloads are running.

It names six migration types: rehost (“lift and shift”), replatform (“lift and optimise”), refactor (“move and improve”), re-architect (“continue to modernise”), rebuild (“remove and replace”) and repurchase. Google describes rehost as the easiest migration to perform, because teams can keep their existing tools and skills, and notes that repurchase can be simpler than code-changing options but may cost more and offer less control.

How the vocabularies line up

The labels matter less than agreeing, for each workload, how much will change and why.

The migration journey

Strategy selection sits inside a wider programme. AWS’s migration strategy guidance describes three phases:

• Assess: a readiness assessment, portfolio discovery, and a business case with total cost of ownership analysis. The readiness assessment is based on the AWS Cloud Adoption Framework’s six perspectives: business, people, governance, platform, security and operations.
• Mobilise: build a secure, scalable landing zone, define the operating model, and migrate a small first set of applications to build skills and refine the process.
• Migrate: apply the proven patterns at scale, often through a repeatable “migration factory”.

The common thread across all three providers is the same: understand the estate, build a well-governed foundation, prove the approach on a few workloads, then scale.

Choosing a strategy for each workload

Work through each application with its business and technical owners and ask:

1. Is it still needed? Usage data often reveals applications that can simply be retired, which removes cost and risk before any migration work starts.
2. Can it move at all? Licensing terms, data residency, latency to on-premises systems and specialised hardware may mean retain, at least for now.
3. Is there a mature SaaS alternative? Commodity functions such as email, CRM or HR are often better replaced than migrated.
4. Is it healthy? A stable, well-performing application is a good rehost candidate. One with known performance or reliability problems should not simply be moved.
5. Will it need major change soon? If so, it may be cheaper to replatform or re-architect once rather than move it twice.
6. What does the team know? Modernising during migration needs skills and time. If either is short, migrate first and modernise afterwards.
7. What are the dependencies? Applications that share databases or call each other heavily often need to move in the same wave.

Record the chosen strategy, the reason, and how success will be measured. Microsoft’s guidance specifically recommends defining success metrics for each decision and reviewing strategies as the programme learns.

Modernise now or later?

Both AWS and Microsoft caution against modernising everything during migration. Modernisation brings long-term benefits but adds risk and time to the migration itself. A pragmatic pattern is to move first with minimal change, establish operations, monitoring and cost controls in the cloud, and then modernise the applications where the business case is strongest.

For large legacy systems, Martin Fowler’s strangler fig approach is a well-known way to modernise incrementally: build new capabilities alongside the old system and move behaviour across piece by piece, rather than attempting a single “big bang” rewrite.

Common pitfalls

• Skipping discovery. Undocumented dependencies are a frequent cause of failed or delayed cutovers.
• No landing zone. Moving workloads before identity, networking, security and cost controls are in place creates problems that are hard to fix later.
• Rehosting without rightsizing. Copying on-premises server sizes into the cloud often means paying for capacity that is never used.
• Ignoring data. Large databases need a tested plan for replication, cutover and rollback.
• Treating migration as the finish line. The benefits come from operating and optimising well after the move.

Sources

1. AWS Prescriptive Guidance: About the migration strategies
2. Microsoft Learn: Cloud Adoption Framework for Azure
3. Microsoft Learn: Select your cloud migration strategies
4. Google Cloud: Migrate to Google Cloud: Get started
5. AWS Prescriptive Guidance: Strategy for migration, overview
6. Martin Fowler: Strangler Fig Application