Zero-Downtime WordPress Migration, Step by Step

· 8 min read
Sealed cardboard moving boxes

Most people stay on hosting they have outgrown because they expect moving to mean downtime. It does not — but only if the sequence is right.

The core idea: the new site is fully working and tested before anything points at it. DNS is the last step, not the first, and it is a switch rather than an outage.

Step 0: lower your TTL, days ahead

This is the step that gets skipped, and it is the one that decides whether “zero downtime” is real.

Your DNS records have a Time To Live — how long resolvers cache them. If your A record has a 24-hour TTL, some visitors keep hitting the old server for a full day after you change it.

At least 48 hours before the migration, drop the TTL on your A and CNAME records to 300 seconds. Resolvers need time to expire the old, long TTL before they will start honouring the short one — which is why doing this on migration day accomplishes nothing.

Restore it to something normal (3600 or higher) about a week after the move.

Step 1: copy everything to the new server

Files and database, complete. The new account should be a full working copy — themes, plugins, uploads, and the database, not a fresh install you reconfigure by hand.

At this point the site exists in two places. The live one is untouched and still serving traffic.

Step 2: test on the new server before DNS

Here is where people go wrong: they change DNS to “see if it works.”

You can reach the new server without DNS by overriding it locally. Edit your machine’s hosts file:

# macOS / Linux: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.10   yourdomain.com www.yourdomain.com

Your browser now resolves the domain to the new server while the rest of the world still gets the old one. The site loads under its real domain name, so nothing is broken by a temporary URL.

Test properly:

  • Homepage and several interior pages
  • Log in to /wp-admin and save a post
  • Submit a contact form and confirm the email arrives
  • For a store: add to cart, reach checkout, complete a test order
  • Check the browser console for mixed-content or 404 errors
  • Confirm permalinks resolve, not just the homepage

Remove the hosts entry when you are done.

Step 3: install the certificate before the switch

A certificate must exist on the new server before traffic arrives, or visitors hit a browser security warning in the gap.

Standard HTTP validation needs the domain to already point at the server — a chicken-and-egg problem. Two ways around it:

  • DNS validation — prove control with a TXT record instead, which works before any traffic moves.
  • Pre-issue at the host level — most managed hosts, HOSTEMCLOUD included, can issue the certificate for a domain hosted on the account before DNS cuts over.

Confirm HTTPS works over your hosts-file override. If it does not, do not proceed. More on certificate mechanics in SSL/TLS basics every site owner should know.

Step 4: freeze content, then re-sync the database

The gap that eats data: between your database copy and the DNS switch, real activity continues on the old server. New orders, comments, form entries, posts.

For a brochure site, just stop editing for an hour.

For anything with transactions, do a final database sync immediately before the switch:

  1. Put the old site in maintenance mode, or simply accept a short read-only window
  2. Export the database again
  3. Import it over the copy on the new server
  4. Switch DNS

The window is minutes, and the site stays up throughout — it is briefly read-only, not offline.

Step 5: switch DNS

Change the A record to the new IP. With a 300-second TTL, the world follows within about five minutes.

Both servers are running during the transition. Visitors hit one or the other; both work. Nobody sees an error.

Leave the old account running for at least a week. This is the cheapest insurance in the process. If something surfaces on day three, the old site is still there.

Step 6: verify after the cutover

Confirm traffic is actually arriving at the new server:

dig +short yourdomain.com
curl -sI https://yourdomain.com | grep -i "^server:"

Then check the things that commonly break after a move:

  • Email. If MX records point elsewhere, confirm they were not disturbed. If mail was on the old host, that is a separate migration — plan it explicitly rather than discovering it.
  • Cron. WordPress cron fires on page loads; real cron jobs configured on the old server do not migrate themselves.
  • Outbound mail. Contact forms and order confirmations often silently stop because the new server sends from a different IP. Send a real test.
  • Search Console. If the IP or certificate changed, re-verify and re-submit the sitemap.
  • Redirect rules. Custom .htaccess rules do not always travel with an automated migration tool. Check them.

What actually goes wrong

In practice, the failures are rarely the file copy:

  1. TTL was never lowered — a long tail of visitors on the old server for a day, splitting form submissions and orders across two databases.
  2. Certificate missing at cutover — security warnings during the window.
  3. Email overlooked — the site moves, mail breaks, and nobody notices until a customer says they never got a reply.
  4. Hardcoded URLs — absolute URLs in the database pointing at a staging hostname. A search-replace that is serialisation-aware fixes it; a naive SQL find-replace corrupts serialised option values.
  5. Old server switched off too early — removes the fallback exactly when it is most useful.

The short version

  1. Lower TTL to 300 — at least 48 hours ahead
  2. Copy files and database
  3. Test via hosts file, under the real domain
  4. Install the certificate before switching
  5. Final database sync, then change the A record
  6. Verify, keep the old server a week, restore TTL

Sequenced that way, there is no moment where the domain resolves to nothing.

Migration is included on every HOSTEMCLOUD plan and we run this sequence for you, including the pre-cutover certificate and the final sync. If you have been postponing a move off an overloaded account — see Cloud VPS vs shared hosting for whether you have actually outgrown it — get started with UNITY and we will handle the move.

← Back to blog