Cloud Migration Strategy Frameworks: The 6 Rs and Beyond

Cloud migration strategy frameworks provide structured decision models for classifying workloads, selecting migration paths, and sequencing execution across an organization's application portfolio. The dominant framework — known as the 6 Rs — originated in AWS migration methodology and has since been adapted by Google Cloud, Azure, Gartner, and independent practitioners. This page covers the definition, internal mechanics, causal logic, classification boundaries, tradeoffs, common misconceptions, and a reference matrix for each migration strategy type.

Definition and scope

A cloud migration strategy framework is a classification system that maps each application or workload to a specific migration path based on technical, financial, and operational criteria. The framework governs scope decisions before execution begins — determining which workloads move, in what form, and on what schedule.

The 6 Rs model — Rehost, Replatform, Repurchase, Refactor, Retire, and Retain — was formalized in AWS migration guidance and represents the most widely referenced taxonomy in enterprise cloud adoption. Gartner independently developed a parallel taxonomy called the "5 Rs" (Rehost, Refactor, Revise, Rebuild, Replace), which predates the AWS articulation but covers substantially overlapping territory. Google Cloud's migration framework uses 4 migration paths — lift and shift, improve and move, remove and replace, and rearchitect — which map directly onto the R-based model with different naming conventions.

These frameworks apply to application migration to cloud, legacy system cloud migration, and data migration contexts. They are used across regulated and non-regulated industries and are referenced in federal cloud adoption documentation, including the U.S. General Services Administration's cloud adoption guidance under the Federal Risk and Authorization Management Program (FedRAMP).

Core mechanics or structure

Each "R" strategy defines a distinct combination of effort, modification depth, and outcome for a given workload. The 6 Rs operate as a decision taxonomy rather than a sequence — each application is independently assessed and assigned to one path.

Rehost (Lift and Shift): The application is moved from on-premises infrastructure to cloud virtual machines with no modification to application code, runtime, or configuration. Only the hosting layer changes. Lift-and-shift migration is the fastest path to cloud and the lowest-risk in terms of application behavior, but it captures the least cloud-native benefit. AWS estimates that organizations can save up to 30% on total cost of ownership through rehosting alone due to infrastructure cost reduction, though actual savings depend on licensing, reserved instance strategy, and workload patterns.

Replatform (Lift, Tinker, and Shift): The application moves to cloud with targeted optimizations — for example, migrating from a self-managed database to a managed database service like Amazon RDS or Azure SQL Managed Instance — without changing the application's core architecture. The distinction from refactoring is that no application code is rewritten. See replatforming vs. refactoring for a detailed comparison.

Repurchase (Drop and Shop): The existing application is replaced by a commercial SaaS equivalent. A legacy on-premises CRM, for example, might be replaced by Salesforce or HubSpot. This strategy eliminates migration of the existing codebase entirely and shifts operational responsibility to the SaaS vendor. SaaS migration considerations govern this path.

Refactor / Re-architect: The application is redesigned using cloud-native patterns — microservices, serverless functions, managed queues, and cloud-native storage. This path captures the highest long-term efficiency gains but requires the most engineering investment. NIST defines cloud-native architectures within its SP 500-322, "Evaluation of Cloud Computing Services Based on NIST SP 800-145" (NIST SP 500-322).

Retire: Applications that are no longer needed are decommissioned. Portfolio analysis typically identifies 10–20% of application inventories as candidates for retirement, according to AWS migration program guidance, which reduces the total migration scope.

Retain: Applications unsuitable for migration in the current cycle — due to regulatory constraints, technical dependencies, or cost-benefit thresholds — remain on-premises or in existing data centers until conditions change. Cloud readiness assessment processes produce the inventory data that drives retain decisions.

Causal relationships or drivers

Migration strategy selection is not arbitrary. Specific technical and business conditions deterministically push workloads toward particular R paths.

Latency and integration coupling drive Retain or Rehost decisions. Applications tightly coupled to on-premises hardware — through low-latency message buses, specialized peripherals, or mainframe co-location requirements — cannot be refactored without resolving the dependency chain first. Workload prioritization frameworks use dependency mapping to identify these constraints.

Licensing cost structures influence Repurchase decisions. Perpetual software licenses for products with active SaaS equivalents frequently produce negative ROI when ported to cloud, because cloud instances accrue both infrastructure cost and license cost simultaneously. Cloud migration cost estimation models must account for this double-cost exposure.

Compliance and data residency requirements constrain path selection for regulated workloads. Applications subject to HIPAA, PCI DSS, or FedRAMP controls may be restricted from certain cloud regions or service types. HIPAA-compliant cloud migration and FedRAMP cloud migration for government each carry path constraints that override pure efficiency reasoning.

Technical debt depth is the primary driver of Refactor decisions. Applications with monolithic architectures, undocumented interdependencies, or end-of-life runtimes generate compounding operational cost in the cloud unless rearchitected. NIST SP 800-146 ("Cloud Computing Synopsis and Recommendations") identifies legacy architecture as a primary inhibitor of cloud efficiency gains (NIST SP 800-146).

Classification boundaries

The critical classification challenge is distinguishing adjacent strategies that share surface-level characteristics.

Rehost vs. Replatform: The boundary is whether any managed cloud service replaces a self-managed component. Moving a VM image from on-premises to EC2 with no other change is Rehost. Replacing a self-managed PostgreSQL instance with Amazon Aurora in the same migration event is Replatform — even if the application code remains identical.

Replatform vs. Refactor: The boundary is application code modification. If the application binary or source code changes, the strategy is Refactor regardless of infrastructure changes. Replatform modifies the operational environment only.

Repurchase vs. Refactor: The boundary is build-versus-buy. Repurchase eliminates the existing codebase. Refactor retains and rewrites it. Organizations sometimes misclassify partial SaaS integrations — for example, retaining a custom app while offloading one function to a SaaS API — as Repurchase when the outcome is actually a Refactor of the retained system.

Retain vs. Retire: Retain is a time-bounded deferral. Retire is permanent decommission. Workloads classified as Retain without a defined reassessment date tend to drift into permanent on-premises residency, which is a governance failure rather than a strategy.

Tradeoffs and tensions

The 6 Rs model creates measurable tensions between competing migration objectives.

Speed vs. optimization: Rehost delivers the fastest migration velocity but the lowest cloud-native efficiency. Organizations prioritizing data center exit deadlines — for example, a lease expiration or a hardware refresh cycle — typically bias toward Rehost even for workloads where Refactor would produce better economics over 36 months. Cloud migration project timeline planning must make this tradeoff explicit.

Cost visibility vs. cost reduction: Repurchase converts capital expenditure to predictable SaaS subscription cost, improving budget visibility, but SaaS per-seat or per-transaction pricing frequently exceeds the total cost of a self-hosted system at scale. Organizations with large user bases may find Refactor economically superior despite higher upfront investment.

Risk distribution: Refactor concentrates risk at the engineering phase — if the rearchitecture is poorly executed, the application may fail post-migration in ways that a Rehost would have avoided. Rehost distributes risk to the post-migration optimization phase, where cloud cost overruns are common. Cloud migration risk management frameworks must account for when in the project lifecycle each strategy type concentrates its primary risk.

Governance complexity: Multi-path portfolios — where an organization simultaneously executes Rehost, Replatform, and Refactor workloads — create governance complexity because each path requires different tooling, skills, and success metrics. Cloud migration governance frameworks must accommodate this heterogeneity.

Common misconceptions

Misconception: Refactor is always the right long-term answer. Refactoring every application to cloud-native architecture is neither economically justified nor technically feasible for most portfolios. Applications with stable, infrequent usage patterns produce better ROI through Rehost or Replatform. Refactor is appropriate where scalability, reliability, or feature velocity requirements cannot be met by the existing architecture.

Misconception: Rehost is a temporary step that always leads to Refactor. Rehosted applications frequently remain in their migrated state indefinitely. Organizations that plan Rehost as a stepping stone to Refactor without allocated engineering budget and timeline tend to accumulate cloud-hosted technical debt equivalent to their on-premises technical debt. This is one of the documented cloud migration common mistakes.

Misconception: Retire and Retain require no active management. Retire requires formal decommission procedures — data archival, license termination, access revocation, and dependency resolution. Retain requires defined reassessment triggers. Neither path is passive. Failing to manage these paths produces shadow IT and orphaned infrastructure.

Misconception: The 6 Rs are mutually exclusive per application. Large monolithic applications may be decomposed — some modules Refactored, some Retired, and the remainder Rehosted — as part of a structured decomposition project. AWS documentation explicitly acknowledges this pattern in multi-wave migration planning. Cloud migration wave planning addresses how split-strategy decompositions are sequenced.

Misconception: Repurchase eliminates migration complexity. SaaS transitions require data migration, user training, API integration development, and contract negotiation. These activities can match or exceed the complexity of a Rehost for data-intensive systems. Cloud migration tools comparison covers the ETL and data transformation tools used in Repurchase scenarios.

Checklist or steps

The following steps represent the standard portfolio assessment sequence used to assign R-strategy classifications to a workload inventory.

  1. Inventory compilation — Enumerate all applications in scope, including runtime versions, hosting infrastructure, dependency maps, and business owners. Minimum data fields: application name, owning team, primary runtime, external dependencies, data classification, and current monthly cost.

  2. Technical feasibility screening — Evaluate each application against cloud provider compatibility requirements. Flag applications with mainframe dependencies, specialized hardware, or unsupported operating system versions for Retain or Retire consideration.

  3. Business value scoring — Assign a business criticality score to each application based on revenue impact, user count, regulatory function, or strategic priority. High-criticality applications with high technical debt are primary Refactor candidates.

  4. Cost modeling — Produce a 36-month total cost comparison for each feasible strategy path. Include compute, storage, licensing, egress, and engineering labor. Cloud migration cost estimation methodologies apply here.

  5. Compliance constraint mapping — Identify regulatory requirements (HIPAA, PCI DSS, FedRAMP, SOC 2) applicable to each workload. Map constraints to cloud service types and regions. Flag path restrictions. See cloud migration compliance for US regulations.

  6. Strategy assignment — Assign one primary R-strategy to each application based on the outputs of steps 1–5. Document the rationale for each assignment.

  7. Dependency sequencing — Group applications by dependency relationship and assign to migration waves. Applications with upstream dependencies must migrate after the systems they depend on. Cloud migration wave planning governs this step.

  8. Governance checkpoint — Review assignments with application owners, finance stakeholders, and security teams before execution begins. Unresolved Retain classifications require a defined reassessment date.

Reference table or matrix

Strategy Code Change? Architecture Change? Avg. Migration Speed Cloud-Native Benefit Primary Risk Phase Typical Use Case
Rehost None None Fast (weeks) Low Post-migration cost overrun Data center exit deadlines
Replatform None Partial Moderate (weeks–months) Medium Integration regression DB modernization, managed services adoption
Repurchase Eliminated Eliminated Variable High (vendor-managed) Data migration, vendor dependency Legacy COTS replacement
Refactor Significant Full Slow (months–years) Highest Engineering execution failure High-scale, high-velocity applications
Retire N/A N/A Immediate N/A Data archival, compliance End-of-life applications
Retain None None None None Governance drift (no reassessment) Regulatory hold, unresolved dependencies

References

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Cloud Hosting Cost Estimator