Migrating a WordPress site to a new host without downtime

Switching hosting providers is a routine event in a WordPress site’s life: a contract ending, a need for more performance, a move to self-hosting. The risk almost never comes from copying the files themselves, but from the DNS cutover and the order in which the steps are carried out. A well-prepared migration comes down to a handful of settings made several days ahead, not on the day itself.

#Why the DNS cutover is the breaking point

Every DNS record carries a lifetime, the TTL (Time To Live), expressed in seconds. Until that period expires, intermediate DNS resolvers — those of internet providers, browsers, corporate caches — keep answering with the old IP address. With a default TTL of 86,400 seconds (24 hours), some visitors can keep hitting the old server for a full day after the switch, which becomes a problem as soon as the old server is shut down or content starts to diverge between the two environments.

#Getting the new host ready before copying anything

Before moving a single file, the new environment needs to be ready to receive the site under conditions equal to or better than the existing one: at least the same PHP version, the same active extensions, a TLS certificate already in place for the final domain name. On a self-hosting panel like the one already covered for self-hosting WordPress with CloudPanel, this step is limited to creating the site and its certificate before any copying. Provisioning this environment ahead of time makes it possible to test the server configuration (URL rewriting, PHP memory limits, caching setup) independently from migrating the content, keeping configuration problems separate from data problems.

#Syncing files and the database without mistakes

The copy runs as two separate flows: files via rsync or an SFTP transfer, the database via a SQL export. WP-CLI makes this step noticeably easier on a self-hosted server, particularly for replacing URLs stored in serialized fields, which generic search-and-replace tools often corrupt.

# On the old server: a clean database export
wp db export backup.sql --add-drop-table

# Copy the files, excluding cache and logs
rsync -avz --exclude 'wp-content/cache' --exclude '*.log' \
  ./ user@new-server:/var/www/site/

# On the new host: import and rewrite the URLs
wp db import backup.sql
wp search-replace 'https://old-domain.tld' 'https://new-domain.tld' \
  --all-tables --precise

Choosing wp search-replace over a plain text replacement avoids breaking the serialized PHP arrays and objects WordPress stores in certain fields (widgets, theme options, page-builder data): a naive replacement changes a string’s length without updating the character count that precedes it, silently corrupting the data.

#Flipping the DNS and checking before shutting off the old server

Once the final sync is done, updating the DNS record triggers the gradual shift of traffic. This is the moment to watch both servers’ access logs in parallel: a gradual drop in traffic on the old one and a matching rise on the new one confirm normal propagation. Testing the site from several networks (mobile, fixed line, VPN) gives a more accurate picture of what visitors actually see than testing from a single machine.

Lowering the TTL to 300 seconds three days before the cutover shrinks the DNS propagation window to a few minutes, versus several hours with the default value of 86,400 seconds.

#Common pitfalls of a poorly prepared migration

Three mistakes come up most often. The first is changing the DNS before testing the site on the new host: without a cutover, a test using the local hosts file (temporarily pointing the domain name to the new IP address from a single machine) validates rendering and functionality without exposing a still-unstable site to the public. The second is forgetting hardcoded URLs inside third-party plugins: page builders, form plugins, or payment services sometimes store the old address outside the tables covered by wp search-replace --all-tables, which means also checking configuration files specific to those plugins. The third involves scheduled tasks (WordPress cron or system cron): an automated backup or a bulk email job still configured to fire on the old server can keep running in duplicate for several days if nobody remembers to disable it.

A hosting contract ending on a fixed date adds another constraint: it’s better to schedule the DNS cutover several days before the contract’s expiry rather than on the day itself, to keep a safety margin if something unexpected delays the final check.

#Cleaning up and monitoring after the migration

Once the cutover is confirmed, third-party services that explicitly point to the old IP address or the old server still need updating: backup bots, monitoring services, any application firewall, and the SPF records if outgoing email runs through the same host. This is also a good time to double-check the minimal hardening baseline on the new server, since default settings often differ from the old host’s. A Search Console check a few days after the migration helps catch a crawl error caused by a misconfigured TLS certificate or a rewrite rule forgotten on the new server.

#Key takeaways

The risk in a hosting migration almost never comes from copying the data, but from the DNS propagation delay and the order of operations around the cutover. Lowering the TTL several days ahead, validating the new environment before touching the DNS, and keeping the old server running for a week after the switch covers most of the downtime scenarios that are otherwise avoidable.

Further reading: the official documentation for the wp search-replace command.