Pointing a domain at a new host without downtime

Switching a live domain from one host to another goes smoothly when the work is done in a fixed order and each step can be undone. The order matters more than the speed: most outages come from changing the records first and preparing the destination second.

This plan is for a move where the public URLs stay the same and only the server behind them changes. If page addresses change too, redirects become the centre of the job; read canonical URLs, redirects and the www question as well. How caches and TTLs work is covered in how DNS works for someone who just bought a domain; this article uses that behaviour rather than re-explaining it.

The sequence

Step 1: write the current state down

Export or copy the full zone before changing anything. A screenshot is not enough; you want text you can paste back. Note every A, AAAA, CNAME, MX, TXT, CAA and NS record, including ones you did not create (email policies, domain-ownership checks, the TXT record Search Console may be using for verification). The most common self-inflicted outage after a host change is mail disappearing because a new DNS panel started with an empty zone.

Also note which hostnames must keep working; most sites need both the bare domain and www.

Step 2: lower the TTL, and do the arithmetic

A resolver that cached your record under a day-long TTL can keep serving the old address for up to a day after the change, whatever TTL the edit sets. The lowered TTL only reaches caches that fetch it later, so the lowering has to happen at least one old TTL before the switch. Here is the worst case for a fictional record with an old TTL of 86,400 seconds, lowered to 300, assuming every resolver honours the TTL it is given:

Google's hosting-move guide gives the planning figure: lower to a conservative low value, with "a few hours" as its example, at least a week in advance. A value of a few hundred seconds is your own choice for the cutover window, and it costs more queries to your nameservers while it lasts. TTL is set per record, so lower every record that will change.

Step 3: stage and test the new host

Deploy the site on the new host and test it fully before DNS knows about it. Two ways to reach it without touching public DNS:

• Use the host's own preview address, if it provides one.
• Point your machine at the new IP only. A hosts-file line (192.0.2.20 example.com www.example.com) does it for the browser. For a command-line check without editing any file:

curl -sI --resolve example.com:443:192.0.2.20 https://example.com/

The curl manual describes --resolve host:port:addr as a custom address for one host and port pair, a sort of /etc/hosts alternative on the command line, so the request keeps the right hostname for TLS. (192.0.2.20 is a documentation address; use the real one from your host.)

Things to test on the staged copy:

• Every important page and form, on the exact hostname, over HTTPS.
• Redirects: bare domain to www or the reverse, HTTP to HTTPS, and old URLs to new ones if any exist. Vercel's domain guide, for one host, says that if you add both the bare domain and www you should configure a redirect from one to the other to avoid duplicate content.
• robots.txt and noindex tags. Google's guide advises a noindex rule on a test hostname so it does not get indexed, and lists removing any such crawl or index block from the new copy as part of the move.
• Verification files or meta tags for Search Console, which must exist on the new copy too.
• Firewalls and denial-of-service protection. Google's caution is to make sure they do not block Googlebot's access to the DNS or the new servers; the URL Inspection tool in Search Console can check it.

Step 4: sort out the certificate

HTTPS works only when the host can present a valid certificate for the name. How a certificate gets issued decides whether your cutover has a gap:

• HTTP-01 (Let's Encrypt's most common challenge): the CA fetches a token file from http://<your domain>/.well-known/acme-challenge/ on port 80. It follows redirects up to 10 deep and cannot be used for wildcard certificates. It only works once the name already reaches the server that answers, so a host that uses it can only issue after the records point at it. That is the short gap some platforms have. Vercel's guide, for example, says it provisions the certificate after DNS verification succeeds, typically within a few minutes.
• DNS-01: you or the host publish a TXT record at _acme-challenge.<your domain>, and the CA looks it up. It needs no traffic at the new host, supports wildcards, and so can be done before the switch. Let's Encrypt warns that DNS providers have their own propagation delay, and that clients often wait as much as an hour before validating.
• Pre-generating: Vercel documents this route for a domain being migrated without downtime. You request the challenge records, publish the TXT records at your current DNS, verify, and the certificate is issued while the old host still serves traffic. The same page then shows the curl --resolve check above to test the certificate against the new host before you change any A record.
• A CDN or proxy in front of the host terminates HTTPS itself, so the certificate on the origin is a separate matter.

Add both the bare domain and www to the new host, so each has a certificate and a redirect rule.

Two records that can block you

CAA. RFC 8659 says that if a CAA record set exists for a name, a compliant CA must not issue unless the request is consistent with it, and a set with no restricting tags restricts nothing. So an old CAA record naming only your previous CA will stop a different CA from issuing for the new host. Run dig yourdomain.com CAA +short early. Let's Encrypt's CAA guide adds that the CA respects the record closest to the name, and that putting CAA records on the registered domain makes them apply to its subdomains too.

DNSSEC. This matters only if you change nameservers. Cloudflare's documentation says that changing nameservers while DNSSEC is still enabled at the registrar causes connectivity errors, because DNSSEC prevents the new provider's records from resolving properly. Check with dig yourdomain.com DS +short: a non-empty answer means a DS record is published at the registry (a real lookup of iana.org on 2026-10-17 returned two). Treat it as a planned sequence with your registrar and both DNS providers.

Step 5: switch the records

Change only what points at the web host.

1. Edit the A and AAAA records on the apex to the new host's addresses. Remove old AAAA records if the new host has no IPv6, or visitors on IPv6 will keep reaching the old server.
2. Edit the www CNAME to the target the new host gave you.
3. Leave MX, TXT and anything else untouched.

Do not also change nameservers, add a CDN, restructure URLs and move email on the same day. Each is a separate cutover with its own cache and rollback, and if two things break you will not know which change did it.

If the nameservers are changing

Moving DNS hosting differs from changing a record. First recreate the complete zone at the new DNS host and compare it with your saved copy line by line. Only then change the NS records at the registrar. The registry's servers publish the delegation with their own TTL; in a real lookup on 2026-10-17, the .com servers answered the delegation for example.com with a TTL of 172800 seconds (two days). Resolvers that cached it may keep asking the old nameservers for that long, so both sets must serve identical data until the old one is retired.

Step 6: verify from more than one angle

Immediately after the change:

dig example.com A +noall +answer
dig @ns1.example.net example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answer
curl -sIL https://example.com/ | head -n 12
curl -sIL https://www.example.com/ | head -n 12

What each tells you:

• The authoritative query should show the new address at once. If it does not, the edit did not save, or you are editing a zone that is not the delegated one.
• Public resolvers move over as their caches expire. The TTL in the answer is what remains at that resolver.
• The header checks confirm status codes, redirect hops and that both hostnames end at the same final URL over HTTPS.

Also check the certificate from a different network, and send a test email to the domain.

Step 7: keep the old host alive

Leave the old host serving the same content. Google's guide says to watch the server logs on both the new and old servers: traffic on the old one should fall as DNS settings propagate and the new one's rise, and the old hosting can be shut down once traffic to it reaches zero. A temporary drop in Googlebot's crawl rate right after the move is, per Google, normal when nothing is wrong, followed by a steady increase over a few days.

Rollback plan

Decide it before you start, and write it down.

• Trigger: what counts as a failure (certificate errors, forms failing, wrong content) and who decides.
• Action: paste back the saved A, AAAA and CNAME records. Rollback is a second cutover with the same caching, so keep the low TTL while you could still need it; raise it on day one and the way back is slow.
• Point of no return: the moment you delete the old host or its data. Do that last, not first.

A cutover, start to finish (fictional)

The fictional example.com has a day-long TTL on its A record, a CNAME for www, separate MX records and a CAA record naming the old certificate provider. A week before, the owner saves the zone and drops the TTL on the A, AAAA and CNAME records to 300 seconds. Two days later a dig CAA shows the problem: the new host's certificate authority is not listed, so the owner adds it. The new host is tested with the resolve option, and its certificate is issued ahead of time through a DNS challenge. The cutover is one edit: the A record gets the new address and the CNAME the new target. Within minutes public resolvers return the new address and HTTPS works on both hostnames. A week later, with the old host's logs quiet, the old server is removed and the TTL is raised again.

Checklist

• Save the whole zone, CAA included, and list hostnames that must keep working.
• Lower TTLs and wait out the old TTL before the switch; the table above is the arithmetic.
• Test the staged site by hostname with curl --resolve, remove staging blocks, and get the certificate ready first.
• Change web records only; check dig CAA and dig DS before touching authorisations or nameservers.
• Keep the old host and the low TTL until its logs go quiet, and write the rollback down first.