Skip to main content
Migration Frameworks

What Are the 7 Migration Strategies?

The complete 7 Rs architectural framework for evaluating server, database, and application migrations: Rehost, Replatform, Refactor, Repurchase, Relocate, Retain, and Retire.

10 min read
Updated: September 2026
Enterprise 7 Rs Framework
framework / 7-rs-matrix
root@architect-ops:~# evaluate-workload --app ecommerce-monolith --tier production
Analyzing code portability, database dependencies, and SLA...
Strategy Selected: REPLATFORM (Lift, Tinker & Shift)
-> Move OS from CentOS 7 to AlmaLinux 9
-> Decouple MySQL to high-availability database cluster
-> Containerize background workers in Docker
Estimated cutover downtime: 0 seconds (Lock-free delta)
root@architect-ops:~#
Quick Answer / Executive Summary

The 7 migration strategies (The 7 Rs) represent the industry standard for classifying server workloads: Rehost (Lift & Shift), Replatform (Lift, Tinker & Shift), Refactor (Cloud-Native Re-architecture), Repurchase (Replace with SaaS), Relocate (Hypervisor-level VM move), Retain (Keep on-premise temporarily), and Retire (Decommission unused assets). Hosting providers primarily leverage Rehost and Replatform to maximize uptime while upgrading hardware.

Understanding the 7 Rs Migration Framework

When planning an infrastructure or cloud transition, there is no one-size-fits-all approach. The 7 Rs of Migration, popularized by Gartner and Amazon Web Services (AWS), provide an objective decision framework for categorizing server workloads based on complexity, cost, business risk, and long-term architectural goals.

By auditing each server against these seven pathways, engineering leaders avoid costly mistakes like over-engineering simple applications or prematurely rewriting stable systems.

Detailed Breakdown of the 7 Migration Strategies

1. Rehost (Lift and Shift)

Moving applications and operating systems directly from physical or virtual hosts to cloud virtual machines without making architectural or code modifications.

When to use: Fast hardware decommissioning, urgent datacenter contract expirations, or legacy applications requiring exact operating system environments.

2. Replatform (Lift, Tinker, and Shift)

Making targeted optimizations to the underlying operating platform without modifying the core application code. Examples include upgrading the OS from CentOS 7 to AlmaLinux 9, switching from self-hosted MySQL to managed AWS RDS, or containerizing with Docker.

When to use: Improving reliability, offloading database maintenance overhead, and reducing licensing costs without the risks of a code rewrite.

3. Refactor / Re-architect

Re-architecting an application into cloud-native microservices, serverless functions, and event-driven patterns. This involves substantial code rewrites to take full advantage of cloud scalability.

When to use: High-growth SaaS products where monolithic server bottlenecks limit feature delivery, concurrency, or global distribution.

4. Repurchase (Drop and Shop)

Retiring a custom-hosted or legacy proprietary software package and moving to a third-party Software-as-a-Service (SaaS) solution. A prime example is migrating self-hosted webmail servers to Google Workspace or Microsoft 365.

When to use: Standard business utilities (CRM, ERP, corporate mail, helpdesk) where maintaining internal server infrastructure delivers no competitive advantage.

5. Relocate (Hypervisor-Level Transfer)

Transferring virtual machines directly between compatible hypervisor environments (such as moving VMs between on-premise VMware clusters and VMware Cloud on AWS, or live migrating between KVM and Proxmox nodes).

When to use: Large enterprise virtualization pools where applications can be moved at the hypervisor layer without rewriting configurations or installing new OS packages.

6. Retain (Revisit Later)

Keeping specific servers or workloads on existing hardware or within the current hosting facility. This is common for legacy systems that have strict data sovereignty rules, specialized hardware dongles, or active deprecation plans.

When to use: Systems with heavy compliance constraints, low business value, or software scheduled for end-of-life retirement within 6 to 12 months.

7. Retire

Decommissioning unnecessary servers, staging environments, orphan databases, and unused cron instances that no longer serve business needs.

When to use: Discovery audits often reveal that 10% to 20% of an enterprise server fleet comprises zombie nodes that can be safely powered off to save hosting fees and eliminate security vulnerabilities.

Strategy Comparison Matrix

Strategy Execution Speed Code Changes Technical Risk Cost Optimization
Rehost Very Fast None Low Moderate
Replatform Fast Minimal (Configs) Low-Moderate High
Refactor Slow Extensive Rewrites High Very High (Long term)
Repurchase Moderate Data Export/Import Moderate Predictable SaaS
Relocate Very Fast None Low Variable
Retire Immediate None Zero 100% Savings
Infrastructure Support

Select the Ideal Migration Strategy for Your Infrastructure

Avoid migration pitfalls with certified Linux systems architects designing your cutover roadmap from day one.