Last updated: June 2026. Written by the Brocoders engineering team based on 60+ software delivery projects.
The 6 Rs of Cloud Migration: Lift and Shift vs. Refactor vs. Replatform (How to Choose)
We see a pattern in migration assessments that shows up often enough to have a name. A team kicks off a full refactor — microservices, containers, the works. Six months in, someone notices the scaling problem that triggered the whole project was caused by a single unoptimized database query. Moving to a managed database service would have fixed it in four weeks.
They chose the right destination. They entered the spectrum at the wrong point.
The 6 Rs of cloud migration give you options. What they don't give you is a starting rule. This guide does.
TL;DR: The 6 Rs of cloud migration are Rehost, Replatform, Refactor, Repurchase, Retire, and Retain. Most teams over-engineer their strategy choice. The right starting point isn't the R that sounds most impressive — it's the one that directly fixes your actual bottleneck. Start there, and move up the spectrum only when the data says you need to.
The 6 Rs: A Quick Map
The 6 Rs of cloud migration are Rehost, Replatform, Refactor, Repurchase, Retire, and Retain — a framework originally developed by Gartner and popularized by AWS.
Here's what each one means in plain language.
Rehost (Lift and Shift). Move your app to the cloud exactly as-is. No code changes, no architecture changes. The fastest path out of a data center. You don't gain cloud-native benefits, but you cut on-premise hardware costs quickly.
Replatform (Lift, Tinker, Shift). Move to the cloud with minor infrastructure adjustments — swap your self-managed PostgreSQL for Amazon RDS, move from manual autoscaling to a managed container service. No architecture changes. You capture real cloud infrastructure benefits without rebuilding your code.
Refactor / Re-architect. Redesign the application's structure to use cloud-native patterns: microservices, containers, serverless, event-driven processing. The most resource-intensive path, but the only one that removes deep architectural constraints.
Repurchase. Drop the app and buy a SaaS replacement. Moving your CRM to Salesforce, your HR system to Workday, or your accounting to NetSuite are all repurchase decisions. Right when the vendor's product covers your use case and the cost of owning your own is hard to justify.
Retire. Decommission apps that don't need to move. AWS prescriptive guidance estimates up to 20% of enterprise portfolios are redundant or unused. Auditing before migration avoids carrying dead weight into the cloud.
Retain. Consciously choose not to migrate certain workloads. Tight compliance requirements, hardware dependencies, or apps scheduled for replacement in 12 months are all legitimate reasons to stay on-premise. Retain is a decision, not a default.
The full comparison of the three most-debated strategies — Rehost, Replatform, and Refactor — is in the table below.
The Most Common Mistake in Migration Planning
The standard advice: assess your app portfolio and match each workload to the right R. That's correct in principle.
In practice, most teams skip straight to "what should this app look like in the cloud?" before diagnosing what it can't do today. That's a product question, not a migration question. And it consistently leads to scope creep.
There's also a structural incentive to be aware of. Cloud vendors — AWS, Azure, Google — all benefit when you refactor. Cloud-native architectures mean higher ongoing managed-services spend. That doesn't make their guidance wrong, but it does mean you're reading material written by people with a financial stake in how you answer the question.
The cost difference matters. A full refactor vs. a rehost can cost anywhere from 2x to 5x more in total project cost, depending on system complexity. Replatforming typically captures 40-60% of the long-term cost benefits of a full refactor at a fraction of that investment and risk.
Most CTOs looking at the 6 Rs don't need the most architecturally elegant path. They need the path that fixes a specific, documented constraint — at a scope their team can actually close.
Rehost vs. Replatform vs. Refactor: The Core Differences
Most comparisons describe what each strategy does. Here's what each strategy costs you if you pick wrong.
| Rehost | Replatform | Refactor | |
|---|---|---|---|
| Also called | Lift and shift | Lift, tinker, shift | Re-architect |
| Code changes | None | Minor | Significant |
| Architecture changes | None | Minimal | Major |
| Time to value | Days to weeks | 4-12 weeks per workload | Months to years |
| Upfront cost | Low | Moderate | High (2-5x rehost) |
| Cloud benefit realized | ~20-30% | ~40-60% | Full |
| Scope risk | Low | Medium | High |
| Best for | Legacy apps, urgent data center exits | Sound architecture with infra overhead | Core systems where architecture IS the bottleneck |
What this table doesn't show: the opportunity cost of entering at the wrong level.
Lift and shift gets your app to the cloud fast. But you're paying cloud prices for on-premise behavior — no elastic scaling, no managed infrastructure savings. The speed advantage is real. If you stay in rehost mode indefinitely, you'll pay for it.
Replatform is the most underused path. Moving to a managed database, adopting autoscaling, or containerizing without restructuring your codebase can unlock real cost reductions and performance gains without the scope risk of a full rebuild. It won't fix architectural constraints — but for most apps, there isn't an architectural constraint. Just infrastructure overhead.
Refactoring makes sense specifically when the architecture is the constraint. When the current design is provably preventing scale, resilience, or delivery speed, and no smaller intervention will fix it.
When Each Strategy Actually Makes Sense
Rehost when:
- You need to exit a data center on a fixed timeline
- The app is stable and won't benefit from cloud-native scaling in the near term
- Your primary goal is reducing hardware costs, not improving performance
- You plan to reassess modernization after seeing real usage patterns in the cloud
Replatform when:
- Your app's business logic is sound but your infrastructure creates operational overhead
- You want to reduce infrastructure spend without rebuilding your code
- Your team doesn't have bandwidth for a full re-architecture cycle right now
- The specific constraint is infra management, not code architecture
Refactor (re-architecting for cloud) when:
- The architecture itself is provably the bottleneck — a monolith that can't scale horizontally, tightly coupled services that block independent deployment
- The app is a core business system with active development investment and a 3-5+ year runway
- You have data — load tests, failure patterns, scaling limits — to prove the constraint, not just a feeling that cloud-native would be cleaner
- Your team has architecture expertise to scope and execute without turning it into a multi-year rewrite
A note on terminology: "re-architecting for cloud" and "refactoring" are sometimes used interchangeably, but re-architecting typically implies a larger scope change — moving from monolith to microservices, adopting event-driven patterns. Refactoring can mean targeted code-level changes within an existing architecture. Both require the same diagnostic question first.
The Bottleneck-First Rule
Before choosing any R, answer these 3 questions.
1. What specific constraint is preventing this system from meeting your business goal?
Write it in one sentence. If you can't, you're not ready to pick a strategy.
A specific constraint: "Our monolith can't handle more than 500 concurrent connections, which limits the number of properties listed on the platform."
Not a specific constraint: "The system doesn't scale well."
2. Can a less invasive approach — one rung lower on the Rs spectrum — fix that constraint?
If moving to a managed database (replatform) solves the problem, a full refactor is premature. If the constraint is code-level architecture, no infrastructure change will fix it. The question forces you to prove the case before committing to the scope.
3. What scope risk can your team absorb right now?
Refactoring projects expand. That's not a failure — it's the nature of the work. The question is whether your business situation supports a 12-24 month modernization cycle while you're still shipping product.
The rule: Enter the Rs spectrum at the lowest rung that directly fixes your constraint. Don't start higher because it looks better on a roadmap.
This is why, according to DataStackHub's 2025 cloud migration data, roughly 38% of migration projects still choose rehosting. Not because those teams lack ambition — because rehosting directly solves their constraint (data center exit, hardware cost reduction) without scope risk they can't absorb.
How It Looks in Practice: 80x Scale in 3 Months
When Lake, a US-based vacation rental platform, came to us, they had one specific constraint: their monolithic back-end couldn't scale past a few hundred connected properties. The business needed to grow by an order of magnitude. The architecture couldn't keep up.
The Bottleneck-First test pointed clearly at refactor.
A replatform — moving infrastructure components to managed cloud services — wouldn't fix it. The problem wasn't self-managed servers. The problem was that the monolith itself had a hard ceiling on concurrency. No infrastructure change would move that ceiling.
So we in Brocoders rebuilt the back-end. Not the entire product. Not a microservices overhaul. We rebuilt the specific architectural layer that was the bottleneck — in Go, with clean REST API design.
Three months from project start to release.
The result: 80x growth in connected properties, from roughly 500 to 40,000. A 210% spike in website activity. Measurable at delivery.
This case matters because it proves both sides of the rule. When refactoring is the right call and the scope is tight, the results are dramatic. But it was the right call specifically because the team could prove what was broken. The scope stayed tight because the problem was specific.
Full case study: Lake Vacation Platform Rebuild
The Other Three Rs
A complete migration assessment includes all 6 Rs. The last three are frequently skipped but often account for a significant share of portfolio decisions.
Repurchase. Replace with SaaS. Right when a vendor's product covers your use case and the cost of building and maintaining your own is hard to justify — common for CRM, HR systems, and accounting platforms. The app doesn't migrate; it gets replaced.
Retire. Audit before you move. Up to 20% of enterprise portfolios are redundant or unused. Every app you retire is cost and complexity you don't carry into the cloud.
Retain. Sometimes the right answer is not to move. Apps with strict compliance requirements, hard hardware dependencies, or a planned replacement in 12-18 months may be better left on-premise for now. Retain is a decision — make it consciously, not by default.
Picking the right strategy for one app is one decision. Mapping it across a portfolio of 20-50 apps is a different problem.
Here in Brocoders, we've helped scaleups across fintech, proptech, SaaS products, and logistics work through that — from targeted replatforming engagements to full back-end rebuilds like Lake. If you're planning a migration and want a second opinion on where to enter the spectrum, we're open to a conversation.
Frequently Asked Questions
Replatforming moves an app to the cloud with minor infrastructure adjustments — such as switching to a managed database — without changing the application's architecture or code. Refactoring (or re-architecting) redesigns the application's structure to use cloud-native patterns like microservices, containers, or serverless functions. Replatforming is faster and lower risk; refactoring delivers greater long-term cloud benefits but requires significantly more time and budget, and is only justified when architecture is the actual bottleneck.
Lift and shift (also called rehosting) means moving an application to the cloud exactly as it is, with no changes to code or architecture. It's the fastest migration path and eliminates on-premise hardware costs, but the app doesn't gain cloud-native benefits like elastic scaling or managed infrastructure. Most teams use lift and shift for legacy apps, urgent data center exits, or as a first step before further modernization once they understand real cloud usage patterns.
Choose refactoring when the application's architecture itself is the bottleneck — for example, a monolithic system that can't scale horizontally, or tightly coupled services that block independent deployment. If the constraint is infrastructure management rather than code structure, replatforming typically resolves it at a fraction of the cost. The test: can you write in one sentence what specific architectural constraint is blocking business goals? If yes, refactoring may be justified. If the constraint is vague, start one rung lower.
Re-architecting for cloud means redesigning an application's fundamental structure — moving from a monolith to microservices, adopting event-driven patterns, or rebuilding around serverless functions — to take full advantage of cloud-native capabilities. It's the most resource-intensive migration strategy, typically requiring months to years of engineering work, but delivers the highest long-term performance and resilience when architecture is the proven constraint.
Timeline depends on strategy and scope. A rehost can move individual workloads in days to weeks. Replatforming typically takes 4 to 12 weeks per workload. A full refactor of a core system commonly spans 8 to 24 months, with large enterprise migrations taking longer. The Lake monolith rebuild — a scoped, targeted refactor with a clearly defined constraint — completed in 3 months. Scope precision is the main variable.
The 6 Rs are Rehost (lift and shift), Replatform (lift, tinker, shift), Refactor (re-architect), Repurchase (replace with SaaS), Retire (decommission), and Retain (keep on-premise). The framework was originally developed by Gartner and popularized by AWS as a way to categorize migration strategies across an enterprise app portfolio.
Rehosting (lift and shift) has the lowest upfront cost and fastest time to cloud. Replatforming costs more upfront — typically $8,000-$25,000 per workload — but often delivers meaningful infrastructure cost reductions within 6-12 months. Refactoring carries the highest upfront cost, typically 2x to 5x the cost of rehosting, and is only worth that investment when architecture is the constraint preventing scale. Choosing a higher-cost strategy than the problem requires is the most common way migration budgets blow up.