AWS Migration Strategies: The 7 Rs and the Tools That Support Them

The 7 Rs are the seven strategies AWS defines for moving an application from an existing environment into the cloud: rehost, replatform, repurchase, refactor, relocate, retain, and retire. Each strategy trades effort against cloud benefit. Rehost moves a workload with no changes, refactor rebuilds it as cloud-native, and retire eliminates it entirely. On the CLF-C02 exam, your job is to read a short scenario and pick the one R that matches the constraints described.

Where the 7 Rs come from

AWS folds migration planning into the AWS Cloud Adoption Framework (AWS CAF), which organizes a cloud journey around business and technical perspectives. When an organization reaches the point of actually moving applications, it assesses each one and assigns it a migration strategy. The original framing was “6 Rs,” borrowed from Gartner’s 5 Rs and extended by AWS. AWS later added relocate, bringing the list to seven. Older study material that mentions six Rs is describing the same model minus relocate.

The key mental model: the 7 Rs sit on a spectrum of effort. At one end, you change nothing about the application. At the other, you rewrite it. Two of the Rs (retain and retire) are not migrations at all; they are decisions to not move something.

The 7 Rs, one by one

Rehost (lift and shift). Move the application to AWS as-is, typically from an on-premises virtual machine to an Amazon EC2 (Elastic Compute Cloud) instance. No code changes, no architecture changes. This is the fastest strategy and the most common choice for large legacy portfolios on a deadline, such as a data center lease expiring. The tradeoff: you get cloud infrastructure benefits (elasticity of the platform, pay-as-you-go billing) but the application itself is no more cloud-native than before.

Replatform (lift, tinker, and shift). Move the application with a small number of targeted optimizations, without changing its core architecture. The classic example: migrating a self-managed database on a VM to Amazon RDS (Relational Database Service), so AWS handles patching, backups, and failover while the application code barely changes. Swapping a self-managed load balancer for Elastic Load Balancing is another replatform move.

Repurchase (drop and shop). Abandon the existing application and buy a different product, usually a SaaS (Software as a Service) offering. Moving from a self-hosted CRM (customer relationship management) system to Salesforce, or from an on-premises HR system to Workday, is repurchasing. You are not migrating software; you are replacing it with something you subscribe to.

Refactor (re-architect). Redesign the application to be cloud-native, changing its architecture to use services like AWS Lambda, Amazon DynamoDB, or containers. This is the most expensive and slowest strategy, and the one that unlocks the most cloud benefit: fine-grained scaling, managed services everywhere, and often a move from monolith to microservices. Scenarios that mention “breaking a monolith into microservices” or “rewriting to serverless” are refactor.

Relocate. Move infrastructure to AWS at the hypervisor level without purchasing new hardware, rewriting applications, or changing operations. The flagship example is moving VMware workloads into VMware Cloud on AWS: entire hosts move, and the applications running on them do not even notice. Relocate is even lower-touch than rehost because individual servers are not converted to EC2 instances at all.

Retain. Keep the application where it is, at least for now. Reasons include unresolved dependencies, compliance rules requiring on-premises processing, or an application that was recently upgraded and has no business case for moving yet. Retain is a deliberate decision, revisited later.

Retire. Decommission the application. Portfolio assessments regularly discover applications that nobody uses anymore. Turning them off saves the entire cost of migrating and running them. If a scenario says an application is “no longer needed,” the answer is retire, not retain.

Strategy	What changes	Effort	Typical trigger
Rehost	Nothing (VM to EC2)	Low	Fast exit from a data center
Replatform	Small optimizations (DB to RDS)	Low-medium	Reduce management burden cheaply
Repurchase	Product replaced with SaaS	Medium	Legacy product with a strong SaaS alternative
Refactor	Architecture rebuilt cloud-native	High	Need scale or agility the old design cannot give
Relocate	Hosting layer only (VMware to VMware Cloud on AWS)	Lowest	Move fast without touching servers
Retain	Nothing; stays put	None	Dependencies or compliance block the move
Retire	Application shut down	None	Nobody uses it

The AWS tools that support migration

CLF-C02 also expects you to recognize the major migration services by purpose:

• AWS Migration Hub is the central dashboard. It tracks migration progress across tools and applications in one place. It does not move anything itself.
• AWS Application Discovery Service collects information about on-premises servers (specifications, utilization, dependencies) to feed migration planning.
• AWS Migration Evaluator builds a data-driven business case, projecting what your on-premises footprint would cost on AWS.
• AWS Application Migration Service (MGN) is the primary rehost tool. It continuously replicates on-premises servers to AWS and converts them to run natively as EC2 instances with minimal cutover downtime.
• AWS Database Migration Service (DMS) moves databases with the source staying operational during migration. Paired with the Schema Conversion Tool (SCT), it can also convert between engines, for example Oracle to Amazon Aurora.
• AWS DataSync moves large amounts of file and object data over the network on an ongoing or one-time basis.
• AWS Snow Family moves data offline in physical devices when the dataset is too large or the network too slow for online transfer.

How the CLF-C02 exam tests this

• A scenario describes moving VMs to EC2 “with no changes” or “as quickly as possible with minimal modification.” The answer is rehost, and if a tool is asked for, it is Application Migration Service.
• A scenario keeps the application code intact but swaps the self-managed database for Amazon RDS. That single managed-service optimization makes it replatform, not rehost and not refactor.
• A scenario replaces an aging licensed application with a SaaS subscription. That is repurchase. Watch for the word “subscription” or a named SaaS vendor.
• A scenario mentions VMware environments moving to AWS without converting servers. That is relocate, the R that did not exist in the old six-R list.
• A discovery finding that an application “has no users” or “is redundant” points to retire; a compliance rule that forces the workload to stay on premises points to retain.

Quick reference

• 7 Rs: rehost, replatform, repurchase, refactor, relocate, retain, retire.
• Rehost = lift and shift, no changes; tool of choice is AWS Application Migration Service (MGN).
• Replatform = lift, tinker, and shift; small optimizations like moving a database to RDS.
• Repurchase = drop and shop; replace with SaaS.
• Refactor = re-architect to cloud-native; highest effort, highest long-term benefit.
• Relocate = move at the hypervisor level (VMware Cloud on AWS); lowest touch of all.
• Retain keeps an app on premises deliberately; retire shuts it down.
• Migration Hub tracks; Discovery Service and Migration Evaluator plan; MGN, DMS, DataSync, and Snow Family move.