How to Migrate Web Hosting Without Downtime

How to Migrate Web Hosting Without Downtime

Migrating a live website can feel risky, but with a careful plan we can move hosts while keeping the site online and avoiding data loss. The key is preparation: make a full copy of content and databases, test the copy on the new server, reduce DNS caching, perform a final quick sync, and switch DNS at the right moment. Below we walk through a practical, step-by-step process that works for static sites, CMS-driven sites (WordPress, Drupal, etc.), and custom apps.

Pre-migration checklist

• Inventory everything: list files, media, databases, DNS records (A, AAAA, CNAME, MX, TXT), SSL certificates, cron jobs, scheduled tasks, and third-party integrations (CDNs, analytics, APIs).
• Backups: take a full backup of files and databases and verify you can restore them locally. Store backups off-server.
• Credentials: ensure you have SSH, SFTP, database, control panel, and DNS provider logins for both old and new hosts.
• Maintenance window: pick a low-traffic window for the final cutover and alert stakeholders.
• Plan email handling: decide whether to keep MX records where they are or migrate email separately—email changes are a common source of lost messages.

Prepare the new host

Set up the new server to match the old environment as closely as possible: operating system packages, web server (Apache, Nginx), PHP/Python/Node versions, database server and extensions. Configure users, permissions, and any required firewall rules.

• Install SSL support (Let’s Encrypt or your certificate) but don’t activate it on the public domain until after DNS cuts over unless you will use the host’s temporary domain.
• Create the databases and database users, and configure any services (Redis, Elasticsearch) the site needs.
• Enable SSH access and set up key-based authentication for fast, secure transfers.

Initial file and database sync

Start with a full copy to the new host while the old site remains live. This reduces the work needed at cutover.

• Files: use rsync over SSH to mirror files and preserve permissions and symlinks. For large media sets, an initial copy followed by incremental sync is faster.
• Databases: perform a full dump (mysqldump, pg_dump) and import it to the new database. For high-traffic sites consider setting up temporary replication or logical replication so the new host can stay nearly in sync.
• Third-party data: export any search indexes, cached assets, or user-uploaded files handled outside the web root and import them.

After the initial sync, keep a documented list of files that change frequently (uploads, caches, logs) so you know what to resync later.

Test the site on the new host

Before changing DNS, verify the migrated site thoroughly. Use the hosts file or a staging domain to point your browser to the new server’s IP while the public domain still resolves to the old host.

• Check front-end pages, login, form submissions, and typical user flows.
• Verify database-driven features, search, and user accounts.
• Run a quick performance and error log check—fix obvious issues before cutover.

If you have a CDN, configure it to use the new origin (or keep using the old origin and update the origin at cutover). If the CDN is fronting both hosts during transition, be mindful of cached content and set low TTLs or purge caches when you switch.

Lower DNS TTL and schedule the final cutover

To minimize propagation delay, lower the DNS TTL for the A/AAAA/CNAME records ahead of time (we usually set it to a small value like 300 seconds) at least 24–48 hours before the final switch. This ensures most resolvers will respect the shorter cache.

• Record current DNS settings so you can restore them if needed.
• Notify stakeholders and choose a low-traffic time for the final sync and DNS update.

Final sync and DNS switch

Execute the final cutover in a tight sequence to avoid lost writes:

• Put the site into a short maintenance/read-only mode if it’s practical—this guarantees no new writes during sync. For forums, e-commerce carts, or high-write systems, consider a specialized approach (see below).
• Perform an incremental file sync (rsync) for changed files and a final database dump/import or apply replication delta. For very large databases, use binlog-based replication or tools that allow a near-instant switchover.
• Update DNS records to point to the new server IPs. Because TTL is low, most users will start resolving to the new host quickly.
• Monitor incoming connections on the new server and check logs for errors. Keep the old server running for a while to accept any straggler traffic.

For sites that cannot be taken into read-only mode (active e-commerce, high-frequency apps), we recommend temporary dual-writing at the application level (write to both databases) or use master-master replication so no writes are lost during the DNS propagation window.

Handle SSL, email and scheduled tasks

• SSL: once DNS points to the new host, obtain or install SSL certificates for the production domain and verify HTTPS. If you used the hosts file for testing, remember to request valid certificates after DNS updates or use ACME DNS validation if necessary.
• Email: verify MX and SPF/DKIM records. If you left MX records unchanged, test inbound/outbound mail. If you moved email hosting, keep the old mail server operational for a short overlap to capture delayed delivery.
• Cron jobs and background workers: replicate scheduled tasks and worker configs on the new host and start them only after the cutover. Ensure background jobs won’t run twice if both servers are active.

Verification and rollback plan

Monitor key metrics: HTTP 200 rates, error logs, performance, and user reports. Test edge cases like password resets, file uploads, and payment processing. Keep a clear rollback plan: if things go wrong, change the DNS back to the old host and resume service there while you fix issues.

• Keep both servers running for at least one DNS TTL period to catch cached lookups.
• If you need to roll back, do a final sync of any new data from the new host back to the old host before switching DNS back.

Post-migration clean-up and tips

• Once stable, raise DNS TTL back to normal to reduce DNS query volume.
• Decommission the old server only after you’re confident all traffic and services have moved and backups have been stored.
• Document the migration steps and problems encountered for future moves.

We’ve found that careful preparation and an explicit final-sync window are the real secrets to a zero-downtime migration. Plan for the parts that change most—the database and user uploads—test thoroughly on a staging IP, and have a rollback path. With those in place, you can move hosts with confidence and minimal user impact.