During DNS migration, resolvers may legitimately retain the previous answer until its published TTL expires. Split traffic can also persist because of an unchanged AAAA record, www record, nameserver mismatch, local hosts file or CDN origin cache.
Protect new writes first. Two active WordPress databases can diverge while both sites appear normal.
Prove which server answered
Add a privacy-safe diagnostic response header or distinct static marker on each server, then test from affected networks.
Record:
hostname
resolver used
A and AAAA answer
response server marker
TLS certificate
timestamp/timezoneDo not expose internal hostnames, versions or origin IPs publicly longer than necessary.
Query authoritative records
Confirm registrar nameserver delegation and query the authoritative provider directly. Review root, www, wildcard and AAAA/CNAME.
If nameservers recently changed, parent delegation TTL and resolver caches also matter. Editing records at the old DNS provider has no effect after delegation moved.
Avoid repeated switching; each change creates another cache population.
Calculate the real propagation window
Use the TTL that was published before the change, not the current lowered value. A resolver can keep the old answer for the remainder of that original TTL.
Some local/corporate resolvers apply minimum caching. Browser/OS DNS, service workers and CDN cache add separate layers.
Document the expected maximum and test multiple resolvers; “global DNS checker” samples are not every visitor.
Check IPv6 and subdomains
An old AAAA record affects IPv6 users even if A is correct. www, language or admin subdomains can point separately.
Test A and AAAA paths with the actual hostname/SNI. Remove or update unused records deliberately; do not delete working email MX/TXT records while editing web DNS.
Keep record inventory/rollback.
Freeze or bridge writes
During split traffic, put the old site in read-only/maintenance or proxy/redirect it to the new server when technically safe. Do not use an HTTP redirect for payment webhooks if method/body/signature may be lost.
Preserve old database/files and logs. Identify posts, users, submissions or operational changes created on each side.
Avoid a final database overwrite that deletes new-server activity.
Reconcile diverged data
Define cutover timestamp and compare stable IDs/references. Merge through application-aware exports/APIs or a rehearsed procedure.
Filesystem uploads and database attachment records must move together. External emails/payments cannot be undone by copying WordPress.
Keep an audit of each reconciled record and prevent additional writes during final merge.
Protect external callbacks
Payment, form, SMTP and API providers may resolve DNS independently and retry for hours. Inventory webhook/callback endpoints and inspect which server receives them.
Where possible, update provider endpoints directly. Do not rely on a 301/302 for signed POST requests because method, body or signature context may be lost. Keep old-server logs and a safe handler/proxy through the documented retry window.
Control search-engine exposure
Both servers can be indexed if the old host remains reachable through an alternate preview hostname. Keep consistent canonical/noindex/access controls without blocking final production.
Do not submit removal requests for the real domain merely because one resolver is stale. Verify crawling after convergence and redirect only retired hostnames intentionally.
Check CDN and local overrides
Cloudflare DNS may be correct while its origin still points to the old IP. Review Load Balancer pools, origin rules and host header.
Remove local hosts-file entries, VPN/private DNS overrides and stale deployment environment variables after testing.
Do not purge every cache until evidence is captured; cache headers can identify the responding layer.
Complete and monitor cutover
Keep the old server online but non-writable through the TTL, CDN cache and external-callback retry window. Monitor its access logs for remaining traffic.
Test public/admin, email, cron and external callbacks on the new server. Recurring migration practice should lower TTL in advance and plan write reconciliation; DNS propagation is predictable, but unplanned dual writes are not.