What are the warning signs that a DNS cutover is not complete?

How to tell a DNS cutover is still in progress

A cutover is incomplete when resolver behaviour is still mixed, not when a single lookup looks correct. The practical test is consistency: the same hostname should resolve to the same destination across locations, ISPs, corporate networks, and retry paths. Until that happens, the old and new targets are both still active in practice.

That is why a “green” check from one vantage point is not enough. DNS propagation is governed by cached data and resolver refresh timing, so you need to watch whether answers converge across independent resolvers rather than whether one authoritative change has been published.

When the answer is still split, the cutover is operationally unfinished even if the zone file is already right. A complete change is one that behaves consistently for real clients, not one that exists only at the authoritative source.

What the warning signs look like in the network

The clearest warning sign is inconsistent resolver paths: users in different regions or networks reaching different endpoints for the same name. You may also see some clients land on the new service while others continue to hit the previous IP or load balancer.

Another common signal is partial correctness. The record looks right when checked from one resolver, yet other resolvers still return the prior value. That pattern points to cache divergence, stale recursion, or uneven refresh timing rather than a malformed DNS change.

Operationally, the cutover is not complete until the old destination stops receiving meaningful traffic. If you still see sessions, health checks, or application requests arriving at the previous endpoint, the change has not fully propagated from the client perspective.

What to validate before declaring success

Check more than one resolver class, including public resolvers, enterprise resolvers, and locations that represent your user base. A cutover can appear stable in a lab, then continue to diverge in real networks because upstream caching behaviour differs.

Validate both the answer and the behaviour behind the answer. If the hostname resolves correctly but some clients still fail over to the old system, you may be seeing stale DNS plus cached connection state, not a finished migration. For service changes, the end state is confirmed only when traffic patterns and client reachability have settled together.

Use the authoritative change as the starting point, then verify stability over time. The practical threshold is not “the record updated”, but “independent clients now see the same destination with no meaningful backflow to the previous one”.

Practitioner Guidance

What to prioritise: Treat cross-resolver consistency as the acceptance criterion. One successful lookup is evidence of progress, not completion, until the old destination stops appearing in live traffic and external checks.

What to verify: Confirm the hostname from multiple recursive resolvers and from user-like networks, then compare those results with application telemetry. If traffic is still split, keep the cutover open and continue monitoring before retiring the old endpoint.

Practitioner takeaway: A DNS cutover is complete only when resolution has converged everywhere that matters, because the real failure mode is not the new record itself but the lingering coexistence of old and new destinations.

Related resources from NHI Mgmt Group

• What are the warning signs that RBAC has outgrown its design?
• What are the warning signs that password-based authentication is costing too much?
• What are the warning signs that access friction is hurting healthcare operations?
• What are the warning signs that AI root cause analysis is unreliable?