WordPress Migration Without Downtime: A Step-by-Step Playbook

You can migrate a WordPress site to a new host — or a new domain — without taking it offline for a single minute, as long as you stage the move correctly and flip DNS only after the new environment is fully verified. The key insight most tutorials skip: the order of operations matters more than any individual tool you use. Get the sequence right and visitors never notice; get it wrong and you end up with broken links, lost emails, and a frantic late-night rollback.

This guide walks through the entire process in the right order, flags every common mistake, and tells you exactly when a professional hand is worth the time you'd otherwise spend debugging.

What "Downtime" Actually Means During a Migration

Downtime during a migration falls into two separate problems that most guides conflate:

• Visitor downtime — the window where your domain resolves to nothing, or to a broken site.
• Broken links and redirects — URLs that work on the old host but return 404s or wrong content on the new one, often because the database still contains hardcoded references to the old domain or environment.

Both are avoidable. Visitor downtime is mostly a DNS timing problem. Broken links are a database serialisation problem. The strategy below solves both.

Before You Touch Anything: Back Up and Audit

Take a complete, verified backup of the existing site — files and database — before any migration work begins. "Verified" means you've confirmed the backup archive actually opens and the SQL dump isn't truncated. A corrupted backup discovered mid-migration is a genuinely bad situation.

Also note:

• Your current PHP version (check Tools → Site Health in wp-admin, or ask your host).
• Any server-level requirements your plugins or theme declare (some require specific PHP extensions like imagick or redis).
• Active cron jobs or wp-config.php constants your site depends on.
• Custom .htaccess or Nginx rules beyond the standard WordPress rewrite block.

If your new host runs a different PHP version than your old one, read through Upgrading PHP for WordPress: What Breaks and How to Prepare before proceeding — a PHP mismatch on the new server is one of the most common reasons a migrated site immediately throws a white screen.

Step 1 — Set Up and Verify the New Environment First

Install WordPress on the new host before you copy anything. Confirm that:

• PHP, MySQL/MariaDB, and any required extensions are available and correctly versioned.
• HTTPS/SSL is provisioned (Let's Encrypt or your certificate of choice) and the new server responds correctly at its temporary URL or IP.
• Caching, object cache, and any server-level rules are configured to match your production setup.

Doing this first means you catch environment problems before your site data is involved, which makes debugging dramatically simpler.

Step 2 — Copy Files and Database to the New Host

There are a few safe ways to do this:

Using a migration plugin (easiest for most setups)

Plugins like Duplicator, All-in-One WP Migration, or WP Migrate handle packaging the database and files into a single archive and deploying it to the destination. For sites under roughly 500 MB, these work well. For larger sites, the free tiers often hit size limits — check before you start.

Manual migration (most reliable for complex or large sites)

1. Export the database via phpMyAdmin or wp db export with WP-CLI.
2. Transfer the wp-content folder (themes, plugins, uploads) via SFTP or rsync. Skip wp-core files — reinstall WordPress fresh on the destination instead of copying core files, to avoid stale or host-patched files causing subtle bugs.
3. Copy your wp-config.php and update the database credentials to match the new host's database.
4. Import the database into the new host's database via phpMyAdmin or wp db import.

Step 3 — Fix the Domain References in the Database (Critical Step)

WordPress stores absolute URLs in the database — in siteurl and home options, in post content, in widget data, and in serialised theme settings. If you're moving to a new domain, every one of those references needs to be updated, and they need to be updated correctly.

Do not do a raw SQL find-and-replace on a WordPress database. WordPress uses PHP serialised strings that include character-count metadata. A naive text replacement changes the content length without updating the character count, silently corrupting widget settings, Customizer data, and plugin options — breakage that often only surfaces weeks later.

The correct tool is Search Replace DB (by Interconnect/it) or WP-CLI's built-in serialisation-safe replacement:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables

Run this against the database on the new host, with the new site's credentials in wp-config.php. After running it, open the wp-admin dashboard via a /etc/hosts override (see Step 4) and verify that settings, menus, and widgets look correct before you touch DNS.

Step 4 — Test the New Site Without Touching DNS

This is the part most guides rush past, and it's what actually prevents downtime. While DNS still points to the old host, you can preview the new site by editing your local /etc/hosts file to point your domain to the new server's IP address. Only your machine sees the new site; everyone else still hits the old one.

On Mac/Linux, open /etc/hosts with sudo and add:

NEW.SERVER.IP.ADDRESS   yourdomain.com www.yourdomain.com

On Windows, the file lives at C:\Windows\System32\drivers\etc\hosts.

With this in place, check:

• Homepage, posts, pages, and archive pages all load correctly.
• Internal links go to the right domain (not the old one).
• Images load (no broken images from unresolved upload URLs).
• Forms, checkout, and login all function.
• SSL/HTTPS shows no mixed-content warnings.
• The admin dashboard is fully accessible and settings look right.

Only proceed to the DNS flip after every item on this list passes.

Step 5 — Lower Your DNS TTL Early

DNS TTL (Time to Live) controls how long resolvers cache your DNS records. The default is often 3,600 seconds (one hour) or higher. If you flip DNS with a high TTL, some visitors will continue hitting the old host for hours.

At least 24–48 hours before your planned migration window, lower your TTL to 300 seconds (five minutes) at your DNS registrar. Once the migration is confirmed good, you can raise it back to a normal value.

Step 6 — The DNS Flip and Parallel-Running Window

Update your DNS A record to point to the new server's IP. From this point, traffic will start shifting over as resolvers pick up the new record — within minutes for most users given your lowered TTL.

Keep the old host alive and serving the site for at least 48 hours after the DNS flip. Do not delete files, cancel the hosting account, or make structural changes to the old host during this window. Some ISPs and corporate networks have long resolver caches regardless of TTL.

Monitor both servers' access logs during this window. When traffic to the old server drops to near zero, you can decommission it safely.

Handling Redirects If the Domain Is Changing

If you're moving to an entirely new domain (not just a new host), set up 301 redirects on the old domain pointing to the equivalent URLs on the new one. The cleanest way is a wildcard redirect in the old server's .htaccess:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

Keep the old domain registered and the redirect live for at least 12 months. Search engines need time to re-index URLs under the new domain, and any external links pointing to the old domain will continue sending referral traffic and link equity via the 301s.

Also submit the new domain to Google Search Console and use the Change of Address tool to signal the domain move formally.

Common Things That Break After Migration (and How to Fix Them)

If you land on a 404 on every page except the homepage, the permalink flush above solves it in about ten seconds — we've written the full explanation in WordPress 404 on Every Page Except Homepage: Fixed.

When to Call a Professional

A straightforward site-to-site migration on the same domain is genuinely DIY-able with this guide. But hand the work off if any of the following are true:

• Your site is WooCommerce with live orders — order data, payment gateway credentials, and session handling need careful treatment.
• You're on a multisite network, which has its own URL structure and table prefixes that the standard search-replace doesn't fully handle.
• The old host is unresponsive or you've lost database access and need to work from a partial backup.
• The migration needs to happen inside a specific low-traffic window and you can't afford trial-and-error.
• You've already attempted the migration and something broke that you can't identify.

If any of those fit, get a free Mend diagnosis — a senior engineer will assess exactly what the migration involves, quote a flat price before touching anything, and most moves are completed the same day with a plain-English report of everything that changed.

Preventing Problems on Future Migrations

The biggest time-sink on any migration is not the move itself — it's debugging the environment differences you didn't spot beforehand. Build a pre-migration checklist that captures PHP version, active extensions, custom server rules, and plugin requirements, and verify the destination matches before you copy a single file. A managed care plan that includes regular backups also means you always have a clean restore point to fall back to if something goes sideways mid-move.

Migrations get dramatically easier when your site is already well-maintained: clean database, no stale plugins, up-to-date PHP, and no hardcoded IP addresses or environment-specific constants scattered through your theme files.