The company website runs on WordPress at a shared host. It's moving into a container I build, on cloud infrastructure we run ourselves, with Cloudflare in front. The rule I've set for the move is simple to say and fussy to deliver: nobody using the site should be able to tell it happened.

What "no downtime" has to mean

  • No minute where the site doesn't answer.
  • No broken links. Every address that works today works the same way afterwards, including the old ones that redirect.
  • Nothing search engines can see changes: same titles, descriptions, canonical tags and redirects.
  • Email keeps flowing. The domain carries everyone's mailbox, so its DNS matters more than the website does.
  • The people who edit the site keep editing it the same way.

Two stages, not one

Moving a website usually changes two things at once: who answers DNS for the domain, and where the website lives. I'm splitting them.

Stage one moves DNS to Cloudflare with every record copied exactly, including the website records, which still point at the old host. Nothing changes for visitors or for email. Resolvers around the world switch to asking Cloudflare over a day or two, and both providers give the same answers the whole time, so it doesn't matter which one anybody asks.

Stage two, a couple of days later, points the website at the new platform. Cloudflare is already answering by then, so the switch is an edge change that takes effect in seconds, and so does the rollback.

The detail that makes the switch instant

Changing a DNS record from one type to another is a delete followed by a create. A resolver that asks in that gap can remember "no such record" for a while, and for those visitors the site is gone. So the website records have the same type before and after the switch, and only where they point changes. Rolling back is the same kind of edit in the other direction, and it doesn't wait for anyone's DNS cache to expire.

Every gate is a script

  • DNS. A snapshot of what the old nameservers answer for every name, the same from the new ones, and a diff that fails on any difference I haven't written down in advance. Its first run found two records an earlier manual check had missed, which is exactly why it exists. It still isn't proof on its own: a lookup only finds the names you know to ask for, so the provider's full record export goes into the diff too.
  • Links and search. Every URL from the sitemaps, the redirect list, a full crawl, the media library and the web archive's history, fetched from the old platform and the new one and compared: status code, redirect target, title, description, canonical tag, structured data, and a screenshot diff at desktop and phone widths.
  • Function. The lead forms end to end, the calculators, the editor, uploads and scheduled posts.
  • Speed. The new platform can't be slower than the old one.

A gate passes when the script says it does, not when the plan says it should.

Testing on the real edge before anyone uses it

Between the two stages the new platform is live on two private addresses behind single sign-on. The test harness uses one of them, and its browser sends every request for the real domain there, so cookies, cross-origin calls and analytics behave exactly as they will in production. The people who look after the site get the other one, to click through and sign off.

Safer, not just moved

  • The web server has no public address. It connects out to Cloudflare, and that connection is the only way in.
  • The database sits on a private network: encrypted connections, its own least-privilege account, and point-in-time backups copied to a second region.
  • The site's code ships inside a versioned, scanned container image instead of living on a server's disk.
  • Only the plugins the site actually uses go into that image.
  • Patching becomes a weekly routine, with a test run before every release.

What I'd tell someone planning the same move

  • Separate the DNS move from the website move. Each gets its own rollback, and the gap between them is your test window.
  • Don't trust lookups to find every DNS record. Get the export from the provider and diff against it.
  • Keep record types the same across a switch.
  • Change the plumbing, not the site. Improvements come afterwards, one at a time, each with its own test.
  • Leave the old site alone until the new one has earned the trust. It's your rollback.

I'll write the next one after the switch.