Moving a site to a new host, cloud provider, or CDN feels done once files are uploaded and DNS is pointed. In practice, migrations fail quietly — broken redirects, stale SSL, missing email records, or cached old IPs that only show up for some visitors. Use this checklist in the first 48 hours after cutover, then again after TTL expires globally.
Before anything else, verify that your A, AAAA, and CNAME records resolve to the new destination — not the old server, not a parking page. Check both the apex domain and www. If you changed nameservers, confirm the registrar shows the new NS set and that glue records are correct.
Use a DNS lookup against your authoritative nameservers first, then a DNS propagation checker to see what resolvers worldwide are returning. Disagreement between regions is normal during TTL rollover; persistent splits after 24–48 hours usually mean a record was missed on one nameserver or an old TTL is still cached at your CDN edge.
A new host means a new certificate — or a new auto-SSL provisioning path. Common post-migration failures include serving the host's default certificate (wrong domain on the cert), an incomplete chain (missing intermediate CA), or HTTP still accessible without redirect.
Run an SSL check on every hostname you serve: apex, www, and any subdomains that should be live. Confirm expiry date, issuer, and that HTTP 301-redirects to HTTPS. If you use HSTS with preload, a certificate mistake is especially painful — fix it before advertising HSTS on the new stack.
Migrations are when redirect rules get lost. The old host had example.com → www.example.com; the new nginx config doesn't. Or trailing-slash rules changed, duplicating content at /about and /about/. Crawlers and bookmarks hit the wrong variant; SEO equity splits.
Manually test: apex to www (or the reverse, whichever is canonical), HTTP to HTTPS, legacy paths from the old site, and any locale or mobile redirects. Use curl or browser devtools to confirm status codes — 301 for permanent moves, not 302 unless intentional. Update your sitemap and internal links to match the canonical pattern on the new host.
Security and caching headers often live in server config, not application code. A move from Apache to nginx, or from origin to Cloudflare, frequently drops Content-Security-Policy, Strict-Transport-Security, and custom cache rules. Worse, the CDN may add its own headers that conflict with what your app sends.
Inspect live responses with the Header Inspector on key pages — homepage, login, API, static assets. Compare against a saved baseline from the old environment if you have one. Re-apply HSTS, CSP, X-Content-Type-Options, and Referrer-Policy at the new edge before announcing the migration complete.
Different hosts mean different geography, hardware, and CDN PoPs. A site that was fast on your old US-East dedicated box may be slower on a shared EU instance without a CDN — or dramatically faster once CDN caching is configured correctly.
Run a speed test from multiple perspectives after DNS has settled. Check Time to First Byte, total load time, and whether static assets are served with long cache headers. Warm the CDN cache by requesting top pages; cold-cache performance on launch day is not what users will see a week later, but it reveals misconfigured compression or missing HTTP/2.
DNS migrations break email more often than websites. MX records pointing to the old provider, missing SPF includes for the new sending service, or DKIM keys that were tied to the previous host's control panel — all cause silent mail loss or spam-folder delivery.
After updating DNS, confirm MX, SPF, DKIM, and DMARC with a DNS lookup. Send test messages to and from addresses on your domain. Check headers for SPF pass, DKIM pass, and DMARC alignment. If you use Google Workspace or Microsoft 365, follow their post-migration verification steps — they often require new TXT records.
Server-side scheduled tasks do not migrate with your database dump. Verify crontab entries, queue workers, and webhook URLs registered at third parties (Stripe, GitHub, Slack) still point to reachable endpoints on the new host. IP allowlists at partners or payment gateways may still reference the old server address.
Check application logs for failed outbound connections — license servers, SMTP relays, internal APIs over VPN. Firewall rules on the new host often block ports that were open on the old one.
New deployments frequently ship with debug mode on, default database credentials, or .env files copied from staging. Confirm production environment flags, rotate secrets that were exposed in migration tickets or chat logs, and restrict file permissions on upload directories.
If the new host uses a different PHP version, Node runtime, or database engine, run your test suite and spot-check admin functions — image uploads, PDF generation, search indexing — that depend on extensions that may not be installed by default.
Turn monitoring back on before you lower TTL for cutover, not after. Uptime checks, SSL expiry alerts, and error-rate dashboards should reference the new endpoints. Keep the old environment read-only for at least one TTL cycle so you can revert DNS if a critical issue appears.
Document what was changed: DNS records, certificate source, redirect rules, and CDN settings. Your future self — or the next migration — will need that map.
Work through DNS, SSL, headers, and speed in that order — each layer depends on the one before it. Quick links: DNS lookup, DNS propagation, SSL checker, speed test, and header inspector.
Start with DNS lookup →