AWS Migration Strategies: The 7 Rs and Real-World Patterns

A fintech company spent $2M rehosting a legacy monolith to EC2, only to find their licensing costs tripled and latency spiked. They could have saved 60% by replatforming to a managed service. The 7 Rs framework exists to prevent these disasters — it's not academic theory, it's a decision tree that forces you to justify every migration choice. Most teams skip the analysis and default to 'lift and shift,' which works until it doesn't. This article breaks down each R with real failure modes and production patterns so you can pick the right strategy without burning cash.

Why the 7 Rs Still Matter in 2025

The 7 Rs of AWS migration—Retire, Retain, Rehost, Replatform, Refactor, Relocate, and Repurchase—remain the foundational decision framework. But in 2025, the nuance is everything. Teams that blindly pick 'Rehost' because it's fastest often regret it when they hit performance ceilings or cost overruns. The real skill is mapping each workload to the right R based on business criticality, technical debt, and operational maturity. For example, a legacy monolith with no automated tests is a terrible candidate for Refactor, no matter how much the team wants to modernize. Conversely, a stateless microservice with good CI/CD is wasted on Rehost—you're leaving cost and agility on the table. The key is to treat the 7 Rs as a decision tree, not a menu. Start with Retire: if the workload isn't adding value, turn it off. Then Retain: some things belong on-prem forever (compliance, latency). Only then evaluate the remaining Rs against a weighted scorecard of migration effort, operational risk, and future flexibility.

import json

workload = {
    "name": "legacy-payment-gateway",
    "is_used": True,
    "has_compliance_lock": False,
    "is_monolith": True,
    "has_tests": False,
    "can_containerize": True,
    "expected_lifespan_years": 3
}

def decide_r(w):
    if not w["is_used"]:
        return "Retire"
    if w["has_compliance_lock"]:
        return "Retain"
    if w["expected_lifespan_years"] < 2:
        return "Rehost"
    if w["is_monolith"] and not w["has_tests"]:
        return "Rehost"
    if w["can_containerize"] and w["has_tests"]:
        return "Replatform"
    return "Refactor"

print(json.dumps({"workload": workload["name"], "recommended_r": decide_r(workload)}))

Rehost: The 'Lift and Shift' Trap

Rehost is the most common migration pattern—and the most dangerous when applied blindly. The idea is simple: move your VM or bare-metal workload to EC2 with minimal changes. But 'minimal changes' often means you replicate your on-premises inefficiencies in the cloud. I've seen teams move a 16-core, 64GB RAM server to an equivalent EC2 instance, only to discover the application uses 5% CPU and 2GB RAM. They're paying for unused capacity. Worse, they miss the opportunity to right-size, auto-scale, or use spot instances. The real production pattern for Rehost is: snapshot the source, launch an equivalent instance, redirect traffic, and then immediately start a right-sizing exercise. Use AWS Compute Optimizer or a simple script to analyze utilization over a week. Then downsize. Also, don't forget networking: security groups, NACLs, and VPC endpoints must be recreated. A common failure mode is forgetting to update DNS TTLs, causing traffic to hit the old on-prem server for hours after cutover.

#!/bin/bash
# Analyze EC2 utilization and recommend right-sizing
# Requires AWS CLI and jq

INSTANCE_ID=$1

# Get average CPU over last 7 days
CPU_AVG=$(aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=$INSTANCE_ID \
  --start-time $(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --end-time $(date -u '+%Y-%m-%dT%H:%M:%SZ') \
  --period 3600 \
  --statistics Average \
  --output json | jq '.Datapoints | map(.Average) | add / length')

# Get max memory (requires CW agent)
MEM_MAX=$(aws cloudwatch get-metric-statistics \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=$INSTANCE_ID \
  --start-time $(date -u -d '7 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --end-time $(date -u '+%Y-%m-%dT%H:%M:%SZ') \
  --period 3600 \
  --statistics Maximum \
  --output json | jq '.Datapoints | map(.Maximum) | max')

echo "Instance $INSTANCE_ID: Avg CPU = $CPU_AVG%, Max Mem = $MEM_MAX%"

if (( $(echo "$CPU_AVG < 20" | bc -l) )); then
  echo "Recommend downsizing CPU"
fi
if (( $(echo "$MEM_MAX < 50" | bc -l) )); then
  echo "Recommend downsizing memory"
fi

Replatform: The Sweet Spot for Modernization

Replatform (or 'lift, tinker, and shift') is where you make a few cloud-optimizing changes without altering the core architecture. The classic example: moving from a self-managed MySQL on EC2 to Amazon RDS. You change the connection string, maybe tweak a few queries, and suddenly you get automated backups, patching, and Multi-AZ. But the trap is scope creep. Teams start refactoring the schema, adding read replicas, or rewriting stored procedures. That's no longer Replatform—it's Refactor, with all the risk and delay. The production pattern is: identify the minimal changes needed to run on a managed service. For RDS, that's typically: convert storage to EBS gp3, enable automated backups, and set up a maintenance window. For containers, it's: add a Dockerfile, create a task definition, and set up a load balancer. Do not touch the application logic. Measure success by reduced operational overhead, not by new features. A common failure mode is underestimating the effort to migrate data. For databases, use AWS DMS with ongoing replication to minimize downtime. For stateful applications, use a blue/green deployment with a data sync step.

resource "aws_db_instance" "migrated_db" {
  identifier = "app-db-replatformed"
  engine         = "mysql"
  engine_version = "8.0"
  instance_class = "db.t3.medium"
  allocated_storage = 100
  storage_type      = "gp3"
  
  db_name  = "appdb"
  username = "admin"
  password = var.db_password
  
  backup_retention_period = 7
  backup_window           = "03:00-04:00"
  maintenance_window      = "sun:05:00-sun:06:00"
  
  multi_az = true
  
  skip_final_snapshot = false
  final_snapshot_identifier = "app-db-final-snapshot-${formatdate("YYYY-MM-DD-hhmm", timestamp())}"
  
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  db_subnet_group_name   = aws_db_subnet_group.main.name
  
  lifecycle {
    ignore_changes = [
      password,
      snapshot_identifier,
    ]
  }
}

resource "aws_db_subnet_group" "main" {
  name       = "main"
  subnet_ids = var.private_subnet_ids
}

resource "aws_security_group" "rds_sg" {
  name        = "rds-sg"
  description = "Security group for RDS"
  vpc_id      = var.vpc_id
  
  ingress {
    from_port   = 3306
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = [var.app_subnet_cidr]
  }
}

Refactor: When to Rewrite (and When to Walk Away)

Refactor (or 're-architect') is the most expensive R, but sometimes it's the only path. You refactor when the existing architecture fundamentally cannot meet your requirements—scalability, resilience, or feature velocity. For example, a monolithic CRM that can't scale beyond 1000 concurrent users because of a shared database. Or a batch processing system that needs real-time streaming. But refactoring is a bet: you're trading current pain for future gain, and the payoff may take months or years. The production pattern is: start with a strangler fig pattern. Identify a bounded context (e.g., user authentication) and extract it as a microservice. Run both old and new in parallel, gradually shifting traffic. Use feature flags to control the rollout. Do not attempt a big-bang rewrite—it almost always fails. A common failure mode is underestimating data migration. When you split a monolith's database, you need to handle distributed transactions or eventual consistency. Use an outbox pattern or Saga to maintain data integrity. Also, refactoring requires strong automated tests. If your test coverage is below 70%, fix that first. Otherwise, you'll break things and not know until production.

import random
import time

# Simulate gradual traffic shift from monolith to microservice

def monolith_login(username, password):
    # Legacy implementation
    time.sleep(0.5)  # Simulate slow DB
    return {"token": "legacy-token", "user": username}

def microservice_login(username, password):
    # New implementation
    time.sleep(0.1)  # Fast
    return {"token": "new-token", "user": username}

# Feature flag: percentage of traffic to new service
NEW_SERVICE_PERCENT = 30  # Start with 30%

def login(username, password):
    if random.randint(1, 100) <= NEW_SERVICE_PERCENT:
        print("Routing to new microservice")
        return microservice_login(username, password)
    else:
        print("Routing to monolith")
        return monolith_login(username, password)

# Simulate 10 requests
for i in range(10):
    result = login(f"user{i}", "pass")
    print(f"Result: {result}")

Retire: The Easiest Migration Is Deletion

Retire is the most underused R. In every migration I've been part of, we found workloads that no one knew were running. They had no owners, no users, and no business value. Yet teams were afraid to turn them off because 'it might be important.' The production pattern is: run a discovery tool (e.g., AWS Application Discovery Service, or a simple script that queries your CMDB) to list all servers and their last login date, CPU usage, and network activity. Flag any server that hasn't had a user login in 90 days or has less than 1% CPU average. Then, contact the listed owner (if any) and ask: 'Can we turn this off for a week?' If no one complains, decommission it. If someone complains, you now know it's used. Document the decision. A common failure mode is keeping a server because 'we might need it for compliance.' But compliance requirements usually specify data retention, not server retention. Archive the data to S3 Glacier and turn off the server. Also, watch out for dependencies: a retired server might be a DNS server or a license server for other workloads. Map dependencies before pulling the plug.

#!/bin/bash
# Find EC2 instances with no recent login or low CPU
# Requires AWS CLI and jq

# Get all instances
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,Tags[?Key==`Name`].Value|[0],LaunchTime]' --output json | jq -c '.[][]' | while read instance; do
  INSTANCE_ID=$(echo $instance | jq -r '.[0]')
  NAME=$(echo $instance | jq -r '.[1] // "unnamed"')
  LAUNCH_TIME=$(echo $instance | jq -r '.[2]')
  
  # Get average CPU over last 30 days
  CPU_AVG=$(aws cloudwatch get-metric-statistics \
    --namespace AWS/EC2 \
    --metric-name CPUUtilization \
    --dimensions Name=InstanceId,Value=$INSTANCE_ID \
    --start-time $(date -u -d '30 days ago' '+%Y-%m-%dT%H:%M:%SZ') \
    --end-time $(date -u '+%Y-%m-%dT%H:%M:%SZ') \
    --period 86400 \
    --statistics Average \
    --output json | jq '.Datapoints | map(.Average) | add / length')
  
  # Check if CPU is below 1%
  if (( $(echo "$CPU_AVG < 1" | bc -l) )); then
    echo "Instance $INSTANCE_ID ($NAME) has avg CPU $CPU_AVG% - candidate for retirement"
  fi
done

Retain: When the Cloud Isn't the Answer

Retain means keeping a workload on-premises. It's not a failure—it's a strategic decision. Common reasons: data residency regulations (e.g., GDPR, HIPAA), latency requirements (e.g., real-time trading systems), or dependency on physical hardware (e.g., legacy mainframes). The production pattern is: for each workload, evaluate if the cloud can meet compliance and performance requirements. If not, retain it, but plan for eventual migration. For example, a bank might retain its core transaction system on-prem because of regulatory approval cycles, but move its customer portal to the cloud. The key is to avoid 'retain forever'—set a review cycle (e.g., every 6 months) to reassess. Cloud services evolve; a service that wasn't compliant last year might be now. Also, consider hybrid patterns: use AWS Outposts or VMware Cloud on AWS to get a consistent experience while retaining on-prem control. A common failure mode is retaining a workload because 'it's too hard to migrate.' That's a risk, not a reason. Quantify the cost of retaining (hardware refresh, data center space, staff) vs. migrating. Often, the cloud wins even with compliance overhead.

import json

workload = {
    "name": "core-banking-ledger",
    "latency_sla_ms": 5,
    "data_residency_required": True,
    "cloud_latency_ms": 10,  # Estimated cloud latency
    "compliance_ready": False  # No cloud service meets compliance yet
}

def should_retain(w):
    if w["data_residency_required"] and not w["compliance_ready"]:
        return True
    if w["cloud_latency_ms"] > w["latency_sla_ms"]:
        return True
    return False

print(json.dumps({"workload": workload["name"], "retain": should_retain(workload)}))

Relocate: The Kubernetes Migration Pattern

Relocate is the AWS term for moving workloads to a different AWS region or account, often as part of a migration from on-prem to AWS. But in practice, it's most commonly used for containerized applications moving to Amazon EKS or ECS. The pattern is: you have a Kubernetes cluster on-prem (or in another cloud) and you want to move it to AWS without changing the application. You use tools like AWS Migration Hub, CloudEndure, or simply re-deploy the manifests. The production challenge is networking and storage. On-prem Kubernetes often uses persistent volumes (PVs) backed by NFS or iSCSI. In AWS, you need to migrate to EBS or EFS. Use Velero or Restic to backup and restore PVs. Also, service discovery changes: on-prem DNS or Consul must be replaced with AWS Cloud Map or CoreDNS. A common failure mode is forgetting to update Ingress controllers and TLS certificates. Also, node groups: on-prem nodes might have custom kernel modules or GPU drivers. Ensure your EKS AMI supports them. The key takeaway: Relocate is not a lift-and-shift for containers—it requires careful mapping of storage, networking, and identity.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data-pvc
  namespace: production
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp3
  resources:
    requests:
      storage: 100Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: app-data-pv
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: gp3
  awsElasticBlockStore:
    volumeID: vol-0abcdef1234567890
    fsType: ext4

Repurchase: Moving to SaaS

Repurchase means replacing your custom or licensed software with a SaaS alternative. For example, moving from a self-hosted CRM to Salesforce, or from an on-prem email server to Microsoft 365. The production pattern is: evaluate if the SaaS offering meets 80% of your requirements. If yes, migrate. The remaining 20% can be handled via custom integrations or workflow adjustments. The trap is trying to make the SaaS tool do everything your old system did—that leads to expensive customizations and vendor lock-in. Instead, adapt your processes to the SaaS tool. A common failure mode is data migration. Exporting data from a legacy system is often messy: inconsistent formats, missing fields, duplicate records. Use ETL tools like AWS Glue or Matillion to clean and transform data. Also, plan for a parallel run period where both systems are active to validate data integrity. Repurchase can be the fastest path to modernization, but it requires organizational change management. Users will resist new interfaces. Invest in training and a phased rollout.

import pandas as pd
import json

# Simulate extracting legacy CRM data
legacy_data = pd.DataFrame({
    "contact_id": [1, 2, 3],
    "full_name": ["Alice Smith", "Bob Jones", "Charlie Brown"],
    "email": ["alice@example.com", "bob@example.com", "charlie@example.com"],
    "phone": ["555-0100", "555-0101", "555-0102"],
    "notes": ["VIP customer", None, "Prefers email"]
})

# Transform to Salesforce format
salesforce_data = legacy_data.rename(columns={
    "contact_id": "Id",
    "full_name": "Name",
    "email": "Email",
    "phone": "Phone",
    "notes": "Description"
})

# Handle missing values
salesforce_data["Description"] = salesforce_data["Description"].fillna("")

# Output as JSON for Salesforce bulk API
records = salesforce_data.to_dict(orient="records")
print(json.dumps(records, indent=2))

Real-World Migration Patterns: Strangler Fig and Parallel Run

Two patterns dominate successful migrations: the Strangler Fig (incremental replacement) and Parallel Run (side-by-side validation). The Strangler Fig is ideal for refactoring monoliths: you gradually replace components with microservices, routing traffic via a proxy or feature flags. The Parallel Run is for data migrations: you run both old and new systems simultaneously, compare outputs, and only cut over when they match. In production, combine them. For example, when migrating a payment system, run the new service alongside the old one, sending a copy of traffic to both. Compare the results. If they diverge, fix the new service. Once confidence is high, shift traffic gradually. A common failure mode is not having a rollback plan. Always keep the old system running until the new one has been stable for at least a week. Also, monitor both systems during the parallel run. Use tools like CloudWatch Logs Insights or a custom dashboard to compare error rates and latency. The key is to automate the comparison—manual checking doesn't scale.

import json
import hashlib

# Simulate comparing responses from old and new systems

def old_system(request):
    # Legacy implementation
    return {"status": "success", "transaction_id": "old-123"}

def new_system(request):
    # New implementation
    return {"status": "success", "transaction_id": "new-123"}

def compare_responses(old_resp, new_resp):
    # Compare relevant fields (exclude transaction_id if different)
    old_hash = hashlib.md5(json.dumps(old_resp, sort_keys=True).encode()).hexdigest()
    new_hash = hashlib.md5(json.dumps(new_resp, sort_keys=True).encode()).hexdigest()
    return old_hash == new_hash

# Simulate a request
request = {"amount": 100, "currency": "USD"}
old_resp = old_system(request)
new_resp = new_system(request)

if compare_responses(old_resp, new_resp):
    print("Responses match")
else:
    print(f"Mismatch: old={old_resp}, new={new_resp}")

Automation and Testing: The Non-Negotiables

No migration should be manual. Automate everything: infrastructure provisioning (Terraform, CloudFormation), configuration management (Ansible, Chef), and deployment (CI/CD pipelines). For testing, you need three layers: unit tests for code changes, integration tests for service interactions, and smoke tests for the migrated environment. A common failure mode is skipping smoke tests. After migration, run a suite of critical user journeys (login, search, checkout) to verify the system works. Also, test failure scenarios: what happens when an AZ goes down? Does your Multi-AZ setup actually fail over? Use AWS Fault Injection Simulator to test resilience. Another non-negotiable is rollback automation. Your migration script should have a --rollback flag that reverts all changes. Test the rollback in a staging environment before the real migration. Finally, monitor everything. Set up CloudWatch alarms for error rates, latency, and resource utilization. If something looks wrong, abort the migration. Better to delay than to break production.

name: Migration Smoke Tests

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Target environment'
        required: true
        default: 'staging'

jobs:
  smoke-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run smoke tests
        run: |
          # Test critical endpoints
          curl -f https://${{ inputs.environment }}.example.com/health || exit 1
          curl -f -X POST https://${{ inputs.environment }}.example.com/api/login \
            -H "Content-Type: application/json" \
            -d '{"username":"test","password":"test"}' || exit 1
          echo "Smoke tests passed"
      - name: Notify on failure
        if: failure()
        run: |
          echo "Smoke tests failed! Aborting migration."

Post-Migration: The First 30 Days

The migration isn't over when traffic is flowing. The first 30 days are critical for stabilization and optimization. Your checklist: (1) Monitor cost—set up budgets and alerts. Many teams see a spike because of data transfer costs or over-provisioned resources. (2) Performance—compare latency and throughput to on-prem baselines. If something is slower, investigate. (3) Security—run a vulnerability scan and review IAM policies. (4) Backup—verify that backups are running and restorable. (5) Documentation—update runbooks, architecture diagrams, and incident response plans. A common failure mode is assuming the cloud is 'self-healing.' It's not. You need to configure auto-scaling, health checks, and recovery procedures. Also, schedule a post-mortem 2 weeks after migration. What went well? What could be improved? Document lessons learned for the next migration. Finally, celebrate. Migrations are hard. Acknowledge the team's effort.

#!/bin/bash
# Post-migration checklist automation

echo "=== Post-Migration Checklist ==="

# 1. Cost check
aws budgets describe-budgets --account-id $AWS_ACCOUNT_ID --query 'Budgets[0].BudgetLimit.Amount' --output text

# 2. Performance check (example: API latency)
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApiGateway \
  --metric-name Latency \
  --dimensions Name=ApiName,Value=my-api \
  --start-time $(date -u -d '1 hour ago' '+%Y-%m-%dT%H:%M:%SZ') \
  --end-time $(date -u '+%Y-%m-%dT%H:%M:%SZ') \
  --period 300 \
  --statistics Average \
  --output json | jq '.Datapoints | .[0].Average'

# 3. Security scan (using AWS Inspector)
aws inspector2 list-findings --query 'findings[?severity==`HIGH`]' --output json | jq 'length'

# 4. Backup verification
aws backup list-recovery-points-by-backup-vault --backup-vault-name Default --query 'RecoveryPoints[0].Status' --output text

echo "Checklist complete. Review any issues."

Common Failure Modes and How to Avoid Them

Every migration has failure modes. Here are the top five I've seen: (1) 'Big Bang' cutover—trying to move everything at once. Always use incremental patterns. (2) Insufficient testing—skipping load testing or security scans. (3) Ignoring data migration complexity—data is always messier than you think. (4) Underestimating network latency—cloud is not on-prem. Test latency-sensitive applications early. (5) Lack of rollback plan—assume the migration will fail and plan for it. To avoid these, follow the principle of 'fail fast, fail small.' Migrate one workload at a time. Test each step. Have a rollback script ready. And communicate with stakeholders. A migration that surprises the business is a failed migration. Also, don't forget people. Your ops team needs training on cloud services. Your developers need to understand new deployment pipelines. Invest in training before the migration, not after.

risks = [
    {"name": "Big Bang cutover", "mitigation": "Use incremental migration (strangler fig)"},
    {"name": "Insufficient testing", "mitigation": "Automate smoke tests and load tests"},
    {"name": "Data migration complexity", "mitigation": "Run parallel systems and compare outputs"},
    {"name": "Network latency", "mitigation": "Test latency-sensitive apps early, consider Direct Connect"},
    {"name": "No rollback plan", "mitigation": "Automate rollback and test it in staging"},
]

for risk in risks:
    print(f"Risk: {risk['name']} -> Mitigation: {risk['mitigation']}")