The 8 Rs of Cloud Migration: Choosing Your Strategy Based on Business Drivers

Most cloud migration projects fail not in execution, but in planning. Specifically, in the critical moment when someone decides — often informally, often prematurely — what the migration strategy will be.

"We're going to lift and shift everything." "We're going to refactor to microservices." "We're going to rehost the legacy stuff and modernize the rest." These decisions sound reasonable. They rarely survive contact with the actual portfolio.

The 8 Rs framework exists to prevent this problem. It forces a different question first: not "what should we do with this workload?" but "what business outcome are we trying to achieve with this workload?" The answer to that question determines the strategy. Not the other way around.

Why Migration Strategy Needs to Follow Business Drivers

Consider a common scenario: a manufacturing company migrating to the cloud to reduce infrastructure costs. The IT team decides to rehost everything (lift and shift) because it's fast and low-risk. Within 18 months, they've moved 200 workloads to the cloud and their costs have gone up. The infrastructure is more flexible, technically. But the business goal — cost reduction — wasn't achieved because rehosting doesn't optimize for cloud economics.

Or the reverse: a financial services firm decides to refactor its core transaction processing system to a cloud-native microservices architecture. The project takes three years, costs $40M, and the system is still not fully migrated. The business driver was "improve reliability." A replatform with managed database services would have achieved it in six months for $4M.

The mismatch between strategy and business driver is the source of most migration failures. The 8 Rs framework addresses this directly.

The 8 Rs: A Decision Framework

Each of the 8 Rs represents a distinct migration strategy, appropriate for different business contexts and workload characteristics.

1. Rehost (Lift and Shift)

Move the workload to the cloud with minimal changes. The application runs on virtual machines in the cloud instead of on-premises hardware, but the architecture is essentially unchanged.

When it's right: Large-scale migrations where speed matters more than optimization, organizations with hard datacenter exit deadlines, workloads with stable demand that will be modernized later, or applications with licensing constraints that make refactoring economically prohibitive.

When it's wrong: When the business driver is cost optimization (rehosting rarely reduces costs meaningfully), when the workload is a strong candidate for managed services, or when the application has known scalability problems that will be amplified, not resolved, by the move.

2. Replatform (Lift, Tinker, and Shift)

Move to the cloud with targeted optimizations — typically moving databases to managed services, containerizing applications, or adjusting configurations for cloud economics — without changing core architecture.

When it's right: Workloads where managed services would reduce operational burden significantly, applications with database dependencies that could benefit from cloud-managed options, and organizations that want meaningful optimization without the cost and risk of full refactoring.

3. Repurchase (Drop and Shop)

Replace the existing application with a cloud-native SaaS alternative. Move from a self-hosted CRM to Salesforce. Move from on-premises HR software to Workday.

When it's right: When the existing application is a commodity function, when the vendor's SaaS product significantly exceeds the capabilities of the on-premises version, or when the business driver is reducing operational overhead more than preserving customizations.

When it's wrong: When the application has deep customizations that represent competitive differentiation, or when the SaaS equivalent lacks critical features your business depends on.

4. Refactor / Re-architect

Substantially redesign the application to take advantage of cloud-native capabilities — microservices, serverless, event-driven architectures, cloud-native data services.

When it's right: When the business driver is scalability, resilience, or developer velocity at scale. When the application's current architecture is a genuine constraint on business growth.

When it's wrong: When the business driver could be achieved with a less disruptive approach. Refactoring is expensive and risky. It's the right choice when it's the only path to the outcome you need — not the default choice because it sounds modern.

5. Retire

Decommission the application entirely. It's no longer serving a meaningful business function.

When it's right: More often than you think. Typical enterprise portfolios contain 20–30% of applications that could be retired. Every application you retire is infrastructure, licensing, and operational cost eliminated.

Why it's often overlooked: Retiring applications requires organizational courage. Someone built that application. Someone uses it occasionally. Retirement conversations are politically difficult. Do them anyway — the savings are real and the risk is minimal.

6. Retain

Don't migrate this workload. Keep it on-premises for now.

When it's right: Regulatory requirements that mandate on-premises data residency, applications with dependencies that make cloud migration prohibitively complex, workloads scheduled for retirement within 12–18 months, or applications undergoing significant changes that make migration premature.

Important nuance: Retain is a legitimate strategic choice, not a failure to decide. Some workloads genuinely don't belong in the cloud yet. Forcing migration on those workloads creates risk and cost without business value.

7. Relocate

Move workloads to a different cloud environment — typically from one cloud provider to another, or from a legacy cloud setup to a current-generation architecture on the same provider.

When it's right: Workloads that are already in the cloud but on outdated configurations, or when a business driver (cost, compliance, capability) requires a provider change.

8. Repave

Rebuild on modern infrastructure — sometimes called "rip and replace." Decommission the existing application and build a replacement from scratch using current technology and architecture principles.

When it's right: When the existing application is so constrained by technical debt that any other strategy would produce diminishing returns, and when the business case for the new capability justifies the investment.

Building Your Migration Roadmap

The 8 Rs aren't applied in isolation. A typical enterprise portfolio will use all eight strategies — different workloads genuinely need different approaches. The work is in the classification.

For each workload, the decision process should follow this sequence:

1. What business outcome does this workload enable? Cost reduction, reliability improvement, scalability, developer velocity, regulatory compliance?
2. What's the current state? Architecture, dependencies, data residency requirements, usage patterns, technical debt, vendor relationships?
3. Which strategy achieves the business outcome given the current state constraints?
4. What are the cost, timeline, and risk tradeoffs of that strategy?

This analysis sounds time-consuming. Done rigorously for a large portfolio, it is. It's also the only reliable way to avoid the expensive strategy mismatches that derail most migration programs.

The Security Constant

Across all 8 Rs, one principle is non-negotiable: security must be embedded at every stage, not added at the end. Each migration strategy introduces different security considerations — data exposure during lift and shift, access control configuration during replatform, vendor security assessment during repurchase.

Build security review into your migration decision framework, not your post-migration checklist.

---

Evaluating a cloud migration and not sure which strategy fits your workloads? Our team applies this framework in enterprise engagements and a lighter-touch version in the AI Cost Audit for teams assessing their software stack.