Sales promises weekend migration "without downtime." A record TTL still 86400 for years. Friday 6 PM: new IP activated in zone. Saturday noon: 40% traffic on old host, 60% on new — broken sessions, partner webhooks split across IPs. Support talks "slow DNS propagation" — in reality, TTL not prepared.
TTL (Time To Live) tells resolvers how long to cache your DNS answer. Migrating without TTL management means promising instant while cache physics requires waiting previous TTL everywhere.
TTL-aware migration cycle
- D-7 to D-2: lower TTL to 300 s on A/AAAA/CNAME records to migrate.
- Wait old maximum TTL (often 24 h if value 86400).
- Prepare new origin (content sync, TLS cert, hosts file tests).
- Cutover: change IP or CNAME to new origin.
- Monitor mixed traffic two to twenty-four hours.
- D+7: raise TTL to moderate value (3600) if desired.
| TTL before | Min wait before cutover | Typical mixed window |
|---|---|---|
| 86400 (24 h) | 24 h | up to 24 h |
| 3600 (1 h) | 1 h | 1–4 h |
| 300 (5 min) | 5–15 min | 15–60 min |
Lowering TTL on D-day does not shorten what is already cached elsewhere.
Apex, www and mail
www: CNAME to new load balancer — relatively simple.
Apex @: provider ALIAS or A record — no RFC CNAME on bare apex.
MX: migrate mail separately — low MX TTL if changing; message loss risk if forgotten.
Document difference between SOA minimum TTL and record TTL — frequent migration confusion.
Tests before public cutover
/etc/hosts file or curl --resolve tests new origin without touching public DNS.
Checklist: valid cert on new host, externalized sessions, webhooks with new IP whitelisted.
Dual-run: old and new in parallel with monitoring comparing error rate.
For general DNS context, see DNS for beginners.
Stakeholder communication
Poorly announced migration generates "site does not work for me" tickets while DNS progresses normally. Warn support team, webhook partners and B2B clients before cutover — with honest window, not instant promise.
Internal or external status page during switch prevents every slow resolver being interpreted as total outage. Brief support: client-side "flush DNS" does not fix 86400 TTL still active at third-party ISP.
Document old and new IP, cutover date/time and host technical contact — useful if partner must whitelist new origin within forty-eight hours.
The peak: "instant" migration sold, TTL forgotten
Here is what no tool can promise.
Preparing migration = TTL timeline + hosts tests + apex/MX plan — not just uploading files to new VPS.
Decide and move forward without blind spots
Before switch weekend:
- Lower TTL to 300 s at least forty-eight hours before D-day.
- Test resolution from multiple public resolvers and local ISP.
- Execute cutover with active monitoring on both origins.
- Monitor traffic percentage on new origin — target 95% within four hours if TTL prepared.
- Raise TTL one week after stabilization.
- Handle MX and apex in separate plan from www if mail is critical.
Compare hosts and DNS tools via the directory and comparison tool.
Frequently asked questions
How long before migration to lower TTL?
At least once old maximum TTL before D-day; 300 seconds is common value for migrated records.
Is TTL 300 always enough?
For cutover yes; still plan one to twenty-four hours mixed traffic depending on resolvers.
Apex domain and migration?
ALIAS or A record — no classic CNAME on apex. Plan distinct from www subdomain.
How to verify propagation?
dig from multiple resolvers; local flush proves nothing for rest of world.
Successful DNS migration is prepared in TTL — not in sales talk.