What TTL actually controls
Moving a website to a new host looks simple on paper: copy files, point the domain, celebrate. In practice, visitors still hit the old server for hours or days because DNS caches keep the previous answer. For a small business that takes leads through a contact form, that split brain means some customers land on the new site and others still see the old one—or a blank page after you shut the old account.
This is an operator checklist TwoQM recommends before you change A, AAAA, or CNAME records for a live marketing site. It is not a vendor bake-off.
TTL (time to live) is how long resolvers and browsers may keep a DNS answer before asking again. If your A record for www.example.com has a TTL of 86,400 seconds (24 hours), many networks can keep serving the old IP for up to a day after you publish the new one. Lower the TTL before the move, wait for the old high TTL to expire once, then switch.
Common small-business mistakes:
Changing hosts and DNS in the same afternoon with a 24-hour TTL still in place.
Editing only the apex (example.com) and forgetting www, mail-related records, or CDN CNAMEs.
Cutting off the old host the minute the panel shows “propagation” for one laptop on one network.
Two weeks out: inventory who answers for the name
Write down, in one shared note:
Registrar — Where you renew the domain (and who can log in).
Nameservers — Registrar defaults, Cloudflare, Google Domains successor, host-managed DNS, or a third party.
Live records — A/AAAA for apex and www, CNAME for CDN or shop subdomain, MX and TXT for mail, any verification TXT records (Google, Microsoft, Apple, payment providers).
Where traffic really terminates — Origin host, CDN edge, reverse proxy, or a marketing platform that “connects” the domain for you.
Export a screenshot or zone file of the current zone. You need a rollback target if the new host is wrong.
Seven to three days out: lower TTL on purpose
Pick the records you will change for the site move (usually apex A/AAAA and www). Set their TTL to something short that your DNS provider allows—often 300 seconds (5 minutes) or 600 seconds. Leave MX and mail TXT alone unless mail is moving too.
Then wait at least as long as the previous TTL. If the old TTL was 24 hours, wait a full day after the low TTL publishes before you flip the IP. That wait is the whole point: caches worldwide refresh to the short value so the later cutover can finish in minutes, not a day.
Confirm the low TTL is live from more than one resolver (your phone on cellular, a second network, or a public lookup tool). Do not trust only the DNS panel “success” toast.
Cutover day: change DNS last, not first
Order of operations that keeps leads flowing:
Build and test the new site on a temporary hostname or hosts-file override—never on the customer URL until you are ready.
Smoke-test forms, HTTPS, redirects, and booking/checkout on the new origin.
Publish the new A/AAAA or CNAME to the new target (with the short TTL still in place).
Keep the old host online and answering until checks from two networks show the new site consistently.
Watch the contact form and analytics for a few hours. If something is wrong, flip DNS back using your exported zone.
Only after the new site is stable should you cancel the old hosting invoice. Early cancellation is how “propagation” becomes a weekend outage.
What to verify in the first hour after the flip
Homepage and one interior page over https:// with a valid certificate for the real hostname (not only the temporary host name).
Apex and www both resolve to the intended target, and one redirects cleanly to the other.
Contact form or booking path still delivers mail to the right inbox.
Google Business Profile, email signatures, and ads still point at the URL customers actually get.
No mixed content or hard-coded old CDN URLs breaking checkout assets.
If you use a CDN in front of the origin, purge cache after the origin cutover and confirm the edge is fetching the new backend—not serving a week-old HTML shell.
After things look good: raise TTL again
Once the new host has been stable for a day or two, raise TTL back to a sane production value (often 1 hour to a few hours) so every page view does not force a fresh DNS lookup. Leave a calendar note for the next move: lower TTL first, wait, then change.
Who owns which login
DNS moves fail more often from access than from technology. Name owners before cutover day:
Who can edit DNS at the registrar or DNS host.
Who can open a ticket with the old and new hosting companies.
Who can roll back the records if the new certificate or form breaks.
TwoQM’s standing advice for operators: treat DNS like a locked cabinet. Shared “admin@” passwords and expired MFA apps are how a planned Saturday migrate becomes a Monday scramble.
Bottom line for this week
If a host move or domain re-point is on your calendar, lower TTL now—not the morning of the switch. Inventory apex, www, and mail records. Test the new site off the public name. Keep the old host warm until two networks agree the new one is live. Then raise TTL again and document who holds the keys.
A quiet DNS cutover is boring on purpose. Boring is how small businesses keep answering the phone for real customers instead of explaining why the website “still shows the old address.”