Hosting Migration: How to Move Without Downtime

Switching hosts shouldn't take your site offline. With careful sequencing — set up the new host, replicate data, test, switch DNS — you migrate invisibly. The ugly alternative (download, upload, pray) produces 1-6 hours of downtime plus inevitable forgotten assets.

The three migration patterns

1. Cold cutover. Take site offline, transfer everything, bring it up at new host. Simple, downtime ~1-6h. Acceptable for personal projects.
2. Parallel with DNS TTL manipulation. Both hosts live during transition; DNS switch is the cutover. Zero downtime if done right. Most common.
3. Blue-green with health checks. Old and new environments both fully functional; traffic shifted gradually via load balancer. Near-zero risk, requires infrastructure most small sites don't have.

Pre-migration checklist

• Inventory everything: files, databases, environment variables, cron jobs, DNS records, SSL certs, CDN rules, email routing.
• Confirm new host has the software stack your app requires (PHP version, Node version, database type, extensions).
• Run a test deploy in a subdomain on the new host first (staging.yourdomain.com).
• Drop DNS TTL to 300 seconds (5 min) 24-48 hours before the planned cutover. Lower TTL means clients refresh faster after you switch.
• Warn users via banner if a brief maintenance window is unavoidable.

The zero-downtime DNS switch (step-by-step)

1. Day -7: Provision new host. Install stack. Copy latest database dump. Copy application files via rsync. Point test subdomain to new server.
2. Day -3: Drop DNS TTL to 300s on all records you'll switch.
3. Day -1: Final rsync of static files. Database replica option — either dump/load again at cutover, or set up replication.
4. T-1 hour: Put old site in read-only mode (or display maintenance banner for dynamic data).
5. T-0: Final database dump from old, restore on new. Update any absolute URLs (wp-config.php, settings tables). Verify new site fully functional.
6. T+0: Change A/AAAA records (or CNAMEs) to point to new host's IPs. Monitor propagation at dnschecker.org.
7. T+10-60 min: Most traffic has moved. Old host traffic drops to residual.
8. T+48h: Old host can be safely shut down.
9. T+72h: Raise DNS TTL back to 3600s or higher.

WordPress-specific gotchas

• wp-config.php — database credentials for new host.
• siteurl and home options — if domain changes, use WP-CLI wp search-replace to update serialized data.
• wp-content/uploads — biggest chunk to rsync.
• .htaccess or Nginx rewrite rules — re-create the pretty permalinks config.
• Caching plugin — flush all cache post-migration.
• SSL — provision new Let's Encrypt certificate on new server (will fail until DNS points at it).

Database transfer methods

SSL certificate handling

Let's Encrypt certs are domain-validated — they require the domain to resolve to the server running certbot. Two approaches:

1. DNS-01 challenge. Issue certs on new server before DNS switch using DNS TXT records. Works before traffic has moved.
2. HTTP-01 challenge post-switch. Accept brief HTTPS warning / fall back to HTTP for ~5 minutes immediately after DNS change until new server issues cert.

Email considerations

If your hosting provider also handles email (shared hosting often does), migrate email separately or earlier. MX records are independent of your A record — you can keep email on old provider while moving web to new provider during the test period. Check SPF/DKIM/DMARC records; update if sender IPs change.

Rollback plan

• Keep old host fully operational for 72 hours post-switch.
• If critical issue surfaces: change DNS back to old host (now propagates faster thanks to low TTL).
• Data written to new host during the brief production window needs to be carried back — keep a log of new inserts if possible.

Common mistakes

• Forgetting to migrate cron jobs.
• Hardcoded absolute URLs in application code.
• Cached DNS on your own machine making it look like migration worked when it didn't.
• Not raising TTL back up after migration — leaves DNS vulnerable to slower recovery from future changes.
• Deleting old host before verifying no critical data remained there.

FAQ

How long does a WordPress migration really take? For a small-medium site (<5 GB uploads, <500 MB DB): 2-4 hours of hands-on work, spread over a 7-10 day calendar to stage properly.

Can managed hosts migrate for me? Yes — Kinsta, WP Engine, Flywheel, SiteGround, and Cloudways all offer free migrations. Their engineers handle the zero-downtime sequence.

What about databases with multi-GB tables? Use replication (MySQL binlog, Postgres streaming, or managed tools like AWS DMS). Cut over when replication lag is zero.