Cloud Migration Strategy: The 6 R's Explained (and How to Pick the Right One)
In short: A cloud migration strategy means deciding, per application, which of six approaches fits: rehost, replatform, repurchase, refactor, retire, or retain. Most organizations use a mix rather than one approach for everything — lifting-and-shifting a workload that doesn't need to change, while re-architecting the one that actually benefits from cloud-native scaling. Getting this mix right, not the migration tooling, is what determines whether the project pays off.
What this means for you
- Treat each application as its own decision — don't default to lift-and-shift for everything.
- Rehosting is fastest but often the most expensive to run afterward; refactoring costs more up front but scales cheaper.
- Most failed migrations fail in the planning phase, not the cutover — dependency mapping catches this early.
"Cloud migration strategy" gets treated as a single decision — AWS, GCP, or Azure — when the harder and more consequential decision is what happens to each application once you've picked a provider. Move it as-is? Rebuild it? Replace it with a SaaS product instead? Those choices, made per workload, are what actually determine the project's cost and outcome.
The 6 R's, explained
The framework below was popularized by AWS in 2016 and has become the industry-standard vocabulary for this decision, building on an earlier 5 R's model from Gartner.
1. Rehost — lift-and-shift
Move the application to cloud infrastructure with no changes to its architecture: same operating system, same binaries, same configuration, just running on a virtual machine in the cloud instead of on-premises hardware. It's the fastest path to "we're in the cloud," which makes it the default choice for time-boxed migrations like a data-center exit. The tradeoff shows up later: an application not designed to scale elastically often costs more to run in the cloud than it did on owned hardware, because nothing about how it consumes resources has changed.
2. Replatform — lift, tinker, and shift
Make targeted changes during the move — swap a self-managed database for a managed equivalent, containerize the application, adjust it to use managed load balancing — without a full rebuild. This is usually the pragmatic middle ground: meaningfully cheaper to run than a straight rehost, without the time and risk of a full refactor.
3. Repurchase — move to a different product
Replace the application with a SaaS or managed equivalent instead of migrating it at all. A self-hosted CRM or ticketing system is the classic candidate — if a mature SaaS product already does the job, migrating your existing one is often more expensive than switching.
4. Refactor — re-architect for the cloud
Rebuild the application to take advantage of cloud-native patterns: breaking a monolith into services, adopting managed and serverless components, redesigning the data layer around how the cloud actually charges for compute and storage. This costs the most up front and takes the longest, but it's the only option that meaningfully changes the application's long-term scalability and running cost — worth it for the systems your business depends on most, not for something you're likely to retire in two years.
5. Retire — decommission it
Every infrastructure audit turns up applications nobody uses, or that duplicate something else in the portfolio. Migrating those is pure waste. Retiring them before the migration starts shrinks the project and removes a support burden you were carrying for no reason.
6. Retain — leave it, for now
Some applications genuinely aren't ready to move — a compliance constraint, a dependency on hardware that can't be virtualized, or a system already scheduled for replacement where a migration would be wasted effort. Retain is a deliberate decision to revisit later, not a default for anything that looks complicated.
How to decide which R fits which workload
Score each application on two axes: how business-critical it is, and how much technical debt or scaling pressure it's already under. A low-criticality, low-debt application is a reasonable rehost candidate — there's little to gain from investing more. A high-criticality application already straining under load is a strong refactor candidate, because the cost of not fixing its architecture compounds. Everything else tends to land on replatform, which is why it's usually the largest bucket in a real migration portfolio.
Dependencies matter as much as the criticality score. An application that looks like a simple rehost candidate on its own can turn into a much bigger project if it shares a database with three other systems that aren't moving on the same timeline — which is exactly the kind of thing a proper technical assessment is supposed to surface before migration starts, not during it.
Why cloud migrations fail or run over
Survey research on data and cloud migration projects has repeatedly found that a large share of CIOs report a failed or disrupted migration at some point, and that missed deadlines are common — not rare. The pattern behind most of those numbers is consistent: the assessment phase got compressed or skipped. Specifically:
- Unmapped dependencies. An application gets migrated before anyone confirms what it still talks to on-premises, and something breaks that nobody was watching for.
- No cost model for how the workload runs in the cloud. Rehosting without adjusting for elastic pricing is the most common way a migration technically succeeds and still blows the budget.
- Testing gets cut to protect a launch date. The fix that would have taken a day during testing takes a week as an incident after cutover.
- The people side gets skipped. New tooling and workflows need adoption time from the team running them, not just a working system.
None of these are technology problems. They're planning problems, which is why they're avoidable with the right process rather than a different cloud provider or migration tool. If your team is weighing this against building the case for cloud migration and DevOps support internally versus bringing in outside help, the assessment phase — dependency mapping, workload scoring, and a real cost model — is the part worth getting external eyes on first, since mistakes made there are the expensive ones to unwind later.
A phased approach that lowers the risk
Assess first: inventory every application, its dependencies, and its current resource usage, and score each one against the 6 R's above. Then pilot: pick one real but low-risk workload and run it through the full migration process end-to-end, including monitoring and rollback, before touching anything business-critical. Use what that pilot teaches you — about tooling gaps, about how your team actually works day to day — to refine the runbook for the harder migrations. Only then move the rest of the portfolio in planned waves, with the highest-risk, most business-critical systems going last, once the process has been proven on lower-stakes workloads first.
Frequently asked questions
What is the best cloud migration strategy?
There isn't one best strategy — there's a best strategy per workload. Most organizations end up running a portfolio: some applications get lifted-and-shifted as-is, some get re-architected to be cloud-native, and some get retired or left alone entirely. Picking the same approach for every application, usually rehosting everything, is one of the more expensive mistakes teams make, because it moves cost and complexity to the cloud instead of removing it.
What are the 6 R's of cloud migration?
Rehost (lift-and-shift the application as-is), Replatform (make small cloud-friendly changes without a full rebuild), Repurchase (switch to a SaaS or managed equivalent), Refactor (re-architect for cloud-native scaling), Retire (decommission an application nobody needs anymore), and Retain (leave it where it is, for now). The framework was popularized by AWS in 2016 and builds on an earlier 5 R's model from Gartner.
How long does a cloud migration take?
It depends entirely on scope — the number of applications involved, how tangled their dependencies are, how much data needs to move, and how much re-architecture is involved versus a straight lift-and-shift. A single, well-understood application can move quickly; a portfolio of interdependent legacy systems is a different project. We define a realistic timeline during discovery, once we've actually assessed what's moving, rather than quoting one up front.
Why do cloud migrations fail or run over budget?
The most common causes trace back to skipping or rushing the assessment phase: unknown dependencies between applications surface mid-migration, nobody modeled what the workload will actually cost to run elastically in the cloud, and testing gets compressed to protect a launch date. Migrations that fail rarely fail on the cutover itself — they fail because the planning phase didn't surface a risk that was knowable in advance.
Should I migrate everything at once or in phases?
In phases, for anything beyond a single simple application. Start with a pilot — a real but low-risk workload — to validate your tooling, runbooks, and rollback plan before committing anything business-critical. A phased migration also lets you apply what you learn from the first few workloads to the harder ones later, instead of discovering process gaps during your most important cutover.
Sources
- AWS: 6 Strategies for Migrating Applications to the Cloud (Stephen Orban) — The original 2016 framework defining the 6 R's — rehost, replatform, repurchase, refactor, retire, retain — that this post's decision framework is built on.
- Curiosity Software: The Research Is Clear — Too Many Migration Projects Fail — Survey findings (citing Cloud Security Alliance research) that most CIOs report a failed or disrupted data migration project, and that missed deadlines are common — the basis for this post's section on why migrations fail.
Need help putting this into practice?
Tech Programmer builds and ships this work for startups and enterprises. Tell us what you are trying to do and we will tell you what it takes.
Related reading
- Zero-Downtime Deployment: Blue-Green, Canary, and Rolling Strategies ExplainedZero-downtime deployment isn't one technique — it's a choice between blue-green, canary, and rolling strategies, each with a different cost and rollback profile. Here is how they actually differ, and the database migration step that breaks most 'zero-downtime' releases anyway.
- How to Choose a Software Development Company: A Vetting ChecklistPicking the wrong software development partner costs more than a bad invoice — it costs months of rework and a codebase you don't fully understand. Here is a practical framework for vetting one before you sign anything.
- MVP Development: A Practical Guide to Building One That Actually Validates Your IdeaAn MVP isn't a smaller version of your product — it's the fastest, cheapest way to find out if anyone wants it. Here is how to scope one that actually validates your idea instead of just shipping fewer features.