Cutover day is when everyone learns how DNS actually works. You flipped the A record, the new site looks perfect from your laptop, and a client in Calgary still sees the old host. That is not your host lying to you. It is propagation, caching, and TTL doing exactly what they were configured to do.
DNS migration is less about "pointing the domain" and more about managing a slow handoff between old and new infrastructure without breaking email, SSL, or forms along the way.
What propagation really means
When you change a DNS record, you update the authoritative nameserver for your zone. Resolvers worldwide do not all ask that server on every lookup. They cache the previous answer for as long as the record's TTL (time to live) says they can.
Propagation is not a single event. It is thousands of caches expiring at different times. Some users see the new IP in five minutes. Others may take up to the old TTL (often 3600 seconds or more if you never lowered it).
Lower TTL before you touch anything
At least 24–48 hours before migration, drop TTL on records you plan to change (A, AAAA, CNAME, MX if email moves too) to 300–600 seconds. Wait for the old high-TTL answers to age out, then make your cutover changes.
Skipping this step is the most common reason teams think migration "failed" when half the internet still resolves to the old server.
Records people forget
Website migration is rarely just one A record. Before cutover, inventory the full zone:
- A / AAAA / CNAME for www, apex, and subdomains (shop, app, staging)
- MX, SPF, DKIM, DMARC if mail moves or even if it stays (verify nothing else changed)
- TXT for domain verification (Google, Microsoft, payment providers)
- SRV or CNAME for Microsoft 365, Autodiscover, etc.
- Custom subdomains for client portals, booking tools, or legacy apps
Export a zone file or screenshot from the current DNS panel. You will need it when something stops working on day three.
Apex vs www (and why both matter)
Some hosts want an A record on the root domain. Others use ALIAS/ANAME or a redirect from apex to www. If you only update www and forget the naked domain, bookmarked links and old marketing materials still hit the old server.
Test both example.ca and www.example.ca from an external DNS checker, not just your browser (your machine may cache aggressively too).
Staging without poisoning production DNS
Preview the new site on a temporary hostname (new.example.ca or a hosts file entry) before you touch production records. Once you are confident, switch the live records.
Avoid leaving a staging CNAME on a subdomain that shares cookies or sessions with production unless you know what you are doing. That is a separate headache from propagation but shows up on the same weekend.
SSL and DNS timing
Let's Encrypt and most certificate workflows need the domain to resolve to the server that will answer the HTTP-01 or DNS-01 challenge. Order of operations that usually works:
- Site files live on new host (staging URL or lowered-TTL window)
- DNS points at new host
- Certificate issues or auto-renews on new server
If you cut over DNS before the site is ready, visitors may see a default parking page or certificate mismatch until the new vhost is configured.
Canadian hosting cutover notes
When moving from US hosting to a Canadian data centre (Edmonton, Beauharnois, Toronto/Cambridge), propagation behaves the same globally. The difference is latency and compliance after caches clear, not the DNS mechanics.
Some Canadian clients keep DNS at their registrar, Cloudflare, or an agency panel while hosting moves to Swift Host. That is fine. Just know who owns the zone and who can make changes at 9 p.m. on a Sunday if rollback is needed.
How to verify without trusting your own browser
- Use multiple DNS lookup tools from different networks (not just one)
- Check from mobile data, not office Wi-Fi (different resolver)
- Run
dig +short example.ca @8.8.8.8and compare to@1.1.1.1 - Hit the site in a private window after DNS shows the new IP everywhere you care about
Your laptop may have OS-level DNS cache. Flush it or wait. "It works for me" is not a migration sign-off.
Rollback plan (write it down)
Before you change anything, know the old A record values and MX targets. If the new host has a surprise (PHP version, missing extension, broken checkout), you want to revert DNS in minutes, not reconstruct records from memory.
Keep the old hosting account active until TTL has fully expired everywhere critical and you have run smoke tests on forms, login, and email.
Bottom line
DNS migration is a timed cache swap, not a light switch. Lower TTL early, document every record, test apex and www, and verify from outside your own network. Do that and propagation stops feeling like magic and starts feeling like a checklist.
Planning a move to Canadian hosting? Talk with Swift Host. We walk through DNS cutovers regularly and can help you avoid the weekend surprises.
