The 7 Rs of AWS Cloud Migration - How to Choose a Strategy Per Workload

This article is for CTOs, engineering leads, and architects planning an AWS migration who need to decide how to move each application. Rather than a generic definition of the 7 Rs, we go through each strategy as a decision: when to choose it, what it realistically costs, its risk, and what you deliver it with.

Why the per-workload choice matters

The most common migration mistake is treating the whole portfolio identically - “we’ll lift-and-shift everything” or “we’ll rewrite everything as microservices.” Both waste budget.

Rehosting everything carries technical debt and inefficient patterns straight into the cloud - you pay cloud prices without cloud benefits. Refactoring the whole portfolio, on the other hand, is months of work spent where half the applications would have been fine with a simple rehost.

That’s why we set the strategy per workload during the assessment phase, weighing four factors: the application’s business value, technical complexity, team capacity, and time constraints (an approaching licence renewal or data-centre contract expiry, for example).

The seven strategies in detail

Retire

What you do: switch off a workload that’s no longer needed.

During assessment you almost always find applications that are redundant, unused, or duplicate the function of other systems. In a typical enterprise portfolio, 10-20% of workloads qualify for retirement. Every retired application means a smaller migration scope, lower cost, and less to maintain afterwards.

Effort: minimal (confirm nothing depends on it, then decommission). Risk: low, provided the assessment mapped dependencies correctly. The main risk is switching off something used by a hidden process. When to choose it: an app with no active users, one superseded by another system, or one whose business value is lower than the cost of migrating it.

Retain

What you do: deliberately leave a workload where it is (on-premise or another cloud), at least for now.

Retain isn’t “never migrate” - it’s “not in this wave.” Workloads with complex dependencies, hard regulatory constraints, or an approaching end-of-life can wait. You document them and plan a future migration path instead of forcing it.

Effort: none for now; the cost is documentation and a future-wave plan. Risk: low, but watch for workloads “temporarily retained” for years - that’s a source of technical debt and double running costs (you maintain both on-premise and cloud). When to choose it: an app with a hardware dependency on-premise, a legal data-residency constraint, or a planned sunset within the year.

Rehost (lift-and-shift)

What you do: move the application 1:1 onto EC2 or containers with no code changes.

The fastest strategy. A typical rehost completes in days to weeks per application. You get cloud benefits (elasticity, pay-as-you-go) immediately, but you don’t optimise for cloud-native patterns - the app runs exactly as it did on-premise, just on someone else’s hardware.

Tool: AWS Application Migration Service (MGN) automates rehost by continuously replicating servers to AWS and orchestrating cutover with minimal downtime. It handles Linux and Windows and supports test migrations. Effort: low. Risk: low technically, but you carry existing inefficiencies across. When to choose it: an app with a 1-2 year remaining lifespan, time pressure (a data-centre exit, say), or when speed matters more than cost optimisation.

Relocate

What you do: move an entire virtual environment without touching the applications - primarily VMware onto VMware Cloud on AWS.

The application, operating system, and configuration stay identical. It’s the fastest way to vacate your own data centre when you have a large VMware estate and don’t want to (or can’t) touch the application stack during the move.

Effort: low. Risk: low for the move itself; you defer modernisation to later (and keep paying VMware licensing in the meantime). When to choose it: a large VMware estate, a hard data-centre exit deadline, and no capacity to modernise at the same time.

Replatform

What you do: migrate with targeted changes to managed services, keeping the application architecture.

Examples: self-hosted PostgreSQL → RDS, cron jobs → EventBridge + Lambda, self-managed Redis → ElastiCache. You keep the shape of the application but hand the operational burden (patching, backups, high availability) to AWS.

Effort: medium - typically 2-4 weeks per workload more than a rehost. Payoff: 40-60% lower ongoing maintenance cost. Risk: medium - you have to test that the managed service behaves like the component it replaces (e.g. connection limits in RDS vs self-hosted). When to choose it: this is the sweet spot for most mid-complexity applications - the best ratio of effort to benefit.

Repurchase

What you do: replace custom-built software with a commercial SaaS product.

Example: self-hosted CRM → Salesforce, a home-grown monitoring stack → Datadog. The application doesn’t move to AWS - it moves to a vendor. It’s as much a business decision as a technical one.

Effort: variable - dominated by data migration and user retraining, not infrastructure. Risk: vendor lock-in and licence cost that grows with usage. When to choose it: building and maintaining the capability in-house no longer has a business case, and a mature SaaS product covers the need.

Refactor / Re-architect

What you do: rebuild the application for cloud-native patterns - microservices, containers (ECS/EKS), serverless (Lambda), event-driven architecture (EventBridge, SQS, SNS).

The most expensive and time-consuming strategy, but it delivers the best long-term results: independent deployments, horizontal scaling, reduced blast radius, zero-downtime deployments.

Effort: high. Risk: highest - this is a genuine architecture change, not a move. It needs strong assessment and phased delivery. When to choose it: reserve it for core business products where you need capabilities the current architecture can’t deliver - true horizontal scaling, multi-region deployment, zero-downtime releases.

How to choose - a typical portfolio split

Most migration projects combine 3-4 strategies. A typical split for a 20-application portfolio looks like this:

The decision order we use in practice: eliminate first (Retire), then defer what has to wait (Retain), and assess the rest on a “speed vs optimisation” axis - from Rehost/Relocate (fast, minimal) through Replatform (the middle) to Refactor/Repurchase (most work, most benefit or a change of model). We set the per-workload strategy during the assessment phase based on business value, technical complexity, team capacity, and time constraints.

For database migrations - whatever strategy you land on - the tool for moving data with minimal downtime is usually AWS DMS; we cover it in the AWS DMS guide.

Funding the migration - AWS MAP

Whichever of the 7 Rs dominate your project, the whole engagement may qualify for the AWS Migration Acceleration Program (MAP), which covers 70-80% of migration partner engagement costs. Qualification requires an active source environment (on-premise or a competing cloud), a target that’s a native AWS service, and a certified MAP partner. We cover the funding detail (Assess / Mobilize / Migrate phases) in the AWS migration cost guide.

Frequently asked questions

Next steps - a strategy assessment for your portfolio

Choosing a 7 R strategy for each workload is the output of an assessment, not guesswork. We analyse your portfolio (applications, dependencies, business value, time constraints) and come back with a map: which application goes to which strategy, in what order, and at what cost.

1. Dependency map and per-workload recommendation - Retire / Retain / Rehost / Relocate / Replatform / Repurchase / Refactor
2. Migration wave plan - what goes first, what follows in later waves
3. Cost and timeline estimate - including MAP funding projections
4. Target architecture recommendation - following the AWS Well-Architected Framework

Planning an AWS migration?

Book a free 30-minute call. We'll walk through your portfolio, provisionally assign 7 R strategies, and check whether your project qualifies for AWS MAP funding (typically 70-80% of costs covered).

Book a call Send us a message