Skip to main content
Migration Strategies

Stop Rehosting Everything: Use the 6 Rs to Cut Migration Costs Now

Most cloud migrations waste money by rehosting everything. Use the 6 Rs to cut costs, but skip rehosting when you can replatform—here's how.

You're planning a cloud migration and you're wondering: "Should I lift and shift or do something smarter?" The answer is: stop rehosting everything. Rehosting is the fastest way to the cloud, but it's also the fastest way to a bloated bill. You need a strategy that picks the right move for each app, and that means using the 6 Rs.

This is for IT leads and cloud architects who are tired of paying for the cloud and getting nothing but the same old on-prem problems. You don't have time for a multi-year re-architecture, but you also don't want to lock in a decade of waste. I'm going to walk you through a practical, first-person approach to applying the 6 Rs to your migration, so you can cut costs and actually get cloud benefits.

1. Start with a Full Inventory and Dependency Map

Before you touch a single server, you need to know what you have. The assessment phase of the Azure migration framework is clear: create a full inventory and dependency map of your servers, services, and apps, and estimate cost savings using the Azure TCO Calculator (Microsoft Learn). You can't decide whether to rehost or refactor an app if you don't know it exists. Use a tool like Azure Migrate, which is free and uses a lightweight appliance to continuously send configuration and performance data to the service (Azure Migrate). This gives you the raw data you need to make decisions.

Here's what can go wrong: you skip the dependency mapping, and you miss that your "simple" app actually depends on a mainframe that's not going anywhere. Suddenly your migration plan is dead in the water. Don't let that be you.

2. Classify Every App with the 6 Rs

Once you have the inventory, classify each app using the 6 Rs: Rehost, Replatform, Refactor, Repurchase, Retire, and Retain (DigitalOcean). Don't overthink it. For each app, ask: does it need to stay on-prem? That's Retain. Is it a zombie? That's Retire. Is it a candidate for a SaaS replacement? That's Repurchase. For the rest, you're choosing between Rehost, Replatform, and Refactor.

Here's a comparison to help you choose:

Strategy Effort Cloud Benefit Best For
Rehost Low Low Quick wins, no code changes
Replatform Medium Medium Managed services, minor tweaks
Refactor High High Long-term scalability, cloud-native

Rehost is fast and simple, but it doesn't leverage cloud-native features (DigitalOcean). Replatform makes minor optimizations, like moving to a cloud-managed database, without changing core architecture (DigitalOcean). Refactor re-architects for microservices or serverless, delivering the most benefit but requiring the most effort (DigitalOcean).

3. Skip Rehosting When You Can Replatform

Here's my recommendation: don't default to rehost. In a Red Hat survey, 47% of organizations plan to skip rehosting and go straight to replatforming (Red Hat). That's smart. Replatforming is the sweet spot for most apps. You get cloud benefits without a full rewrite.

For example, moving Microsoft SQL Server to Amazon RDS for SQL Server is a classic replatform (AWS Prescriptive Guidance). You're not changing your app, but you're offloading database administration to the cloud. That's a win. Similarly, porting .NET Framework apps to .NET Core on Linux can cut licensing costs and improve performance (AWS Prescriptive Guidance).

Don't rehost just because it's the path of least resistance. Replatforming is often the cheapest way to get real value.

4. Use Refactor Sparingly, and Only for Strategic Apps

Refactoring is the most complex and costly migration strategy (AWS Prescriptive Guidance). It's not for everything. AWS explicitly says refactor is not recommended for large migrations because it modernizes during the migration, which is the most complex strategy to manage across many applications (AWS Prescriptive Guidance). Save it for apps that are business-critical and need to scale.

Refactoring can mean breaking a monolithic app into microservices, which are easier to build, test, deploy, and update (Red Hat). Or it could mean using serverless, where an idle function costs nothing (Red Hat). But that kind of change takes time and money. If you're not ready for that, replatform.

5. Don't Forget to Retire and Retain

The 6 Rs include two that people often skip: Retire and Retain. Retire decommissions applications no longer needed (DigitalOcean). AWS even defines 'zombie applications' as those with average CPU and memory usage below 5% over 90 days (AWS Prescriptive Guidance). If you have apps like that, retire them. You'll save on licensing and maintenance, and you won't pay to run them in the cloud.

Retain keeps applications on-premises for compliance, technical, or timing reasons (DigitalOcean). For example, data residency compliance might force you to keep certain data on-prem (AWS Prescriptive Guidance). Don't fight that. Keep those apps on-prem and focus your migration efforts elsewhere.

6. Use a Phased Approach: Assess, Mobilize, Migrate

Don't try to do everything at once. AWS approaches large-scale migrations in three phases: assess, mobilize, and migrate (AWS Prescriptive Guidance). This lets you create a migration plan, set up a foundation, and migrate the first set of applications in weeks (AWS Prescriptive Guidance). Similarly, the Azure framework uses four stages: Assess, Migrate, Optimize, and Monitor (Microsoft Learn).

Start with a pilot. Pick a few apps that are good replatform candidates, migrate them, and learn from the experience. Then scale up.

7. Optimize and Monitor Continuously

Migration doesn't end at cutover. You need to optimize and monitor. Flexera's 2025 State of the Cloud report found that 84% of organizations say managing cloud spend is the top challenge (Flexera 2025). And wasted cloud spend on IaaS and PaaS rose to 29% in 2026, the first increase after five years of decline (Flexera 2026). That's a lot of money going up in smoke.

Use the Monitor phase to track performance and costs. Set up alerts for underutilized resources. Consider a FinOps team—63% of organizations now have a dedicated FinOps team (Flexera 2026). They can help you right-size and eliminate waste.

Here's the thing to remember: your migration strategy is a cost strategy. If you rehost everything, you'll miss the savings that replatforming and retiring can bring. Use the 6 Rs, and you'll cut costs and get the cloud benefits you're paying for.

Sources

  • DigitalOcean - https://www.digitalocean.com/resources/articles/cloud-migration-strategy
  • Red Hat - https://www.redhat.com/en/blog/how-should-you-modernize-your-applications
  • Microsoft Learn - https://learn.microsoft.com/en-us/training/modules/design-migrations/3-describe-azure-migration-framework
  • AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
  • AWS Prescriptive Guidance (phases) - https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/introduction.html
  • Flexera 2025 - https://www.flexera.com/about-us/press-center/new-flexera-report-finds-84-percent-of-organizations-struggle-to-manage-cloud-spend
  • Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/

Share this article:

Comments (0)

No comments yet. Be the first to comment!