Switching Hosts Without Downtime: The Cutover Playbook

Migrating hosts is one of those tasks that looks simple until something goes sideways mid-transfer: a form submission that vanishes, a DNS change that takes six hours to propagate, or a database dump that misses the last hour of orders. None of that is inevitable. With a bit of sequencing, you can move a live WordPress site to a new host with no visible downtime at all. This is the playbook.

Start with a pre-migration audit

Before you touch DNS or copy a single file, take stock of what actually needs to move. A rushed migration usually fails because something was assumed rather than checked.

• Inventory plugins and themes. Run wp plugin list and wp theme list on the current site and save the output. You want a clean reference for what should exist after the move.
• Check PHP version compatibility. If you are moving to a host running PHP 8.3 with OPcache (a solid default for current WordPress), confirm your plugins do not throw deprecation warnings on that version. Test in staging first if anything looks old.
• Note any server-level customizations. Cron jobs, custom .htaccess or LiteSpeed rewrite rules, cache exclusions, and any redirects that live outside WordPress itself all need to be replicated, not assumed to “just come along” with a database export.
• Identify dynamic, time-sensitive content. Forms, e-commerce orders, membership signups, and comment activity are the things most likely to be lost if your final sync misses a window. Know where they live in the database so you can re-check them after cutover.
• Document DNS records. Pull the full record set (A, AAAA, MX, TXT, CNAME) from your current DNS provider before you change anything. If you are moving to a setup behind Cloudflare, plan for orange-clouded proxying on the records that need edge caching and WAF protection, and keep MX records unproxied since Cloudflare does not proxy mail traffic.

Stage your DNS TTL in advance

The single biggest lever for a low-downtime migration is DNS time-to-live (TTL), and it needs to be lowered well before the cutover, not during it. TTL controls how long resolvers cache your DNS answers; a high TTL (say, 24 hours) means a chunk of the internet keeps hitting your old server long after you have flipped the switch.

1. At least 24 to 48 hours before the move, log into your current DNS provider and drop the TTL on the records you plan to change (typically the root A record and any relevant CNAMEs) down to something short, like 300 seconds.
2. Wait out the old TTL fully before proceeding. If your previous TTL was a full day, you need to wait that full day for the shorter TTL to actually take effect across resolvers.
3. Only after the short TTL has propagated should you prepare the actual cutover. This way, when you do change the record to point at the new host, most of the internet picks up the change within minutes instead of hours.
4. After the migration is confirmed stable, raise the TTL back to a normal value (an hour or more) to reduce unnecessary DNS lookup overhead going forward.

If your new host sits behind Cloudflare, remember that Cloudflare’s own proxy layer adds a further benefit here: once records are proxied (orange cloud), the visible IP address stays the same to visitors even if your origin changes behind the scenes, which further insulates users from any DNS propagation lag on future changes.

Set a content freeze window

The other classic failure mode is data drift: content gets created on the old site after your final backup was taken, and it never makes it to the new host. The fix is a short, well-communicated content freeze.

• Announce the freeze internally. If other people publish to the site (authors, store managers, support staff), tell them explicitly when the freeze starts and ends, and why. A freeze window of an hour or two is usually enough for a small to mid-sized site.
• Put the old site in maintenance mode if needed. For sites with active checkout flows or frequent form submissions, consider a maintenance page during the final sync so no new data can be created while you are exporting.
• Take your final export during the freeze. Use wp db export for the database and a full file copy (via rsync, sftp, or your host’s migration tooling) for uploads, themes, and plugins. Because nothing is changing on the old site during this window, this export is your single source of truth for the new environment.
• Import and verify on the new host before touching DNS. Bring the database and files onto the new host, update wp-config.php with the new database credentials, and run wp search-replace to swap the old domain for the new one (or a staging subdomain) across all serialized data.

Verify before you cut over

With the site live on the new host but DNS still pointing at the old one, you can test the new environment safely using your local hosts file to preview it under the real domain name before anyone else sees it.

• Check that all pages, menus, and forms render and function correctly.
• Confirm object caching is active if you are using Redis or Memcached, and that full-page caching (LiteSpeed Cache, for example) is warming properly rather than serving errors.
• Run a quick Core Web Vitals check. You want LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. A migration is a good moment to catch a regression before it reaches real visitors.
• Verify SSL is issued and working on the new host, particularly if you rely on Cloudflare’s Universal SSL for the public-facing certificate.

Cut over and verify again

Once you are satisfied, update the DNS record to point to the new host. Because you staged a short TTL earlier, propagation should be fast. Monitor traffic and error logs closely for the first hour: watch for 500 errors, missing assets, or a spike in 404s that would indicate a broken permalink structure. Re-run wp cache flush and warm the cache manually if needed. Finally, confirm that your origin IP is not exposed anywhere, since keeping it unpublished matters for DDoS resilience, especially if a proxy layer like Cloudflare is part of your setup. A host that handles caching, object cache configuration, and edge protection out of the box, which is exactly what ServerBorn’s NVMe and Redis stack is built for, removes a lot of this final tuning work from your plate.

The takeaway

Downtime during a host migration is almost always a sequencing problem, not a technical one. Lower your DNS TTL early, audit what actually needs to move, freeze content for a short and well-communicated window, and verify the new environment thoroughly before and after the switch. Do those four things in order, and the cutover itself becomes the least eventful part of the whole process.