Lift-and-Shift or Modernize? How to Decide in Azure

The question that defines the project

Every Azure migration hinges on a decision that changes cost, timeline, and value: move as-is (lift-and-shift) or modernize? There is no single answer. Modernizing everything delays and inflates the project; moving everything as-is wastes the cloud's potential. Maturity lies in choosing the strategy workload by workload.

As a Microsoft partner and CSP, RHC uses a proven framework for this decision: the 6 Rs of migration.

The 6 Rs of migration

In practice, most projects combine Rehost for speed and Replatform/Refactor where the return justifies it.

Lift-and-shift (Rehost): speed first

Lift-and-shift moves the server to Azure virtually unchanged. It is the fastest, lowest-risk strategy, ideal when:

• The datacenter is expiring and the deadline is short.
• The application is stable and will not change much.
• You want to get off the hardware now and optimize later.
• The application is legacy and rewriting it does not pay off.

The advantage is speed; the downside is you carry the inefficiencies along — the application does not automatically gain elasticity, managed resilience, or reduced operational cost. That is why lift-and-shift is usually the first step, not the final destination.

Modernize (Replatform and Refactor): value first

Modernizing means leveraging Azure's managed services (PaaS), which relieve your team from maintaining the operating system, patches, and infrastructure. Examples of gains:

• Swapping a SQL Server on a VM for Azure SQL Managed Instance or Azure SQL Database — no server to manage, with built-in high availability.
• Moving a web application from a VM to Azure App Service — simplified scaling and deployment.
• Adopting serverless (Azure Functions) for event-driven workloads, paying only for actual use.

Replatform makes targeted tweaks (the classic example is moving the database to PaaS while keeping the rest). Refactor goes deeper, rewriting parts of the application. The greater the effort, the greater the return in operational cost, scalability, and resilience.

How to decide workload by workload

The decision is not ideological, it is economic. Guiding questions:

1. What is the timeline? An expiring datacenter pushes toward Rehost first.
2. Does the application change much? Actively evolving applications justify modernizing; frozen legacy does not.
3. What is the current operational cost? Workloads consuming heavy maintenance pay off when moved to PaaS.
4. How critical is it? Critical systems gain from the cloud's managed resilience.
5. Is it worth keeping? Sometimes the best strategy is Retire or Replace with SaaS.

The two-speed approach

The strategy that works best in practice combines the two:

• Wave 1 — Rehost: exit the datacenter fast, cutting hardware and contract risk. The application already runs in Azure.
• Wave 2 — Modernize: after stabilizing, evolve the highest-return workloads to PaaS, one by one, without the datacenter deadline pressure.

This captures the best of both worlds: speed now, value later. The database is often the first modernization target, given the high cost of keeping it on a VM.

Common mistakes

• Modernizing everything at once — delays the project and increases risk.
• Rehost as the final destination — forfeits cloud savings and resilience.
• Ignoring Retire — migrating servers that should be shut down.
• Deciding by trend, not return — each workload has its own math.

Checklist / Key takeaways

• Decide the strategy workload by workload using the 6 Rs.
• Rehost (lift-and-shift) delivers speed and lower short-term risk.
• Replatform and Refactor deliver long-term value with PaaS.
• Consider Retire/Replace before migrating what should not exist.
• Adopt the two-speed approach: exit fast, modernize later.
• Treat the decision as economic, based on timeline, cost, and criticality.

RHC helps map each workload, apply the 6 Rs, and design the wave plan that balances speed and modernization according to each system's return.