One of the main fears when switching hosting is website downtime. In fact, with proper preparation, a DNS switch can be performed completely unnoticed by users. The key tool here is proper management of TTL (Time To Live).

What TTL Is and Why It Matters

TTL (Time To Live) is the time, in seconds, during which DNS servers cache your record. If TTL = 86400 (1 day), then after changing the A record, some users will still be routed to the old server for up to 24 hours.

TTL	Propagation Time	When to Use
86400 (24 hours)	Up to 24 hours	Stable record, no changes
3600 (1 hour)	Up to 1 hour	Default value
300 (5 minutes)	5–15 minutes	Preparing for migration
60 (1 minute)	1–5 minutes	Emergency switch

DNS Migration Checklist Without Downtime

24–48 hours before migration: Lower the TTL to 300 seconds
Set up the new server before switching DNS
Test via /etc/hosts — confirm the site works
Sync content — final rsync before the switch
Change the A record to the new server's IP
Monitoring — watch for errors for an hour
Old server — keep it active for 48–72 hours

Testing the New Server via /etc/hosts

># On your PC (Linux/macOS)
sudo nano /etc/hosts

# Add the line:
NEW-SERVER-IP example.com www.example.com

# Now the browser will open the site from the new server
# (DNS records are not changed)

# Windows: C:\Windows\System32\drivers\etc\hosts

Final Sync Before the Switch

# Sync files (changes only)
rsync -avz --delete user@old-server:~/public_html/   root@new-server:/var/www/example.com/

# Sync the database
mysqldump -h old-server -u dbuser -p dbname |   ssh root@new-server "mysql -u newuser -p newdb"

DNS checking tools: Use dnschecker.org or whatsmydns.net to monitor DNS propagation worldwide in real time.

Checking DNS from the Command Line

># Check the current A record
dig example.com A +short

# Check via a specific DNS server
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short

# Automatic monitoring (poll every 30 sec)
while true; do
  echo "$(date): $(dig @8.8.8.8 example.com A +short)"
  sleep 30
done

Migrating Mail Without Interruption

MX records control mail independently of the website. When migrating hosting, it's important not to break mail:

># Migrate mail BEFORE changing the MX records
# Change MX only after moving mailboxes
# Keep the old MX records as backup (priority 20)

# Example:
# MX 10 mail.new-server.com  ← primary
# MX 20 mail.old-server.com  ← backup (keep for 72 hours)

Don't cancel the old hosting right away! Pay for the old hosting for one more month after migration. This is insurance in case something went wrong or users with a high TTL are still hitting the old server.

Common mistakes during DNS migration

Three mistakes explain nearly every "the site didn't switch over" complaint after a migration.

dig example.com NS +short
ns1.old-host.com
ns2.old-host.com

The most common reason DNS panel changes "don't work" is that the domain is still delegated to the old hosting's name servers while the edits go into the new host's panel. Lowering the TTL and changing the A record somewhere nobody actually queries changes nothing. Check the NS delegation through the registrar first, and only then edit records in the right place.

curl -I https://example.com/ | grep -i "x-served-by\|server"

If response headers still show signs of the old server for some visitors right after the switch, that's expected behavior with a high TTL, not a bug. It's a real problem, not the norm, if signs of the old server are still there 48-72 hours after changing the record with a TTL of 300.

550 5.1.1 <user@example.com>: Recipient address rejected: User unknown

The MX record was switched before mailboxes were actually moved to the new server, so mail starts arriving where no mailboxes exist yet. The order in the checklist below isn't arbitrary: migrate mail first, then change MX.

Migration strategies compared

Parameter	Single cutover	Parallel run (dual-run)
Downtime risk	Higher	Minimal
Preparation complexity	Lower	Higher (two live environments)
Migration-period cost	One plan	Two plans at once
Best for	Small sites without a critical audience	High-traffic production

Running the old and new servers in parallel for a few days after switching the A record isn't overkill — it's standard practice: some users and bots will keep hitting the old IP because of caching resolvers, regardless of the TTL you set.

When lowering the TTL won't help

If the domain is on Cloudflare with proxying enabled (orange cloud), end users see Cloudflare's anycast addresses, not your hosting's IP — the A record's TTL doesn't affect them at all, and the switch happens instantly at the proxy level. TTL only matters for records that resolve directly to a server IP (grey cloud), or for NS delegation when changing DNS registrars. Some ISP resolvers ignore TTLs below 300-600 seconds and cache longer than advertised — plan for a real buffer of 24-48 hours, not just the technical TTL value.

How to verify the result

Before switching real user traffic, compare both servers directly:

# Direct request to the new server, bypassing DNS, to compare the response
curl -I --resolve example.com:443:NEW_SERVER_IP https://example.com/

# Direct request to the old server — it should still respond
curl -I --resolve example.com:443:OLD_SERVER_IP https://example.com/

Compare the headers or a marker on the page (say, a version number in an HTML comment) in both responses — that confirms both servers are serving the expected content before real users start hitting the new IP.