Step by Step Guide to Zero Downtime WordPress Migrations

Moving a live WordPress migrations site to a new host is stressful. One wrong move and visitors see “Error establishing a database connection”, half-loaded pages, or a maintenance screen right when you need your site the most.

This guide walks you through a zero downtime WordPress migrations workflow. You will use backups, a staging copy, and smart DNS changes so that visitors always see a working site, even while you are copying files and databases behind the scenes.

If you are brand new to migrations, you may also want a broader overview, but here we will focus specifically on a repeatable, zero downtime process that you can use for business-critical sites.

Prerequisites

Before you start, confirm that you have everything you need for a safe, zero downtime move. This is not a beginner task; missing access details is the easiest way to get stuck mid-migration.

• Admin access to the current WordPress migrations site (wp-admin).
• File access to the old host (SFTP/FTP or SSH + WP-CLI).
• Database access (phpMyAdmin or a similar tool).
• Access to the new hosting account where the site will live.
• Login to the DNS provider or domain registrar where your domain’s DNS records are managed.
• Enough disk space on the new host to store a full copy of your site.
• Time window when your site has lower traffic (for the final cutover).

Step 1: Plan Your Zero Downtime WordPress Migrations Strategy

Why this matters

A zero downtime WordPress Migrations is mostly about timing and traffic control. You keep the old site live, prepare a full copy on the new host, then switch DNS so that visitors gradually start hitting the new server without ever seeing an error page.

How to do it

1. List any “write-heavy” features on your site: comments, WooCommerce orders, membership signups, form entries, etc.
2. Choose a low-traffic time window (often late night or weekend for your main audience).
3. Decide how you will copy the site:
   • Migration plugin (backup and restore between hosts).
   • Manual copy with SFTP + database export/import.
   • Host-provided migration tools.
4. Decide how you will handle new content during the cutover:
   • Short “content freeze” (disable new orders/comments for 15–30 minutes), or
   • Final ultra-fast sync right before DNS change if you must stay fully writeable.
5. Schedule the final DNS switch and notify stakeholders (clients, editors, marketing team) in advance.

Checkpoint

You should have a written plan: when you will migrate, which tools you will use, and how you will handle new orders or content during cutover.

Troubleshooting

• Not sure about traffic patterns? Check your analytics for hourly traffic over the last week and pick the lowest-traffic window.
• Unsure which method to pick? If your site is small and simple, a migration plugin is often easiest. For bigger sites, manual or host-assisted WordPress Migrations are safer.

Step 2: Take Complete, Tested Backups

Why this matters

Zero downtime is pointless if a mistake corrupts your only copy of the site. You need at least one verified, restorable backup of both files and database before touching anything.

How to do it

1. On the old host, take a full file backup (the entire WordPress directory, including wp-content, themes, plugins, and uploads).
2. Export the database from phpMyAdmin or a similar tool as a .sql file.
3. Store the backups in at least two locations (for example, the new host and your local machine).
4. If you need a step-by-step backup walk-through, follow a dedicated tutorial on how to back up a WordPress site before continuing.

Checkpoint

You have verified that your backup files exist, are reasonably sized (not zero bytes), and can be opened locally (the .zip and .sql files are not obviously corrupted).

Troubleshooting

• Backups are too large to download: Ask your host for a temporary download link or use a backup plugin that can send archives directly to cloud storage.
• Database export times out: Export tables in smaller chunks (e.g., 50 tables at a time) or use WP-CLI from SSH.

Step 3: Set Up a Staging Copy on the New Host

Why this matters

This is where the “zero downtime” magic starts. You clone your live site to the new host but keep the domain pointing at the old server until everything is tested.

How to do it

1. Create a temporary URL or subdomain on the new host (for example, temp.yourdomain.com or a host-provided preview domain).
2. Create an empty database on the new host and note the database name, username, password, and host.
3. Upload your WordPress files (from the backup) to the document root of the temporary URL.
4. Edit wp-config.php to point to the new database credentials.
5. Import your database backup into the new database via phpMyAdmin or a similar tool.
6. If your host offers one-click staging, you can also follow a process to create a WordPress staging site and then adjust it to point to the new hosting environment.

Checkpoint

You can visit the temporary URL or staging URL and see a working copy of your site (even if URLs or images are not perfect yet). Logging into wp-admin on the staging copy works.

Troubleshooting

• Site redirects back to the live domain: Temporarily define WP_HOME and WP_SITEURL in wp-config.php to point to the temporary URL, or adjust URLs directly in the database.
• White screen of death: Enable WP_DEBUG in wp-config.php and check error logs on the new host.

Step 4: Sync Files and Database to the New Environment

Why this matters

Now you need the staging copy to be an up-to-date clone of your live site. Before you change DNS, both environments should match as closely as possible.

How to do it

1. On the old host, sync any new uploads that were added since your first backup (for example, by downloading the latest wp-content/uploads folders and uploading them to the new host).
2. Export a fresh copy of the live database to capture recent content and settings.
3. On the new host, put the staging site into maintenance mode temporarily to avoid conflicting writes.
4. Import the fresh database into the staging database, replacing the earlier import.
5. Run a search-and-replace for the old domain and paths if needed (carefully, and with a backup).

Optional: use WP-CLI for faster sync

If you have SSH and WP-CLI on both servers, you can export and import the database via command line (run these in your SSH terminal):

# On the OLD host
wp db export ~/live-site.sql

# Securely copy the file to the NEW host (example using scp)
scp ~/live-site.sql youruser@new-host:/home/youruser/

# On the NEW host
wp db import ~/live-site.sql

Checkpoint

Your staging copy on the new host now matches the current live site content. You can browse a few key pages and confirm that design, navigation, and core functionality work.

Troubleshooting

• Mixed content issues (HTTP/HTTPS): Ensure the new host has a valid SSL certificate and update WordPress and site URLs to use https://.
• Broken image paths: Confirm that the uploads folder copied correctly and file permissions are not overly restrictive.

Step 5: Lower DNS TTL Ahead of the Cutover

Why this matters

DNS caching is the main reason some visitors keep hitting the old server after your migration. Lowering the TTL (time to live) before the move makes DNS changes propagate faster.

How to do it

1. Log into your DNS provider or registrar where your domain’s DNS zone is hosted.
2. Locate the A record (or CNAME) that points your domain (for example, yourdomain.com and www.yourdomain.com) to the current server.
3. Lower the TTL for those records (commonly to 300 seconds or 5 minutes).
4. Wait at least one full TTL period so that the lower value has time to propagate.

Checkpoint

Your DNS zone now shows a low TTL (e.g., 300) for the records that will change. You have waited long enough for resolvers to refresh the new TTL setting.

Troubleshooting

• No TTL field visible: Some providers apply TTL at the zone level. Look for “Advanced settings” or similar options, or contact support.
• Using a CDN like Cloudflare: You may need to change DNS in the CDN dashboard instead of the registrar.

Step 6: Freeze Writes, Do the Final Sync, and Switch DNS

Why this matters

This is the critical moment. You want to avoid a scenario where a user places an order on the old site while some visitors are already on the new site. A short content freeze and final sync keep data consistent.

How to do it

1. Announce a short “content freeze” window (for example, 15–30 minutes) so your team knows not to publish posts, process orders manually, or edit settings.
2. On the live site (old host), temporarily disable:
   • New orders (switch WooCommerce to catalog mode or maintenance for checkout).
   • New registrations or comments if they are critical to your business.
3. Take a final database export from the old host.
4. Import this final export into the database on the new host (overwriting the staging database once more).
5. Confirm that the new host version still works correctly (quick spot-check: homepage, login, a key product or content page).
6. Return to your DNS provider and update the A/CNAME records to point to the new host’s IP or hostname.
7. Keep the old server running for several hours (or up to 24–48 hours) to handle any DNS stragglers.

Checkpoint

Within minutes, most visitors should start hitting the new server. Both the old and new servers show the same final content, but the old one is now effectively in “read-only” mode until you shut it down.

Troubleshooting

• Some people still see the old site: Ask them to clear DNS cache or try a different network. In most cases, this resolves within the TTL you configured earlier.
• SSL certificate errors after DNS switch: Make sure the SSL certificate is issued and correctly installed on the new host for your exact domain (and www if used).
• White screens only on the new server: Re-check PHP version, memory limits, and error logs. Some plugins/themes may require different settings than your old server.

Step 7: Test, Monitor, and Decommission the Old Host

Why this matters

After DNS has propagated, you still need to verify performance, security, and backups on the new environment. This is also when you safely shut down the old server.

How to do it

1. Test the new site from multiple devices and networks. Confirm that pages load quickly and correctly.
2. Log into wp-admin on the new host and check that all key plugins and themes are active and updated.
3. Trigger a test order, form submission, or registration to confirm that write operations work correctly.
4. Set up or verify backups on the new host (schedule, retention, remote storage).
5. Once you are confident everything is stable and all traffic has moved, remove the site from the old host and cancel that hosting plan.
6. Optionally raise the DNS TTL back to a more conservative value (e.g., 1800–3600 seconds) now that the migration is complete.

Checkpoint

Your site is running only on the new host, backups are configured, and the old hosting account has been safely decommissioned after a stable monitoring period.

Troubleshooting

• Unexpected slowdowns on the new host: Check PHP workers, caching configuration, and database performance. Consider upgrading the plan or using a caching plugin and CDN if needed.
• Broken cron jobs or scheduled tasks: Verify WordPress cron events and any server-level cron jobs that were configured on the old host.

For deeper issue diagnosis after migrations, use a dedicated guide on troubleshooting WordPress migration errors as a companion to this workflow.

Confidently Running Zero Downtime WordPress Migrations

A zero downtime WordPress Migrations is really a series of small, careful steps: verified backups, a staging copy on the new host, final syncing, and a planned DNS cutover with a short content freeze. When you treat each step as its own mini project, the move feels far less risky.

With this workflow, you can migrate WordPress sites for clients or your own business without scary “site down” moments. Document your process, refine your checklists, and you will be able to repeat this migration pattern across future projects with confidence.

Further Reading

• WordPress Migration Blog Guide
• WordPress Migration Checklist for Blogs
• WordPress Disaster Recovery Walkthrough
• Choosing Managed Hosting for WordPress

Frequently Asked Questions