Websites and deployment
When to lower DNS TTL before a website migration
Plan DNS cache duration, cutover timing and rollback without claiming TTL makes every resolver update instantly.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Lower the relevant record TTL at least one old-TTL period before cutover so existing caches can expire under the previous policy. Some resolvers may cache longer, so keep both old and new services viable during the transition and retain a rollback plan.
What this means in plain English
TTL tells DNS resolvers how long they may keep an old answer. Lowering it before a move can make later changes appear sooner, but existing caches follow the old TTL until that time expires.
Keep both old and new websites working while answers change. Some networks may keep records longer than requested, and a quick rollback still needs the old service to be available.
How far ahead should TTL change?
| Old TTL | Wait this long after lowering before relying on it |
|---|---|
| Cutover | Change only verified target records |
| Overlap | Old service stays healthy while caches converge |
A simple example
A record has a 24-hour TTL. The owner lowers it to five minutes one day before the move, waits for the old 24-hour period, then changes the address. Lowering it five minutes before cutover would not clear caches already holding the full day.
What to do, step by step
1. Inventory authoritative DNS and current records.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on old ttl: wait this long after lowering before relying on it. Write the result down so you can compare it later.
2. Lower only the records being changed.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Verify the target via a temporary hostname.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Monitor answers from multiple resolvers after cutover.
Finish by checking the result against overlap: old service stays healthy while caches converge. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Change only the records that need to move. Replacing nameservers adds risk to mail and verification records that may have nothing to do with the website.
Common mistakes and how to avoid them
Lowering TTL five minutes before a 24-hour cache expires.
This gives a misleading or unsafe result because it leaves out old ttl. A better approach is to inventory authoritative dns and current records, then check the result before making the change permanent.
Changing nameservers unnecessarily.
This gives a misleading or unsafe result because it leaves out cutover. A better approach is to lower only the records being changed, then check the result before making the change permanent.
Turning off the old host immediately.
This gives a misleading or unsafe result because it leaves out overlap. A better approach is to verify the target via a temporary hostname, then check the result before making the change permanent.
Words explained
- DNS
- The system that connects a domain name to the service or server that should answer for it.
- TTL
- Time to live: how long another DNS server may keep an answer before asking for a fresh one.
- rollback
- Returning to the previous working release when a new deployment fails.
Quick checklist
- Inventory authoritative DNS and current records.
- Lower only the records being changed.
- Verify the target via a temporary hostname.
- Monitor answers from multiple resolvers after cutover.
Common questions
What is the simple answer?
Lower the relevant record TTL at least one old-TTL period before cutover so existing caches can expire under the previous policy. Some resolvers may cache longer, so keep both old and new services viable during the transition and retain a rollback plan.
What should I check first?
Start with old ttl: wait this long after lowering before relying on it. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Inventory authoritative DNS and current records. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Lowering TTL five minutes before a 24-hour cache expires. Avoiding that one mistake makes the rest of the comparison much more trustworthy.