Separate zone authority, recursion, and client targeting into different workstreams.

DNS migrations go wrong when zone hosting, forwarders, scavenging, and client resolver changes all move at once. Break those streams apart and prove each one independently.

Runbook note: Keep old and new DNS hosts answering in parallel until authoritative zone transfer, forwarder behavior, and client resolver selection all test cleanly from the same workloads.

• Inventory every AD-integrated zone, reverse zone, conditional forwarder, delegation, root-hint override, and DNS policy before introducing new servers.
• Document which systems use static resolver settings, DHCP-delivered settings, VPN profiles, firewall objects, or load balancer health checks tied to current DNS servers.
• Decide whether recursion remains on the domain controllers or moves to a dedicated resolver tier, then test that design intentionally.
• Define rollback as restoring prior resolver targeting and forwarder behavior without losing directory-integrated zone updates.

Command path:

• Get-DnsServerZone -ComputerName HF-DC-OLD01
• Get-DnsServerForwarder -ComputerName HF-DC-OLD01
• Get-DnsServerScavenging -ComputerName HF-DC-OLD01
• dcdiag /test:DNS /e /v

GUI path: DNS Manager > Forward Lookup Zones, Reverse Lookup Zones, Conditional Forwarders, and Server Properties > Forwarders and Advanced.

Create parity first so cutover becomes a routing change, not a redesign.

The new Windows Server 2025 DNS hosts should already have the same zone scope, forwarder intent, logging decisions, and scavenging model before production clients are pointed at them.

• Promote or configure the new servers so they receive the directory-integrated zones and verify application partitions replicate normally.
• Mirror forwarders, root-hint decisions, DNS policies, recursion scope, aging intervals, and debug or analytical logging choices from the old estate where still required.
• Validate secure dynamic updates from DHCP and domain members before any client resolver cutover begins.
• Confirm reverse zones and conditional forwarders are present on the servers that will actually receive branch or VPN queries.

Command path:

• Install-WindowsFeature DNS -IncludeManagementTools
• Get-DnsServerZone -ComputerName HF-DC25-01
• Get-DnsServerDirectoryPartition -ComputerName HF-DC25-01
• Resolve-DnsName dc01.corp.example.com -Server HF-DC25-01

GUI path: Server Manager > Add Roles and Features, then DNS Manager on the new server to verify zones, policies, and forwarders.

Do not let cleanup automation race ahead of client reality.

Scavenging should be predictable and conservative during migration windows. The objective is to remove stale records after cutover, not to delete valid records while resolver paths are still moving.

• Review no-refresh and refresh intervals against real DHCP lease durations, reservation practices, and static-registration exceptions.
• Exclude critical records that are manually managed or generated by appliances that do not refresh cleanly.
• Confirm DHCP credentials or service accounts used for secure dynamic updates are valid on every server that will process registrations.
• Delay aggressive scavenging until clients have fully moved and stale NS or host records can be clearly distinguished from active ones.

Command path:

• Get-DnsServerScavenging
• Set-DnsServerScavenging -ScavengingState $true -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00
• Get-DnsServerResourceRecord -ZoneName corp.example.com -RRType A
• ipconfig /registerdns

GUI path: DNS Manager > Server Properties > Advanced and zone Properties > Aging to review intervals, dynamic updates, and cleanup settings.

Move consumers in batches so failures are attributable.

The safest DNS cutover is a client-targeting exercise. Shift small resolver populations first, compare answers, then expand to DHCP scopes, VPN users, servers, and remote sites.

• Start with an admin pilot, then one server segment, then one user-facing subnet before broad DHCP scope changes.
• Update DHCP option 006, static NIC settings, SD-WAN profiles, and VPN resolver lists in a planned order so conflicting answers are easy to trace.
• Use identical test queries from old and new resolver paths to catch conditional-forwarder or recursion mismatches before wider rollout.
• Keep old resolvers reachable during the change window so rollback is a server-address reversal instead of a rebuild.

Command path:

• Get-DhcpServerv4OptionValue -OptionId 6
• Set-DhcpServerv4OptionValue -ScopeId 10.10.20.0 -DnsServer 10.10.10.11,10.10.10.12
• Resolve-DnsName app.corp.example.com -Server 10.10.10.11
• nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com 10.10.10.11

GUI path: DHCP Manager > Scope Options > 006 DNS Servers and VPN or network-controller interfaces that publish resolver settings.

Testing has to prove who answers, not just that an answer exists.

Post-cutover checks should show that authoritative data, forwarder behavior, reverse lookups, and secure dynamic registration are all being served by the intended 2025 hosts.

• Compare authoritative answers, SOA serials, and NS records from old and new servers until the new hosts are unquestionably leading.
• Run forward and reverse lookups for domain members, appliances, VPN clients, and branch workloads to catch registration gaps.
• Review DNS Server event logs and failed query telemetry for recursion or delegation problems masked by client caching.
• Test branch and remote-site lookups explicitly because they often depend on different forwarders, policies, or WAN firewalls than headquarters.

Command path:

• Resolve-DnsName corp.example.com -Type SOA -Server HF-DC25-01
• Resolve-DnsName 10.10.20.45 -Type PTR -Server HF-DC25-01
• Get-WinEvent -LogName "DNS Server" -MaxEvents 50
• dcdiag /test:DNS /DnsDynamicUpdate

GUI path: DNS Manager, Event Viewer > Applications and Services Logs > DNS Server, and Active Directory Sites and Services for cross-site validation.

Retire the old resolvers only after stale records and hidden consumers are accounted for.

The last stage is controlled retirement: remove stale NS records, demote unused listeners, and document any application or network object that was still pinned to the previous resolver tier.

• Delete retired NS references, old host records, and unused delegations only after confirming the new servers answer those names reliably.
• Review firewalls, ACLs, monitoring probes, and backup jobs for references to old DNS server IPs or hostnames.
• Keep a final rollback note with the prior DHCP scope options and static resolver assignments for fast restoration if an edge case appears later.
• Publish the new authoritative resolver list, scavenging cadence, and validation evidence to operations.

Command path:

• Remove-DnsServerResourceRecord -ZoneName corp.example.com -RRType NS -Name "corp.example.com" -RecordData "HF-DC-OLD01.corp.example.com"
• Get-DnsServerResourceRecord -ZoneName corp.example.com -Name "_msdcs"
• dcdiag /test:DNS /e
• Clear-DnsServerCache -ComputerName HF-DC25-01 -Force

GUI path: DNS Manager > Zone properties, Name Servers, and resource-record views for final cleanup and retirement.