The client's database had outgrown their server—200GB, millions of rows, 24/7 operations. They couldn't afford hours of downtime. We needed a migration that kept the app running throughout.

Our Approach: Dual-Write

1. Set up replication from old server to new server
2. Enable dual-write mode in the application—every write goes to both databases
3. Run a background job to sync any rows missed during replication lag
4. Verify row counts and checksums match
5. Switch read traffic to the new server
6. Disable dual-write, decommission old server

What Could Have Gone Wrong

Replication lag during peak hours caused a 12-minute window where some writes only hit the old server. Our sync job caught them. Without that verification step, we'd have lost data silently.

Total Downtime

Zero. Users never noticed. The entire migration took a weekend of careful monitoring, but the app stayed live the whole time.