How do we avoid split-brain during dual writes?

Keep one authoritative write path (Blue) until Green proves itself. Enable dual writes but never enable dual reads that alter state. Use idempotency keys for writes, keep CDC Blue->Green, and only flip write authority when you are ready to decommission Blue.

What if our workload uses sticky sessions?

Either migrate to stateless sessions first or scope canaries by session boundary and drain old sessions before increasing weights. A shared Redis session store can bridge the gap. Enable connection draining at the LB and set short session TTLs during the window.

Is DNS switching reliable enough?

Use DNS for coarse weighting and mesh/LB for fine-grained routing. Keep TTL low (30–60s), but rely on ALB/Istio weights and connection draining for precision. Test client caching assumptions ahead of time.

Can we do this without a service mesh?

Yes. Use Nginx/HAProxy/Envoy at the edge, ALB weighted target groups, and application flags. Mesh just gives you nicer knobs and telemetry.

How long should we keep dual writes on?

At least 24 hours of peak traffic with shadow reads and zero mismatches, plus a full business cycle if your data has daily/weekly quirks. Only then turn off dual writes and decommission the old store.

Guides · Oct 3, 2025 · 10 minute read

The Zero‑Downtime Migration Checklist You Actually Use at 2 A.M.

A battle-tested, step-by-step runbook with checkpoints, metrics, and tooling that keeps revenue flowing while you move a critical workload.

Back to all posts

The Zero‑Downtime Migration Checklist You Actually Use at 2 A.M.

Key takeaways

Implementation checklist