Zero-Downtime Website Migration Checklist for DNS, SSL, Databases, and Email

Why Unplanned Server Migrations Break Company Email and SSL Certificates

We frequently get emergency calls from businesses whose previous agency tried to move their website to a new host by switching nameservers on Friday afternoon. Within an hour, company Google Workspace or Microsoft 365 emails stop arriving because the MX and SPF records were not copied over, and shoppers see browser SSL security warnings.

A production server migration should never involve downtime, broken email delivery, or lost customer orders. Achieving a zero-downtime cutover requires separating DNS management from web hosting and following a strict sequence forty-eight hours before the switch.

Lowering DNS TTLs and Auditing Zone Records 48 Hours Before Cutover

Every DNS record has a Time-To-Live (TTL) value that tells ISP resolvers around the world how long to cache the IP address. If your domain A record has a default TTL of 14,400 seconds (four hours), changing the IP address means some visitors will still hit the old server four hours later.

Two days before migration, we export a complete backup of the existing DNS zone file, verify every MX, TXT, SPF, DKIM, DMARC, and subdomain CNAME record, and lower the TTL on the web A and AAAA records down to 300 seconds.

• Change only the specific A, AAAA, or www CNAME records pointing to the web server instead of replacing entire domain nameservers.
• Provision and verify Let's Encrypt or Cloudflare origin SSL certificates on the new server before updating public DNS.
• Test the migrated site on the new server IP using local /etc/hosts overrides across desktop and mobile flows.
• Verify PHP version, cron schedules, queue workers, and outbound transactional SMTP credentials on the destination server.

Preventing Split-Brain Database Writes During the DNS Switch

For static brochures, having traffic hit both old and new servers during a five-minute DNS propagation window does not matter. For an e-commerce store or SaaS portal, having Customer A place an order on the old server database while Customer B places an order on the new server database creates a split-brain mess.

To prevent split-brain writes, we either proxy web traffic through Cloudflare for an instant origin IP swap, or we configure the old web server to connect remotely (or proxy requests via Nginx) to the new server database during the brief propagation window.

Post-Cutover Verification and 301 Redirect Checks

Immediately after updating the DNS A record, our team runs an automated verification script that checks HTTP status codes, SSL certificate chains, checkout form submissions, webhook endpoints, and Google Search Console crawl connectivity.

We keep the old server online in read-only archival mode for seven days as a safety net before decommissioning it cleanly.

We also document the entire server architecture, DNS zone layout, SSL renewal hooks, and database credentials in a clear runbook shared with your internal team. Your company retains full administrative ownership of every domain and cloud account.