How to Migrate a WordPress Site to a New Host Without Downtime

Overview

If your goal is a WordPress migration without downtime, the core idea is simple: build the new environment first, verify it privately, and only then point live traffic to it. Most migration problems happen because the new host is configured after DNS changes instead of before them.

This checklist assumes a standard WordPress site with a database, uploads, plugins, and a domain that you control. The exact tools vary by host, but the sequence remains consistent:

1. Audit the current site.
2. Lower DNS risk where possible.
3. Back up everything.
4. Set up the new hosting environment.
5. Copy WordPress files and database.
6. Update configuration and test on the new server.
7. Handle SSL, email, caching, and cron details.
8. Change DNS only after the new site is ready.
9. Monitor traffic, errors, forms, and admin access.
10. Keep the old host active until the move is clearly complete.

If you remember only one principle, make it this: do not cancel the old host immediately after changing DNS. DNS propagation, stale caches, and background tasks can still send some visitors to the old environment for a period of time.

Pre-migration checklist

• List your domain registrar, DNS provider, old host, and new host.
• Confirm WordPress version, PHP version, database engine, and any server-specific requirements.
• Export a full file backup and a database backup.
• Document active plugins, themes, custom code, redirects, cron jobs, SSL setup, and email routing.
• Check disk usage so the new host has enough space for files, backups, and logs.
• Review TTL values on critical DNS records if you plan to reduce them before cutover.
• Identify anything that writes data constantly, such as WooCommerce orders, membership signups, support forms, booking tools, or comments.

For supporting tasks, it helps to keep related guides nearby. If you need help with DNS basics, see How to Point a Domain to Your Website: DNS Records Explained for Beginners. If you need more context on propagation timing, bookmark DNS Propagation Checker Guide: How Long DNS Changes Take and What to Do While Waiting.

Checklist by scenario

This section breaks the migration into practical scenarios so you can follow the right path instead of forcing one generic process onto every site.

Scenario 1: Standard WordPress site with low content changes

This is the simplest case: a brochure site, blog, or company website where content is not changing every minute.

1. Reduce TTL ahead of time if practical. If you manage DNS directly, lowering TTL before migration can shorten the effect of cached records later. Do this in advance rather than at cutover time.
2. Create backups. Download all WordPress files, especially wp-content, and export the database. Store backups outside both hosting accounts.
3. Provision the new host. Create the site, database, database user, PHP settings, and any needed server-level configuration.
4. Copy files. Upload WordPress files to the new host. For large sites, use SSH, rsync, or your host's migration utility if available.
5. Import the database. Restore the SQL dump to the new database.
6. Update wp-config.php. Set the new database name, username, password, and host. Keep salts and table prefix intact unless you intentionally changed them.
7. Test using a temporary URL or hosts file. Confirm the site loads from the new host before touching DNS.
8. Check permalinks, media, plugins, forms, and admin login.
9. Issue or install SSL on the new host. HTTPS should work before or immediately after cutover, depending on your host's certificate flow.
10. Change DNS. Update the A record, CNAME, or nameservers based on your setup.
11. Monitor both environments. Keep the old host active until traffic has clearly shifted and no data is being written there.

Scenario 2: WooCommerce, membership, or any site with live transactions

This is where most downtime fears are justified. If the site receives orders, account changes, or bookings during migration, your main risk is not only downtime but also split data: some transactions reaching the old server while others hit the new one.

1. Choose a low-traffic migration window. A quiet period reduces the chance of data divergence.
2. Prepare the new host completely in advance. Do not start setup during the cutover window.
3. Make an initial copy of files and database.
4. Test the cloned site privately. Avoid sending real customer traffic to it yet.
5. At cutover, freeze changes briefly if your workflow allows. Options include maintenance mode, pausing checkout, temporarily disabling new registrations, or announcing a short maintenance window.
6. Take a final database export from the old host. This captures the last-minute orders or submissions.
7. Import the final database to the new host. If uploads changed during the last window, sync those too.
8. Verify transactional functions. Test checkout, login, account pages, payment callbacks where possible, and outbound email.
9. Switch DNS.
10. Watch logs and order flow closely. Compare the final entries on the old host with the first entries on the new one to make sure nothing was missed.

If performance is one reason for the move, pair this migration with a post-move review using How to Speed Up a WordPress Site: Performance Checklist You Can Reuse.

Scenario 3: Domain stays the same, but server stack changes

Sometimes the domain is unchanged, but the new host uses a different PHP version, object cache, web server, file permissions model, or security layer. In that case, the migration is not just a transfer; it is also an environment change.

• Check PHP compatibility for themes and plugins.
• Review file permissions and ownership if moving between managed hosting and VPS setups.
• Confirm whether the new host uses Apache, Nginx, or a managed abstraction.
• Translate redirect rules if needed.
• Review caching behavior at plugin, server, and CDN levels.
• Test scheduled tasks and background jobs.
• Verify image processing, backup jobs, and any custom scripts outside WordPress.

If pages start failing after the move, likely places to check include permalink rules, caching, PHP compatibility, and server configuration. For related troubleshooting, see How to Fix the WordPress 404 Error and WordPress White Screen of Death Fix Guide.

Scenario 4: Manual migration versus host migration plugin

Both can work. A migration plugin may be faster for standard sites, while manual migration gives you more control for large or unusual setups.

Use a migration plugin when:

• The site is a typical WordPress install.
• Your host supports the plugin's workflow.
• You want a faster all-in-one export/import process.

Use manual migration when:

• The site is large or complex.
• You need control over database imports and file syncs.
• You are changing infrastructure or server behavior.
• You need to verify each step independently.

Whichever method you use, the no-downtime principle stays the same: prepare, test privately, then cut over.

What to double-check

Before you point the domain to the new host, work through this verification list. These checks catch most issues while the old site is still safely serving visitors.

WordPress configuration

• Database credentials: confirm DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST.
• Site URL behavior: make sure the site resolves correctly under the production domain and does not force the temporary URL.
• Permalinks: resave them in the admin if pages return 404 errors.
• Uploads: verify images, PDFs, and generated thumbnails.
• Plugin licensing: some plugins bind to domains or servers and may need reactivation.
• Cron jobs: check WordPress cron and any server cron tasks for backups, imports, or scheduled publishing.

Infrastructure and DNS

• DNS records: know exactly which records will change. Do not accidentally overwrite mail-related DNS when changing web hosting.
• Nameservers versus individual records: changing nameservers is broader and riskier than changing a single A record if other services depend on the same zone.
• CDN and proxy settings: if you use a CDN or reverse proxy, confirm the origin IP, SSL mode, and caching behavior.
• Firewall and WAF rules: verify that login, admin AJAX, REST API, and webhook endpoints are not blocked.

SSL and mixed content

• Install the certificate on the new host.
• Confirm the redirect from HTTP to HTTPS works as expected.
• Look for mixed-content warnings caused by hardcoded asset URLs.
• Check secure cookies, login screens, and checkout flows.

For deeper HTTPS troubleshooting, see How to Set Up SSL Certificates: HTTPS Installation and Common Fixes.

Functional testing checklist

• Homepage loads correctly.
• Main navigation works.
• Key landing pages render without layout issues.
• Forms send and deliver.
• Search works.
• Admin login works.
• User registration or password reset works if applicable.
• Checkout, cart, or payment flow works if applicable.
• Robots rules and indexing settings are correct.
• Backups are running on the new host.

If layout or script issues appear only on the new server, use Browser DevTools to Troubleshoot CSS, JavaScript, and Network Errors.

Common mistakes

These are the avoidable errors that turn an otherwise straightforward WordPress host migration into a stressful recovery job.

Changing DNS too early

This is the most common mistake. If DNS points to a server that is not fully tested, visitors become your testers. Always validate the new host before sending production traffic to it.

Not taking a final database sync for active sites

If the site receives form submissions, orders, comments, or user changes during the migration window, an old database export is not enough. You need a final sync close to cutover.

Overlooking email and other non-web DNS records

Web hosting changes do not automatically mean email should move too. If you replace the full DNS zone or nameservers without checking MX, SPF, DKIM, and other records, you can fix the website and break mail at the same time.

Cancelling the old host immediately

Even after the switch looks successful from your location, some users may still resolve the old destination temporarily. Keep the old account live until traffic, logs, and forms indicate the move is truly complete.

Forgetting caches

WordPress cache plugins, server caches, object caches, browser caches, and CDN caches can all serve stale content. After cutover, purge caches in a deliberate order and verify the origin server is serving the current version.

Ignoring file paths and server-specific settings

Absolute paths, custom includes, backup scripts, and security rules often break when the server layout changes. Review anything in custom code, .htaccess, Nginx rules, or deployment scripts that references the old environment.

Leaving a noindex or maintenance setting enabled

Temporary staging protections are useful, but they should not survive the move to production. Check search visibility, robots settings, and maintenance mode status after launch.

For a broader go-live review, use Website Launch Checklist: Everything to Test Before You Go Live.

When to revisit

This migration checklist is worth revisiting before any infrastructure change, not just a full host move. The details that change over time are usually the ones that cause trouble: DNS workflows, SSL handling, caching layers, PHP versions, plugin behavior, and the site's own transaction patterns.

Review and update your plan when any of the following is true:

• You are planning seasonal traffic peaks and want a safer migration window.
• You are switching hosts, control panels, or cloud providers.
• You are adding a CDN, proxy, or new security layer.
• You are upgrading PHP or changing the server stack.
• You are moving from a low-change site to a store, membership site, or booking workflow.
• Your backup or deployment process has changed since the last migration.

A practical action plan to save for next time

1. Create a one-page migration worksheet with registrar, DNS provider, old host, new host, SSL method, and rollback notes.
2. Keep a current inventory of plugins, custom code, cron jobs, redirects, and external integrations.
3. Maintain tested backups that are stored off-host.
4. Document how you test a site privately before DNS cutover.
5. Write a post-migration checklist covering pages, forms, admin access, SSL, email, and analytics.
6. Schedule a final review 24 to 48 hours after cutover to catch delayed issues.

If you expect to move again, bookmark this article alongside your DNS and SSL references. A successful WordPress migration without downtime is usually not about one clever trick. It is about doing ordinary tasks in the right order, with a rollback path, and with enough verification to avoid surprises.

For readers comparing approaches, you may also want the related walkthrough Step-by-Step Guide to Migrating a WordPress Site to a New Host with Zero Downtime.