Cloud Migration Strategy: The 6 Rs, and How to Pick One per Application

The single most expensive mistake in cloud migration is treating it as one decision. It’s a portfolio of decisions, one per application, and the 6 Rs framework exists to make each of those decisions cheap, fast, and defensible.

Where the 6 Rs come from, and why they stuck

Gartner published the original “5 Rs” in 2010; AWS extended it to 6 (later 7, adding “relocate” for VMware estates). The framework survived because it matches how migrations actually fail: teams either lift everything blindly and inherit their old inefficiencies at cloud prices, or they try to modernize everything at once and the project dies at month nine. Assigning an R per application forces the middle path.

The six dispositions:

R	What it means	Typical share of a portfolio
Rehost	Move the workload as-is onto cloud VMs (“lift-and-shift”)	30-40%
Replatform	Move it with targeted upgrades, managed database, managed load balancing, but no code re-architecture	15-25%
Repurchase	Drop the app; buy the SaaS equivalent	10-15%
Refactor	Re-architect for cloud-native services (containers, serverless, managed queues)	5-15%
Retire	Turn it off	10-20%
Retain	Leave it on-premise, deliberately, with a revisit date	5-15%

Those shares come up again and again in real assessments. If your plan says “100% rehost” or “100% refactor,” the assessment was skipped, not completed.

Each R in detail: when it applies

Rehost, move it, don’t touch it

You take the VM (or a fresh install of the same stack) and run it on EC2, Azure VMs, or Compute Engine. Tools like AWS Application Migration Service (MGN) or Azure Migrate replicate running servers block-by-block, so cutover is hours, not weeks.

Choose rehost when: the app is stable, changes rarely, and the driver is a deadline, a datacenter lease expiring, a hardware refresh you want to avoid, an acquisition. Rehost is also the honest default when the team doesn’t yet have cloud operational experience: you learn to run cloud infrastructure on workloads you already understand.

The tradeoff you accept: you pay cloud prices for on-prem sizing habits. A server sized for peak-day-of-year runs at 8% CPU the other 364 days, and now that waste is a monthly line item. Plan a right-sizing pass 60-90 days after cutover, it routinely cuts rehosted compute bills 25-40%. Our cost estimation guide covers how to model this before you commit.

Replatform, move it with one or two upgrades

Same application code, better foundations. The classic moves: self-managed Postgres or SQL Server onto RDS / Azure SQL / Cloud SQL; a hand-rolled HAProxy box onto a managed load balancer; file shares onto object storage.

Choose replatform when: the operational pain is concentrated in a component the cloud runs better than you do. Databases are the canonical case, patching, backups, failover, and replication all become someone else’s pager. A replatform typically adds 20-50% to the migration effort of a rehost and removes an ongoing operational burden permanently.

The tradeoff: each swapped component needs testing (connection pooling behavior, extension availability, maintenance windows), and managed services cost more per unit than raw VMs, you’re buying back engineering time. Usually a good trade; verify it per component, not on faith.

Repurchase, stop running it at all

Exchange → Microsoft 365. Self-hosted CRM → a SaaS CRM. A homegrown HR tool → an off-the-shelf product. You migrate data, not infrastructure.

Choose repurchase when: the app is commodity, nothing about how you run email or expense reports differentiates your business. The migration becomes a data-export/import project plus change management for users.

The tradeoff: per-seat SaaS pricing can exceed self-hosting costs at scale, customizations don’t come with you, and you take on a vendor dependency. Model 3-year total cost, not year one.

Refactor, re-architect for the cloud

Break the monolith into services, containerize, adopt managed queues and autoscaling, possibly go serverless. This is the only R that changes what the application is.

Choose refactor when: the application has a scaling or velocity problem the current architecture can’t solve, traffic spikes it can’t absorb, a release cadence measured in months, or infrastructure costs that grow linearly with load. Refactoring costs 5-10x a rehost and takes 3-12 months per application, so it needs a business case, not an aesthetic preference.

A pattern that works: rehost first, refactor later, one component at a time, once the app is already in the cloud and you have real usage data. Refactoring during migration doubles the risk of both projects. See the full comparison in lift-and-shift vs replatform vs refactor.

Retire, the free money

Every assessment finds servers nobody can explain. Duplicate tools, abandoned pilots, reports nobody has opened since 2021. Industry assessments consistently find 10-20% of a portfolio can simply be decommissioned.

Do this first. Every retired app is one you don’t migrate, don’t license, don’t secure, and don’t pay to run. The mechanism: flag suspected-dead apps, turn off access (not the server) for 30 days, and see who screams. Silence is your answer.

Retain, a decision, not a default

Some things stay: a latency-sensitive factory-floor system, an app whose license forbids virtualized/cloud deployment, a mainframe workload with no credible path, something already scheduled for replacement next year.

The discipline is writing down why and when you’ll revisit. “Retain, reason: vendor support contract until Q3 2027, revisit then” is a strategy. “We’ll deal with it later” is a growing pile of technical debt in a shrinking datacenter, and a half-empty datacenter costs almost as much to run as a full one.

The decision table

Score each application, then read off the row that fits:

Situation	Assign	Why
Nobody used it in 90 days	Retire	Migration cost of $0 beats every alternative
Commodity function (email, CRM, HR) with a mature SaaS market	Repurchase	You gain nothing by operating it
Stable, low-change, deadline-driven move	Rehost	Speed and low risk; optimize after cutover
Solid app, but the database/infra components hurt operationally	Replatform	Swap the painful parts for managed services in transit
Scaling limits, high change rate, or costs growing with traffic	Refactor	Only here does re-architecture pay back
Regulatory, latency, or licensing blocker, or replacement already planned	Retain	Moving it creates risk without benefit

Two scoring axes settle most arguments: business value (revenue-touching? how many users? cost of an outage?) and technical fit (OS/database versions, dependencies, license mobility). High value + poor fit is where refactor money goes. Low value + any fit is rehost, repurchase, or retire.

A worked example: 40-application portfolio

A mid-market manufacturer, one aging datacenter, lease ends in 14 months:

• 7 apps retired (18%), old reporting tools, a dead intranet, two duplicate monitoring stacks. Savings: ~$4,100/month in licenses and power before the migration even starts.
• 5 repurchased (12%), Exchange and a self-hosted helpdesk to SaaS.
• 17 rehosted (43%), the stable line-of-business majority, moved with Azure Migrate over four monthly waves.
• 8 replatformed (20%), six SQL Server instances to Azure SQL Managed Instance, two web apps onto managed App Service. See how to migrate a production database for what that entails.
• 2 refactored (5%), the customer-facing ordering system (traffic spikes every quarter-end) rebuilt on containers with autoscaling, after the deadline, from inside the cloud.
• 1 retained, a shop-floor system wired to physical PLCs; revisit at the 2028 equipment refresh.

The deadline was met by the rehost wave; the value was created by the retire, replatform, and refactor decisions. That’s the pattern.

Mistakes that turn a strategy into a slogan

1. One R for everything. The portfolio is heterogeneous; the strategy must be too.
2. Refactoring during migration. Two hard projects fused into one impossible one. Move first, modernize from inside.
3. Skipping retire. Migrating dead software is paying to relocate garbage.
4. Treating retain as failure. A documented retain with a revisit date is a healthy decision.
5. Assigning Rs without dependency mapping. Apps move in groups, a rehosted app whose database was refactored out from under it mid-wave is an outage with extra steps. Map dependencies during assessment (the roadmap covers when and how).

FAQ

What are the 6 Rs of cloud migration?

Rehost (lift-and-shift the workload unchanged), replatform (move with targeted upgrades, like swapping a self-managed database for a managed one), repurchase (replace the app with a SaaS product), refactor (re-architect for cloud-native services), retire (decommission it), and retain (leave it on-premise for now). Each application in your portfolio gets exactly one.

Which migration strategy is cheapest?

Retire is cheapest, 10-20% of a typical portfolio is unused software you can simply shut down. Among apps you keep, rehost has the lowest migration cost (often $1,000-$15,000 per server including labor) but the highest ongoing run cost, because unoptimized VMs waste 30-50% of their capacity. Refactor is the most expensive up front and usually the cheapest to run.

Should we refactor everything to be cloud-native?

No. Refactoring costs 5-10x what rehosting costs and takes months per application. It only pays back on applications with heavy traffic, high change rates, or scaling problems. A stable internal app with 50 users will never return the investment, rehost or replatform it.

How long does it take to choose a strategy for each application?

For a portfolio of 20-100 applications, a disciplined assessment takes 2-6 weeks: inventory from discovery tooling, dependency mapping, then a scoring workshop. Spending longer than that usually means you’re seeking certainty the data can’t give you, assign a provisional R and validate it during the pilot.

Can we mix strategies in one migration?

You should. Almost every real migration is a mix: retire the dead weight first, rehost the stable majority to hit the deadline, replatform databases along the way, and schedule one or two refactors for the applications where cloud-native actually pays. A single strategy applied to everything is a red flag.

---

Assigning the right R to 40 applications is the kind of judgment call that goes faster with someone who has done it before. If you’re staring at a portfolio and a deadline, talk to a Webisoft cloud engineer, we’ll walk your application list with you and pressure-test the assignments before anything moves.