How I Migrated 2TB of S3 Data and an Entire Kubernetes Cluster Without Losing a Single Night's Sleep

When the client said 'we need to move everything to a new AWS account with zero downtime', I made a very large cup of coffee and started writing a very detailed plan.

The Problem

• •2TB of S3 data across 12 buckets
• •A Kubernetes cluster running 30+ microservices
• •A PostgreSQL database with 800GB of data
• •Zero tolerance for downtime during business hours

The Strategy

Phase 1: S3 Data Sync (4 weeks before cutover)

Use aws s3 sync with --delete flag running on a continuous cron to build a live mirror of all buckets in the destination account. By the time you flip, the delta is minutes not weeks.

aws s3 sync s3://source-bucket s3://dest-bucket \
  --source-region eu-west-1 \
  --region eu-west-2 \
  --delete

Phase 2: Cluster Rebuild

Build the destination cluster in parallel using the same IaC (Terraform + Helmfile). Deploy all services in read-only mode pointing to the old database.

Phase 3: Database Migration

Set up AWS DMS for continuous replication. Test queries against the replica for two weeks before cutover.

Phase 4: The Cutover

1. Enable maintenance mode on the application (5 minutes max)
2. Final S3 sync
3. Promote the database replica
4. Update all environment variables in the new cluster
5. Flip DNS
6. Monitor for 30 minutes
7. Disable maintenance mode

Total downtime: 4 minutes 37 seconds.

What Almost Went Wrong

The S3 event notifications were pointing to Lambda functions in the old account. We caught it in dry-run. Build a dependency map before you start — not during.