Cloud Migration: The 7R Framework

Cloud migration isn’t a single decision — it’s hundreds of decisions about hundreds of applications. “Lift and shift everything” is a strategy that guarantees you’ll spend more in the cloud than you did on-premises while getting fewer benefits. “Refactor everything as microservices” is a strategy that guarantees your migration will take three years and cost five times the estimate.

The right approach is systematic: assess each workload, choose the right migration strategy for each, group workloads into waves, and execute with clear cutover plans. This guide covers the 7R framework that structures those decisions.

The 7R Strategies

Strategy	Definition	Effort	Cost Savings	When To Use
Rehost	Lift and shift (move VMs as-is)	Low	10-20%	Quick migration needed, minimal changes
Replatform	Lift and reshape (minor cloud optimizations)	Medium	20-40%	Easy wins: managed DB, auto-scaling
Refactor	Re-architect for cloud-native	High	40-70%	Strategic applications, long-term investment
Repurchase	Replace with SaaS	Variable	30-50%	Commodity workloads (email, CRM, HR)
Retire	Decommission	None	100%	Unused or redundant applications
Retain	Keep on-premises	None	0%	Regulatory, latency, or dependency constraints
Relocate	Move to cloud via VMware/Hyper-V	Low	5-15%	VMware environments, fastest path

Decision Tree

Is the application still needed?
├── No → RETIRE (decommission)
│
└── Yes → Is there a SaaS replacement?
    ├── Yes, and it's better → REPURCHASE (switch to SaaS)
    │
    └── No → Must it stay on-prem?
        ├── Yes (compliance, latency) → RETAIN (keep on-prem)
        │
        └── No → Is it a strategic application?
            ├── Yes → REFACTOR (re-architect for cloud-native)
            │
            └── No → Are there easy cloud optimizations?
                ├── Yes → REPLATFORM (managed services, auto-scaling)
                │
                └── No → REHOST (lift and shift)

Migration Assessment

Application Portfolio Analysis

def assess_application(app):
    """Score application for migration strategy recommendation."""
    
    scores = {
        "business_value": app["revenue_impact"] + app["user_count_score"],
        "technical_complexity": (
            app["dependencies_count"] * 2 +
            app["custom_integrations"] * 3 +
            app["legacy_framework_penalty"]
        ),
        "cloud_readiness": (
            app["containerized"] * 3 +
            app["stateless"] * 2 +
            app["uses_managed_services"] * 2 -
            app["hardcoded_ips"] * 2 -
            app["shared_database"] * 3
        ),
    }
    
    if scores["business_value"] > 7 and scores["cloud_readiness"] > 5:
        return "REFACTOR"
    elif scores["technical_complexity"] > 8:
        return "REPLATFORM"  # Too complex to refactor, but needs some optimization
    elif scores["business_value"] < 3:
        return "RETIRE or RETAIN"
    else:
        return "REHOST"

Dependency Mapping

Application A (Web Frontend)
    ├── → Application B (API Gateway) [HTTP]
    │       ├── → Application C (Auth Service) [gRPC]
    │       ├── → Application D (Order Service) [gRPC]
    │       │       ├── → PostgreSQL (shared DB) [TCP:5432]
    │       │       └── → Application E (Inventory) [gRPC]
    │       └── → Redis (session cache) [TCP:6379]
    └── → CDN (static assets) [HTTPS]
    
Migration constraint: A, B, C, D must migrate together (tight coupling)
Can migrate separately: E (API boundary), Redis (replace with ElastiCache)

Migration Waves

Wave Planning

Wave	Applications	Strategy	Duration	Risk
Wave 0	Non-production environments	Rehost	2-4 weeks	Low
Wave 1	Independent, low-risk apps	Rehost/Replatform	4-6 weeks	Low
Wave 2	Medium complexity, some dependencies	Replatform	6-8 weeks	Medium
Wave 3	Core business apps	Refactor/Replatform	8-12 weeks	High
Wave 4	Legacy with deep dependencies	Rehost + gradual refactor	12-16 weeks	High

Cutover Planning

Cutover Checklist Template

## Pre-Cutover (T-7 days)
- [ ] Cloud environment fully provisioned
- [ ] Data replication caught up (lag < 1 minute)
- [ ] DNS TTL reduced to 60 seconds
- [ ] Rollback plan tested
- [ ] All teams confirmed availability for cutover window

## Cutover (T-0)
- [ ] Freeze source database writes
- [ ] Verify final data sync
- [ ] Switch DNS / load balancer to cloud target
- [ ] Smoke test: login, core workflows, payment processing
- [ ] Monitor error rates for 30 minutes
- [ ] Confirm: proceed or rollback?

## Post-Cutover (T+1 to T+7)
- [ ] Monitor performance vs baseline
- [ ] Check data integrity (row counts, checksums)
- [ ] Decommission source (after 30-day soak period)

Anti-Patterns

Anti-Pattern	Problem	Fix
”Lift and shift everything”	Paying cloud prices for on-prem architecture	Assess each workload, right strategy per app
Big bang migration	Everything moves at once, massive risk	Waves: start small, learn, accelerate
No dependency mapping	Migrating app A breaks app B	Map dependencies before migration planning
Skipping retire/retain	Migrating apps that should be killed	Portfolio assessment: retire 10-30% of apps
No rollback plan	Single cutover with no way back	Maintain rollback capability for 30 days
Ignoring data gravity	Moving compute but forgetting data transfer costs	Migrate data first, then compute

Checklist

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For cloud migration consulting, visit garnetgrid.com. :::