Moving a website, email or domain without downtime: the DNS steps that usually go wrong

Why DNS causes outages

DNS translates domain names into the addresses and services behind them: where the website is hosted, which servers receive email, which services may send email for the domain, and many verification records for third-party tools. A single domain can have dozens of records added over years by different people.

When a company moves to new website hosting, a new email provider or a new DNS provider, those records must be recreated correctly and switched at the right time. Missing a record can take down a customer portal, stop invoices from being delivered or break integrations that nobody associated with the domain.

Step one: inventory every record

Export or document the complete current DNS zone before changing anything. Many providers allow zone file exports. Record every entry, including subdomains, and identify what each one is for. Unknown records should be investigated rather than dropped.

A, AAAA and CNAME

Where the website, subdomains, apps and portals point.

MX

Which servers receive email for the domain.

TXT

SPF, DKIM, DMARC and verification records for tools such as search consoles, email platforms and collaboration suites.

CNAME for services

Records used by email sending platforms, help desks, landing page tools and content delivery networks.

SRV and others

Records used by collaboration, calling or specialised services.

Step two: lower TTLs in advance

Each DNS record has a time to live, or TTL, which tells resolvers how long they may cache the answer. If a record has a TTL of 24 hours, some users may continue to reach the old destination for up to a day after a change.

Lower the TTL of records that will change, for example to a few minutes, at least one full old TTL period before the migration. On the day, changes then take effect quickly for most users, and a rollback is also fast. After the migration is stable, TTLs can be raised again.

Changing nameservers, meaning moving the whole zone to a different DNS provider, is different: nameserver records are held by the registry and can take longer to update across the internet, often up to a day or two. Recreate the zone at the new provider first and verify it before switching nameservers.

Websites and certificates

Before switching a website, make sure the new hosting can serve the site securely. Many certificate authorities validate domain control by requesting a file from the website, which only works once DNS points to the new server. Options include issuing certificates through DNS validation beforehand or using a platform that provisions certificates immediately after the switch, with a plan for the few minutes in between.

Test the new site before the switch using a temporary URL or local hosts file entries, including forms, payments, logins and redirects from old URLs. Keep the old hosting running until traffic has fully moved and no errors appear.

Email migrations

Email is the most sensitive part. Create mailboxes and aliases at the new provider, migrate existing mail, then change MX records during a quiet period. Because some senders may still deliver to the old servers for a while, keep old mailboxes accessible and collect any mail that arrives there during the transition.

Update authentication at the same time. SPF must include the new provider’s sending servers, DKIM keys from the new provider must be published, and DMARC should remain in place so reports reveal any legitimate source that fails. Do not remove records for other sending services, such as marketing platforms, invoicing tools or help desks, that still send email for the domain.

Registrar transfers and DNSSEC

Moving a domain to a new registrar requires unlocking the domain, obtaining an authorisation code from the current registrar and confirming the transfer. For generic top-level domains, transfers are commonly restricted for 60 days after registration or a previous transfer, and country domains follow their own registry rules. Make sure registrant contact details and email addresses are current, because confirmations are sent there.

DNSSEC adds cryptographic signatures to DNS. It improves security but can cause complete outages during migrations if the signing keys at the registry do not match the new DNS provider. When moving DNS for a signed domain, follow the new provider’s procedure for DNSSEC, which may involve adding new keys before switching or temporarily disabling DNSSEC and re-enabling it afterwards.

A migration checklist

Document the current zone and owners of each service. Lower TTLs in advance. Prepare the new hosting, email and DNS, and test before switching. Plan certificate issuance. Switch during a low-traffic period with people from each affected service available. Verify website, email flow, authentication and integrations immediately afterwards. Keep old services running until everything is confirmed. Raise TTLs again and update documentation.

Finally, secure the registrar and DNS accounts with multi-factor authentication and company-owned logins, so the next change does not depend on someone who has left.

Where this sits in what we do

This article covers one decision inside a wider engagement. The solution page sets out how that engagement runs, what it includes and what it costs to find out.

• Custom Business Platform — A platform built around how your business actually runs — customer portal, internal tooling, database and the automation between them.
• Quote to cash without re-keying: where the handoffs break
• Product data is the e-commerce growth lever nobody budgets for
• Website uptime and certificate monitoring: catching outages, expiring certificates and broken checkouts first
• WhatsApp Business Platform pricing per message: how the July 2025 change affects customer service and marketing
• All insight articles