The failure mode is switching DNS before the new host is ready, so visitors get a certificate warning or a 404 for the minutes-to-hours it takes to sort out. Doing it in the right order removes that gap.
Guides · Hosting
Moving a Domain to New Hosting Without Downtime
The order of operations for repointing a live domain so visitors never hit a broken or uncertified site.
5 min · updated 29 Aug 2026Before you touch DNS
- Deploy the site fully to the new host and test every important page on the host-provided URL.
- Add your custom domain (apex and www) in the new host's dashboard.
- Let the new host issue its TLS certificate — many can do this via a CNAME/TXT validation record you add now, before the cutover.
- Note the new host's target: an IP for an A record, or a hostname for a CNAME/ALIAS.
Lower the TTL first
A day or two ahead, drop the TTL on the records you will change (A/AAAA/CNAME for apex and www) to 300 seconds. This means when you do switch, resolvers pick up the change in minutes instead of hours — and if something is wrong, your rollback also propagates in minutes.
Make the switch
- Change the apex record to the new host's target. Use ALIAS/ANAME/flattened-CNAME if your DNS provider supports it; otherwise an A record to the new IP.
- Point www at the same place (usually a CNAME to the apex or the host).
- Keep any unrelated records (MX for email, TXT for SPF/DKIM, subdomains) exactly as they were — only change what serves the website.
After the switch
- Watch for certificate errors from real browsers, not just curl.
- Check that the non-canonical host redirects (www → apex or vice versa).
- Verify old paths 301 to their new equivalents.
- Leave the old host running for 48 hours as a safety net, then decommission it.
- Raise the TTL back to something normal (3600+) once stable.
Rather not do this yourself?
Hosting, launch, performance, and cloud hardening are all services here. Hand it over.