DNS cutover should expose a site already proven on its new server. It should not be the moment you discover missing uploads, a PHP mismatch or broken checkout. Test with the real hostname before changing public records, and retain a clear rollback route.
Record current DNS and ownership
Export or screenshot authoritative A, AAAA, CNAME, MX, TXT and CAA records with TTLs. Confirm who controls the registrar, DNS provider and Cloudflare account. Identify DNSSEC before changing nameservers.
Do not recreate only web records. Mail authentication and service verification records are easy to omit and can fail later.
Confirm the final migration state
Set a content freeze or plan a final database delta. Compare recent posts, users, submissions or orders between source and destination. Ensure files transferred after the first copy.
Take a pre-cutover backup on both sides and record its location and time.
Test the real hostname against the new IP
Use a hosts entry or a request preserving Host and TLS SNI:
curl -I --resolve example.com:443:203.0.113.20 https://example.com/Test root and www, HTTP and HTTPS, plus important inner URLs. IP-only browsing can select the wrong virtual host and is not an equivalent test.
Validate TLS and redirects
Ensure the certificate covers every public hostname and is served by the new origin. Check the entire redirect chain for a single canonical destination without loops.
If Let’s Encrypt requires live DNS, arrange issuance deliberately and know what visitors will receive during the short interval. Do not disable HTTPS enforcement without a timed plan.
Exercise critical WordPress paths
Verify login, editor, media, search, permalinks, REST, cron, forms and email. Test business-critical transactions using approved sandbox methods. Inspect PHP and server logs after these actions.
Confirm robots controls, canonical tags and sitemaps contain production URLs. Remove staging access restrictions only when public launch is intended.
Check mail separately
Preserve MX records if mailboxes are not moving. Verify SPF, DKIM and DMARC still authorise the application’s sending service and test outbound SMTP from the new server.
Changing an A record does not normally require changing MX. However, an MX that points to the bare domain needs careful review because the bare domain’s address is changing.
Record the outcome and keep the test message identifier with the cutover notes.
Review proxy and cache settings
If Cloudflare or another proxy is involved, confirm origin address, SSL mode, cache exclusions and firewall access. Purge only after the destination is ready.
Check both A and AAAA. Leaving old IPv6 sends a subset of users to the previous server and produces confusing intermittent reports.
Set cutover and rollback criteria
Write the exact records to change, responsible person, observation period and measurable rollback triggers. Keep old hosting intact and preferably read-only. Avoid making unrelated plugin or design changes during cutover.
Lower TTL in advance only when useful; lowering it moments before the switch does not change already cached answers.
Monitor after the switch
Query several public resolvers, then inspect real traffic, status codes, PHP errors, certificate and application events. Compare origin logs so you know when traffic has moved.
Watch forms, email and scheduled tasks, not only uptime. Some users can legitimately retain old DNS until their cached TTL expires.
Close the migration carefully
After the observation window, reconcile any writes that reached the old site, increase TTL if appropriate and remove temporary access. Keep the old environment for the agreed rollback period before cancellation.
Recurring maintenance should retain DNS exports, certificate alerts and a current migration checklist. A controlled cutover is reversible, observable and deliberately boring.