How to Move WordPress Without Downtime

If you need to move a WordPress site to a new hosting account or platform, the safest approach is to prepare the new environment first, copy the files and database, test everything on the destination server, and only then switch traffic over. Done correctly, this avoids broken links, missing images, database errors, and the kind of downtime that can affect visitors, orders, and search visibility.

The exact method depends on how your site is set up, but the core principle is always the same: keep the old site live while you build and verify the new one, then make the DNS change only after the new copy is ready. In many hosting environments, this can be done with a temporary URL, hosts file testing, a staging domain, or a control panel such as Plesk.

What causes downtime during a WordPress move

Downtime usually happens when the live site is changed before the destination is fully working, or when DNS points visitors to a server that does not yet have the correct files, database, or configuration. Common causes include:

  • Copying files without exporting and importing the database.
  • Forgetting to update wp-config.php with the new database details.
  • Changing the domain too early, before testing the new copy.
  • Leaving DNS TTL too high, which slows down propagation.
  • Using an SSL certificate that is not installed on the new host.
  • Missing PHP extensions, memory limits, or rewrite rules on the new server.

If your site uses WooCommerce, membership features, booking forms, or other dynamic content, even a short interruption can affect active sessions and orders. For that reason, migration should be treated as a controlled switch rather than a simple file transfer.

The safest no-downtime migration process

The most reliable way to move WordPress without downtime is to clone the site to the new hosting account, verify it privately, and only then update DNS. This works well whether you are moving between shared hosting, managed WordPress hosting, or a VPS with a control panel such as Plesk.

1. Prepare the new hosting environment

Before copying anything, make sure the destination account has the right stack for WordPress. Check the following:

  • PHP version compatibility with your theme and plugins.
  • Database support, usually MySQL or MariaDB.
  • Enough disk space for files, backups, and media uploads.
  • Correct PHP extensions such as curl, mbstring, zip, and gd.
  • Apache or Nginx rewrite support for pretty permalinks.
  • SSL availability for HTTPS.

If you are using Plesk, create the domain or subscription first, then confirm the document root, PHP handler, and database access. In managed hosting platforms, the provider may preconfigure most of this, but it is still worth checking PHP version and memory limits before migration begins.

2. Lower the DNS TTL in advance

To reduce propagation time later, lower the TTL for your domain records at least 24 hours before the switch. A lower TTL means resolvers refresh records more frequently, which helps the move complete faster.

Typical values for a migration window are 300 seconds or 600 seconds. If you cannot change the TTL, the move can still work, but DNS changes may take longer to settle.

3. Back up the old site completely

Take a full backup of both files and database before making any changes. Store the backup in more than one place if possible. You should include:

  • The WordPress core files.
  • wp-content, especially themes, plugins, and uploads.
  • The database export.
  • Any custom configuration files such as .htaccess.
  • Additional files used by caching, security, or image optimization plugins.

If your host provides backup tools in the control panel, use them, but do not rely on a single backup snapshot. A manual export gives you more control if the migration needs troubleshooting.

4. Copy the files to the new host

Upload the site files to the new hosting account using SFTP, the file manager in your control panel, or a migration plugin. For larger sites, SFTP or a file transfer method through the hosting platform is usually more reliable than a browser upload.

Make sure the following are copied correctly:

  • All core WordPress files.
  • The entire wp-content directory.
  • Custom directories created by plugins or themes.
  • Hidden files such as .htaccess or .user.ini.

After upload, check file ownership and permissions. Incorrect permissions can cause failed media uploads, plugin errors, or update issues later.

5. Export and import the database

Export the WordPress database from the old host and import it into the new one. This step is essential because WordPress content, settings, menus, and plugin configuration are all stored in the database.

When importing, confirm that:

  • The database encoding is preserved, usually utf8mb4.
  • The table prefix matches the one in wp-config.php.
  • No tables are missing after import.
  • The database user has the correct privileges.

In Plesk or similar control panels, you can usually create a database and import a dump through phpMyAdmin or a database management tool. If the database is large, a command-line import is often faster and less likely to time out.

6. Update wp-config.php

Once the files and database are in place, update wp-config.php with the new database name, database user, password, and host. Confirm that the authentication salts and table prefix are correct.

If the destination host uses a different database host value, such as localhost or a specific internal hostname, use the value provided by the hosting platform. A wrong database host is one of the most common causes of a white screen after migration.

7. Test the site before changing DNS

Testing before DNS switch is the main step that prevents downtime. There are several ways to view the new site privately:

  • Use a temporary URL provided by the hosting company.
  • Edit your local hosts file to point the domain to the new IP.
  • Use a staging subdomain on the destination server.
  • Preview the site through a proxy or control panel feature if available.

During testing, check the following pages and features:

  • Homepage and key landing pages.
  • Contact forms.
  • Login and admin access.
  • Product pages, checkout, or booking flows if relevant.
  • Menus, widgets, images, and embedded media.
  • Permalinks and redirects.

Also confirm that CSS and JavaScript files load correctly. If the page loads without styling, the site may still be pointing to the old domain in the database or using hard-coded asset URLs.

How to move WordPress without downtime using a staging copy

For most sites, the best pattern is:

  1. Clone the site to the new host.
  2. Test the clone privately.
  3. Keep the old site live while testing.
  4. Freeze content changes shortly before the final cutover if the site is dynamic.
  5. Switch DNS only after verification.
  6. Monitor both the site and email after the change.

If your site publishes new content constantly, you may need a short content freeze for the final sync. For example, a store might pause new orders for a brief window, copy the final database changes, and then switch DNS. This keeps the public site available while minimizing the risk of lost data.

Updating URLs after migration

Many migrations require a search and replace in the database to update old URLs to the new domain or path. This is especially important if the old site used http and the new site uses https, or if the site moved from a temporary URL to the final domain.

Common examples include:

  • Changing http://old-domain.example to https://new-domain.example.
  • Replacing temporary subdomain references with the live domain.
  • Updating serialized data carefully when plugin settings store URLs.

Use a method that handles serialized data correctly. A standard database search in SQL can break some plugin settings if it changes text lengths in serialized fields. Many migration tools and WordPress-safe search and replace utilities avoid this problem.

SSL, redirects, and cache after the move

After DNS switches to the new host, complete a few post-migration checks as quickly as possible.

Install or renew SSL

Confirm that the SSL certificate is active for the domain on the new server. If HTTPS is not ready, browsers may show warnings or redirect loops. On managed hosting platforms, SSL is often available through the control panel, while in Plesk it can usually be enabled from the domain’s hosting settings.

Set the correct redirects

If you are changing the domain, preserving old URLs with 301 redirects is important for users and search engines. If the domain stays the same, check that the site forces a single preferred version, such as HTTPS with or without www, depending on your setup.

Clear caches

Clear any plugin cache, server cache, CDN cache, and browser cache after migration. Cached content can make it look as though the new server is not working properly when the issue is only stale content.

Special considerations for WooCommerce and dynamic sites

Static blogs are simpler to move than ecommerce sites, but many WordPress sites now handle more than basic content. If your installation includes WooCommerce, bookings, memberships, or user dashboards, a no-downtime move needs extra care.

  • Avoid migrating during peak traffic.
  • Pause checkout if you need a final database sync.
  • Check order emails after the move.
  • Verify payment gateway callbacks and webhook URLs.
  • Test account registration and password reset flows.

If orders or form entries are being written during the migration window, you may need a final incremental copy or a short maintenance window to prevent data loss. The goal is to keep the public site available while ensuring that new transactions are not missed.

Common problems and how to fix them

White screen after migration

This often points to a PHP version mismatch, missing extension, or plugin conflict. Check the error log in your hosting control panel and temporarily disable plugins by renaming the plugin directory if needed.

Database connection error

Recheck the database name, username, password, and host in wp-config.php. Also confirm the database user has privileges on the imported database.

Images not loading

Usually the site still references the old domain or file path. Run a safe search and replace for old URLs and clear all caches.

Redirect loop

This can happen when WordPress, the server, and SSL settings disagree about whether the site should use HTTP or HTTPS. Review the site URL settings, force one canonical version, and check any reverse proxy or CDN configuration.

Permalinks returning 404 errors

Save the permalink settings again in the WordPress admin to regenerate rewrite rules. Also confirm that Apache rewrite support is enabled and that .htaccess was copied correctly.

Using Plesk or another control panel for migration

If your hosting account uses Plesk, the migration process can be simpler because many tasks are available from the interface. Typical actions include creating the site, adding the database, importing backups, setting PHP options, enabling SSL, and reviewing logs. Similar features are available in many modern hosting platforms, even if the interface looks different.

Useful checks in a control panel include:

  • PHP version and handler selection.
  • Document root and domain mapping.
  • Database creation and access control.
  • File manager permissions.
  • SSL certificate status.
  • Error and access logs.

Logs are especially useful when the site works in one environment but not another. They often reveal missing files, denied access, or PHP errors that are not visible in the browser.

SEO checks before and after the switch

A WordPress migration can affect organic traffic if technical SEO is not preserved. Before moving, record the current site structure and ensure the following are maintained:

  • Page URLs where possible.
  • 301 redirects for any changed URLs.
  • Canonical tags.
  • XML sitemap location.
  • Robots.txt rules.
  • Metadata from SEO plugins.

After the move, resubmit the sitemap in search engine tools if the domain changed, and monitor crawl errors. If the site is on the same domain, search engines should usually pick up the new hosting location without needing a structural change, as long as the site remains accessible and fast.

Recommended migration checklist

  • Lower DNS TTL in advance.
  • Back up files and database.
  • Prepare the new hosting account.
  • Copy files and import the database.
  • Update wp-config.php.
  • Test the site privately.
  • Fix URL references if needed.
  • Install SSL and verify redirects.
  • Switch DNS only after testing.
  • Monitor logs, forms, and checkout after cutover.

Frequently asked questions

Can WordPress be moved without any downtime at all?

In most cases, yes, or at least with no noticeable downtime for visitors. The key is to build and test the new site before changing DNS. For dynamic sites, a very short freeze may still be needed to avoid losing orders or form submissions.

How long does DNS propagation take?

It depends on the TTL and the resolver caches used by internet providers. A low TTL can reduce the delay to minutes or a few hours, while a higher TTL can take longer. During propagation, some visitors may still reach the old server temporarily.

Do I need a migration plugin?

Not always. A plugin can be helpful for smaller sites or for users who prefer a guided process, but manual migration gives more control and is often better for larger or more complex setups. On managed hosting, platform tools may also automate much of the work.

What if my site uses a temporary domain on the new host?

That is fine for testing, but do not leave the site indexed on the temporary URL. Before going live, replace temporary URLs with the final domain and confirm that search engines cannot access the staging copy.

Should I move email with the website?

Only if your email is hosted with the same provider and you intentionally want to change it. If email is separate, keep MX records unchanged. A website move should not break mail unless DNS records are edited incorrectly.

Is it better to migrate during low traffic hours?

Yes. Even when there is no visible downtime, moving during a quiet period gives you more room to test and respond if anything needs attention after the DNS change.

Conclusion

Moving WordPress without downtime is mostly a matter of preparation and verification. Keep the old site live, clone the site to the new hosting account, test it privately, and only then switch DNS. If you also lower TTL in advance, confirm PHP and database compatibility, install SSL, and review logs after the move, the transition should be smooth for both visitors and administrators.

For hosting users working with a control panel such as Plesk or a managed WordPress platform, the process is usually straightforward once the site is staged correctly. The safest migration is not the fastest one; it is the one that lets you check every important part before customers ever notice a change.

  • 0 Users Found This Useful
Was this answer helpful?