How to migrate a website to a new host without downtime

To migrate a website to a new host without downtime, you run both servers side by side: the old one keeps serving visitors while you build, sync and test the new one, and only then do you point DNS at it. Two things make the switch invisible to users. Lowering the DNS TTL in advance means the change spreads in minutes rather than hours, and keeping the old server alive afterwards means anyone still on the old IP gets a working site. This is the checklist I follow for every server and WordPress move, including how to protect your search rankings.

Website migration checklist: plan before you touch anything

Most failed migrations fail on something nobody wrote down. Before provisioning the new server, I inventory the old one:

• Software versions — PHP, Node or Python version, web server, database engine and version. Moving from MySQL 5.7 to 8.0 or PHP 7.4 to 8.3 in the same step is a separate project, not a detail.
• Everything that runs on a schedule — crontab -l for every user, systemd timers, queue workers.
• Everything that sends email — contact forms, order notifications, password resets.
• Hardcoded IPs — allowlists at payment gateways, APIs and partners that only accept requests from the old server's IP.
• The full DNS zone — export every record, not just the A record.
• A URL list — crawl the site and export every indexable URL, so you can check them all afterwards.

Pick the cutover window using your analytics: the lowest-traffic hour of the week, on a day you will be around for the following 24 hours. Friday evening is not that day.

Lower the DNS TTL first

TTL (time to live) is how long resolvers are allowed to cache a DNS answer. If your A record has a TTL of 86400, a resolver that looked it up just before your change can keep sending visitors to the old IP for a full day. So the first step of any DNS TTL migration is to lower it to 300 seconds, and to do it early enough for the old, long TTL to expire everywhere. That means at least one full old-TTL period before cutover; I do it 24 to 48 hours ahead.

# Check the TTL resolvers are currently seeing
dig +noall +answer example.com A
dig +noall +answer www.example.com A

# example.com.   86400   IN   A   198.51.100.20   <- lower this to 300

If your domain is proxied through Cloudflare, you get an easier path: visitors only ever see Cloudflare's IPs, so changing the origin IP in the dashboard takes effect across the edge almost immediately regardless of TTL. That is one of several reasons I put sites behind Cloudflare before a move. Changing nameservers is a different matter: it can take up to 48 hours, so I never combine it with a host move. If DNS itself feels like the risky part, that is exactly what my DNS management service handles.

Build the new server and sync the data

Build the new server to match the inventory, then copy files and data while the old site stays live. For files, rsync is the right tool because you can re-run it and it only transfers what changed:

# Initial copy (run from the new server)
rsync -aHAX --numeric-ids --info=progress2 \
  deploy@old-server:/var/www/example.com/ /var/www/example.com/

# Database: consistent dump without locking InnoDB tables
ssh deploy@old-server "mysqldump --single-transaction --routines --triggers example_db | gzip" \
  | gunzip | mysql example_db

For PostgreSQL, use pg_dump -Fc and pg_restore. For a large or very busy database, set up replication from old to new instead, so the final cutover only needs replication to catch up rather than a full dump.

Sort out TLS before cutover, not after. If you wait for DNS to switch before requesting a Let's Encrypt certificate, the first visitors get a certificate error. Either copy the existing certificate across, or issue a new one with a DNS-01 challenge, which does not need the domain pointing at the new server.

Test the new server through your hosts file

This is the step that makes a no-downtime migration possible: you browse the real domain on the new server, with valid HTTPS, while everyone else still sees the old one. Point the domain at the new IP in your own hosts file only.

# macOS / Linux: /etc/hosts
# Windows:       C:\Windows\System32\drivers\etc\hosts  (edit as Administrator)
203.0.113.50   example.com www.example.com

Or test from the command line without editing anything, using curl's --resolve flag:

curl -sI --resolve example.com:443:203.0.113.50 https://example.com/ | head -5

Then go through the site properly: log in, submit every form, place a test order, upload an image, check that emails arrive, and trigger the cron jobs by hand. Compare page load times too. A new server that is slower than the old one is a problem to fix now, not after cutover.

Cutover: moving to the new host without downtime

Anything written to the old server after your last sync is lost unless you handle it. For a brochure site that is nothing. For a store, a membership site or anything with a login, you need a short freeze window:

1. Put the old site into maintenance mode, or disable checkout and comments, so nothing new is written.
2. Run a final rsync and database sync. Because the heavy lifting was done earlier, this usually takes minutes.
3. Switch the A and AAAA records to the new server. Do not forget www and any other subdomains.
4. Take the new site out of maintenance mode.
5. On the old server, proxy all requests to the new one, so visitors on stale DNS still write to the new database.

# On the OLD server, after cutover: forward everything to the new one
location / {
    proxy_pass https://203.0.113.50;
    proxy_set_header Host $host;
    proxy_ssl_server_name on;
    proxy_ssl_name $host;
}

That last step is what turns "mostly no downtime" into genuinely no downtime. Watch the access log on the old server; once requests drop to zero, the move is complete.

Keep a rollback plan

Decide before cutover what would make you roll back and how. Because the TTL is still at 300 seconds, rolling back is simply pointing DNS at the old IP again. The catch is data: any orders or signups made on the new server after cutover must be copied back. That is why I keep the old server untouched, apart from the proxy, for at least a few days, and only cancel it after a full week of normal traffic. Once everything is stable, raise the TTL back to a normal value such as 3600.

Keep your SEO rankings through the migration

A pure host move, with the same domain and the same URLs, is invisible to Google when it is done well. The ranking losses I get called in to fix almost always come from one of these:

• A staging noindex leaking into production. Check robots.txt, the X-Robots-Tag header and the WordPress "Discourage search engines" setting on the new server.
• Changed URLs without redirects. If any paths change, map every old URL to its new one with a 301. Crawl your saved URL list against the new site and fix every 404.
• Lost trailing-slash or www rules. These lived in the old server's config and are easy to leave behind.
• Extended downtime or 5xx errors, which Google notices and responds to by crawling less.

In Google Search Console, a domain property is not affected by changing hosts. Resubmit the sitemap after cutover, then watch the Pages and Crawl stats reports for a couple of weeks. If you are also changing the domain name, that is a different kind of migration and needs the Change of Address tool as well as site-wide 301 redirects.

A careful migration is mostly preparation and patience. If you would rather not risk your live site on it, I handle the whole move, from inventory to rollback plan, through my server migration service, or with the WordPress-specific details covered in WordPress migration. After the move, my guide to fixing Cloudflare 522 errors is worth bookmarking, since a firewall on the new server is the most common post-migration surprise. Each website and server migration gets a fixed price agreed in writing before I start.

Frequently asked questions