How I Plan a Zero-Downtime AWS Migration: Architecture, Cutover & Rollback Playbook

Phase 1: Network Foundation & Target VPC Provisioning

Before any data moves, establish a dedicated high-throughput, low-latency hybrid network connection between your existing data center (or source cloud) and AWS using AWS Direct Connect or redundant IPsec AWS Site-to-Site VPN tunnels with Transit Gateway.

# Test IPsec MTU and throughput before provisioning DMS replication instances
ping -M do -s 1422 <AWS_TRANSIT_GATEWAY_PRIVATE_IP>
iperf3 -c <AWS_TARGET_INSTANCE_IP> -P 8 -t 30

Ensure no overlapping CIDRs exist between the source private subnets and the destination AWS VPC. Provision multi-AZ subnets across at least three Availability Zones for resilience.

Phase 2: Continuous Data Replication with AWS DMS & CDC

Databases represent the highest-risk component of any migration. The goal is zero data loss (RPO = 0) and zero downtime (RTO < 1 min).

We configure AWS Database Migration Service (DMS) with Change Data Capture (CDC) utilizing source database transaction logs (WAL in PostgreSQL or Binary Logs in MySQL):

• Full Load + CDC: Captures baseline table data and continuously captures ongoing DML statements (INSERT, UPDATE, DELETE).
• Multi-AZ Replication Instance: Dedicated dms.r6i.2xlarge or larger with provisioned IOPS (gp3/io2) to prevent replication bottlenecking.
• Schema Conversion: Use AWS Schema Conversion Tool (SCT) beforehand to transform constraints, stored procedures, and triggers. Triggers must remain disabled on the target Aurora cluster during CDC load to avoid duplicate execution.

aws cloudwatch get-metric-data --metric-data-queries '[
  {
    "Id": "dms_lag",
    "MetricStat": {
      "Metric": {
        "Namespace": "AWS/DMS",
        "MetricName": "CDCLatencyTarget",
        "Dimensions": [{"Name": "ReplicationTaskIdentifier", "Value": "prod-db-migration-task"}]
      },
      "Period": 60,
      "Stat": "Maximum"
    }
  }
]' --start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ) --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

Phase 3: Stateless Container Workloads & Shadow Testing

Containerize application workloads and deploy them onto Amazon EKS or Amazon ECS Fargate. Before sending production user traffic:

1. Shadow / Mirror Traffic: Utilize Envoy / NGINX / Istio or AWS ALB traffic mirroring to clone 10-20% of incoming live read traffic to the AWS environment without returning responses to users.
2. Latency & Query Profiling: Verify that Amazon Aurora PostgreSQL handles real production query concurrency with acceptable cache hit ratios and execution times.
3. Circuit Breaker Verification: Test external API dependencies, Secrets Manager caching, and Redis cluster failovers.

Phase 4: The 60-Minute Cutover Window & Route 53 Canary

Execute cutover following this strict step-by-step procedure:

Phase 5: The Instant Rollback Playbook

A migration without a verified rollback plan is an unacceptable operational risk. By setting up reverse CDC replication (streaming from AWS Aurora back to the on-prem database immediately after cutover), the legacy environment remains a fully synchronized live replica.

If an unrecoverable defect occurs within the first 24 hours:

# 1. Flip Route 53 weighted record back to legacy endpoint (instant 60s propagation)
aws route53 change-resource-record-sets --hosted-zone-id Z1234567890   --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{"Name":"api.domain.com","Type":"A","SetIdentifier":"AWS","Weight":0,"TTL":60,"ResourceRecords":[{"Value":"198.51.100.10"}]}}]}'

# 2. Confirm traffic returns to legacy cluster with zero lost transactions