How to migrate a website with zero downtime (step-by-step)

Most migration horror stories share one root cause: doing the copy and the cutover at the same time. Separate them — stage everything first, flip DNS last — and moving a website becomes a calm, reversible, five-phase procedure. Here is the exact playbook our engineers use.

Phase 0 — 48 hours before: lower your TTL

DNS TTL (time-to-live) tells resolvers how long to cache your records. If it’s sitting at 24 hours — many registrars’ default — some visitors will keep hitting your old server for a full day after you switch. So before anything else:

• Find the A/AAAA records for your domain (and www) at your DNS provider.
• Drop TTL to 300 seconds. Don’t change the value the records point to yet.
• Wait out the old TTL once so the short value propagates. This is why we start 48 hours early.

Phase 1 — a real backup

Not the host’s automatic one — your own, downloaded, verified:

• cPanel: Backup → “Download a Full Account Backup.” One archive with files, databases, mail and settings.
• Manual stacks: archive the web root and dump every database:

tar -czf site-files.tar.gz /var/www/example.com
mysqldump -u root -p --single-transaction exampledb > exampledb.sql

Open the archive and the SQL file and look inside. A backup you haven’t verified is a hope, not a backup.

Phase 2 — stage the copy on the new server

Restore everything onto the new host while the old site keeps serving traffic. On cPanel-to-cPanel moves the full-account archive restores in one step (this is also exactly what our free migration team does for you). Manual stacks: rsync the files, import the SQL, recreate config — PHP version, SSL, cron jobs, redirects.

rsync -azP site-files/ user@new-server:/var/www/example.com/
mysql -u appuser -p exampledb < exampledb.sql

Dynamic sites keep changing, so plan a final delta sync for cutover moment: re-run rsync (it only copies changes) and re-dump the database, or put WooCommerce/forums into maintenance mode for the last few minutes.

Phase 3 — preview the new server before DNS knows about it

The hosts-file trick lets your machine alone see the new server under the real domain name — the single most under-used step in migrations:

# /etc/hosts (macOS/Linux) · C:\Windows\System32\drivers\etc\hosts
203.0.113.42  example.com www.example.com

Now browse your site normally and test like a pessimist: homepage, deep pages, login, search, checkout, forms, uploads, HTTPS padlock, and the browser console for hard-coded old-IP references. Fix everything here, where mistakes cost nothing. Then remove the hosts entry.

Phase 4 — the cutover

• Pick a low-traffic window (your analytics know when).
• Run the final delta sync from Phase 2.
• Update the A/AAAA records to the new IP. With a 300-second TTL, the world moves over in minutes.
• Watch both servers’ access logs: traffic drains from old, rises on new. Verify with dig example.com +short or dnschecker.org.

Because the old server is untouched, your rollback plan is one line: point DNS back. That’s what zero-downtime really means — not that nothing can go wrong, but that nothing that goes wrong is expensive.

Phase 5 — the week after

• Confirm SSL renews on the new host and force-HTTPS works.
• Re-point any external services pinned to the old IP (payment webhooks, monitoring, mail SPF/DKIM if mail moved).
• Watch Search Console for crawl errors — same URLs on a faster server is an SEO non-event, often a small win via improved TTFB.
• Raise TTL back to 3600+ once stable. Keep the old account one more week, then close it.