5 Migration Strategies for Legacy Applications (The 5 Rs, Honestly Applied)

The "5 Rs" framework (rehost, replatform, refactor, replace, retire) has been around since Gartner published it in 2011. It's still useful because it forces a conversation that a lot of migration projects try to avoid: what are we actually trying to accomplish, and for which applications? Here's how we apply it in practice, with the decision criteria we use to pick one strategy over another.

1. Rehost (Lift and Shift)

Take the VM as-is and move it to IaaS. The application doesn't know it moved. No code changes, no OS changes, just a new data center.

When rehost is the right call:

• The application works fine and nobody complains.
• You have a date-certain to leave an old data center (lease expiration, equipment failure, M&A).
• The application has no active development team.
• Licensing is flexible enough to move without renegotiation.

When rehost is a mistake:

• The application is the bottleneck for a business initiative. Rehosting doesn't fix performance problems — it usually makes them slightly worse.
• The application is expensive to run on-prem because it's inefficient. It will be equally expensive in the cloud, just billed hourly.
• The OS is end-of-life and you won't be able to patch it.

Real numbers: Rehost takes 1 to 4 weeks per application once tooling is in place (Azure Migrate, AWS MGN, Google Migrate for Compute). Cutover windows are typically 2 to 6 hours. Post-migration cost is usually 10 to 30 percent higher than a well-run on-prem deployment for steady-state workloads — the savings story depends on elasticity, which most rehosted apps don't have.

2. Replatform (Lift and Improve)

Move the app but swap some components — usually the database, the runtime, or the OS. Example: move a Windows IIS app to Azure App Service, or move a self-managed PostgreSQL to RDS.

When replatform is the right call:

• The OS or database is a maintenance burden you want to hand off.
• The application is stateless or mostly stateless.
• You can tolerate a short refactor of connection strings, logging, and configuration.

Common replatform patterns that work:

• SQL Server on-prem → Azure SQL Managed Instance (nearly drop-in, preserves SQL Agent jobs and cross-database queries)
• Tomcat on VM → AWS Elastic Beanstalk or App Runner
• File server → Azure Files or FSx for Windows
• Self-managed Redis → ElastiCache or Azure Cache for Redis

Budget: Replatform adds 2 to 6 weeks per application on top of a rehost baseline, and the TCO improvement is significant — typically 20 to 40 percent over rehost for the same workload because managed services shed operational overhead.

3. Refactor (Re-architect)

Rewrite parts of the application to take advantage of cloud-native services. Monolith becomes microservices, SQL Server becomes DynamoDB, synchronous RPC becomes event-driven.

When refactor is the right call:

• There is active business pressure for features the current architecture can't support.
• The app has a dedicated product team that can own the rewrite.
• The value of the new capabilities exceeds the cost of the rewrite by a comfortable margin.

When refactor is a mistake, which is most of the time:

• The only justification is "cloud native is better." It isn't, for every workload. Well-architected monoliths run cheaper and faster than most microservices architectures.
• The team has never built distributed systems. You will spend more time debugging distributed failures than you saved on hypothetical scalability.
• The app is stable and the business value of the rewrite is hard to articulate.

Real cost: Refactors take 6 to 24 months and cost 2x to 10x what a rehost costs. Most refactors fail to deliver the promised benefits within 12 months. Go in with eyes open.

4. Replace (Repurchase)

Drop the existing application and buy a SaaS replacement. Move from a homegrown CRM to Salesforce or Suite. Move from a custom timesheet app to BambooHR. Move from a bespoke ticketing system to Zendesk.

When replace is the right call:

• The application is a commodity — there is nothing unique about how your business does it.
• The data model is transferable.
• You can negotiate a reasonable SaaS contract without data egress ransomware.

When replace is a mistake:

• The application encodes a differentiator. Replacing a custom pricing engine with a generic one is the fastest way to destroy margin.
• The SaaS contract has data portability problems.
• The cutover would displace a larger project.

Pattern we see most: Replace is the best answer more often than people think. Finance, HR, ticketing, CRM, project management, and file sharing are almost always better as SaaS.

5. Retire (Decommission)

Turn it off. Don't migrate it.

When retire is the right call:

• Nobody uses it. Check the access logs.
• It's been "mission critical" for ten years but nobody can name who depends on it.
• The functionality has been replaced by something else nobody bothered to shut the old thing down for.

How to confirm: Run network flow logs for 30 days. Count active users. Ask the putative owner to describe what would happen if you turned it off. If they can't articulate the impact, you probably can.

Typical finding: In a portfolio of 100 applications, 10 to 20 percent can usually be retired with no business impact. That's a real savings that costs nothing to achieve.

The Decision Matrix We Actually Use

For every application in scope, we score on four dimensions:

| Dimension | Low | Medium | High | |---|---|---|---| | Business criticality | Replace/Retire | Replatform | Refactor or Rehost with care | | Active development | Rehost | Replatform | Refactor | | Technical health | Retire | Rehost | Replatform/Refactor | | SaaS equivalent exists | Replace | — | Rehost/Replatform |

Then we sanity-check the scores against reality. Sometimes the score says "refactor" but the team doesn't have the bandwidth, so replatform wins by default.

Three Takeaways

1. The right answer for most applications is rehost or replatform. Refactor and replace are the exceptions, not the rule.
2. Retire is the cheapest migration strategy. Every application you don't move is a win.
3. Migration strategy should be chosen per-application, not per-portfolio. A blanket "we're refactoring everything" mandate is how migration projects go over budget by 3x.