{"id":4341,"date":"2026-07-16T17:20:43","date_gmt":"2026-07-16T17:20:43","guid":{"rendered":"https:\/\/ownwebservers.com\/kb\/?p=4341"},"modified":"2026-07-17T20:40:15","modified_gmt":"2026-07-17T20:40:15","slug":"zero-downtime-website-migration-rsync-dns-ttl","status":"publish","type":"post","link":"https:\/\/ownwebservers.com\/kb\/zero-downtime-website-migration-rsync-dns-ttl\/","title":{"rendered":"Zero-Downtime Website Migration: A Complete rsync and DNS TTL Playbook"},"content":{"rendered":"\n

There’s an old-school way to migrate a live site: pick a dead-quiet Tuesday at 3 a.m., slap up a maintenance page, and hope DNS propagates before anyone important notices. That still works fine for a hobby blog. For anything with paying customers or active sessions, it’s a needless gamble. Done properly, a zero downtime migration<\/a> lets you move a production site \u2014 files, database, mail routing, cron jobs, all of it \u2014 without a single visitor noticing anything happened.<\/p>\n\n\n\n

Copying files isn’t the hard part. Rsync does that job reliably and has for two decades. What actually trips people up is coordinating three clocks that don’t run in sync: when your data is genuinely caught up between servers, when DNS resolvers around the world actually pick up the new IP, and when it’s safe to finally walk away from the old box. Get that sequencing wrong and you’ll serve stale pages, drop form submissions into a void, or \u2014 worse \u2014 end up with two databases quietly diverging while traffic splits between them.<\/p>\n\n\n\n

This guide walks through an rsync-based server migration paired with proper DNS TTL prep ahead of time. That combination is what actually makes a live website migration possible without ever hanging a “back in 20 minutes” sign on the door.<\/p>\n\n\n\n

Pre-Migration Planning and Assessment<\/h2>\n\n\n\n

Auditing the Current Server Environment<\/h3>\n\n\n\n

Before you touch anything, inventory the source server top to bottom. PHP\/Python\/Node versions, installed extensions, every user’s cron jobs (not just root’s \u2014 run crontab -l<\/code> per user), mail configuration, SSL certificate details, and any firewall rules that aren’t already staring at you from the vhost config. I’ve been burned by a “simple” WordPress migration once where a cron job was quietly syncing inventory from a third-party API \u2014 nobody remembered it existed until orders stopped updating three days later and someone asked why stock counts were frozen.<\/p>\n\n\n\n

Check connection counts and write patterns on the database too. A high-write OLTP workload needs a very different cutover approach than a mostly-static brochure site.<\/p>\n\n\n\n

Choosing the Destination Server and Matching Software Versions<\/h3>\n\n\n\n

Match major software versions on the new server before you move a single byte \u2014 same PHP minor version, same MySQL\/MariaDB flavor, same web server, and if it’s Apache, the same module set. Version drift is probably the single most common reason migrations “work in staging” and then quietly break after cutover. If an upgrade is part of the plan, do it as its own project afterward and test it properly \u2014 don’t bundle a version jump with a server move. Change one variable at a time, always.<\/p>\n\n\n\n

Creating a Migration Timeline and Rollback Plan<\/h3>\n\n\n\n

Write actual timestamps down, not just a vague list of steps. Something like: TTL dropped at T-48h, first full rsync at T-24h, incremental syncs every few hours after that, final sync plus DB dump at T-0, DNS cutover at T-0, source server frozen read-only until T+72h. And decide your rollback trigger in advance \u2014 “if error rate exceeds X% in the first hour, revert DNS” \u2014 before you’re mid-cutover and tempted to just wing it.<\/p>\n\n\n\n

Lowering DNS TTL in Advance<\/h2>\n\n\n\n

Understanding TTL and Resolver Caching Behavior<\/h3>\n\n\n\n

Resolvers cache your A\/AAAA records for as long as your TTL tells them to, and they couldn’t care less about your migration schedule. Plenty of ISP resolvers are also flat-out non-compliant and hold onto records longer than instructed \u2014 which is exactly why the overlap window after cutover isn’t optional, it’s insurance.<\/p>\n\n\n\n

Setting TTL to 300 Seconds 24-48 Hours Ahead<\/h3>\n\n\n\n

Drop your TTL down to 300 seconds (5 minutes) at least 24-48 hours before cutover. That gives the old, longer TTL time to fully age out of caches everywhere before you actually need fast propagation to matter. Don’t lower the TTL and migrate the same day \u2014 you’ll still be fighting cached records left over from the previous, higher TTL. Verify the change has actually propagated with dig +trace yourdomain.com<\/code> run from a couple of different networks, not just the office Wi-Fi.<\/p>\n\n\n\n

Building and Syncing the Destination Server<\/h2>\n\n\n\n

Get everything that isn’t tied to an IP address configured well ahead of time \u2014 firewall rules, vhost configs, PHP-FPM pools, SSL certs. If you’re on Let’s Encrypt, you can often knock out DNS-01 or even HTTP-01 validation against a staging subdomain before cutover day, or just carry over the existing cert and key if it came from a commercial CA. The goal is that by cutover, the only things left to flip are IP-bound: DNS records, and maybe a few outbound whitelist entries on third-party services.<\/p>\n\n\n\n

Kick off your initial full sync well in advance:<\/p>\n\n\n\n

rsync -avz --delete \/var\/www\/site\/ user@newserver:\/var\/www\/site\/<\/code><\/pre>\n\n\n\n
-a<\/code> preserves permissions, ownership, and timestamps; -z<\/code> compresses data in transit; --delete<\/code> keeps the destination clean instead of accumulating orphaned files as the source keeps changing underneath you. Run this early, then follow up with incremental syncs every few hours as cutover approaches \u2014 each pass only has to move a shrinking delta, which is what keeps your final pre-cutover sync short and boring.<\/p>\n\n\n\n
Staging Validation Before DNS Ever Changes<\/h3>\n\n\n\n
Add a temporary hosts file entry on your workstation, or point a staging subdomain at the new server’s IP, and actually put the site through its paces there \u2014 database connectivity, file upload permissions, cron execution, outbound mail, session handling. This is where you find the missing PHP extension or the config file with a hardcoded IP address baked into it, while it’s still nobody’s emergency.<\/p>\n\n\n\n
The Cutover Sequence<\/h2>\n\n\n\n
When the moment arrives, order matters \u2014 don’t improvise this part:<\/p>\n\n\n\n
    \n
  1. Flip the application into brief read-only or maintenance mode on the source \u2014 seconds, not hours, just long enough to cover the write-sensitive final steps.<\/li>\n\n\n\n
  2. Take a final database export with mysqldump --single-transaction --routines --triggers dbname > final.sql<\/code>, which gets you a consistent snapshot without locking tables on an InnoDB database.<\/li>\n\n\n\n
  3. Import that dump on the destination, then run one last rsync pass with checksum verification:<\/li>\n<\/ol>\n\n\n\n
    rsync -avz --checksum --delete \/var\/www\/site\/ user@newserver:\/var\/www\/site\/<\/code><\/pre>\n\n\n\n
    --checksum<\/code> matters here because timestamp comparisons alone can lie after multiple incremental syncs across different filesystems \u2014 this gives you byte-for-byte certainty instead of a guess.<\/p>\n\n\n\n
      \n
    1. Update DNS to point at the new server’s IP.<\/li>\n\n\n\n
    2. Take the source out of maintenance mode, but leave it running, fully intact, untouched.<\/li>\n<\/ol>\n\n\n\n
      Post-Cutover: Monitoring and the Safety Window<\/h2>\n\n\n\n
      Leave the source server running, unchanged, for 48-72 hours minimum. This isn’t foot-dragging \u2014 it’s your rollback insurance and your buffer against resolvers that ignore TTLs entirely. Tail the access logs on both servers side by side:<\/p>\n\n\n\n
      tail -f \/var\/log\/nginx\/access.log<\/code><\/pre>\n\n\n\n
      Watch request volume on the old server taper off toward zero. Some poorly-behaved ISP resolvers will keep dribbling a bit of traffic its way for days. Don’t decommission it until that trickle has genuinely stopped \u2014 not just slowed down.<\/p>\n\n\n\n
      Best Practices<\/h2>\n\n\n\n