DNS and Nameservers When Changing Hosts: What Actually Causes Downtime

Almost every "my site went down during migration" story traces to the same two moves: pointing nameservers at the new host before the site was ready there, or letting a 24-hour TTL sit unchanged while the cutover happened. Neither is a hosting failure. Both are DNS sequencing mistakes, and both are avoidable with changes you make days before the switch.

Nameservers vs DNS Records: the Distinction That Causes the Outage

These get used interchangeably and they are not the same thing, which is the root of most migration confusion.

Nameservers decide which company answers DNS questions about your domain. They are set at your registrar, and they look like ns1.examplehost.com. Changing them moves the entire zone -- every record at once -- to a different provider's control.

DNS records are the individual answers inside that zone. An A record points a hostname at an IP address. A CNAME points one hostname at another. MX records route email. TXT records carry verification and mail authentication.

The difference matters at cutover because you have two separate ways to move a site, and they carry very different risk:

Method	What Changes	Risk	Best For
Change nameservers at the registrar	The whole zone moves, including MX and TXT	High -- email breaks if records are not recreated first	Simple sites with no third-party email
Change only the A record	Web traffic moves; MX and TXT stay put	Low -- email and verifications are untouched	Almost every migration with business email
Move DNS to a third party first, then migrate	Zone control leaves both hosts	Low ongoing, one extra step up front	Sites that change hosts more than once

The default choice

If you have email on the domain, change the A record, not the nameservers. Moving nameservers hands your entire zone to a host that has never seen your MX records, and the mail outage is usually discovered by a customer rather than by you.

TTL Is the Setting That Decides Your Rollback Window

Every DNS record carries a time-to-live: how long resolvers are permitted to cache the answer before asking again. A 24-hour or 48-hour TTL is a common default and it is the single worst thing to leave in place during a migration.

The reason is not that a long TTL makes propagation slower in some abstract sense. It is that a long TTL destroys your ability to undo. If you cut over and something is broken on the new host, lowering the TTL at that point does not help -- resolvers are already holding the old answer for up to the full original TTL. You are locked into the broken state until those caches expire.

The fix is ordinary and has to happen in advance:

Lower the TTL to 300 seconds at least 48 hours before cutover. The change itself has to propagate under the old TTL, which is exactly why doing it on migration day accomplishes nothing.
Confirm the low TTL is actually live before you touch anything else. Query the record and read the TTL value back rather than trusting the control panel.
Cut over. With a 300-second TTL, a mistake costs five minutes rather than a day.
Raise the TTL back to 3600 or higher once the new host has been stable for a day or two. Very low TTLs add lookup overhead you do not need permanently.

What "Propagation" Actually Means

DNS propagation is the most misunderstood word in hosting support. Nothing propagates outward from your registrar like a wave. Each resolver independently caches your record until its copy expires, then asks again. There is no global sync, and no queue you can jump.

Two practical consequences. First, the correct estimate for how long a change takes is your old TTL, not a fixed 24 to 48 hours. That figure is folklore derived from common default TTL values. Second, a propagation checker showing mixed results is normal and expected mid-window, not evidence that something is wrong.

The exception is a nameserver change, which involves the registry rather than just resolver caches and is slower to settle. That is another argument for moving A records instead when you have the choice.

The Records People Forget

When a migration breaks something other than the website, it is almost always one of these. Inventory them before cutover, not after.

MX records. If email runs on a third-party provider, these must exist at the new DNS host before nameservers move. This is the most common and most damaging omission.
SPF, DKIM and DMARC TXT records. Mail authentication lives in TXT records. Lose them and mail still sends, but delivery quietly degrades into spam folders -- a failure with no error message.
Domain verification TXT records. Search Console, Microsoft 365, and similar services verify via TXT. Losing these does not break anything immediately, which is why nobody notices for weeks.
Subdomain records. A staging site, a mail client hostname, a status page, a help desk CNAME. Anything not on the root domain is easy to miss when you are focused on whether the homepage loads.
CAA records. These restrict which certificate authorities may issue for your domain. A CAA record that does not include your new host's CA will silently block SSL issuance, and the symptom looks like a broken certificate rather than a DNS problem.

A Cutover Sequence That Does Not Break Anything

Export the current zone file from the existing DNS provider, or screenshot every record. This is your recovery document and it takes two minutes.
Build the site fully on the new host and test it by IP or by the host's temporary URL. Confirm SSL can be issued there. Nothing DNS-related happens yet.
Recreate every non-web record at the destination if you are moving nameservers -- MX, TXT, CAA, subdomains. Compare against the export line by line.
Lower TTL to 300 and wait 48 hours. Verify the low TTL is live.
Cut over, preferring an A record change over a nameserver change wherever email is involved.
Test in this order: site loads over HTTPS, certificate is valid and not the old host's, email sends and receives, forms submit, subdomains resolve.
Keep the old hosting account active for at least two weeks. This is the cheapest insurance in the entire process and the step people skip to save one month of hosting. Cancelling early is covered in the migration and cancellation sequence, and the order matters more than the savings.
Raise TTL back once stable.

What Should You Check First If It Breaks?

Work from the outside in. Query the record itself and see which IP is being returned. If it is still the old host, this is a caching or TTL question and the answer is to wait out the window you set. If the record returns the new IP and the site still fails, DNS has done its job and the problem is on the new host: a missing virtual host entry, a certificate that was never issued, or a firewall rule.

If the website works and email does not, the cause is almost certainly a missing MX or TXT record, not the web migration. Restore those from the zone export. If mail sends but lands in spam, check SPF and DKIM before anything else. That pattern is authentication records that did not come across, and it will not resolve on its own.

If the certificate is invalid, check whether a CAA record is blocking issuance before you open a ticket. Hosts cannot issue around a CAA restriction, and support will spend an hour on it if you do not mention it.

Compare hosting options on HostingDive -- reviews and comparisons filtered by site type, traffic level, and budget. If the migration is being driven by performance rather than price, the small business sizing guide is the better starting point, since moving a site that is simply under-resourced will not fix it.

Frequently Asked Questions

How long does a DNS change actually take?: Up to the TTL that was in force before you made the change. If your TTL was 3600 seconds, most resolvers pick up the new answer within an hour. If it was 86400, you are waiting up to a day. The widely repeated 24-to-48-hour figure is just the common default TTL restated, not a property of DNS itself. Nameserver changes are the exception and can take longer because the registry is involved.
Should I change nameservers or just the A record?: The A record, in almost every case where the domain carries email. Changing nameservers moves the entire zone to a provider that has none of your MX, SPF, DKIM or verification records, so those have to be recreated first and exactly. Changing the A record moves web traffic only and leaves everything else untouched.
Can I migrate with no downtime at all?: Close to it, if the site is static or read-mostly: build and test on the new host, lower TTL in advance, then switch. The hard case is a site with active writes such as a store or a forum, where anything submitted during the window can land on whichever host a given visitor resolves to. That is handled by a short maintenance window or read-only period, not by DNS technique.
Why does a propagation checker show different results in different cities?: Because that is how DNS works. Each resolver caches independently and expires independently, so a mixed picture during the TTL window is the expected state rather than a fault. It only indicates a problem if the split persists well beyond your old TTL, which usually points at a record that exists in one place and not another.
Do I need to keep the old host running after switching?: For at least two weeks. Visitors on cached DNS may still reach it, you may discover files or a database you did not migrate, and rollback is only possible while the old environment exists. The cost of one extra month is small against reconstructing a site you already deleted.