Ask five cloud providers how many cloud migration strategies exist and you will get five different answers. AWS’s original framework had six. In 2020, AWS added a seventh, Relocate, for moving VMware workloads wholesale. Microsoft’s Cloud Adoption Framework splits one of the original six into two separate strategies and adds a third, landing at eight. Akamai’s version drops one of the original six entirely. Cisco still teaches the classic six.
None of that is pedantry. Whichever count a team plans around changes what gets budgeted, how long the migration takes, and which workloads get grouped together by mistake. This blog uses the six R’s that show up most consistently across vendor frameworks and cover the decisions nearly every enterprise migration actually has to make: Rehost, Replatform, Repurchase, Refactor, Retire, and Retain. Where a seventh or eighth strategy from AWS or Microsoft is genuinely useful, it is called out in context.
The rest of this blog treats each strategy the way a CTO actually has to, as a cost, risk, and timeline decision, not a dictionary definition.
The 6 R’s at a Glance
| Strategy | What changes | Typical timeline | Best for |
|---|---|---|---|
| Rehost | Infrastructure only | Weeks | Stable workloads, fast deadlines |
| Replatform | Targeted infrastructure optimization | Weeks to months | Workloads that need cloud-native benefits without a rebuild |
| Repurchase | Application replaced entirely | Months | Heavily customized legacy systems with a mature SaaS alternative |
| Refactor | Code and architecture | Months to a year or more | Business-critical systems limited by their current architecture |
| Retire | Nothing; workload is decommissioned | Days | Low-value, redundant, or unused systems |
| Retain | Nothing; workload stays in place | Not applicable | Compliance-bound or recently upgraded systems |
Rehost: The Fast Option That Is Not Free Later
Rehosting, commonly called lift and shift, moves a workload to cloud infrastructure with minimal changes to the application itself. It is the fastest path to an exit date on a data center lease and the lowest-risk option for a workload nobody wants to touch under deadline pressure.
The tradeoff shows up after the migration is done, not during it. Rehosting moves a workload’s existing inefficiencies to the cloud along with the workload, and those inefficiencies now show up as a monthly bill instead of sunk capital. Flexera’s 2026 State of the Cloud Report found that wasted cloud spend rose to 29% of total cloud spend, the first increase in five years, and unoptimized rehosted workloads are a routine contributor. Rehost is the right call for a workload on a hard deadline, or one already slated for retirement or a refactor within a year or two. It is the wrong default for an entire portfolio, because the bill for an unoptimized workload arrives every month, not once.
Replatform: Optimization Without a Rebuild
Replatforming makes targeted changes during the move, migrating a database to a managed service or containerizing an application, without touching the core architecture. It captures real cloud-native benefits, lower operational overhead, and better reliability, without the cost and risk of a full refactor.
This is the strategy most CTOs underuse. It requires more planning than a rehost but far less than a refactor, and for a large share of enterprise workloads it delivers most of the cost and reliability benefit a full rearchitecture would, at a fraction of the engineering time and with a much shorter path to production.
Repurchase: When Buying Beats Building
Repurchase means retiring a custom or heavily modified system in favor of a SaaS alternative, replacing a homegrown CRM with a commercial platform, for example. It is the R most likely to get left out of a technical migration conversation, because it is a build-versus-buy decision that happens to coincide with a migration rather than a purely technical one.
The case for repurchase is strongest when the system being replaced is highly customized legacy software that nobody fully understands anymore, the kind where the original developers are long gone, and the documentation is thin. The real cost is organizational rather than technical: data migration, user retraining, and process change. That is why the repurchase decision belongs in the same planning conversation as the migration timeline, not bolted on after the technical plan is already set.
Refactor: The Expensive Option With the Longest Payoff
Refactoring, sometimes called re-architecting, rebuilds an application to take advantage of cloud-native capabilities: microservices instead of a monolith, serverless instead of fixed capacity, horizontal scaling instead of a bigger box. It is the most expensive and time-consuming of the six strategies, and it is the only one that actually removes technical debt instead of carrying it forward into the new environment.
Refactor the systems that are genuinely limiting the business, the ones where scaling constraints, maintenance cost, or architectural rigidity show up as a real, measurable business problem, not every legacy system a team finds distasteful. A refactor with no clear business driver behind it becomes a multi-quarter engineering investment with no sponsor once budget season arrives. Refactoring is also where a migration and an AI-readiness effort tend to converge, since the same architectural changes that enable elastic scaling often enable the data pipelines and integration patterns an AI-native application needs.
Retire: The Free Option Almost Everyone Under-Uses
Retiring a workload means turning it off. It is the only one of the six strategies that shrinks the migration scope instead of adding to it, and it is consistently the most under-used. An honest application portfolio assessment routinely turns up workloads with negligible active usage that nobody has gotten around to decommissioning, because retiring something requires a decision, and lift-and-shifting it does not.
Every workload retired before migration is one fewer system to secure, monitor, license, and pay for in the new environment. It is worth a genuine audit rather than an assumption that everything currently running still needs to.
Retain: Not Every Workload Needs a Migration Story
Retaining a workload means leaving it exactly where it is, for now. Compliance requirements, a recent capital investment in on-premises infrastructure, or a vendor dependency with no cloud equivalent are all legitimate reasons to retain a system. The mistake is treating retain as a failure to migrate rather than a deliberate decision with its own review date.
Gartner expects more than 40% of leading enterprises to have adopted hybrid computing architectures for critical business workflows by 2028, up from about 8% today. That is a useful reminder that a cloud migration strategy ending in “everything eventually moves” is increasingly not the realistic target for most enterprises. A durable hybrid footprint, with a clear and documented rationale for what stays and why, is often the more honest plan than a roadmap that quietly assumes 100% migration.
How to Decide Which R Fits Which Workload
Four questions, asked per workload rather than once for the entire portfolio, do most of the decision-making work.
How much business value does this workload still generate?
Low or falling value points toward retire. High value combined with real technical constraints points toward refactor.
How stable is the workload, and does it need to change in the next two years anyway?
A stable workload with no near-term change requirement is a solid rehost candidate. One already on a modernization roadmap is a candidate to refactor now instead of migrating it twice.
Is there a mature SaaS alternative?
If yes, and the current system is heavily customized and poorly documented, repurchase usually beats any technical migration path.
What does the team have the capacity and skill to execute within the current budget cycle?
A refactor scoped beyond the team’s realistic bandwidth quietly becomes a rehost anyway, just a slower and more expensive one, because the deadline eventually forces a fallback.
The Mistake Most CTOs Make: One R for Everything
The most common planning error is not choosing the wrong strategy for a given workload. It is choosing one strategy for the entire portfolio. An “everything gets rehosted” mandate hits its limit the first time a business-critical system needs capabilities a lift-and-shift cannot deliver. An “everything gets refactored” mandate runs out of budget and time long before the portfolio does.
A workable migration plan applies a different R to different tiers of the application portfolio, informed by the criteria above, sequenced so the easiest wins (retire, rehost) fund and de-risk the harder work (refactor) later in the roadmap. It is also where migration planning surfaces genuine data quality and dependency problems: Flexera’s 2026 data found that understanding application dependencies is now the single most common cloud migration challenge organizations report, ahead of technical feasibility and cost comparison.
FAQ
1) What are the 6 R’s of cloud migration?
Rehost, Replatform, Repurchase, Refactor, Retire, and Retain. Some vendors, including AWS and Microsoft, now list seven or eight strategies by splitting refactor into finer categories or adding options like Relocate and Rebuild, but these six cover the decisions most enterprises actually face.
2) Which cloud migration strategy is the cheapest?
Retire costs the least, since it eliminates a workload rather than moving it. Among strategies that actually migrate something, rehost has the lowest upfront cost, though it can cost more over time if the workload is never optimized after the move.
3) Which cloud migration strategy takes the longest?
Refactor, typically months to more than a year depending on the system’s complexity, because it rebuilds the application’s architecture rather than changing infrastructure or configuration.
4) Can a CTO use more than one strategy in the same migration?
Almost always should. Enterprise application portfolios rarely fit a single strategy. The strongest migration plans apply different R’s to different workload tiers based on business value, technical constraints, and team capacity.
5) Is rehosting a bad strategy?
No, but it is frequently misapplied as a default for every workload rather than a deliberate choice for stable, low-complexity systems on a deadline. Rehosting without a later optimization or refactor plan is a common contributor to the wasted cloud spend research firms like Flexera track every year.
How [x]cube LABS Can Help
[x]cube LABS runs cloud migrations across five core execution strategies: Rehost, Replatform, Refactor, Retain, and Retire, with Repurchase evaluated case by case during discovery for workloads where a SaaS alternative outperforms a technical migration entirely. Every workload is assessed individually against this framework instead of being assigned a single strategy for the whole portfolio, through a four-phase process: preparation and planning, discovery and proof of concept, migrate and validate, then optimize, with the team staying engaged through the optimization phase rather than handing off at cutover.
The practice is vendor-agnostic across AWS, Azure, and GCP, with recommendations based on workload requirements and compliance needs rather than partnership incentives. That approach has scaled an industrial IoT monitoring platform across more than 80 countries and rebuilt a national diagnostics platform’s patient engagement systems on a hybrid Azure and AWS architecture, scaling daily order throughput roughly one hundred times over. For more on how the cloud services practice approaches assessment, migration, and post-migration optimization, see the team’s full methodology.
Talk to someone who has actually built this.