The Zero-Downtime Server Transfer Runbook: How We Move Live Websites, Databases, and Mailboxes Without Losing a Single Order or Email
Over the last 28 years, we have migrated hundreds of commercial websites, databases, and email domains off legacy shared hosts, aging VPS instances, and agency servers. A clean server transfer is never guesswork—it is a 5-stage sequence that starts 48 hours before cutover.
During a server move, half your visitors see the old server and half see the new one for 24 hours—causing lost form leads, missing database orders, SSL certificate warnings, and 404 errors on Google links.
Switching DNS or registrar nameservers while TTLs are still set to 3,600–86,400 seconds, doing a single slow file copy during live traffic, and failing to pre-crawl legacy URLs.
Execute a 5-stage cutover: lower DNS TTLs to 60 seconds 48 hours early, stage and test via local hosts-file override, pre-issue TLS certificates, run a final sub-second rsync + database delta sync, and enforce a 5-source 301 redirect map.
Interactive Server Transfer & Cutover Checklist
Use this step-by-step runbook before moving any production website or database between servers:
1. The Split-Brain Window: Why Changing Nameservers Without Lowering TTLs Loses Data
When a business owner or inexperienced developer moves a website to a new server, they typically copy the files over, export and import the database, and then log into their domain registrar to change the A record or nameservers—all in the same afternoon.
Here is what actually happens when you do that on a domain with a standard 4-hour (14400) or 24-hour (86400) DNS cache time: ISPs that cached your old IP ten minutes before your change will keep sending visitors to the old server for the rest of the day, while visitors on other networks land on the new server. If a customer submits a quote request, places an order, or sends an email that lands on the old server after you already exported the database, that lead is stranded on the decommissioned box.
Avoiding that split-brain window is simple once you respect DNS caching math: you must lower the TTL at least 24 to 48 hours before you move the site. Once the old TTL expires worldwide and every resolver is honoring a 60-second TTL, your actual cutover window shrinks from 24 hours down to roughly 60 seconds.
| Migration Phase | Typical "Same-Day Flip" Migration | GreenTree 5-Stage Zero-Downtime Protocol |
|---|---|---|
| DNS Cache Preparation | Flips A record or NS while TTL is still 3,600s–86,400s | Lowers TTL to 60s at T-48h so global caches expire before cutover |
| File & Media Transfer | Single large FTP/SCP copy during live cutover (hours of drift) | Two-pass rsync: bulk sync at T-24h, sub-second delta sync at cutover |
| Pre-Cutover Verification | Tests only after flipping public DNS (visitors find the bugs) | Verified via local hosts file & curl --resolve before public DNS moves |
| Legacy URL & SEO Preservation | Old page URLs return 404 Not Found after launch | Mandatory 5-source URL audit mapped to permanent 301 redirects |
2. Testing the New Server in Private Before a Single Visitor Sees It
You should never flip public DNS to find out whether your new server works. Before we move any domain’s DNS record, we stage the complete application and database on the new node and test it directly against the target IP address using curl --resolve and a local hosts-file entry (C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on Linux/macOS).
That lets our team click through every page, submit live test forms into the new PostgreSQL or MariaDB database, check response headers, and verify mobile layouts in a real browser while 100% of public traffic is still happily served by the existing server. When cutover arrives, we run our second-pass rsync delta and final database sync—which finishes in seconds because 99.9% of the bytes are already there.
# STAGE 1 (T-24h): Bulk Initial Sync (While Old Server Remains Live) rsync -avz --progress --stats /var/www/client-site/ deploy@new-node:/var/www/client-site/ # STAGE 2 (T-12h): Verify Target Server & TLS Headers Without Touching Public DNS curl -I --resolve www.clientdomain.com:443:203.0.113.50 https://www.clientdomain.com/ # STAGE 3 (Cutover Minute): Dry-Run First, Then Fast Delta Sync + Final DB Dump/Restore rsync -avzn --delete --stats /var/www/client-site/ deploy@new-node:/var/www/client-site/ rsync -avz --delete --stats /var/www/client-site/ deploy@new-node:/var/www/client-site/ pg_dump -Fc client_production_db | ssh deploy@new-node "pg_restore -d client_production_db --clean --if-exists"
Common Questions on Zero-Downtime Server Migration Runbook
How do I test a website on a new server IP before changing DNS?
Add a temporary line to your computer’s local hosts file (C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on Mac/Linux) mapping the domain name to the new server’s IP address, or run curl -I --resolve domain.com:443:NEW_IP https://domain.com/. Your browser will load the site from the new server while everyone else on the internet still sees the old server.
What if a visitor submits a contact form right during the 60-second DNS switch?
By lowering the DNS TTL to 60 seconds 48 hours ahead of time and keeping the old server proxying or forwarding to the new database during the transition window, any request that hits the old IP during cache expiration is still captured cleanly.
Why do so many website redesigns lose Google rankings right after launch?
Because the new site changes URL structures (for example, changing /services.html or /about-us/ to /services and /about) without mapping every historical URL to a 301 permanent redirect. Our 5-source pre-cutover crawl inventories Sitemap, Search Console, Wayback Machine, internal links, and backlinks before cutover.
The Zero-404 Domain Cutover Playbook: Migrating 20-Year-Old Corporate Domains Without Losing Rank
Explore our complete 5-source pre-cutover URL discovery standard (Sitemap, Search Console, Wayback Machine, Crawl & Backlinks) and forced 301! redirect methodology.
Moving Off Legacy Hosting, WordPress, or an Unreliable Server?
Every GreenTree Core Cloud ($99/mo), Core Cloud + Management ($199/mo), and custom Dedicated/Cluster plan includes our white-glove zero-downtime migration and 5-source 301 URL audit at no extra migration fee.
Related Notes From the Sysadmin Desk
Moving Off Usage-Metered Cloud (Netlify Credits & Non-Pausing Supabase Compute): Our Production Cutover Runbook to Flat-Rate Docker & PostgreSQL 16
Export the Supabase PostgreSQL schema and data via pg_dump, replace client-side VITE_SUPABASE_ANON_KEY calls with server-side Express + pg pool endpoints, translate netlify.toml redirects/headers into server.mjs, and deploy inside an isolated Docker container.
Authoritative BIND DNS in the Real World: Why Secondary Nameservers Serve Stale TTLs (And How to Catch Zone Drift in 60 Seconds)
Always increment the YYYYMMDDnn SOA serial before rndc reload, strip stale per-record TTL overrides, align registrar glue/NS records with the zone, and query every delegated nameserver directly.
Transferring Business Email to SmarterMail Without Breaking Outlook, iPhones, Shared Calendars, or DMARC
Pre-create all mailboxes, aliases, and lists; run a 2-pass IMAP sync (bulk pre-sync + post-MX delta sync); publish both CNAME and SRV Autodiscover records; and audit every sender before tightening DMARC.