Lower TTL before the change
Reducing TTL shortly before changing the A or AAAA record does not help if resolvers have already cached a longer TTL. Lower it far enough in advance for the old value to expire.
← All tools
Free WordPress Tool
DNS TTL Cutover Planner
Plan when to reduce DNS TTL before a WordPress migration and estimate how much time existing resolver caches need to expire.
Free to useNo account requiredRuns in your browser
TTL readiness
—
Enter your values and calculate.
How to use this result
This is a planning estimate based on the values you enter. Real WordPress environments can be affected by disk speed, database size, cache behavior, provider limits, plugin architecture, active traffic and third-party services. Verify the production environment before making a live change.
TTL does not force instant propagation
Reducing TTL helps future DNS changes converge faster, but it does not purge resolver caches that already stored the older TTL. Lower it before the migration window, not at the moment of cutover.
Using TTL correctly during a hosting migration
Use the calculator as a planning aid, then validate the result against the actual WordPress installation, hosting account and production traffic. These notes explain the technical assumptions behind the result and the checks I would make before acting on it.
Do not change unrelated records
A website migration often requires only the web records to change. MX, SPF, DKIM, DMARC and verification records may belong to separate email or SaaS systems and should normally remain untouched.
Cloudflare proxy changes what you test
When Cloudflare proxying is enabled, public DNS returns Cloudflare addresses rather than the origin. Verify the origin separately and confirm SSL mode, cache rules, WAF settings and origin certificates before launch.
Raise TTL after stability
Once the new environment is verified, longer TTLs can reduce DNS lookup load and provide normal caching behavior. Do not leave emergency migration values forever without a reason.
Questions about this tool
Is this result a guarantee?
No. It is an estimate based on the inputs available in a browser. Production WordPress sites can have custom code, unusual server limits, third-party integrations and traffic patterns that change the real requirement.
Does the tool send my data anywhere?
The calculator runs in your browser. The page does not need an account or a database to calculate the result. Avoid pasting passwords, API keys or private customer information into any planning field.
When should I get a manual review?
Use a manual review when the site generates revenue, has active users, contains a large database, uses memberships or subscriptions, has custom integrations, or cannot tolerate an extended rollback window.
Professional interpretation
How to use DNS TTL Cutover Planner in a real WordPress project
The useful part of a planning tool is not the number by itself. It is understanding which assumptions produced the result, which production conditions can change it, and what should be checked before you act. Use this tool as part of a wider migration or infrastructure review rather than as an automatic go/no-go decision.
DNS changes affect more than the website
A domain can carry website routing, mail delivery, verification records, subdomains, third-party SaaS records and security policies. Review the full zone before changing nameservers or replacing records.
TTL is a cache instruction, not a global timer
Recursive resolvers and client caches do not all update at one exact moment. Lower TTL before a planned cutover when possible, then keep the old origin available long enough to absorb straggling traffic.
Email deserves a separate verification pass
MX, SPF, DKIM and DMARC should be checked independently of the website. A migration can appear successful in the browser while business email is silently misrouted or authentication begins failing.
Practical questions
Will everyone see a DNS change when TTL expires?
Not necessarily. TTL influences caching, but resolver behavior and previously cached answers vary.
Can nameserver changes break email?
Yes if the new DNS zone does not reproduce the required MX and authentication records.
Should the old server remain online?
Usually for a reasonable overlap period, especially while DNS propagation and cached traffic settle.