Your new server is ready, the final data sync is almost complete, and one DNS edit will decide where the next wave of users connects. The edit itself may take seconds. The operational transition can last much longer because resolvers and clients may continue using previously cached records while newer queries already point at the replacement server.
- Start With the Exact Records That Move Production
- Lower TTL Before the Migration Window, Not During It
- Make the New Server Production-Ready Before DNS Points to It
- Run the Cutover as an Ordered Change
- Keep Data Authority Separate From DNS Authority
- Verify the Cutover From More Than One Resolver
- Design Rollback for Split Traffic
- Watch for Negative Caching When Introducing New Names
- Restore Normal TTLs Only After the New Path Is Stable
Start With the Exact Records That Move Production
A DNS cutover should begin with an inventory, not with an edit in the provider dashboard. List every production hostname that can send users, APIs, workers, or third parties to the old server. For each name, record the current record type, target, TTL, authoritative DNS provider, and the service that depends on it.
Most straightforward migrations change an A or AAAA record from the old server address to the new one. Other environments may use a CNAME, load balancer, reverse proxy, CDN, or provider-managed IP reassignment instead. Do not assume every hostname follows the same path. The public website may use one mechanism while an API, mail endpoint, monitoring target, or partner integration uses another.
Use the broader dedicated server migration checklist to inventory the application, data, integrations, and rollback boundaries around the DNS change. If the migration includes a database, complete the consistency and write-control work from the database migration playbook before treating traffic switching as safe.
Lower TTL Before the Migration Window, Not During It
The DNS TTL defines how long a resource record may remain cached before a resolver should discard it and consult the source again. RFC 1035 specifies TTL values in seconds for cached resource records. That creates an important operational consequence: lowering the TTL at the start of the cutover does not retroactively shorten copies that were already cached with the previous, longer TTL.
Choose the shorter TTL your authoritative DNS service supports for the records that will change, then make that adjustment far enough in advance for the old TTL to age out. Record both values. The exact lead time depends on the TTL that was active before the change and on your DNS provider’s behavior, so avoid turning a convenient number into a universal rule.
Do not lower every record in the zone without a reason. Keep the change scoped to the production names involved in the migration. Also verify that you still have working administrative access to the authoritative DNS account, that the intended operator can make the change, and that the exact new values are prepared before the maintenance window.
Different resolvers can hold different cached answers at the same moment. Plan for a period in which some clients reach the old server and others reach the new one. The safest design keeps both destinations predictable during that overlap.
Make the New Server Production-Ready Before DNS Points to It
The destination should already behave like production when tested privately. Complete the relevant work from the deployment checklist: networking, firewall policy, TLS, application configuration, monitoring, logs, backups, remote recovery access, and required background services.
Test through the real production hostname without changing public DNS by using a controlled local hosts-file entry, an internal resolver override, or another private test path. This catches hostname-dependent behavior such as TLS certificates, redirects, virtual hosts, cookies, origin rules, and application configuration that an IP-only test can miss.
Confirm that the new public addresses are the ones you actually expect to publish. If the move changes address ownership, reverse DNS, IPv6 delivery, allowlists, or recovery assumptions, review the dedicated server IP address checklist before cutover.
Run the Cutover as an Ordered Change
Confirm the DNS records, old and new targets, operator, maintenance window, validation owner, rollback authority, and latest safe rollback point. Avoid unrelated DNS changes during the window.
Put the application into the planned maintenance or read-only state, pause scheduled jobs and workers that can create state, and verify that third-party integrations cannot continue writing behind the maintenance page.
Transfer the remaining database and file changes, verify the result, and record the final synchronization point. Do not switch traffic while data consistency is uncertain.
Run the critical application checks against the destination using the production hostname. Confirm logs, monitoring, authentication, reads, writes in a controlled test context, and external dependencies.
Change only the records required for the cutover. Record the exact time, previous values, new values, and operator. Query the authoritative service to confirm that it is serving the intended answer.
Watch requests, errors, logs, and application behavior on the new server while also checking whether the old server still receives legitimate traffic. Cached clients may continue to arrive there during convergence.
Keep Data Authority Separate From DNS Authority
DNS decides where a client tries to connect; it does not decide which copy of your data is authoritative. A dangerous migration state occurs when both servers accept independent writes while caches send traffic to both destinations. Unless the application has a tested replication and conflict-management design, choose one write-authoritative environment at every stage.
For a conventional warm migration, that usually means stopping writes on the old environment, completing the final synchronization, validating the new environment, then allowing production writes only after the new server is ready to become authoritative. If some cached users still reach the old address, the old endpoint should behave safely: maintenance mode, read-only behavior, or a controlled redirect only when that redirect is valid for the protocol and application.
Verify the Cutover From More Than One Resolver
A successful query from the operator’s laptop proves only one resolution path. Check the authoritative answer and then test through multiple independent recursive resolvers or networks that represent real client paths. At the same time, verify the application rather than treating the DNS answer as the finish line.
| Area | What to verify | Failure signal |
|---|---|---|
| Authoritative DNS | The intended record and TTL are being served by the authoritative provider. | The control plane still publishes the old value or an unintended record set. |
| Recursive resolution | Independent resolvers begin returning the new destination as cached copies expire. | Unexpected answers persist beyond the previously active TTL or differ because another record was missed. |
| TLS and hostname | The production hostname presents the expected certificate and virtual-host behavior. | Certificate errors, wrong redirects, default sites, or host-header mismatches. |
| Application state | Authentication, reads, controlled writes, uploads, queues, and jobs work on the new server. | Missing data, failed writes, duplicate jobs, or dependency errors. |
| Old destination | Traffic declines as expected and any remaining requests receive safe behavior. | Continuing production writes or important clients that never reach the new server. |
| Monitoring | External checks, logs, alerts, and resource metrics represent the new production path. | Green monitoring that is still testing the retired endpoint. |
Design Rollback for Split Traffic
Changing the DNS record back is not an instant rollback. Some resolvers may already cache the new address while others still have the old one. A rollback can therefore create the same split-traffic condition in reverse.
Define rollback criteria before the cutover. Examples include failed critical user journeys, data-integrity uncertainty, broken authentication, unreachable dependencies, severe performance instability, or approaching the end of the maintenance window without a stable service. If rollback is triggered before the new server accepts production writes, returning authority to the old environment is usually simpler.
Once the new server has accepted writes, stop and preserve them before redirecting traffic. Determine whether those changes must be synchronized back, reconciled manually, or kept on the new environment while the service remains in maintenance mode. DNS should never be used to hide an unresolved data-authority problem.
Watch for Negative Caching When Introducing New Names
If the migration creates a brand-new hostname, remember that a previous lookup may have returned NXDOMAIN before the record existed. RFC 2308 defines negative caching for DNS responses, including how long a resolver may retain evidence that a name or record does not exist.
Create required hostnames before they become operational dependencies, and verify them from outside your authoritative DNS service. This is a different problem from changing an existing cached A or AAAA record, but it can look like ordinary “DNS delay” during a migration if nobody recorded the earlier NXDOMAIN state.
Restore Normal TTLs Only After the New Path Is Stable
Keep the shorter migration TTL while you still expect to make a fast corrective change, but do not leave temporary settings indefinitely without a reason. After the service has passed its observation period, restore the planned steady-state TTL and record the final DNS configuration in the server’s operational documentation.
Do not cancel or erase the old server just because most DNS queries now return the new address. Confirm that meaningful traffic has stopped reaching it, external allowlists and monitoring targets are updated, backups from the new environment are working, and the rollback window has formally closed. When the migration is complete, use the dedicated server cancellation checklist to separate technical retirement from billing cancellation and data erasure.
The DNS change is safe only after the new server is privately validated, the final data state is known, the previous TTL has had time to age out, the old destination can handle residual cached traffic safely, and operators know exactly what would trigger rollback. Record the change time and keep both environments under observation until the overlap is no longer operationally relevant.
