Skip to content

The seven migration strategies (7 Rs)

AWS describes seven strategies for moving a workload to the cloud, the 7 Rs. Every application in a portfolio assessment gets exactly one of these labels, and the label determines the tooling, the effort and the risk. Older material lists six and omits relocate.

StrategyAlso known asWhat it meansExampleEffortOptimisation gained
RetireDecommission or archive the application; shut down its serversEnd-of-life a label printer app nobody usesLowestCost removed entirely
RetainDo nothing, for nowLeave it in the source environment and revisit laterA mainframe application awaiting a proper assessmentLowestNone
RehostLift and shiftMove the servers unchangedOn-premises MySQL server to an EC2 instanceLowLittle
RelocateMove many servers at once to a cloud version of the same platform, without changing the application or operationsVMware estate to a VMware environment on AWS; an RDS instance to another VPC or accountLowLittle, but fastest to complete
RepurchaseDrop and shopReplace the application with a different product, usually SaaSLegacy on-premises CRM to a SaaS CRMMediumMaintenance and licensing removed
ReplatformLift, tinker and shiftMove it, and change the underlying platform to gain something specificSelf-managed SQL Server to Amazon RDS for SQL Server; x86 to GravitonMedium–highSubstantial
RefactorRe-architectRedesign the application around cloud-native servicesRewrite a monolith as serverless componentsHighestHighest

Retire first. Portfolio assessments routinely find applications with average CPU and memory usage below five per cent, or no inbound connections for ninety days. Migrating those costs money twice — once to move them, then forever to run them.

Rehost and relocate are the volume strategies. In a large migration, most applications should land in one of these two. They minimise compatibility risk and cutover windows, and the application keeps serving users while its data replicates.

Refactor is not a migration strategy for a large programme. AWS explicitly recommends against it at scale: it modernises the application during the move, which multiplies the number of things that can go wrong at cutover. Rehost or replatform first, modernise once it is running in the cloud and the AWS services are easy to reach.

Retain is a decision, not a deferral. Common legitimate reasons: data residency obligations, a dependency on specialist hardware with no cloud equivalent, a recent capital investment in the current platform, or a vendor SaaS release due within the planning horizon.

Rehost is automated by AWS Transform MGN, and the databases underneath it by AWS DMS. Replatform and refactor decisions, and the AWS services each pattern lands on, are covered in services and strategies.