Cloud migration strategies: how to choose the right path per workload

Cloud migration programs fail when teams apply one strategy to every workload. Critical systems, legacy dependencies, compliance constraints, and release timelines rarely fit a single migration pattern.

Start by classifying each workload against the 6 Rs: rehost, replatform, repurchase, refactor, retire, or retain.

Why strategy selection is workload-specific

A cloud migration plan should account for:

• Dependency complexity
• Regulatory and data residency constraints
• Recovery time and uptime requirements
• Engineering capacity during transition
• Business deadlines tied to revenue or customer commitments

Two workloads in the same portfolio can need different migration paths even if they run on similar infrastructure today.

The 6 Rs, with practical use cases

Rehost

Rehost (“lift and shift”) moves a workload with minimal architecture change. It is usually the fastest route when migration speed matters more than optimization.

Use rehost when:

• The workload is stable and low risk
• Dependencies are understood
• You need to exit a data center quickly

Trade-off: rehost can carry existing inefficiencies into the cloud.

Replatform

Replatform keeps the core workload intact but swaps selected components for managed cloud services, such as moving a self-managed database to a managed service.

Use replatform when:

• The workload can benefit from managed operations
• Team capacity supports moderate change
• You want incremental reliability improvements without full redesign

Repurchase

Repurchase replaces a self-hosted capability with SaaS.

Use repurchase when:

• The capability is commoditized (for example, email or collaboration tooling)
• Running the platform in-house no longer provides strategic advantage
• Vendor cost and contractual terms are acceptable

Refactor or rearchitect

Refactor changes application structure to better use cloud-native patterns, such as decomposing a monolith into services.

Use refactor when:

• You need meaningful scalability or resilience gains
• Release velocity is constrained by current architecture
• There is enough product and engineering bandwidth for deeper change

Trade-off: refactoring has higher delivery risk and longer timelines.

Retire

Retire decommissions workloads that no longer provide value.

Use retire when:

• The workload has low usage or duplicate functionality
• Business owners confirm it is no longer required
• Decommissioning risk is manageable

This is often one of the fastest ways to reduce migration scope and cost.

Retain

Retain keeps a workload on-premises for now.

Use retain when:

• Migration risk exceeds current business value
• Compliance or technical constraints block short-term migration
• The workload is near end of life

Retain is a strategic deferral, not a failure state.

A phased migration process that supports the 6 Rs

Most successful programs run through five delivery phases:

Planning

Inventory workloads, map dependencies, and define target-state objectives.

Review

Validate readiness, constraints, and sequencing before large-scale cutovers.

Optimize

Tune architecture, security controls, and cost model assumptions for cloud operation.

Modernize

Implement selected replatforming or refactoring work where ROI is clear.

Measure

Track outcomes against migration goals: reliability, lead time, security posture, and cost.

How to choose the right strategy per workload

Apply a decision scorecard for each workload:

• Business criticality: What is the operational and revenue impact of failure?
• Dependency risk: How many upstream and downstream systems are coupled?
• Cloud readiness: How much change is needed for safe migration?
• Security and compliance: What controls must be proven before go-live?
• Cost and effort: What is the migration effort versus expected benefit?
• Time constraint: Is there a hard deadline driving sequencing?

This approach helps teams avoid using rehost as a default when refactor or retire would produce better long-term outcomes.

Final guidance

The goal is not to migrate everything; the goal is to migrate the right workloads with acceptable risk and measurable business value.

Treat strategy selection as an engineering and business decision, review it at each migration wave, and adjust as workload realities become clearer.