Refactor First? Why Most Cloud Migrations Should Skip 'Lift and Shift'

Is 'Lift and Shift' a Slow-Motion Disaster?

We've all heard the conventional wisdom: move first, optimize later. Just rehost your applications as-is, get to the cloud quickly, and then modernize. But in our practice, that advice is often a trap. Rehosting is fast, sure, but it locks in your current architecture—and your current costs—without delivering the agility you were promised. (DigitalOcean) In fact, a Red Hat survey found that while 38% of organizations plan to rehost first and then modernize, 47% plan to skip rehosting entirely and go straight to replatforming. That's a huge signal that the industry is waking up to the hidden costs of 'lift and shift.'

So here's the contrarian question we want to answer: If rehosting is so popular, why are so many teams planning to skip it? And what does that mean for your migration strategy? The answer isn't to never rehost—it's to rehost only when you have a clear, short-term reason, and to treat rehosting as a tactical exception, not a default strategy. Let's dig into the evidence.

Why Rehosting Often Fails to Deliver

Rehosting, or 'lift and shift,' moves applications to the cloud without changing code. It's the fastest path, and it's great for quick wins—like when you need to exit a data center fast or consolidate infrastructure. But the problem is that you're moving your old problems into a new environment.

Red Hat's application migration guidance is blunt: rehosting without modification can lead to higher long-term costs because you're not using cloud-native capabilities. You're renting virtual machines that behave like your old servers, but you're paying cloud premiums for the privilege. And you're not getting the scalability, resilience, or operational benefits that come from managed services or microservices. (Red Hat)

In our experience, this is why so many cloud cost reports look alarming. Flexera's 2025 State of the Cloud found that 84% of organizations say managing cloud spend is their top challenge, and wasted spend on IaaS and PaaS rose to 29% in 2026—the first increase after five years of decline. (Flexera 2026) A big chunk of that waste comes from rehosted workloads that run 24/7 at full capacity, even when they're only used during business hours. You can't easily scale down a rehosted app if it wasn't designed for elasticity.

Replatforming: The Middle Path That Usually Wins

If rehosting is risky, what should you do instead? The answer is replatforming, sometimes called 'lift, tinker, and shift.' You make small, targeted changes during migration—like moving your database to a managed service or switching to a cloud-native load balancer—without rearchitecting the whole app. (DigitalOcean) This gives you immediate benefits like managed backups, automatic failover, and better performance, without the cost and complexity of a full refactor.

In Red Hat's survey, replatforming was actually the most common migration approach, at 20% of applications. (Red Hat) That's telling. It suggests that many teams are realizing they can get 80% of the benefits of cloud at a fraction of the effort. For example, instead of rehosting a Microsoft SQL Server database, you could replatform to Amazon RDS for SQL Server. (AWS Prescriptive Guidance) You don't change your code, but you get automated patching, multi-AZ replication, and point-in-time recovery—all without being a database admin.

Now, replatforming isn't always enough. If your application is a monolithic mess that can't scale, you might need to refactor. But refactoring is the most complex and costly strategy. (AWS Prescriptive Guidance) It can take months or years, and it's not something you want to do for every application in your portfolio. That's why we recommend a prioritization exercise: identify the 10-20% of applications that are business-critical and truly need cloud-native architectures, and refactor those. The rest? Replatform or repurchase.

How to Decide: A Practical Framework

So how do you decide which strategy to use for each application? We've developed a simple framework that goes beyond the generic 6 Rs and forces you to think about your actual business drivers. Here's a comparison of the three main strategies, based on the definitions from AWS and DigitalOcean:

Now, let's apply this to a real scenario. Imagine you have a legacy CRM that's used by your sales team. It's a monolithic app that runs on a single server, and it's starting to show its age. If you rehost it, you'll be up in a few days, but you'll still have the same performance issues and you'll be paying for a VM that's idle most of the night. If you replatform it to a managed service, you might get auto-scaling and better uptime, but you're still tied to the old architecture. If you refactor it into microservices, you could rebuild it with modern APIs, but that's a six-month project. In this case, we'd probably recommend repurchase—moving to a SaaS CRM like Salesforce. (DigitalOcean) That gives you the features you need without the operational overhead.

The key is to avoid the trap of 'move everything as-is.' The AWS guidance for large migrations is clear: they recommend rehost, replatform, relocate, and retire as common strategies, but they explicitly say refactor is not recommended for large migrations because it's too complex to manage across many applications. (AWS Prescriptive Guidance) So for a typical enterprise migration, replatforming should be your workhorse strategy.

One More Thing: Don't Forget to Retire

We've talked about moving, but sometimes the best move is to not move at all. AWS defines 'zombie applications' as those with average CPU and memory usage below 5%, and 'idle applications' as those with 5-20% usage over 90 days. (AWS Prescriptive Guidance) These are prime candidates for retirement. In Red Hat's survey, retire applied to just 10% of applications. (Red Hat) That's a lot of wasted resources. Before you migrate, do a thorough inventory and identify apps that are truly dead weight. It's easier than you think to decommission them and save money.

Quick tip: Before you start any migration, run a discovery tool like Azure Migrate to get a full inventory and dependency map. (Microsoft Learn) You'll often find that 20% of your applications are candidates for retirement, which instantly reduces your migration scope.

The Bottom Line: Skip Rehosting Unless You Have To

The single most important thing to remember: Rehosting is a tactical tool, not a strategy. If you're migrating to achieve cost savings or agility, replatforming is usually the better choice. It gives you cloud benefits without the cost and risk of a full refactor. And if you're tempted to rehost because it's fast, ask yourself: Are you solving a short-term problem, or are you creating a long-term liability?

In our view, the cloud migration case study that ends with 'we lifted and shifted everything' is rarely a success story. The ones that succeed are the ones that took the time to match each application to the right strategy—and that often means skipping the lift and shift.

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
• AWS Prescriptive Guidance - https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• Flexera 2026 - https://www.flexera.com/blog/finops/the-new-era-of-cloud-what-2026-data-tells-us-about-spend-scale-and-strategy/
• Microsoft Learn - https://learn.microsoft.com/en-us/training/modules/design-migrations/3-describe-azure-migration-framework