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

Reviewed May 20, 2026. This legacy article remains indexable for search continuity and historical context. For current Pilotcore migration service positioning, start with Cloud Migration Assessment and Cloud Services.

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.

For related context, see Cloud Migration Assessment and What is cloud migration?.

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

Strategy comparison

Strategy	What changes	Best fit
Rehost	Move the workload with minimal application change	Fast data-centre exit or low-risk first migration
Replatform	Make limited cloud adjustments during the move	Apps that benefit from managed databases, storage, or runtime services
Repurchase	Replace a self-hosted capability with SaaS	Commodity capabilities where vendor risk and terms are acceptable
Refactor	Redesign the application for cloud-native patterns	High-value systems where scalability, reliability, or delivery speed justify more work
Retire or retain	Remove, defer, or keep the workload outside migration scope	Low-value, end-of-life, or constrained systems

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

AWS Prescriptive Guidance documents these common migration strategies, often described as the 6 Rs. The right choice still depends on workload value, risk, and team capacity.

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.

Frequently asked

Frequently asked questions

1. 01

   Which cloud migration strategy should a team choose first?

   Choose per workload. A simple rehost may fit low-risk systems, while refactoring or replatforming can make more sense when the current architecture blocks scale, reliability, or cost goals.

2. 02

   Is rehosting always the cheapest migration path?

   No. Rehosting can reduce migration effort, but it may preserve old cost and reliability problems if the workload is poorly sized or hard to operate.