The 7 Cloud Migration Strategies: Rehost, Relocate, Replatform, Refactor, Repurchase, Retire, Retain

TL;DR: The right cloud migration strategy is rarely one approach for your entire estate. Use the seven Rs to assess each workload by business value, technical risk, cost, dependencies, and compliance requirements. Move quickly where speed matters, modernize selectively where it creates differentiation, and avoid migrating systems that should be retired or retained.

Why Cloud Migration Fails Without Workload-Level Decisions

Many cloud programs begin with a broad objective: exit a data center, reduce infrastructure overhead, improve resilience, or enable faster product delivery. Those are valid goals. Problems begin when the organization applies one migration method to every application.

A lift-and-shift program may meet a data center exit deadline but create expensive, poorly optimized cloud environments. A broad modernization mandate can produce the opposite outcome: teams spend years rewriting applications before realizing operational value.

Effective cloud migration strategies treat the application portfolio as a set of different business and technical decisions. A customer-facing platform with scalability constraints deserves a different path than a lightly used reporting server, a VMware-hosted internal system, or a commodity HR application.

The seven Rs provide a useful portfolio triage framework. They help you decide whether to move, modernize, replace, remove, or temporarily leave each workload in place.

What Are the 7 Cloud Migration Strategies?

The 7 Rs cloud migration framework includes rehost, relocate, replatform, refactor, repurchase, retire, and retain. Each option balances speed, risk, investment, and long-term operating value differently.

Rehost: Move Fast With Minimal Change

Rehosting, often called lift and shift, moves an application from on-premises infrastructure to cloud virtual machines with few or no code changes.

Rehost is often appropriate when you need to:

• Exit a data center on a fixed timeline.
• Reduce reliance on aging hardware.
• Move stable applications with limited engineering capacity.
• Establish a cloud operating baseline before deeper modernization.

The principal advantage is speed. The tradeoff is that you may carry existing architecture and infrastructure inefficiencies into the cloud. An application designed for permanently provisioned servers may become expensive if its compute, storage, and licensing model is not optimized after migration.

Rehosting should not mean “move and forget.” Put a post-migration optimization backlog in place for rightsizing, storage tiering, backup policies, and reserved-capacity decisions.

Relocate: Move the Virtualization Estate

Relocation moves workloads to cloud-hosted infrastructure while preserving much of the existing virtualization layer. This approach is common for organizations with substantial virtualized estates and a near-term need to change hosting location without redesigning every virtual machine.

Relocate can reduce migration disruption because teams preserve familiar tools, operating procedures, and machine configurations. However, you must examine the long-term commercial implications, including platform dependency, licensing portability, support arrangements, and the cost of running a virtualization layer in the cloud.

It is usually a transition strategy, not automatically a final-state architecture.

Replatform: Make Targeted Cloud Improvements

Replatforming makes limited, high-value changes without rewriting the application. Common examples include moving a self-managed database to a managed database service, adopting cloud object storage, or packaging an application for a managed container platform.

This is often the strongest middle ground in the rehost vs replatform decision. You preserve most application behavior while improving operations, resilience, patching responsibilities, or scalability.

Replatform is a good fit when:

• A managed service can remove significant maintenance effort.
• The application has a stable codebase but an inefficient infrastructure footprint.
• You need better backup, disaster recovery, or availability capabilities.
• Small changes can materially improve cloud economics.

The risk is underestimating integration and testing work. A database migration, for example, may affect drivers, query behavior, batch jobs, reporting tools, and recovery procedures.

Refactor: Redesign for Cloud-Native Value

Refactoring, sometimes called rearchitecting, changes application design to use cloud-native capabilities such as managed event services, scalable compute, APIs, or independently deployable components.

This path can improve reliability, performance, release velocity, and scalability. It also has the highest implementation risk and typically requires the most product, engineering, and testing investment.

Refactor only when there is a clear value case. Good candidates include revenue-generating digital products, systems that cannot meet performance targets, and platforms whose slow release cycle limits the business. Avoid using refactoring as a default migration method for every legacy application.

Repurchase: Replace the Application With SaaS

Repurchasing replaces an existing application with a software-as-a-service product or commercial cloud solution. It is often appropriate for commodity functions such as collaboration, HR, CRM, service management, or expense management.

The technical migration may be simpler than a rewrite, but the organizational change can be substantial. Evaluate data migration, process redesign, integrations, vendor configuration, access controls, and user adoption before committing.

A SaaS replacement is successful when it reduces the total burden of ownership without forcing unnecessary customization that recreates the legacy system's complexity.

Retire: Eliminate What No Longer Creates Value

Retirement decommissions applications, servers, databases, and integrations that are unused, duplicated, obsolete, or no longer justified by business demand.

Retirement is often the fastest way to reduce migration scope and cost. Yet it requires disciplined discovery. Low utilization alone does not prove a workload is safe to remove; it may support a monthly close process, archive regulatory data, or serve as an undocumented dependency.

Confirm ownership, data retention obligations, inbound and outbound integrations, and recovery requirements before shutting down a workload.

Retain: Keep Workloads Where They Are

Retaining means deliberately leaving a workload in its current environment for now. Reasons may include regulatory restrictions, specialized hardware, latency needs, non-portable licensing, unsupported software, or a weak financial case for migration.

Retain is not a failure. It is a valid portfolio decision when documented with an owner, a rationale, risk controls, and a review date. Without those controls, retained systems can become unplanned technical debt.

Rehost vs Replatform vs Refactor: How to Choose

The most consequential choice in many programs is whether to rehost, replatform, or refactor.

Choose rehost when speed and low change risk matter most. For example, a stable internal application may need to leave a closing data center within six months. Moving it largely unchanged may be the rational decision, provided you plan to optimize its cloud spend later.

Choose replatform when modest changes can materially improve operating economics or reliability. Moving a database from self-managed virtual machines to a managed service may reduce patching, backup, and failover responsibilities without requiring a full application rewrite.

Choose refactor when the workload is strategically important and existing architecture blocks business outcomes. A customer portal that cannot scale during demand peaks or takes months to release improvements may justify deeper modernization.

A practical question for each option is: what business result do you gain for the additional cost, time, and delivery risk? If the answer is unclear, do not default to the most complex approach.

How to Assess Your Application Portfolio

Use the 7 Rs cloud migration model at the workload level, then group similar decisions into migration waves. A simple scoring model makes architecture discussions more transparent to business stakeholders.

Score Business Value and Criticality

Assess revenue impact, customer impact, operational importance, and the cost of downtime. A payroll system, customer ordering application, and archived departmental report may all require different migration priorities even if they use similar technology.

Score each workload from one to five for:

• Business criticality.
• Customer or revenue dependency.
• Required availability and recovery objectives.
• Differentiation value.
• Expected future usage.

High-value, differentiating systems may justify replatforming or refactoring. Low-value systems with declining usage may be candidates for retirement or replacement.

Map Technical Complexity and Dependencies

Inventory is not enough. You need dependency mapping across applications, databases, file transfers, identity systems, network routes, scheduled jobs, and third-party services.

A workload that appears simple may depend on a legacy database, a shared file server, or a nightly batch process. Missing these dependencies is a common cause of failed cutovers.

Assess code ownership, release frequency, operating system support, data volume, integration count, and rollback feasibility. These factors determine whether a workload belongs in an early pilot or a later migration wave.

Evaluate Security and Compliance Constraints

For each application, identify data classification, residency requirements, audit obligations, encryption needs, privileged access paths, and logging requirements. Security controls should be designed into the target environment before workloads arrive.

A governed landing zone should establish identity management, network segmentation, centralized logs, security monitoring, encryption standards, account or subscription structure, and policy guardrails. This reduces the chance that every migration team creates its own inconsistent controls.

Establish a Cost Baseline

Do not compare cloud pricing only with current server hardware cost. Build a total cost baseline that includes infrastructure, software licenses, data center facilities, support contracts, backup, disaster recovery, operational labor, and expected refresh costs.

Then model the future state by workload. Include compute, storage, network egress where relevant, managed-service charges, licensing, support, and migration implementation effort. Treat estimates as ranges until usage and architecture details are validated.

Organizations that need a workload-by-workload roadmap can begin with cloud strategy services.

Security, Downtime, and Cost Risks That Need a Mitigation Plan

Migration risk is manageable when it is visible, owned, and tested before production cutover.

Security Risks

Common security risks include over-permissioned identities, inconsistent encryption, exposed management interfaces, missing logs, and unmanaged secrets. Mitigate these risks through a landing zone, least-privilege access, centralized audit logging, encryption in transit and at rest, vulnerability management, and tested incident-response procedures.

Also validate that service accounts, automated jobs, API keys, and third-party integrations work within the new identity and network model.

Downtime and Data Risks

Downtime risk usually comes from incomplete dependency discovery, insufficient data synchronization, DNS errors, performance surprises, and unclear rollback procedures.

For every production migration, define:

• The maximum permitted outage window.
• Data synchronization and validation steps.
• Entry and exit criteria for cutover.
• Business acceptance testing responsibilities.
• A tested rollback decision point.
• Communications for users, support teams, and stakeholders.

Not every workload needs zero downtime. But every workload needs an agreed recovery plan that matches its business criticality.

Cost Risks

Cloud cost overruns often result from oversized instances, idle non-production environments, excessive data retention, uncontrolled snapshots, or cloud services provisioned without ownership.

Apply financial operations controls before scaling migration waves: tagging standards, budgets, alerts, environment schedules, cost allocation, and regular rightsizing reviews. Measure actual run cost against the approved estimate after each wave, then use the findings to improve the next wave.

Building a Practical Migration Roadmap

A migration roadmap should sequence risk reduction, not simply list applications by age or business unit.

Build the Landing Zone First

Start with the secure, governed target foundation. Define identity, networking, logging, monitoring, policy controls, backup patterns, cost governance, and operational support ownership. This gives every migration wave a repeatable destination.

Select a Representative Pilot

Choose a pilot workload that is important enough to validate the process but not so critical that a learning issue becomes a major business event. A good pilot tests the migration factory: discovery, design, security review, data transfer, cutover, monitoring, rollback, and handover to operations.

Create Dependency-Aware Waves

Group applications into waves based on shared dependencies, business calendars, outage tolerance, and team capacity. Avoid placing too many high-risk systems in one wave. Also avoid migrating an application before the services it depends on are ready.

Use governance checkpoints after each wave to review cost variance, defects, security findings, operational readiness, and lessons learned. Adjust the roadmap rather than repeating avoidable mistakes at greater scale.

Business Impact / Bottom Line

The commercial value of cloud migration strategies is prioritization. You avoid two expensive extremes: moving every workload unchanged and inheriting high cloud bills, or over-modernizing every system and delaying business value.

A strong portfolio typically separates work into three investment categories:

• Move now: Rehost, relocate, or replatform workloads with a clear near-term case.
• Modernize selectively: Refactor systems where product value, resilience, or delivery speed justifies the investment.
• Do not move yet: Retire, retain, or repurchase systems where migration is unnecessary or a better alternative exists.

Measure the program through migration velocity, cutover success rate, post-migration availability, security findings, cost variance against forecast, and the size of the optimization backlog. For refactored systems, also track deployment frequency, lead time for change, and performance improvements tied to customer or operational outcomes.

FAQ

What are cloud migration strategies and when do they make sense?

Cloud migration strategies are the decision paths used to move, improve, replace, remove, or retain workloads during a cloud program. They make sense when you need to balance business urgency with technical risk rather than treating every application the same. Use them during data center exits, infrastructure refreshes, modernization programs, merger integration, resilience initiatives, or cloud cost optimization efforts.

What security, downtime, and cost risks need a mitigation plan?

Your mitigation plan should cover identity and access controls, encryption, logging, secrets management, network segmentation, compliance evidence, data synchronization, cutover testing, rollback procedures, and operational monitoring. It should also include cost ownership, tags, budgets, usage alerts, and post-migration rightsizing. The depth of each plan should match workload criticality and recovery requirements.

How should success, cost, and implementation risk be measured?

Measure success using both delivery and business metrics. Delivery measures include migrated workloads per wave, cutover success, defects, rollback events, and schedule variance. Cost measures include forecast-versus-actual run cost, one-time migration spend, savings from retired assets, and optimization opportunities. Implementation risk should be scored by dependency complexity, data sensitivity, outage tolerance, team readiness, and rollback feasibility. Review these measures after every wave to improve future decisions.