Rehost or Replatform? A Cloud Migration Reality Check

The 47% Who Aren't Lifting and Shifting

Here's a stat that might make you pause: nearly half of organizations (47%) plan to skip rehosting altogether and go straight to replatforming (Red Hat). That's not a fringe move. When I first saw that number, I thought it was a typo—but then I remembered my own migration nightmares. We once lift-and-shifted a legacy CRM and spent three months untangling network latency issues that didn't exist on-premises. Speed isn't everything when you're paying for it later.

The Contenders: Rehost vs. Replatform vs. Refactor

You've probably heard of the 6 Rs—Rehost, Replatform, Refactor, Repurchase, Retire, and Retain (DigitalOcean). For this head-to-head, we're focusing on the three that actually move workloads. Here's the short version:

• Rehost (lift-and-shift): Move as-is, no code changes. Fastest, simplest, but you're basically running a VM in the cloud.
• Replatform (lift, tinker, and shift): Make minor optimizations—like swapping to a cloud-managed database—without changing core architecture.
• Refactor (re-architect): Redesign the app to use microservices, serverless, or containers. Most benefit, most effort.

Each has its place, but if you're looking for a balance between effort and payoff, replatform is your workhorse.

Speed to Cloud: The Tortoise and the Hare

Rehost wins on speed, hands down. You're not touching code, so you can move workloads in days or weeks. Replatform takes a bit longer because you're making those small tweaks—but you're not re-architecting, so it's still measured in weeks, not months. Refactor is the tortoise: it can take months per application.

But here's the catch: rehosted apps are not cloud-native and are harder to scale (DigitalOcean). I've seen teams celebrate a quick migration, only to hit a wall when they needed auto-scaling during a traffic spike. Replatform buys you scalability without the full refactor timeline. In one project, we swapped a self-managed PostgreSQL for Amazon RDS—took two days—and suddenly we had automated backups and failover. That's a win.

Cost and Effort: The Hidden Price Tag

Rehost is cheap upfront—no developer hours on code changes. But you'll pay later in operational overhead because you're running a VM that doesn't leverage cloud-native features. Replatform requires a bit more investment—maybe a few days of engineering per app—but it pays off by reducing long-term maintenance and improving efficiency. Refactor is the big spender: it demands significant time and resources, and you'll need a strong business case.

Don't forget the hidden costs of migration. The assessment phase should include a TCO calculation, but many teams under-assess their application portfolio, leading to missed dependencies and budget overruns (Microsoft Learn). I once saw a team miss a scheduled job that was tied to a mainframe—that caused a data sync failure that took a week to fix. So whatever strategy you choose, invest in a proper assessment first.

Scalability and Cloud-Native Benefits: Where Rehost Falls Short

Here's where rehost falls short. Lift-and-shift doesn't fully leverage cloud-native features (DigitalOcean). You get a VM that runs your app exactly as it did on-premises—no auto-scaling, no managed services, no serverless. Replatform, on the other hand, lets you adopt a cloud-managed database, which brings you closer to cloud-native without a rewrite. Refactor is the ultimate: microservices, containers, serverless—the full buffet. But you only need that if your app demands it.

A concrete example: we had a monolithic e-commerce app that we replatformed by moving its MySQL database to Azure SQL. That simple change gave us geo-replication and automated patching. We didn't have to touch the app code. That's the kind of win you can get without a rewrite.

Risk and Complexity: The Devil You Know

Rehost has lower initial risk because there are no code changes—you're just moving the box. But that same lack of change can become a liability: you're not fixing technical debt, and you're not improving resilience. Replatform carries a moderate risk—you're touching a few things, but you're not rewriting the core. Refactor is the highest risk: you're essentially rebuilding the app, and if you miss a dependency, you're in trouble.

Common challenges include data security, compatibility with existing infrastructure, and under-assessing the application portfolio (DigitalOcean). Replatform lets you address compatibility issues by swapping out a database, while refactor forces you to confront every dependency. In my experience, the risk with replatform is manageable if you have good test coverage. We once replatformed a billing system and caught a critical bug in staging because we had integration tests. That saved us from a potential outage.

The Verdict: Replatform Wins for Most Workloads

If you're migrating a portfolio of applications, don't default to rehost just because it's fast. The 47% that skip rehosting are onto something: replatforming is the most common approach at 20% (Red Hat), and it's the sweet spot between effort and benefit. It gives you cloud-native advantages without the refactor cost.

That said, rehost has its place—for quick wins or applications that are retiring soon. Refactor is for your critical, long-lived applications that need to scale. But for the bulk of your portfolio, replatform is the pragmatic choice.

So here's your playbook: assess your apps, categorize them, and default to replatform. Rehost only when you need speed at all costs, and refactor only when the business case is clear.

Quick tip: Use the Azure migration framework's four stages—Assess, Migrate, Optimize, Monitor (Microsoft Learn)—to keep your migration disciplined. Don't skip the assess phase; it's where you'll catch those missed dependencies.

Bottom Line

Replatform is the smart default for most cloud migrations. It balances speed, cost, and scalability, giving you cloud-native benefits without the refactor pain. So next time you're tempted to lift-and-shift, ask yourself: do you want to move fast, or move smart? Choose replatform.

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