AWS Migration Strategies: The 7 Rs and How to Choose
AWS Migration Strategies: The 7 Rs and How to Choose ! Engineers reviewing workloads for cloud migration AWS migration strategies are the approaches you use to move each workload into the cloud.
AWS migration strategies are the approaches you use to move each workload into the cloud. AWS defines seven of them, known as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor (or re-architect). The hard part is not memorizing the list. It is matching the right R to each application, in the right order, for a business reason you can state in one sentence.
This guide covers when each strategy fits, what it costs you in effort and money, and how to run the migration from workload assessment to post-migration optimization.
BitruptBuild a Migration Plan That FitsBitrupt builds tailored, scalable software solutions, helping organizations plan technology that meets their specific needs.Explore Bitrupt
TL;DR
- The 7 Rs are chosen per application, not per company. A single AWS cloud migration usually mixes four or five of them.
- For large migrations, AWS recommends rehosting, relocating or replatforming first and modernizing after the move, rather than starting with refactor.
- Define the business goal before the technique. Moving servers with no clear goal tends to produce technical debt, not cloud efficiency.
- Budget for the hidden lines: test and cutover instances, storage, and data transfer between Regions or out of AWS.
- Build security and compliance into the early mobilize phase, not as a final check.
Table of Contents
- What the 7 Rs actually decide
- Retire: the cheapest migration is the one you skip
- Retain: a decision, not a failure
- Rehost: the fastest route off the data center
- Relocate: moving the platform, not the machines
- Repurchase: replace it with SaaS
- Replatform: lift, tinker and shift
- Refactor or re-architect: the big investment
- How to choose: a short decision path
- The migration process, step by step
- Security and compliance: shared responsibility in practice
- Downtime, cost and other common challenges
- After cutover: post-migration optimization
- Our perspective
- Plan your AWS migration with Bitrupt
- FAQ
- Sources
What the 7 Rs actually decide
A migration strategy is a decision about one workload: what you will do with it on the way to AWS. Think of moving house. Some things go in the truck unchanged, some get repaired first, some you sell, and some you should have thrown out years ago. Treating the whole house the same way is how moves go over budget.
AWS frames the 7 Rs as a standard way to categorize every workload in a portfolio during assessment and planning. Strategies apply at the application level, not the server level. Group servers into applications first, then decide. Even AWS Transform, which uses generative AI to suggest an R for discovered inventory, gives you a recommendation to review, not a verdict.
| Strategy | In one line | Effort | Typical fit |
|---|---|---|---|
| Retire | Turn it off | Low | Unused or duplicated apps |
| Retain | Leave it where it is | None now | Apps not ready or not worth moving |
| Rehost | Lift and shift | Low | Fast exit from a data center |
| Relocate | Move at the hypervisor or container level | Low | VMware-based estates |
| Repurchase | Move to SaaS | Medium | Commodity software |
| Replatform | Lift, tinker and shift | Medium | Managed database or runtime swaps |
| Refactor | Re-architect for cloud-native | High | Core products that must scale |
Retire: the cheapest migration is the one you skip
Retiring means decommissioning or archiving an application so its servers can be shut down. Portfolio discovery often turns up reporting tools nobody opens, duplicate systems left from an acquisition, or test environments that outlived their projects.
Benefits: you stop paying to run, license and secure something with no value, and you shrink the scope of everything that follows.
Limits: retirement needs sign-off. An app that looks idle may feed a quarterly report or an audit trail. Check dependencies and data retention rules before anything is switched off.
Cost: negative, in the best sense. Archive the data you must keep and avoid migration labor for the rest.
Retain: a decision, not a failure
Retaining means keeping an application where it is, for now. AWS lists reasons such as no business value in migrating, for example an app with only a few internal users. Other common reasons are a recent hardware investment, a vendor license that does not allow a move, or a dependency on a system that must migrate first.
Benefits: you focus your effort where the return is.
Limits: retained systems still need a network path to the cloud. Plan connectivity and revisit the decision each year, because “later” quietly becomes “never.”
Cost: you keep paying for the existing environment, so give each retained app a review date.
Rehost: the fastest route off the data center
Rehosting, or lift and shift, moves servers to AWS with little or no change. AWS Application Migration Service (MGN) is the AWS-native tool for this pattern.
Example: a regional healthcare group has a patient scheduling system on aging virtual machines and a lease ending in nine months. Rehosting gets it onto Amazon EC2 on time, with the same code, so clinicians see no change.
Benefits: speed, low risk to application logic, and a stable foothold from which to modernize later.
Limits: you carry old inefficiencies with you. Without a clear business goal, rehosting can leave you with technical debt rather than cloud efficiency.
Cost: the migration service is cheap, but infrastructure is not free. AWS notes you pay for EC2 and EBS resources provisioned for replication and for test or cutover instances. Right-size after the move instead of copying oversized on-premises servers one for one.
Relocate: moving the platform, not the machines
Relocation moves infrastructure at the platform level, such as VMware workloads to AWS, without changing individual servers or rewriting anything. It suits organizations with a large virtualized estate and a hard deadline, because operational tooling stays familiar.
Limits: you keep the same architecture and the same operating model, so savings come later through modernization. It only applies where the source platform is supported.
Cost: expect a lower migration labor cost than replatforming, with optimization work deferred to after the move.
Repurchase: replace it with SaaS
Repurchasing means dropping a self-managed application and moving to a SaaS product. Think HR, CRM, email or a ticketing system that you run on your own servers today.
Benefits: no servers to patch, and vendor-managed updates.
Limits: data migration, user retraining, integration rework and the loss of custom behavior. For regulated data, check the vendor’s compliance posture before you sign.
Cost: you swap infrastructure spend for subscription spend. Compare total cost over several years, including integration and training, not just the license line. Our guide to hidden cloud ERP costs shows the budget buckets that tend to get missed in this kind of move.
Replatform: lift, tinker and shift
Replatforming makes a few targeted changes to gain cloud benefits without touching the core architecture. The classic example is moving a self-managed database to a managed service. AWS Database Migration Service (DMS) handles data movement for these cases.
Example: a fintech startup runs its ledger on a database server it patches by hand. Moving to a managed database removes backups and patching from the engineering to-do list while the application code stays the same.
Benefits: real operational savings at moderate risk.
Limits: scope creep. Every “small tweak” needs testing, and a replatform that keeps growing is a refactor in disguise.
Cost: DMS offers on-demand, serverless and Savings Plan pricing, with no minimum fees or upfront commitments on the first two. Add testing time to the estimate.
Refactor or re-architect: the big investment
Refactoring redesigns an application to use cloud-native capabilities: services, containers, event-driven components, managed data stores. It is the most expensive R and the most rewarding when the product itself must scale, ship faster or support new features such as AI.
Example: an ed-tech company wants adaptive learning that personalizes lessons per student. The monolith cannot support it, so it is split into services around a modern data pipeline.
Limits: AWS says refactor is not recommended for large migrations because it modernizes during the move. The safer sequence is to land on AWS first, then modernize.
Cost: highest engineering effort, with payback in lower run costs, faster releases and capabilities the old design could not offer. This is cloud modernization in the full sense, and our legacy system modernization guide goes deeper on how to sequence it.
How to choose: a short decision path
Run each application through these questions in order:
- Does anyone still need it? If not, retire.
- Is there a blocker today, such as licensing, compliance or a dependency? If yes, retain and set a review date.
- Does a SaaS product do the same job? Consider repurchase.
- Is the deadline the main constraint? Rehost or relocate.
- Would one or two targeted changes remove real operational pain? Replatform.
- Is this a product whose architecture limits the business? Plan a refactor, after it is stable on AWS.
Analogy: buying a Ferrari for a farm is the refactor of a back-office tool nobody uses. It looks impressive and solves nothing. Match the investment to the value of the workload.
The migration process, step by step
AWS describes migration in three phases: assess, mobilize, and migrate and modernize. The Well-Architected Migration Lens applies six pillars across them: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability.
Assess: workload assessment and dependency mapping
Start with inventory. AWS Application Discovery Service and Migration Evaluator gather infrastructure and dependency data to support migration planning. Then:
- Group servers into applications.
- Map what talks to what: databases, batch jobs, third-party APIs, authentication.
- Record owners, data sensitivity, uptime needs and compliance obligations.
- Assign a provisional R and a business reason to each application.
Missed dependencies are a classic cause of cutover surprises. An app that moves cleanly but loses its link to an on-premises file share is still an outage.
Mobilize: landing zone, security and team
Build the landing zone, close readiness gaps and set up security and compliance workstreams. For larger organizations, AWS urges setting up a Cloud Center of Excellence early so decisions do not stall.
Cloud architecture planning belongs here too: account structure, network layout, identity, logging, backup and tagging for cost allocation.
Migrate: data transfer, testing and cutover
- Data transfer. AWS DataSync handles file transfers, DMS handles databases. Both support encryption in transit. Our overview of cloud migration tools explains how to avoid paying for replication longer than you need.
- Testing. Launch test instances, run functional, performance and security tests against real data volumes, and have business users sign off.
- Cutover. Pick a window, freeze changes, run a final sync, switch traffic, and keep a tested rollback path until the new environment is proven.
- Monitoring. Watch latency, error rates and cost daily in the first weeks.
Security and compliance: shared responsibility in practice
Under the AWS model, AWS secures the infrastructure and you secure what you put in it. That means data management, credentials and adherence to your compliance regulations stay with you.
Timing matters. AWS guidance says that treating security as a late validation step often leads to failed audits or costly re-architecture, and recommends doing security discovery and documentation in the mobilize phase. The Migrate guidance adds the need to understand data security obligations, set up secure credential handling and monitor throughout.
In practice:
- Classify data before it moves. Patient records and payment data carry different rules than marketing assets. If you handle health data, confirm your obligations with your compliance officer or counsel.
- Keep credentials out of scripts and use a secrets service.
- Turn on logging from day one so audit evidence exists when you need it. Our SOC 2 checklist lists the controls auditors typically ask about.
- Decide early whether any workloads, such as private AI systems, must stay in a tightly controlled environment. Approaches like air-gapped Kubernetes deployments show what artifact verification looks like when data cannot leave your boundary.
Downtime, cost and other common challenges
Downtime. Continuous replication lets you cut over in minutes instead of days, but only if rehearsed. Practice at least one full cutover in a test environment. For applications you are changing at the same time, a zero-downtime deployment runbook keeps releases from colliding with migration weekends.
Cost surprises. Three lines catch teams out:
- Test and cutover instances start billing the moment they launch.
- Data coming into AWS is free, but transfer between Availability Zones, Regions or out of AWS is charged at standard rates.
- Oversized servers copied as they were on premises.
After the move, plan a cost review. Our three-phase AWS cost optimization approach shows how engineering and finance can do this together over several weeks.
Skills gaps. Teams that ran a data center for years rarely have cloud-native experience. Pair them with experienced engineers rather than learning on production.
No clear why. AWS migration experts flag this one most: define the business goal before the technique. Scalability for a fintech and adaptive learning for an ed-tech company lead to different strategy choices.
After cutover: post-migration optimization
Migration is the start of the operating model, not the end. In the first 30 to 90 days:
- Right-size compute and storage using real usage data.
- Decommission source systems and replication resources you no longer need.
- Review alerts, backups and recovery tests.
- Pick the next modernization targets: managed databases, containers, or data pipelines that feed analytics and AI.
- Record lessons learned for the next wave.
Our perspective
We see the same pattern in nearly every engagement: teams pick a strategy before they understand the application. Someone says “just lift and shift it” and six months later the cloud bill matches the old data center bill, with new problems on top.
Our view is simple. Assessment is insurance. A few weeks of workload assessment and dependency mapping cost far less than an emergency re-architecture after a failed cutover. We favor a sequence that matches AWS guidance: get stable on AWS first with rehost, relocate or replatform, then modernize the applications that earn it.
We staff migrations with senior engineers only, and we respond within 24 hours, because migration decisions get stuck when answers take days. Whether you need a full delivery team or a few experienced engineers added to your own, we scope the engagement around the workloads, not the other way around.
— Usama
Plan your AWS migration with Bitrupt
If you have an inventory and a deadline but not yet a strategy, our cloud migration services cover assessment, landing zone design, migration and post-migration optimization, delivered by senior engineers. Pricing is scoped per project, so start with a conversation about your workloads.
FAQ
What are the 7 migration strategies for AWS?
They are retire, retain, rehost, relocate, repurchase, replatform and refactor or re-architect. AWS uses them to categorize every workload in a portfolio. Each application gets one, based on its business value, risk and deadline.
What is the difference between the 6 Rs and the 7 Rs?
Older AWS material described six strategies. The current AWS guidance lists seven, adding relocate. The practical difference is small: relocate covers platform-level moves such as VMware to AWS, which the older list folded into rehosting.
Which AWS migration strategy is best?
None is best in general. Rehosting is fastest, replatforming balances effort and benefit, and refactoring delivers the most long-term capability at the highest cost. For big portfolios, AWS suggests landing first and modernizing afterward.
What AWS tools help with migration?
AWS offers Application Migration Service for rehosting, Database Migration Service for databases, DataSync for file transfers, and Application Discovery Service and Migration Evaluator for discovery. The AWS decision guide on migration services explains how to choose among them.
Sources
- About the migration strategies, AWS Prescriptive Guidance
- Migration strategy (7Rs) recommendations, AWS Transform
- Migration tools, AWS Prescriptive Guidance
- AWS Application Migration Service pricing
- AWS DMS pricing
- Migration Lens, AWS Well-Architected Framework
- Design principles, Migration Lens
- Migrate, Migration Lens
- AWS Secure Migrations Framework
- Choosing AWS migration services and tools
