Domains & DNS
DNS rollback planning: keep a safe path back during a cutover
DNS rollback planning is useful only when the previous destination can still serve correct data. A saved old A record is not a recovery plan if the old database is stale, mail was moved, certificates expired, or the previous server has already been terminated.
Preserve the old destination deliberately
Keep the previous service online through the verification window and document its IPs, hostnames, certificates, database state, credentials, and dependencies. If you intend to roll back, know which pieces must also roll back with DNS.
Avoid destructive cleanup immediately after a successful-looking cutover.
Record exact DNS before the change
Save old and new values, TTLs, zone serials, nameserver delegation, and any related records such as MX, CNAME, TXT, or SRV that are part of the same service. Rollback should change the minimum necessary records.
Do not replace an entire zone file to reverse one web record unless the entire zone really changed.
Account for data created after cutover
Orders, accounts, uploads, form entries, messages, and database changes created on the new system will not appear on the old system automatically. Decide whether rollback means a reverse sync, a write freeze, or accepting a defined data-loss window.
This is why stateful migrations need an application plan in addition to DNS.
Test rollback criteria before launch
Write the symptoms that trigger rollback, who makes the decision, how long caches may take to respond, and what verifies recovery. A vague “if anything goes wrong” rule wastes time during an incident.
- Keep the source usable.
- Save exact old DNS.
- Plan reverse data synchronization.
- Define rollback owner and threshold.