Introduction

For an active e-commerce store or lead generation business, taking the website down for hours during a server migration means lost sales and damaged reputation.

Amateur developers post 'Site Under Maintenance' banners for half a day while waiting for DNS propagation.

Professional infrastructure engineers execute zero-downtime cutovers where visitors never experience a single second of outage.

Here is the exact technical protocol for zero-downtime website and server migrations.

Zero-downtime server migration and DNS cutover protocol
Zero-downtime server migration and DNS cutover protocol

Step 1: Lower DNS TTL (Time-To-Live) 48 Hours in Advance

DNS records are cached by global ISP resolvers based on their TTL setting (often 86400 seconds / 24 hours).

Two days before the scheduled migration, reduce the TTL on your domain's A and CNAME records to 300 seconds (5 minutes).

This ensures that when you point the domain to the new server on launch day, global resolvers will pick up the new IP address in minutes rather than days.

Never skip this crucial preparatory step.

Step 2: Pre-Issue SSL/TLS Certificates on the Destination Server

If the new server does not have an active SSL certificate ready when DNS switches, visitors will see alarming 'Your connection is not private' security warnings.

Pre-issue Let's Encrypt certificates on the destination server using DNS-01 challenge verification via Cloudflare or certbot before pointing traffic.

Ensure Nginx or Apache is fully configured to serve HTTPS traffic with zero SSL handshake errors.

Verify the setup using local hosts file overriding before updating public DNS.

EXPLORE SPECIALIZED SERVICE

Server Migrations & DevOps

RECOMMENDED SERVICEServer Migrations & DevOpsTailored engineering, complete client ownership & clean code.
DIRECT INQUIRYDiscuss Your Project ScopeGet a transparent quote and delivery timeline within 24 hours.

Step 3: Database Synchronization and Instant Cutover

Place the old site in temporary read-only mode for e-commerce transactions to prevent split-brain database divergence.

Run a final rsync of new uploaded media files and an immediate mysqldump synchronization to the new database.

Update the DNS A record to the new server IP.

Because your TTL was reduced to 300 seconds, traffic transitions instantly to the new server with zero lost orders or broken sessions.

Frequently Asked Questions

When should a migration cutover be scheduled? — Schedule cutovers during your lowest traffic window, typically late Tuesday or Wednesday night (avoid Friday evenings).

How long should the old hosting account remain active? — Keep the old server running for at least 7 days post-migration as a safety fallback before canceling the subscription.

What if an unexpected error occurs on the new server? — Simply point the DNS A record back to the old server IP; the 300-second TTL allows instant rollback.

CONTINUE READING

Related Insights & Guides