The cutover is a moment, so prepare it like one
By the time you flip DNS, months of work have been done. The final change is tiny, a record updated, and it is where the business sees the result. If it is improvised, a small mistake becomes a visible outage. If it is rehearsed, it is almost dull. Our aim is to make the switch an unremarkable step with an equally unremarkable way back.
DNS cutover and rollback planning closes each wave of our cloud migration service. The decision rules come from the roadmap, and the data side is handled with the database migration plan.
What good looks like
- Every name in scope is listed, with its record type, TTL, owner and consumers.
- The new endpoint was tested end to end before it received a single real user.
- TTLs were reduced early enough to matter.
- Go, no-go and rollback criteria are written as measurable conditions.
- The rollback has been done at least once in rehearsal and its duration is known.
- The old environment remains available until the new one is proven.
Preparing the ground
TTL staging
The time to live on a record tells resolvers how long they may cache it. If your records carry a long TTL, a change will not reach everyone quickly, and a rollback will be just as slow. So lower the TTL ahead of time, by at least the old TTL, wait for it to age out, and only then make the change. Afterwards, raise it again once stable, since very low TTLs increase query volume and make you more sensitive to resolver issues.
Checking everything behind the name
A record pointing at a new load balancer is only as good as what sits behind it. Before cutover we confirm certificates cover every hostname, health checks return healthy for real application paths and not just a default page, security rules allow client traffic and the application can reach its dependencies in the right locations. Partners who allow-list your IPs need advance notice of the new egress addresses, which is where the network design and the identity setup intersect with the plan.
Gradual shifting with weighted records
Where both environments can safely serve traffic, weighted routing lets you move users in steps and watch. In Route 53, two weighted records with a health check allow gradual movement:
resource "aws_route53_record" "app_old" {
zone_id = var.zone_id
name = "app.example.com"
type = "A"
ttl = 60
records = [var.old_public_ip]
set_identifier = "old"
weighted_routing_policy { weight = 90 }
}
resource "aws_route53_record" "app_new" {
zone_id = var.zone_id
name = "app.example.com"
type = "A"
alias {
name = aws_lb.new.dns_name
zone_id = aws_lb.new.zone_id
evaluate_target_health = true
}
set_identifier = "new"
weighted_routing_policy { weight = 10 }
}
An alias record cannot carry a separate TTL, since it inherits the target’s behaviour, so the plan allows for that when timing the rollback. We move 10, then 50, then 100 percent, holding at each step while error rates, latency and business metrics are reviewed. This is the same idea as a blue-green deployment applied at the DNS layer. Azure Traffic Manager and Front Door offer the same pattern.
Writing a rollback that works
A rollback needs more than “change the record back”. It has to deal with state, with caches and with the people involved.
- Trigger. For example, error rate above a threshold for a set number of minutes, or a failed business check such as order completion. Referencing your SLOs helps pick sensible numbers.
- Decision maker. One named person, with a deputy.
- Mechanism. The exact command or pipeline job that restores the previous record set, tested.
- Data. What happens to writes made on the new side. If both databases are in play, the plan states whether you replay, discard or reconcile.
- Communication. Who tells whom, and where.
- Time. The measured duration from decision to restored service, from the rehearsal.
If the data answer is “we cannot go back after the first write”, the plan says so, and the go decision is taken knowing that.
Decisions and trade-offs
Weighted shift or hard cut. Gradual is safer for stateless web tiers and APIs. A hard cut is simpler for stateful systems where two active sides risk inconsistency.
Native DNS or a global traffic layer. Plain DNS is simple and cheap but slow to react. Traffic managers and CDNs can steer faster and fail over automatically, at the price of another component to understand. Use it where fast failover matters.
When to delay. If rehearsal shows the rollback takes longer than the business can tolerate, or a dependency is untested, we recommend postponing. A date missed is cheaper than an unplanned outage.
A worked example: the day-of sequence
On the day, the runbook reads as a short checklist. Confirm the new endpoint is healthy and the rollback command is ready. Announce the start in the agreed channel. Shift the first weight and hold while someone reads the dashboards aloud. Run the scripted business check, such as placing a test order. Continue to the next step only when the check passes, and write down the time of each step so the next wave can reuse the real numbers.
Common failure modes
- Long TTLs left in place, so rollback takes hours.
- Hard-coded IP addresses in applications, configuration and firewalls.
- Certificate mismatch on the new endpoint.
- Health checks that pass while the application is broken.
- Forgotten records: MX, TXT verification, internal views of the same zone.
- Declaring victory too early and shutting the old side before long-lived clients have moved.
Delivery and handover
The runbook, the record definitions in code and the rehearsal results are yours. The procedure is repeated for each wave and summarised in the operations runbook for future changes. Our Terraform service can keep DNS under code long term.
How to tell it is working
The rehearsal matched reality. During cutover, the metrics stayed within the agreed bounds and nobody needed to improvise. Residual traffic to the old endpoint falls to zero over the expected window. To plan your own cutover, book a consultation.