Moving a site to a new server with zero downtime

Most server migrations fail the same way: DNS gets switched first, and everyone hopes things work. I flip the order. No record changes until the new server is fully ready and tested.

#1. Lower the TTL in advance

DNS records stay cached by resolvers and visitors' machines for the length of their TTL. If the TTL is 24 hours, a change can take a day to reach everyone.

At least a day before the move, I lower the TTL on the relevant records to 300 seconds. By migration day, the old value has expired.

#2. Copy the files

rsync only sends what changed when you run it again, so you can take the first copy well ahead of time:

rsync -azP --delete /var/www/site/ deploy@new-server:/var/www/site/

#3. Move the database

For PostgreSQL, a custom-format dump is small and flexible to restore:

pg_dump -Fc site_db | ssh deploy@new-server "pg_restore --no-owner -d site_db"

On MySQL you'd do the same with mysqldump --single-transaction.

#4. Test without touching DNS

Put the new server's address in your own machine's hosts file and the domain points to the new server for you alone:

203.0.113.24  example.com www.example.com

Logins, forms, payments, emails. I try everything one by one. You can also get the SSL certificate at this stage using DNS validation.

#5. Sync the last delta and switch

I open a short maintenance window, stop writes, and run rsync and the database transfer one final time. Then I point the DNS records at the new address. Thanks to the low TTL, traffic moves over within minutes.

#6. Don't shut the old server down right away

I keep the old server running for at least a week. If something goes wrong, switching DNS back is a single step. Once all is well, I raise the TTL again and retire the old server.