Cloud migration programs rarely fail on technology. They fail on decisions. Either every application is lifted and shifted, carrying old inefficiencies into a more expensive environment, or every application is earmarked for modernization, and the program stalls after a handful of heroic rewrites while the data center lease runs out. The 7 Rs exist to prevent both outcomes. They give architects, application owners and finance a shared vocabulary for deciding, workload by workload, what moves, how it moves and when.
The framework is more than a decade old, but the pressure to use it well has rarely been higher. Virtualization licensing changes, a wave of Microsoft end-of-support dates and board-level demands to get data ready for AI have pushed many organizations into migration decisions on deadlines they did not choose. This guide explains each strategy as the major providers define it in 2026, offers a repeatable method for assigning dispositions across a portfolio, covers the special cases that dominate current programs and shows how the choices translate into migration waves.
Why the 7 Rs Matter More in 2026
Three forces are reshaping migration portfolios this year.
- Virtualization economics. A CloudBolt survey of 302 North American IT decision-makers, conducted in January 2026 and reported by CIO.com, found that 86% are reducing their VMware footprint after Broadcom’s licensing changes, 59% have seen price increases above 25%, and 72% name public cloud IaaS as a destination. Yet only 2% had moved 75% or more of their environment. Analysts quoted in the same piece describe leaving VMware as a multi-year program rather than a procurement switch, which is exactly the situation the 7 Rs are designed for.
- End-of-support deadlines. Microsoft lists SQL Server 2016 extended support as ending on July 14, 2026, and Windows Server 2016 on January 12, 2027. Each date forces a choice between paying for Extended Security Updates, upgrading in place or using the deadline to replatform. Microsoft notes that ESUs for these products are available for three more years in Azure, which changes the economics of rehosting old servers there.
- AI and data ambitions. Many migration business cases now include “make data usable for AI,” which favors replatforming databases onto managed services and consolidating data into governed cloud platforms, but can also tempt teams into over-ambitious refactoring.
Meanwhile, tooling has improved. AI-assisted discovery, code analysis and conversion are compressing the effort for some strategies, a shift we cover in AI-assisted cloud migration. Better tools make each disposition cheaper to execute, but they do not make the decision for you.
The Strategies as AWS and Microsoft Define Them Today
AWS Prescriptive Guidance documents seven strategies. Microsoft’s Azure migration guidance lists eight, separating refactor, rearchitect and rebuild, and calling repurchase “replace.” The labels differ slightly; the discipline is the same.
Retire
Decommission or archive applications that no longer deliver value. AWS suggests concrete signals: “zombie” applications with average CPU and memory utilization below 5%, “idle” applications between 5% and 20% over 90 days, and servers with no inbound connections for 90 days. In most portfolios, retirement is the cheapest win available, because every retired server is one you never migrate, secure or license again.
Retain
Keep the application where it is, for now or indefinitely. Legitimate reasons include data residency or regulatory constraints, dependencies that must move first, a recent hardware refresh, a vendor SaaS version that is coming soon, specialized hardware with no cloud equivalent, or mainframe and midrange platforms that need a dedicated plan. Retain is a decision with a review date, not a polite word for “ignored.”
Rehost
Lift and shift to cloud infrastructure without changing the application. It is the fastest path for large numbers of servers and the default for deadline-driven exits. Both providers recommend migrating first and optimizing later, because applications are easier to modernize once they run in the cloud, with cloud-native monitoring and automation around them.
Relocate
Move servers or applications to a cloud-hosted version of the same platform, for example a VMware-based service in the cloud, or move resources between accounts, VPCs or regions. AWS describes it as the fastest path with no architecture change, no new hardware and no rewritten code. In 2026, check carefully how virtualization licensing is handled in the target service, because relocating keeps you on the same platform and therefore exposed to the same vendor’s pricing.
Replatform
“Lift, tinker and shift”: move with targeted optimization but without changing the core architecture. Typical moves include SQL Server to a managed database service, a Windows-to-Linux shift, adopting ARM-based instances or containerizing virtual machines. This is where much of the value in modern programs sits, because it removes undifferentiated operational work without the cost and risk of a rewrite.
Repurchase or Replace
Replace the application with a different product, typically SaaS. Common for CRM, HR, ITSM and collaboration tools. The migration effort shifts from infrastructure to data migration, integration, identity and user training, and security and compliance reviews must come first.
Refactor, Rearchitect and Rebuild
Redesign the application to use cloud-native capabilities, or build a new implementation when other options cost more than they return. Triggers include monoliths that slow delivery, code nobody can maintain and scaling needs the current design cannot meet. AWS is blunt that this is the most complex and costly strategy and advises against refactoring during large migrations unless no other option is acceptable. For platform choices at this stage, see our containers versus serverless decision guide.
The goal of the 7 Rs is not to modernize everything. It is to give every workload an explicit, defensible decision, so that effort is spent where it returns the most and deadlines are met everywhere else.
A Disposition Method That Scales Across Hundreds of Applications
Assigning strategies one meeting at a time does not scale beyond a few dozen applications. A repeatable method does.
- Build the inventory from evidence. Combine CMDB records with automated discovery of servers, utilization, network connections and installed software. The CMDB tells you what people think runs; discovery tells you what actually runs and talks to what.
- Group servers into applications. Dispositions apply to applications and their dependencies, not individual machines. Use dependency mapping and owner interviews to define application boundaries and move groups.
- Apply quick filters. Flag retirement candidates using utilization and connection data, and flag retain candidates for hard constraints such as residency, specialized hardware or pending SaaS replacement. In many estates, these two filters alone remove a meaningful share of the portfolio from the migration scope.
- Score the remainder. Rate each application on business value, technical condition, migration complexity and constraints (see criteria below). Plot value against condition to suggest a default strategy.
- Validate with owners. Hold short, structured disposition workshops in which owners confirm or challenge the suggested R. Record the rationale, because it will be questioned later.
- Attach cost and effort. Estimate run cost in the target state and one-time migration effort for each disposition. This is what turns a technical classification into a business case.
- Revisit at milestones. Dispositions change as you learn. Re-score applications at each wave planning cycle rather than treating the first assessment as final.
Decision Criteria: How to Choose Between the Rs
A simple scoring model with clear criteria makes workshops faster and outcomes more consistent.
- Business value and roadmap. Is the application differentiating, needed but commodity, or declining? Differentiating applications with active roadmaps justify replatforming or refactoring; commodity functions point toward replacement; declining ones toward retirement or retention.
- Technical condition. Supported operating system and database versions, test coverage, code maintainability and availability of source code. Poor condition plus high value suggests refactoring after migration; poor condition plus low value suggests retirement or replacement.
- Deadline pressure. Data center exits, contract renewals and end-of-support dates favor rehost and relocate for anything that cannot be safely changed in time.
- Data gravity and latency. Applications that exchange large volumes with each other should move together; latency-sensitive systems tied to on-premises equipment may need to be retained or deployed at the edge.
- Licensing. Bring-your-own-license rights, hybrid benefits, ESU availability and virtualization subscription terms can swing the economics between rehost, replatform and replace.
- Compliance and sovereignty. Residency rules and sector regulations may constrain target regions or require specific controls, which can favor sovereign cloud offerings or retention.
- Team capacity. A refactor that the team cannot staff will not happen on schedule. Match the disposition to the skills you have or can realistically add.
Special Cases Dominating 2026 Programs
VMware estates
For large VMware footprints, the realistic answer is usually a blend. Relocating to a cloud-hosted VMware service buys time and avoids reworking operations, but keeps you on the same platform. Rehosting to native cloud virtual machines with tools such as AWS Transform MGN or Azure Migrate removes the hypervisor dependency but requires new operational tooling. Some workloads are better replatformed straight to managed databases or containers. A phased plan, with relocation for the hardest-to-move systems and rehost or replatform for the rest, matches the gradual “calculated retreat” that CloudBolt’s survey describes.
Windows Server and SQL Server 2016
For servers running these versions, compare three paths: upgrade in place and stay on-premises, rehost to the cloud and use ESUs while planning an upgrade, or replatform databases to a managed service that removes version management from your team altogether. The deadline is a useful forcing function for the third option, since a managed database service also removes much of the patching work that caused the version drift in the first place.
Mainframe and midrange
These systems usually start as retain with a dedicated modernization track. AI-assisted code analysis has made assessment faster, but the disposition for core transaction systems should still be driven by business risk, data migration complexity and the availability of skills, not by tooling enthusiasm.
Data platforms and AI readiness
Warehouses, data marts and reporting databases are frequent replatform candidates, often toward a lakehouse or a managed cloud warehouse. Treat them as their own track, because their consumers span many applications and their cutover needs careful reconciliation. Our guide to near-zero-downtime migration with CDC covers the cutover patterns.
From Dispositions to Migration Waves
Dispositions tell you what to do; waves tell you when. Good wave plans balance risk, dependencies and learning.
- Start with a pilot wave of low-risk, representative applications to prove the landing zone, network connectivity, security controls, tooling and runbooks.
- Group by dependency, not by department. Applications that talk to each other heavily should move in the same or adjacent waves to avoid latency and data transfer surprises.
- Mix strategies within waves carefully. Rehost-heavy waves move fast and build momentum; replatform work runs in parallel streams with its own testing cadence.
- Schedule retirements early. Decommissioning shrinks scope and frees licenses and hardware, which helps fund later waves.
- Plan optimization after each wave. Rightsize, apply commitments and fix tagging within weeks of cutover, or migrated workloads quietly cost more than they did on-premises.
Worked Example: A 300-Application Portfolio
Imagine a hypothetical manufacturer with roughly 300 applications on about 1,500 virtual machines, a VMware renewal in 18 months and a significant number of Windows Server 2016 and SQL Server 2016 instances. Leadership wants to exit one of two data centers and build a governed data platform to support AI use cases.
Discovery and utilization analysis flag about 40 applications as retirement candidates, mostly duplicate reporting tools and abandoned departmental apps; owner workshops confirm 30 of them. Around 25 applications are retained for now, including plant-floor systems tied to local equipment and a midrange ERP with its own modernization track. Eighteen commodity applications, such as a legacy helpdesk and an on-premises HR tool, are slated for SaaS replacement.
Of the remaining applications, most are scored as rehost candidates because the VMware renewal makes speed essential, with the hardest-to-move clusters relocated to a cloud-hosted VMware service as a bridge. About 50 applications with SQL Server back ends are replatformed to a managed database service, using the end-of-support deadline as the business case. Only a handful of high-value customer-facing applications are marked for refactoring, and those are scheduled after the migration rather than during it. The data warehouse is replatformed in its own track toward a lakehouse architecture.
The resulting plan runs a pilot wave in month three, followed by monthly waves of 20 to 40 applications. Retirements happen in the first six months, freeing licenses that offset early cloud costs. The bridge environment is scheduled for exit once its workloads have been rehosted, avoiding a long-term dependency on the platform the program set out to leave.
Pitfalls to Avoid
- One R for everything. Blanket lift-and-shift or blanket modernization both fail; the value is in differentiation.
- Refactoring under deadline. Rewrites during a time-boxed migration are the most common cause of slipped exits. Migrate first, modernize after.
- Skipping retirement analysis. Every application you migrate unnecessarily costs effort, licenses and run spend for years.
- Treating retain as permanent by default. Give every retained application an owner and a review date.
- Ignoring post-migration optimization. Rehosted workloads sized like their on-premises predecessors are often overprovisioned. Budget for rightsizing and commitments from the start.
- Underestimating data. Data migration, reconciliation and cutover planning routinely take longer than infrastructure moves, especially for replatformed databases and SaaS replacements.
Conclusion: Make Every Decision Explicit
The 7 Rs are simple to list and hard to apply well. In 2026, virtualization licensing, end-of-support deadlines and AI ambitions are compressing timelines and raising the stakes of every disposition. Organizations that succeed build an evidence-based inventory, filter aggressively for retirement and retention, score the rest against clear criteria, validate with owners and translate decisions into dependency-aware waves with optimization built in. The result is a program that meets its deadlines, spends modernization effort where it creates the most value and leaves a cloud estate that is cheaper and easier to evolve than the one it replaced.
How Hanoi Technology Can Help
Hanoi Technology runs cloud migration assessments and migration factories, from discovery and 7 Rs dispositions to wave execution and post-migration optimization.