Here’s a crisp 3-part plan using a blue-green (best-practice) cutover on AWS EKS.
1) Prep (Build & Prove)
Build green: Create EKS + StorageClass (gp3/io2), deploy MongoDB (Helm/Operator, StatefulSet). Backups: Configure PBM → S3 (Object Lock on). Take/verify full backup on-prem. Restore & sync: Restore backup to green. Start live sync (mongosync/mongomirror) from on-prem to green. Readiness checks: Replication healthy, auth/roles seeded, slow queries tuned, Grafana alerts clean.
2) Migrate (Keep Data In Sync)
Dual run: Keep on-prem = blue, EKS = green. Continuous sync: Oplog tailing to green; lag < few seconds. App prep: App supports two URIs; set short DNS/TTL; bake feature flags for DB URI switch. Dry runs: Read-only test on green; run canary jobs; compare row counts and key metrics.
3) Cutover (Switch & Confirm)
Freeze window (minutes): Pause writes on blue (brief app maintenance or queue writes). Final catch-up: Wait lag → 0; lock + snapshot; stop sync. Flip traffic: Update Route53/DNS or Secret/ConfigMap to green Mongo URI; roll app pods. Validate: Writes/reads OK, dashboards green, error rate normal. Decommission: Keep blue read-only for 24–72h; if all good, turn off sync and retire blue.
Rollback (fast path): If issues post-flip, point app back to blue URI, re-enable sync, investigate, retry later.