How to Plan DNS TTLs Before a VPS Migration

The risky part of a DNS migration is often the period when some visitors reach the old server and others reach the new one. Lowering a TTL can shorten that overlap for future cached answers, but it cannot reach into every resolver and erase an answer already cached. A useful migration plan therefore begins before the address change and includes the application's data, not just its DNS records.

Work backward from the existing TTL

Record the current TTL for every hostname being moved. If an A record has a one-day TTL, changing it to five minutes immediately before a cutover leaves previously cached one-day answers in circulation. Publish the shorter TTL sufficiently early for that earlier interval to pass. Treat resolver caches and application caches as different things: a browser or long-running client may maintain connections independently of a DNS lookup.

Use a timeline with three named moments: lower the TTL, change the address, and restore the routine TTL. The right values depend on the provider's permitted settings and the operational window. There is no universal number that turns DNS into an instantaneous switch.

Decide who accepts writes during overlap

For a static documentation site, two servers serving identical files may be acceptable during the transition. For a shop, forum, or ticket system, both servers accepting independent writes can produce diverging orders or user records. Choose one authoritative write path, or arrange an application-supported replication and cutover process before editing DNS.

An example checklist for a small forum is to announce a maintenance window, synchronize uploads, stop new writes on the old application, perform the final database transfer, verify the new application, and then change DNS. Keep the old host capable of presenting a clear maintenance response while cached answers remain. Tailor that sequence to the application's documented migration procedure.

Verify more than one answer

After the cutover, query the authoritative server and a few recursive resolvers relevant to your users. Record the time and answer from each. Agreement provides useful evidence of progress, although a handful of successful checks cannot prove that every network has updated. Watch requests arriving at both servers to see whether traffic still reaches the old address.

Validate certificates, redirects, uploads, and background jobs on the destination. If a login fails while the page loads, the migration may have a cookie or session-storage problem. Changing the TTL again will not repair that failure.

Make rollback a data decision

Returning DNS to the old address is simple only while the old application still has authoritative data. Once the new system accepts writes, a rollback needs a plan for those changes. Define the person who can authorize rollback, the time allowed for verification, and how writes will be preserved. Retain independently recoverable copies of important data; LayerOne does not provide automated VPS backups or snapshots.

Review DNS caching concepts for the TTL mechanism. Our backup planning guide helps with recovery preparation, and LayerOne docs cover the destination server.