The safest way to reduce DNS TTL before migrating your hosting is to lower it to 300 seconds (5 minutes) at least 24–48 hours before the cutover. When you then point your records to the new server, the rest of the internet sees the new destination within minutes instead of waiting up to 48 hours.
This guide explains exactly what TTL is, why it matters during a migration, and how to execute the change so your site stays online throughout.
What Is DNS TTL and Why Does It Matter for Migrations?
TTL stands for Time To Live. It is a number, in seconds, that tells recursive DNS servers around the world how long they can cache a record before re-querying the authoritative nameserver.
- TTL of 86,400 s (24 hours): resolvers can cache the record for a full day.
- TTL of 3,600 s (1 hour): refreshed every hour.
- TTL of 300 s (5 minutes): refreshed every 5 minutes.
When you migrate hosting you change the IP address in your A record (or swap nameservers). If your TTL was 86,400 s, cached resolvers will keep sending traffic to the old IP for up to a day. Visitors end up on a stale site or, worse, an error page.
How Far in Advance Should You Lower the TTL?
The golden rule:
Lower the TTL at least as many hours before the migration as your current TTL expresses in hours. If your current TTL is 86,400 s (24 h), act 24 hours in advance. If it is 3,600 s (1 h), one hour is enough.
In practice, most domains sit at somewhere between 1 hour and 24 hours. To be safe, the standard recommendation is to act 48 hours before the migration.
| Current TTL | Minimum lead time |
|---|---|
| 86,400 s (24 h) | 24–48 hours |
| 43,200 s (12 h) | 12–24 hours |
| 3,600 s (1 h) | 1–2 hours |
| 300 s (5 min) | Ready to migrate now |
Exact Steps to Lower Your DNS TTL
1. Find where your DNS is managed
Your DNS records could live at:
- Your domain registrar's panel (GoDaddy, Namecheap, Name.com, etc.)
- Your current hosting control panel (cPanel, Plesk) if you pointed nameservers there
- An external DNS service such as Cloudflare
Log in to whichever place currently holds your DNS zone.
2. Note the current TTL of every record you will change
Identify all records that will change during the migration, typically:
Arecord for the root domain (@)AorCNAMErecord forwwwMXrecords if email is also moving
Save the current values in a text file. You will need them if something goes wrong and you need to roll back quickly.
3. Lower the TTL to 300 seconds
Edit each record and change the TTL field to 300. Some panels show dropdown options like "5 minutes" — that is the same value.
Save the change and wait out the old TTL before proceeding. If your old TTL was 24 hours, wait 24 hours so every resolver in the world expires its cached copy and begins reading the new 300 s TTL.
4. Verify the low TTL has propagated
Use a quick command-line check:
dig A yourdomain.com +nocmd +noall +answerThe number in the second column is the TTL remaining. When you see values at or near 300, you are ready. You can also rely on the web agency team at elenlace.com to run propagation checks on your behalf.
5. Execute the migration and update DNS records
With TTL at 300 s, copy files to the new hosting, test by editing your local hosts file to point to the new IP, and then update the A record to the new server's IP. The change will propagate globally in roughly 5–10 minutes.
6. Raise the TTL back up after confirming success
Once the site has served correctly from the new host for at least an hour, restore the TTL to its normal value (3,600 s or 86,400 s). A very low TTL means more DNS queries, adding negligible but real latency at high traffic volumes.
Common Mistakes When Lowering TTL
- Lowering the TTL and migrating immediately. The low TTL only helps after the old TTL has expired everywhere. Waiting is not optional.
- Forgetting MX records or subdomains. If email lives on the same host, failing to update MX records can break mail delivery for hours.
- Skipping a full backup before migrating. A reduced TTL protects propagation speed, not your data.
- Confusing nameserver TTL with record TTL. When you swap nameservers (NS records), propagation depends on the TTL set by the registry for NS records — values you do not control. Changing only the
Arecord (keeping the same nameservers) gives you full TTL control.
For more zero-downtime migration strategies, browse our performance and migration guides.
Key Takeaways
- TTL tells DNS resolvers how long to cache your records; lowering it before a migration shrinks the propagation window from hours to minutes.
- Set TTL to 300 s at least 24–48 hours before the cutover (based on your current TTL).
- Wait for the old TTL to fully expire before making the DNS change.
- Update every relevant record: A, CNAME, MX, and any subdomains.
- Verify with
digor an online tool that the low TTL has propagated worldwide. - Restore the TTL to its normal value once the new hosting is confirmed stable.
Ready to migrate your hosting with zero downtime? Reach out to us at elenlace.com and our team will handle the entire DNS migration process, from TTL reduction to final verification.
FAQ
What happens if I don't lower the TTL before migrating?
Nothing catastrophic, but propagation can take up to 48 hours. During that window, some visitors will reach the old host while others land on the new one. If the old server is already shut down, those visitors will see errors.
What is the recommended minimum TTL?
For a migration, 300 seconds (5 minutes) is the industry standard. Some providers allow 60 seconds, but it offers no real advantage and increases DNS query load unnecessarily.
How long does a 300-second TTL take to propagate?
That depends on your old TTL. If it was 3,600 s, within one hour all resolvers will have expired their cached copy and will start reading the new 300 s TTL. From that point on, any IP change propagates globally in under 10 minutes.
Do I need to lower TTL if I use Cloudflare?
If Cloudflare manages your DNS zone, it automatically sets TTL to 300 s for DNS-only records and "Auto" for proxied records. However, if you plan to switch nameservers away from Cloudflare, the same lead-time logic applies to allow the NS TTL to expire before the switch.
Compare providers
Other providers and guides worth comparing:
