Choosing a path for a legacy app starts with knowing what each R stands for. This guide is for IT heads, app owners and architects at mid-size companies in India and the GCC. They have older, custom or tightly coupled apps to move to AWS or Azure. It explains the 7 Rs of cloud migration, and why the lists differ: AWS names seven, Microsoft names eight and an early Gartner list had five. Treat seven as one vendor’s count.
Last reviewed 2026-11-01 by Manish Sharma.
The 7 Rs of Cloud Migration: The Short Answer
In the 7 Rs of cloud migration, the AWS names are retire, retain, rehost, relocate, repurchase, replatform and refactor. They sort into five questions you ask about each app. Decide per app, and mix strategies across the portfolio.
Key Takeaway Choose each path from what the app needs, whatever the strategy is called.
There Is No Single Official List
Three lists are in use. An early Gartner list had five strategies: rehost, refactor, revise, rebuild and replace. Secondary coverage dates it to 2010 or 2011, and Gartner’s original report is not freely available. Treat the year and the names as reported by others.
The AWS Prescriptive Guidance names seven: retire, retain, rehost, relocate, repurchase, replatform and refactor or re-architect. The Microsoft Cloud Adoption Framework names eight: retire, retain, rehost, replatform, refactor, rearchitect, rebuild and replace.
Why the counts differ is partly history. In a 2021 post on the AWS Enterprise Strategy blog, AWS says its earlier model had six strategies, from a 2016 post. It says the list grew to seven in late 2017 with the launch of VMware Cloud on AWS. The same label can also mean different things across vendors, so map the names before you compare two sources.
Seven, eight and five are each one source’s count. When a report on cloud migration quotes “the 7 Rs” or “the 8 Rs”, check which list it uses.
The 7 Rs of Cloud Migration, Part 1: Decide Whether to Move at All
Two of the Rs mean leaving an app where it is: retire it or retain it. Check these first, because they take work off the list.
Retire
Retire an app that has no business value, has unsupported operating systems or components, or has very low use. AWS Prescriptive Guidance gives usage signals (as of November 2026). Apps with average CPU and memory below 5% are called “zombie” apps. Those between 5 and 20% over 90 days are called “idle”, and AWS says you might retire either kind. It also lists no inbound connection for 90 days as a signal. Treat these as prompts to ask the owner, and confirm with the owner before you retire anything.
An app with low use all year may still run a quarterly or year-end process. Ask the owner when it last mattered.
Retain
Retain an app when moving it is not yet right. AWS lists reasons such as data residency, high risk, dependencies that must move first, a recent upgrade, no value, a SaaS version expected soon, and specialized hardware. It also names mainframe, mid-range platforms such as IBM AS/400 and Oracle Solaris, and non-x86 Unix. On Azure, Microsoft notes that you can manage retained on-premises workloads from the cloud with Azure Arc.
Mainframe, mid-range and non-x86 Unix systems need careful assessment before any move. A rehost plan written for x86 servers may not fit them.
The 7 Rs of Cloud Migration, Part 2: Move With the Least Change
Rehost and relocate move an app with little or no change. AWS calls relocate the quickest way to migrate. Neither path changes the app, so the old app’s problems move with it.
Rehost, also called lift and shift, moves the app as it is onto cloud virtual machines. It does not fix existing problems, and it can carry technical debt into the new environment. Technical debt means old shortcuts that make change harder. Microsoft advises confirming that the workload needs no modernization within about two years before you rehost it.
Relocate moves servers to a cloud version of the same platform. One example is VMware workloads moving onto a VMware service in the cloud. Relocate can also move instances between accounts, networks or Regions on AWS.
For cloud migration tools, AWS lists AWS Transform MGN among its services for automating rehosting, and Azure Migrate covers servers on Azure (as of November 2026). This guide does not compare tools. Our guide on application migration to the cloud covers the method for the move.
Advantages
Limitations
For the strategy view of rehost, replatform and refactor, see our post on legacy modernization.
The 7 Rs of Cloud Migration, Part 3: Change Some of It
Replatform keeps the app’s design and swaps parts of what it runs on. Common changes are a managed database, a newer operating system, or containers. The aim is to improve cost, security or operations while the legacy app keeps running.
Each swap needs a compatibility test, so replatform one part at a time and keep a way back.
The 7 Rs of Cloud Migration, Part 4: Change Most of It
Refactor means changing the app’s code or design, and AWS calls it the most complex path. Microsoft splits it into refactor, rearchitect and rebuild, from small code changes to full redevelopment.
For large migrations, AWS lists rehost, replatform, relocate and retire as the common strategies. It does not recommend refactor there, because refactor can be hard to manage across many apps. AWS suggests modernizing after the move where possible, and refactoring first only when the other paths are not acceptable. Cases that fit include a mainframe that no longer meets demand, a monolith that slows delivery, and an app nobody can maintain or whose source code is unavailable. A monolith is an app built as one tightly coupled block.
Change as few things at once as you can. Our guide to cloud migration risks covers what goes wrong when a move changes too much.
Key Takeaway The more you change during a move, the more you can break, so change the minimum that the app needs.
The 7 Rs of Cloud Migration, Part 5: Replace It
Repurchase, which Microsoft calls replace, drops the old app for a SaaS product or a commercial alternative. Some workloads are better deployed new than migrated.
Assess business, security and compliance fit first. Then plan training, data migration, authentication and networking, since these are where a replacement stalls.
How to Choose Among the 7 Rs of Cloud Migration for a Legacy App
Apply the checks in order, and stop at the first path that fits. Ask the cheapest questions first.
A Decision Order
Does the app still have business value and use?
Do residency, risk, dependencies, hardware or platform type say not yet?
Try rehost or relocate first, then replatform.
Modernize during the move only if you have the skills and time, compatibility requires it, or funding allows.
Note the owner, the dependencies and a review date.
Our post on cloud optimization covers what to do after the move.
The Evidence That Decides
Tie each choice to evidence you can point to. Look at the source code, the software’s support status, its dependencies, its licenses, data-residency rules and any specialized hardware. Then ask whether the benefit outweighs the cost.
Record the choice, the owner, the dependencies and a review date, so the decision can be challenged later.
A Comparison of the 7 Rs of Cloud Migration for Legacy Applications
The table maps each of the 7 Rs of cloud migration in the AWS list to the closest Microsoft name. Map the names before you compare two sources.
| Strategy (AWS / Microsoft) | What changes | Fits a legacy app when | Evidence to check | Main risk |
|---|---|---|---|---|
| Retire / Retired | Nothing is moved | The app has no value or very low use | Usage over 90 days | Retiring a rarely used but needed app |
| Retain / Retained | Nothing moves yet | Residency, risk or platform says not yet | Residency rules, platform type | Staying put with no review date |
| Rehost / Rehosted | Where it runs | It needs no change for two years | Dependencies, support status | Carrying technical debt |
| Relocate / none | The platform, same product | It runs on a platform with a cloud version | Platform version, compatibility | Compatibility limits |
| Replatform / Replatformed | Parts of the stack | A managed service would help | Compatibility test results | Hidden incompatibilities |
| Refactor / Refactored, Rearchitected, Rebuilt | Code and design | Other paths are unacceptable | Source code, skills, time | Cost and complexity |
| Repurchase / Replaced | The app itself | A SaaS or commercial product fits | Business, security and compliance fit | Data and training effort |
The same label can mean different things across vendors. Match each strategy by what changes.
What This Article Does Not Cover, and When to Get Help
This guide chooses a path. It does not give the method for the move, the full set of risks or a checklist. Our post on legacy modernization goes deep on rehost, replatform and refactor.
Bring in outside help when no one knows the app well, when the estate includes mainframe or mid-range platforms, or when the timeline is tight. For the wider picture, see how Signisys helps you migrate legacy applications to the cloud. Our page on cloud migration and modernization on AWS and Azure adds detail. See also cloud services and platform engineering.
References
- AWS Prescriptive Guidance, About the migration strategies, guide for AWS large migrations.
- Microsoft Learn, Select your cloud migration strategies, Cloud Adoption Framework.
- AWS Enterprise Strategy Blog, 7 Strategies for Migrating Applications to the Cloud, 30 November 2021.
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.