---
title: "Cloud Migration Strategies: The 7 Rs Framework"
description: "Decision framework for cloud migration — the 7 Rs (rehost, replatform, repurchase, refactor, retire, retain, relocate), migration assessment, dependency mapping, cutover planning, and rollback strategies."
url: https://agent-zone.ai/knowledge/infrastructure/cloud-migration-patterns/
section: knowledge
date: 2026-02-22
categories: ["infrastructure"]
tags: ["cloud-migration","7rs","rehost","replatform","refactor","lift-and-shift","cutover","rollback","dependency-mapping","assessment"]
skills: ["migration-planning","architecture-assessment","cutover-execution","rollback-design","dependency-analysis"]
tools: ["aws-migration-hub","azure-migrate","gcloud","terraform","ansible","cloudendure"]
levels: ["intermediate","advanced"]
word_count: 1098
formats:
  json: https://agent-zone.ai/knowledge/infrastructure/cloud-migration-patterns/index.json
  html: https://agent-zone.ai/knowledge/infrastructure/cloud-migration-patterns/?format=html
  api: https://api.agent-zone.ai/api/v1/knowledge/search?q=Cloud+Migration+Strategies%3A+The+7+Rs+Framework
---


# Cloud Migration Strategies

A company does not "migrate to the cloud" -- it migrates dozens or hundreds of applications, each with different characteristics, dependencies, and risk profiles. The 7 Rs framework provides vocabulary for per-workload decisions, but selecting the right R requires understanding the application, its dependencies, and the organization's tolerance for change.

## The 7 Rs

### Rehost (Lift and Shift)

Move the application to cloud infrastructure with minimal changes. A VM on-premises becomes an EC2 instance. OS, application code, and configuration remain the same.

**When to rehost:** the application works and the business will not invest in changing it; you face a hard deadline (data center lease expiring, hardware EOL); the application will be retired within 1-2 years.

```bash
# AWS Application Migration Service workflow
# 1. Install replication agent on source server
sudo python3 aws-replication-installer-init --region us-east-1

# 2. Agent continuously replicates disk (block-level) to AWS
# 3. Launch test instance from replicated data
# 4. Validate, then perform cutover: launch final instance, update DNS
```

**Cost of rehosting:** you bring your inefficiencies. An oversized on-premises server becomes an oversized EC2 instance. Plan a right-sizing exercise 3-6 months after rehosting.

### Replatform (Lift, Tinker, and Shift)

Make targeted optimizations during migration without changing core architecture. Replace self-managed components with managed services.

| On-premises component | Cloud managed service | Effort |
|---|---|---|
| Self-managed MySQL | Amazon RDS for MySQL | Low -- change connection string |
| Self-managed Redis | ElastiCache | Low -- change endpoint |
| NFS file shares | EFS or S3 | Medium -- change file paths |
| Self-managed load balancer | ALB/NLB | Medium -- reconfigure backends |

**When to replatform:** the application is mostly fine but self-managed infrastructure is painful. Moving PostgreSQL to RDS eliminates patching, backup management, and failover configuration.

### Repurchase (Drop and Shop)

Replace the application with a SaaS product. Custom-built HR systems, CRM tools, and ticketing systems are rarely competitive with purpose-built SaaS. The main challenge is data migration -- extracting data from the old system and mapping it to the new one's data model.

### Refactor (Re-architect)

Redesign to take full advantage of cloud-native capabilities: auto-scaling, serverless, event-driven architecture.

**When to refactor:** the application has a strong business case for cloud-native features and is a core differentiator worth the investment. **The critical mistake:** refactoring everything. Teams adopt "if we are migrating, let us do it right" and try to refactor every application simultaneously, multiplying risk and extending timelines. Refactor selectively. Rehost the majority.

### Retire

Turn off the application. Discovery during assessment frequently reveals applications that are unused, superseded, or serve negligible traffic. Every retired application is one fewer thing to migrate and maintain.

### Retain (Revisit Later)

Keep the application where it is. Hard dependencies on specialized hardware, regulatory requirements for on-premises data, or mid-project risk. Document why and set a review date.

### Relocate (Hypervisor-Level Lift and Shift)

Move VMware workloads to cloud-hosted VMware environments (VMware Cloud on AWS, Azure VMware Solution, Google Cloud VMware Engine) without modifying any VMs or their configurations.

## Migration Assessment

### Application Portfolio Discovery

Cloud providers offer discovery tools: AWS Application Discovery Service, Azure Migrate, and Google Cloud Migrate. These collect CPU, memory, disk, and network utilization over weeks for right-sizing decisions.

### Assessment Criteria

| Factor | Questions | Strategy Impact |
|---|---|---|
| Business criticality | Revenue impact of downtime? | High -> conservative (rehost) |
| Technical complexity | Custom middleware? Proprietary protocols? | High -> rehost or retain |
| Compliance | PCI, HIPAA, data residency? | May constrain region or strategy |
| Dependencies | What connects to it? What does it connect to? | Coupled apps migrate together |
| Team capacity | Cloud skills? Bandwidth? | Low -> rehost, High -> replatform |
| Age | End-of-support OS or runtime? | Legacy -> rehost, then plan modernization |

### Dependency Mapping

Applications do not exist in isolation. Migrating application A without its dependency on database B and messaging system C means A does not work in the cloud.

Organize dependencies into migration groups -- sets of applications that must migrate together due to latency-sensitive connections. Applications communicating only via APIs (tolerant of 10-50ms latency increases) can migrate independently with temporary cross-network connectivity.

## Cutover Planning

The cutover is the highest-risk moment. Everything before it is preparation.

### Blue-Green Cutover

Run old and new environments simultaneously, then switch traffic:

```
Phase 1: Both running, traffic on old
Phase 2: DNS cutover to new (TTL: 60s, reduced 48h prior)
Phase 3: Validation period (hours to days), monitor error rates
Phase 4: Decommission old after validation
```

### Cutover Checklist

```markdown
## Pre-Cutover
- [ ] Final data sync verified (replication lag < 1s)
- [ ] DNS TTLs reduced to 60 seconds (48h ago)
- [ ] Rollback procedure documented and reviewed
- [ ] Monitoring dashboards ready for both environments

## Cutover
- [ ] Stop writes to old environment
- [ ] Verify final sync completes
- [ ] Switch DNS to new environment
- [ ] Run smoke tests, monitor error rates 15 minutes
- [ ] Decision: proceed or rollback

## Post-Cutover
- [ ] Monitor performance vs baseline for 7 days
- [ ] Verify integrations and scheduled jobs
- [ ] Confirm backups running on new environment
```

### Data Cutover

**Zero-downtime:** set up replication from old to new database. At cutover, pause briefly, verify sync, switch connection string. Seconds of downtime.

**Maintenance window:** schedule downtime, dump database, restore to new environment, switch connection. Minutes to hours depending on volume.

**Dual-write:** application writes to both databases during transition. Eliminates downtime but introduces consistency risks. Use only when zero downtime is mandatory and replication is not feasible.

## Rollback Strategies

Every cutover needs a rollback plan with pre-defined triggers.

**DNS rollback:** change DNS back to the old environment. With 60-second TTLs, clients switch in 2-3 minutes. Keep the old environment warm for the entire validation period.

**Database rollback complication:** if the new environment accepted writes after cutover, those writes exist only in the new database. Mitigate by continuing reverse replication during validation, or implementing a write log for replay.

### Rollback Triggers

Define before cutover, not during the crisis:

- Error rate exceeds 5% above pre-cutover baseline
- P99 latency exceeds 3x baseline
- Any data integrity check fails
- Payment processing failure rate exceeds 0.1%

## Migration Wave Planning

Execute large migrations in waves ordered by risk:

**Wave 1 (low risk):** internal tools, dev environments, static sites. Proves the process without business impact.

**Wave 2 (medium risk):** standard web applications, APIs with clear dependency maps, good test coverage.

**Wave 3 (high complexity):** core business applications, databases with complex replication, many dependencies.

**Wave 4 (deferred):** retained applications requiring further analysis.

Each wave should take 2-4 weeks including planning, execution, and validation. The pattern across all successful migrations: start small, prove the process, build confidence, then accelerate. Teams that attempt a big-bang migration of all workloads simultaneously discover their unknowns in production, at scale, with no fallback.