AWS Cloud Migration Strategies: The 7 Rs Explained

Cloud migration strategy is the decision about what to do with each application or workload when moving it to AWS. There is no single strategy for an entire company: one application may move unchanged, another may move to a managed service, another may be rewritten, and an unused application may be shut down.

AWS groups the main choices into the 7 Rs of migration:

Retain     → keep it where it is for now
Retire     → remove it because it is no longer needed
Rehost     → move it with minimal changes
Relocate   → move it to another AWS location or platform
Repurchase → replace it with a different product
Replatform → move it and make limited optimisations
Refactor   → redesign or re-architect it for the cloud

This is Part 65 of the AWS Cloud Practitioner Study Notes. The right choice depends on business goals, deadline, technical debt, dependencies, compliance, risk tolerance, and the team’s ability to operate the target architecture.

The 7 Rs at a glance

Strategy	Main idea	Application change	Typical reason
Rehost	Lift and shift	Low	Move quickly with low disruption
Relocate	Move an existing workload to another AWS location or platform	Low	Change AWS environment without redesigning
Repurchase	Replace with a new product or service	High in product choice, low in code changes	Adopt a SaaS or newer licence
Replatform	Move with a few cloud optimisations	Low to moderate	Reduce operations without a full rewrite
Refactor / re-architect	Redesign for cloud-native capabilities	High	Maximise agility, scalability, or resilience
Retain	Keep the workload in its current environment	None now	Dependency, risk, compliance, or timing
Retire	Decommission the workload	None	Remove duplication, waste, or obsolete systems

The strategies are not a ranking from “bad” to “good”. A fast rehost can be the correct business decision, while an unnecessary refactor can create migration risk. Many real migration programmes use several Rs at the same time.

1. Rehost: lift and shift

Rehost means moving an application to AWS with little or no modification. The goal is to change the infrastructure location while keeping the application architecture mostly the same.

On-premises VM or server
          ↓
EC2 instance with the same application

Example

A company runs a Windows application on a VMware virtual machine. It moves the workload to an EC2 instance, keeps the operating system and application structure, and changes only the surrounding networking, storage, and operational configuration required by AWS.

Why choose rehost?

• The data-centre exit deadline is close.
• The application is stable and business-critical.
• The team wants to reduce migration changes and rollback risk.
• The application is not yet suitable for a managed service.
• The organisation wants to migrate first and modernise later.

Benefits

Rehosting is usually the fastest and least invasive application migration path. Existing operational knowledge, deployment packages, and application behaviour can often be preserved. It is also easier to estimate than a rewrite because the target is similar to the source.

Trade-offs

The application may still carry the limitations of its old design. It may run on oversized EC2 instances, depend on manual patching, or fail to use elasticity and managed services. Rehosting changes the location, not necessarily the operating model.

Exam clue

“Move quickly”, “minimal changes”, and “lift and shift” usually indicate rehost.

2. Relocate: move without redesigning

Relocate means moving a workload to another AWS environment, account, Region, or supported AWS platform without changing its basic architecture. The emphasis is on moving the existing workload as a unit rather than converting or rewriting its components.

Example

A VMware workload already running on AWS is moved to a different VMware Cloud on AWS environment or AWS account. Another example is moving an existing RDS database to another VPC or AWS account when the database engine and general design remain the same.

Why choose relocate?

• The workload is already compatible with the target platform.
• The organisation is changing accounts, Regions, or AWS environments.
• The goal is consolidation or data-centre exit, not application redesign.
• A large application should move as a unit to reduce interdependency changes.

Benefits

Relocation can preserve the workload’s existing configuration and operating model while changing its AWS placement. This can be useful for large estates where changing every application component at once would create unnecessary risk.

Trade-offs

Relocation does not automatically modernise an application. Network ranges, IAM permissions, encryption keys, DNS, licensing, service quotas, and data-transfer paths still require careful planning. A workload moved between environments can also retain technical debt.

Exam clue

“Move an existing workload to another AWS Region, account, VPC, or supported AWS platform without redesigning it” points to relocate. Do not confuse it with rehost: rehost commonly describes moving from on-premises to AWS, while relocate focuses on moving an already compatible workload to another AWS location or platform.

3. Repurchase: replace the product

Repurchase means replacing an existing application or licence with a different product, usually a cloud-based or Software as a Service (SaaS) product. The organisation stops running the old product and adopts a new one.

Self-managed legacy CRM
          ↓
Cloud CRM SaaS subscription

Example

A company replaces a self-hosted email or customer relationship management system with a SaaS product. The company may migrate the data and integrate the new product, but it no longer ports the original application to EC2.

Why choose repurchase?

• The existing product is expensive to maintain.
• The organisation wants to stop managing infrastructure for a commodity capability.
• A cloud product provides features that would be costly to build.
• The current licence model no longer fits the business.
• The old application has little strategic differentiation.

Benefits

The organisation can remove hardware, patching, upgrades, and much of the underlying platform management. The replacement may offer faster feature delivery and built-in availability or collaboration capabilities.

Trade-offs

Repurchase is not a simple infrastructure copy. Data export and import, identity integration, API compatibility, custom workflows, vendor lock-in, subscription cost, and user training can become major work. Some custom features may not exist in the replacement product.

Exam clue

“Replace the existing application with a SaaS product” or “change the licence and adopt a new product” means repurchase.

4. Replatform: move and optimise

Replatform means moving an application to AWS while making limited changes that improve its operation, but without changing its fundamental architecture. It is sometimes called lift, tinker, and shift.

Self-managed database on a VM
          ↓
Amazon RDS using the same database engine

Example

A company moves a MySQL database from an EC2 instance or on-premises server to Amazon RDS for MySQL. The application still uses a relational database, but AWS manages many database infrastructure tasks. Another example is moving an application into containers without redesigning it as many independent services.

Why choose replatform?

• The application architecture is acceptable, but operations are expensive.
• A managed AWS service can remove routine administration.
• The team needs some cloud benefit without a full rewrite.
• The workload has a fixed deadline and moderate change capacity.

Benefits

Replatforming can reduce patching, backup, provisioning, and hardware-management work. It can also improve deployment consistency and make scaling or recovery easier while preserving most application behaviour.

Trade-offs

The migration still requires compatibility testing. Database extensions, operating-system access, networking, monitoring, backup retention, maintenance windows, licensing, and performance characteristics may differ on the managed service. A service change can also expose hidden assumptions in the application.

Exam clue

“Move to a managed AWS service with minimal code changes” usually indicates replatform. Amazon RDS is a common target in exam examples.

5. Refactor or re-architect: redesign for the cloud

Refactor, also called re-architect, means changing the application’s architecture substantially to use cloud-native capabilities. This can include decomposing a monolith, adopting managed services, introducing event-driven workflows, or redesigning the data layer.

Monolith on one server
          ↓
Services, queues, APIs, managed databases, and event-driven workers

Example

A monolithic order application is redesigned into independently deployable services. Synchronous work is separated from asynchronous processing, files move to Amazon S3, relational data moves to a managed database, and workloads use containers or serverless components where appropriate.

Why choose refactor?

• The existing architecture cannot meet required scale or availability.
• The application is strategically important and will evolve for years.
• The business needs faster independent releases.
• The organisation wants elasticity, managed services, or event-driven processing.
• Technical debt is blocking important business capabilities.

Benefits

Refactoring can produce a better long-term fit for cloud elasticity, resilience, automation, and independent delivery. It can also remove assumptions tied to a physical data centre or a single large server.

Trade-offs

This is the most complex and risky strategy. It requires architectural design, new operational skills, data migration planning, testing, observability, security controls, and often a period in which old and new systems coexist. The cost and timeline are harder to predict.

For a large migration programme, AWS guidance commonly recommends moving workloads with lower-change strategies first and modernising them after migration when that reduces programme risk. Refactoring during a migration can still be correct when the existing architecture cannot meet the target requirements, but it should be an intentional business decision.

Exam clue

“Redesign the application to use cloud-native architecture”, “break a monolith into microservices”, or “use serverless and managed services” points to refactor / re-architect.

6. Retain: keep it for now

Retain means keeping the workload in its current environment instead of migrating it immediately. Retain is a deliberate decision, not a failure to plan.

Example

A factory system depends on specialised hardware that cannot yet be moved. The company keeps it on-premises while migrating its surrounding reporting and integration services to AWS.

Why choose retain?

• The application has unresolved dependencies.
• A legal, compliance, sovereignty, or licensing requirement requires the current location.
• The workload is near retirement or replacement.
• The business cannot accept migration risk yet.
• The required AWS service or Region is not available.
• The application is stable and migration value is low.

Benefits

Retaining avoids forcing an unsafe or uneconomic migration. It allows the team to focus first on workloads with clearer benefits and revisit the decision when constraints change.

Trade-offs

The organisation continues paying for and operating the existing environment. It may also need hybrid connectivity, identity integration, monitoring, security controls, and data synchronisation between on-premises systems and AWS.

Exam clue

“Keep the workload on-premises until a later date because of dependencies or compliance” means retain.

7. Retire: remove what is unnecessary

Retire means decommissioning an application because it is obsolete, duplicated, unused, or no longer valuable. It is a migration strategy because removing a workload reduces the scope of the migration.

Example

An application portfolio contains three reporting tools that provide overlapping dashboards. After confirming that one tool is no longer used, the organisation archives required data and shuts down the unused systems instead of migrating them.

Why choose retire?

• No users depend on the application.
• Another system has replaced its function.
• It contains duplicate or obsolete capabilities.
• The cost and risk of moving it are greater than its value.
• The software is end-of-life and should be removed.

Benefits

Retiring reduces migration work, infrastructure cost, licensing, attack surface, operational noise, and future maintenance. It also helps teams avoid moving unnecessary technical debt into AWS.

Trade-offs

Retirement must be verified carefully. Teams should check owners, usage, integrations, scheduled jobs, legal retention, audit records, backups, and hidden dependencies. “No recent login” does not necessarily mean “safe to delete.”

Exam clue

“Decommission unused or duplicate applications” means retire.

AWS migration phases

The 7 Rs describe the strategy for each workload. AWS also describes a broader migration process in three phases:

Assess → Mobilize → Migrate and modernize

1. Assess

The assess phase establishes why the organisation should migrate and what it currently has. Typical activities include:

• Define business outcomes and migration drivers.
• Discover servers, applications, databases, storage, and network paths.
• Identify owners, users, dependencies, and data classifications.
• Measure utilisation, performance, availability, and current cost.
• Assess cloud readiness and organisational gaps.
• Build a business case and TCO estimate.
• Classify each workload against the 7 Rs.

The output is not just a server list. It should connect business importance, technical dependencies, cost, risk, and the desired AWS outcome.

2. Mobilize

The mobilize phase prepares the organisation and the AWS foundation. Typical activities include:

• Build or improve the landing zone.
• Establish account structure, networking, identity, logging, and security guardrails.
• Define governance, tagging, budgets, and cost ownership.
• Prepare operations, monitoring, backup, incident response, and support processes.
• Close skills and capability gaps.
• Select pilot workloads and build migration runbooks.
• Refine the business case and wave plan.

The landing zone should make the target environment safe and repeatable. Migrating workloads into an ungoverned account can create security, cost, and operational problems that are harder to fix later.

3. Migrate and modernize

In this phase, teams design, move, validate, and improve workloads. A migration wave commonly includes:

Select wave
  ↓
Discover dependencies and define success criteria
  ↓
Build target infrastructure and connectivity
  ↓
Replicate or transfer data
  ↓
Test application, security, performance, and recovery
  ↓
Cut over traffic
  ↓
Monitor, stabilise, and decommission the source

Modernisation can happen during the move or after the workload is stable in AWS. The safest choice depends on the business deadline, application risk, and the value of changing the architecture.

How to choose the right strategy

Ask these questions for every application:

1. Is the application still needed? If not, retire it.
2. Must it remain where it is for now? If so, retain it.
3. Is speed and low disruption the priority? Consider rehost.
4. Is it already on AWS but in the wrong account, VPC, Region, or platform? Consider relocate.
5. Can a SaaS product replace it? Consider repurchase.
6. Can a managed AWS service remove operational work with limited change? Consider replatform.
7. Does the current architecture prevent required scale, resilience, or agility? Consider refactor.

The decision should also consider:

Decision factor	Questions
Business value	Is the workload strategic, commodity, or near retirement?
Urgency	Is there a data-centre exit date or contract deadline?
Technical fit	Are there OS, database, hardware, or licensing constraints?
Dependencies	Which services, users, networks, and databases must move together?
Risk	What outage, data-loss, rollback, and compliance risks exist?
Skills	Can the team operate containers, serverless, or managed databases?
Cost	What are migration, data-transfer, licensing, and ongoing AWS costs?
Target outcome	Is the goal relocation, cost reduction, resilience, speed, or innovation?

Migration waves and the pilot

Large portfolios should normally migrate in waves rather than as one enormous cutover. Start with a pilot that is valuable enough to teach the team but not so critical that a failed first attempt threatens the organisation.

A practical wave plan groups applications by dependency and risk:

Wave 1 → low-risk pilot and shared foundation
Wave 2 → related applications with known dependencies
Wave 3 → business-critical or data-heavy systems
Wave 4 → complex refactors and remaining exceptions

Do not select a wave using server size alone. A small service with many dependencies may be harder to migrate than a large but isolated application. Map the application, database, identity, network, monitoring, backup, and downstream integration dependencies before setting the cutover order.

Migration services and strategies are different concepts

The 7 Rs answer “what strategy will we use for this workload?” AWS migration services answer “which tools can help us discover, move, track, or modernise it?”

Need	Example AWS capability
Discover servers and dependencies	AWS Application Discovery Service
Track migration status	AWS Migration Hub
Build a migration business case	AWS Migration Evaluator
Move virtual or physical servers	AWS Application Migration Service
Migrate relational databases	AWS Database Migration Service (AWS DMS)
Transfer files and objects online	AWS DataSync
Move very large data offline	AWS Snowball Edge

These tools do not decide the 7 R automatically in every situation. The strategy still depends on business requirements, application constraints, and the target operating model.

Exam traps and final memory map

• Rehost is lift and shift: minimal application changes.
• Relocate moves an already compatible workload to another AWS location or platform.
• Replatform makes limited optimisations, often by adopting a managed service such as RDS.
• Repurchase replaces the old product, often with SaaS.
• Refactor or re-architect changes the application substantially for cloud-native benefits.
• Retain means keep it where it is for now.
• Retire means decommission it.
• The 7 Rs classify individual workloads, not necessarily the whole company.
• Assess, mobilize, and migrate and modernize are migration phases, not three additional Rs.
• Migration services help with discovery, business cases, movement, and tracking; they are not themselves the 7 Rs.

The shortest memory trick is:

Need it?        No → Retire
               Yes
Must wait?      Yes → Retain
               No
Replace it?     Yes → Repurchase
Move location?  Yes → Relocate
Move unchanged? Yes → Rehost
Small upgrade?  Yes → Replatform
Redesign it?    Yes → Refactor

AWS migration strategy is therefore a portfolio decision: remove what is unnecessary, delay what is constrained, move simple workloads quickly, adopt managed services where they help, and reserve major redesign for workloads that justify the investment.

Sources

• AWS Prescriptive Guidance: About the migration strategies
• AWS Prescriptive Guidance: Phases of a large migration
• AWS Prescriptive Guidance: Overview of the AWS migration process
• AWS: Choosing AWS migration services and tools