What are the 7 Rs of cloud migration, and how do you choose per application?

• Retire – decommission the application entirely; portfolio assessments routinely find unused systems.
• Retain – deliberately leave it where it is for now, due to hard dependencies, looming retirement, or compliance constraints.
• Rehost (lift-and-shift) – move to cloud infrastructure with no code changes; fast and low-risk.
• Relocate – move an entire platform (e.g., VMware) to the cloud without changing the hypervisor or OS.
• Repurchase (drop-and-shop) – replace with a SaaS subscription.
• Replatform (lift-tinker-and-shift) – make targeted optimizations like moving to a managed database.
• Refactor (re-architect) – significantly redesign for cloud-native; highest effort, highest benefit.

What are the 7 Rs of cloud migration?

The 7 Rs are seven strategies for moving an application portfolio to the cloud. The key insight is that you choose one per application, never one blanket strategy for the entire estate.

| R | Also Called | Effort | Cloud Benefit | When to Use |
|---|-----------|--------|---------------|-------------|
| Retire | Decommission | None | N/A | Unused or redundant applications |
| Retain | Revisit | None | None (stays on-prem) | Hard dependencies, compliance, near EOL |
| Rehost | Lift-and-shift | Low | Basic (exit DC) | Large estates under time pressure |
| Relocate | Platform move | Low | Basic | VMware-to-cloud without changes |
| Repurchase | Drop-and-shop | Medium | High (no ops) | Better SaaS exists (email, CRM) |
| Replatform | Lift-tinker-shift | Medium | Moderate | Managed DB, managed runtime |
| Refactor | Re-architect | High | Maximum | Strategic, high-value systems |

package com.bank.migration;

public class MigrationAdvisor {

    public enum Strategy {
        RETIRE, RETAIN, REHOST, RELOCATE, REPURCHASE, REPLATFORM, REFACTOR
    }

    public Strategy recommend(int businessValue, int complexity, boolean unused,
                              boolean hasSaasReplacement, boolean needsCloudNative) {
        if (unused) return Strategy.RETIRE;
        if (complexity > 8 && businessValue < 3) return Strategy.RETAIN;
        if (hasSaasReplacement) return Strategy.REPURCHASE;
        if (needsCloudNative && businessValue > 7) return Strategy.REFACTOR;
        if (businessValue > 5) return Strategy.REPLATFORM;
        return Strategy.REHOST;
    }

    public static void main(String[] args) {
        var advisor = new MigrationAdvisor();
        System.out.println("Expense tool: " +
            advisor.recommend(1, 2, true, false, false));  // RETIRE
        System.out.println("Email server: " +
            advisor.recommend(6, 5, false, true, false));  // REPURCHASE
        System.out.println("Payments monolith: " +
            advisor.recommend(10, 7, false, false, true)); // REFACTOR
        System.out.println("Accounts DB: " +
            advisor.recommend(8, 4, false, false, false)); // REPLATFORM
        System.out.println("Batch reports: " +
            advisor.recommend(4, 3, false, false, false)); // REHOST
    }
}

Expense tool: RETIRE
Email server: REPURCHASE
Payments monolith: REFACTOR
Accounts DB: REPLATFORM
Batch reports: REHOST

How does Retire reduce migration scope?

Portfolio assessments routinely find that a meaningful slice of applications are redundant or unused. The cheapest migration is the one you do not do.

 Before assessment: 200 applications to migrate
 After assessment:
   - 30 applications retired (unused, redundant)
   - 15 applications retained (hard dependencies, near EOL)
   Remaining: 155 applications actually need migration
   Scope reduced by 22% with zero migration effort

How does Rehost (lift-and-shift) work?

Rehost moves the application to cloud infrastructure with no code changes. The same virtual machines, just running in the cloud.

# Rehost: move a VM to AWS as-is using Application Migration Service
# No code changes, no architecture changes
# Benefits: exit data center, elastic compute, pay-as-you-go
# Limitation: cloud prices for data-center-shaped workloads

How does Replatform work?

Replatform makes a few targeted cloud optimizations without changing the core architecture. The classic example is moving a self-managed database onto a managed service.

# Before: self-managed PostgreSQL on EC2
# You patch the OS, manage backups, configure replication, handle failover

# After: Amazon RDS for PostgreSQL
# Provider patches OS and DB engine
# Automated backups, multi-AZ failover, point-in-time recovery
# Application code barely changes -- just the connection string

# Terraform for replatform:
resource "aws_db_instance" "bank_accounts" {
  engine               = "postgres"
  engine_version       = "15.4"
  instance_class       = "db.r6g.xlarge"
  multi_az             = true
  backup_retention_period = 7
  # The provider now handles patching, backups, and failover
}

How does Refactor work?

Refactor is the deepest and most expensive strategy. You significantly redesign the application to become cloud-native.

 Before (monolith):
 ┌────────────────────────────────────┐
 │  Payments Monolith (single WAR)    │
 │  - Transfer logic                  │
 │  - Account queries                 │
 │  - Statement generation            │
 │  - Notification sending            │
 │  All deployed together             │
 └────────────────────────────────────┘

 After (microservices):
 ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
 │ Transfer │  │ Account  │  │Statement │  │ Notify   │
 │ Service  │  │ Service  │  │ Service  │  │ Service  │
 └──────────┘  └──────────┘  └──────────┘  └──────────┘
      │              │              │              │
      ▼              ▼              ▼              ▼
  [Own DB]       [Own DB]      [Own DB]       [SQS Queue]
  Independent scaling, deployment, and failure isolation

How do you choose per application?

The decision is a structured assessment scoring each application.

 Assessment Criteria:

 1. Business value    (1-10): How important is this to the business?
 2. Technical complexity (1-10): How hard is it to migrate?
 3. Cloud suitability  (1-10): How well does it fit cloud patterns?
 4. Migration cost     (estimate): Developer time + risk
 5. Business urgency   (1-10): How soon must it move?

 Decision matrix:
   Low value + unused       ──▶ RETIRE
   Hard dependencies / EOL  ──▶ RETAIN
   High volume + time pressure ──▶ REHOST
   Better SaaS exists       ──▶ REPURCHASE
   DB/runtime burden        ──▶ REPLATFORM
   Strategic + high value   ──▶ REFACTOR

What is the difference between Replatform and Refactor?

| Aspect | Replatform | Refactor |
|--------|-----------|----------|
| Code changes | Minimal (connection string, config) | Significant (architecture redesign) |
| Architecture | Same monolith or structure | Microservices, serverless, event-driven |
| Effort | Medium | High |
| Risk | Low-medium | High |
| Cloud benefit | Moderate (managed ops, backups) | Maximum (elasticity, resilience, agility) |
| Example | Self-managed DB to RDS | Monolith to microservices |

What are common mistakes with cloud migration?

# WRONG: one R for everything
"We'll lift-and-shift the entire estate."
# Result: cloud prices for data-center-shaped workloads
# No auto-scaling, no managed services, same operational burden

# WRONG: refactor everything
"We'll make everything cloud-native."
# Result: budget blown, timeline missed, team burned out

# CORRECT: choose per application based on value and suitability
# Retire the unused, retain the blocked, rehost the bulk,
# replatform the operational burdens, refactor only the strategic few

What should a senior engineer know?

The senior discipline is that the two zero-effort decisions (Retire and Retain) should happen first to shrink the scope. Then real investment lands only where the cloud benefit clearly justifies it. Applying one R to everything is the most common and expensive mistake.