--- title: "The Zero-Downtime Server Transfer Runbook: How We Move Live Websites, Databases, and Mailboxes Without Losing a Single Order or Email | GreenTree Field Notes" url: https://www.greentreehosting.com/field-notes/zero-downtime-server-migration-and-cutover-runbook/ description: "By Gene Salvatore: Interactive 7-step sysadmin server migration runbook—T-48h 60s TTL reduction, parallel host-header staging, forced 301! redirect verification, delta database sync, and 30-day safety net." format: text/markdown generated_from: prerendered HTML (build time) --- [ALL SYSADMIN FIELD NOTES & RUNBOOKS](https://www.greentreehosting.com/field-notes) FN-2026-02 // SERVER TRANSFERSServer Transfers & Cutovers · 9 min read # 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. Published: 2026-10-25•Last tested: 2026-10-25•Tested on Ubuntu 24.04 LTS & AlmaLinux 9, rsync 3.2+, PostgreSQL 16 (pg_dump/pg_restore) & BIND 9.18 01 // THE SYMPTOM 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. 02 // THE ROOT CAUSE 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. 03 // THE PERMANENT FIX 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. T-48 HOURS PREPARATION 60s DNS TTL Lower existing A, MX & TXT cache timers 48 hours before cutover so old caches expire worldwide TWO-PASS FILE & DB SYNC < 5 Sec Delta Bulk rsync runs 24h early; cutover pass transfers only changed bytes and final DB rows PRE-CUTOVER URL AUDIT 5 URL Sources Sitemap, Search Console, Wayback Machine, ScreamingFrog/Crawl & Backlinks mapped to 301s POST-CUTOVER WATCH 60s Telemetry LogBot.app & DNSBot.app verify HTTP 200, TLS 1.3 & database form capture every 60 seconds **Sysadmin Safety Notice:**Always test rsync --delete flags with --dry-run (-n) first, and verify that your target database backup restores cleanly on a staging database before running a live cutover. INTERACTIVE SYSADMIN RUNBOOK · SAVED IN YOUR BROWSER ## Interactive Server Transfer & Cutover Checklist Use this step-by-step runbook before moving any production website or database between servers: PROGRESS: 0 OF 6 STEPS VERIFIED (0%)CLICK ANY STEP TO CHECK OFF T-48h: Lower DNS TTLs to 60 seconds on the current authoritative nameservers If the current zone has a 3600s (1 hr) or 86400s (24 hr) TTL, lower it at least 24–48 hours before the cutover window and increment the SOA serial. T-36h: Inventory hidden dependencies (cron jobs, .env secrets, SMTP credentials, PHP/Node versions) Check /etc/crontab, user crontabs, systemd timers, outbound SMTP relays, and any hardcoded filesystem paths or IP allowlists. T-24h: Run Pass #1 bulk rsync and import a baseline database snapshot onto the new server Transfer the 99.9% of static media, uploads, and application files while the old server remains live, then test the new server using a local /etc/hosts override. T-2h: Pre-validate TLS certificates and verify the 5-source 301 redirect map Ensure Let’s Encrypt or commercial SSL certificates are already issued on the target server (using DNS-01 or pre-flight validation) so no visitor ever sees an HTTPS warning. Cutover Minute: Briefly hold writes, run Pass #2 delta rsync + final DB dump/restore, and flip DNS Because Pass #1 already copied bulk files, Pass #2 takes seconds. Update the A/AAAA records (with 60s TTL), verify SOA serial increment across all nameservers, and confirm live form submission. T+1h: Monitor old-server access logs until residual cached traffic drops to zero Keep the old server in read-only/proxy mode briefly while watching tail -f access.log to confirm every ISP resolver has picked up the new IP. FIELD NOTE 01 // WHY SERVER MOVES GO WRONG ## 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 | FIELD NOTE 02 // TWO-PASS RSYNC & HOSTS-FILE VERIFICATION ## 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. Two-Pass Rsync + Pre-Cutover curl --resolve Verification Commands ``` # 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" ``` ⚠ Test on a non-production system first and verify backups before running administrative commands. SYSADMIN Q&A ## 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. COMPANION CORNERSTONE REFERENCE GUIDE (/LIBRARY) ### 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. [Read Full Engineering Guide](https://www.greentreehosting.com/library/forensic-pre-cutover-crawl-and-zero-404-redirect-standard) WHITE-GLOVE MIGRATION INCLUDED ### 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. [Explore Managed Cloud & Migrations](https://www.greentreehosting.com/hosting)[Use Our 301 Cutover Validator Tool](https://www.greentreehosting.com/tools/forensic-301-cutover-and-seo-equity-validator) RELATED FIELD NOTES & RUNBOOKS ## Related Notes From the Sysadmin Desk [View All 8 Field Notes](https://www.greentreehosting.com/field-notes) [Server Transfers & Cutovers9 min readMoving Off Usage-Metered Cloud (Netlify Credits & Non-Pausing Supabase Compute): Our Production Cutover Runbook to Flat-Rate Docker & PostgreSQL 16Export 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.Open Field Note & Checklist](https://www.greentreehosting.com/field-notes/migrating-off-metered-netlify-and-supabase-to-flat-rate-docker-and-postgresql)[DNS & Linux Infrastructure7 min readAuthoritative 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.Open Field Note & Checklist](https://www.greentreehosting.com/field-notes/bind-dns-soa-serial-drift-and-60-second-ttl-troubleshooting)[SmarterMail & Mail Ops8 min readTransferring Business Email to SmarterMail Without Breaking Outlook, iPhones, Shared Calendars, or DMARCPre-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.Open Field Note & Checklist](https://www.greentreehosting.com/field-notes/smartermail-mailbox-migration-autodiscover-and-dmarc-alignment)