How to migrate WordPress without downtime

Migrating a WordPress site without downtime is mostly about preparation. If you move files, database, DNS, and SSL in the right order, visitors can continue using the live site while you test the new one in parallel. This is especially important for business websites, online shops, membership portals, and any WordPress installation where even a short interruption can affect conversions, rankings, or customer trust.

In a managed hosting or control panel environment such as Plesk, the migration process is usually straightforward, but the same core rules apply whether you are moving between hosting accounts, changing web servers, or switching to a new EU hosting platform. The goal is to keep the current site online until the new copy is fully ready, then switch traffic with minimal propagation time.

How WordPress migration without downtime works

To avoid downtime, you do not replace the live website immediately. Instead, you create a complete copy of the site on the new hosting account, verify that it works, and only then point the domain to the new environment. During this process, the original site remains accessible to visitors.

The main idea is simple:

  • copy the WordPress files and database to the new hosting platform;
  • test the site on a temporary URL, staging domain, or hosts file preview;
  • lower DNS TTL in advance so the domain change propagates faster;
  • freeze content updates briefly if the site receives frequent changes;
  • switch DNS only after the new site is confirmed to work correctly.

If the site is small and mostly static, the process can be almost seamless. For active websites, online stores, and sites with forms or orders, you need a controlled cutover plan.

Before you start: what to check

Preparation reduces risk more than any single migration tool. Before you move the site, review the following items:

  • Current WordPress version and active plugins.
  • PHP version, memory limit, and database version on the new host.
  • Disk space for files, backups, and media uploads.
  • Email services if the domain also handles mail.
  • SSL certificate status and renewal method.
  • CDN or caching layer that may need to be paused or refreshed.
  • Custom DNS records such as MX, SPF, DKIM, DMARC, and subdomains.

It is also a good idea to document the current setup, especially if the site uses custom Apache rules, redirects, or server-side caching. On managed hosting, those settings may need to be recreated in the new control panel.

Step 1: Lower DNS TTL in advance

If your DNS records are controlled by your registrar or DNS provider, reduce the TTL of the main records at least 24 to 48 hours before the switch. A shorter TTL means that DNS resolvers will refresh the IP address more quickly after the final cutover.

Common values are:

  • 300 seconds for a fast cutover;
  • 600 seconds if you want a slightly more conservative setting;
  • 3600 seconds is often too high if you want minimal propagation delay.

Focus on the A record and, if used, the AAAA record for the main domain and www subdomain. If your DNS is managed inside a hosting control panel, update the TTL there. This step does not move the site yet, but it makes the final migration smoother.

Step 2: Create a full backup of the current site

Before touching anything, create a complete backup of both WordPress files and the database. Even if you are using a migration plugin, keep a manual backup as a fallback.

What to back up

  • WordPress core files
  • wp-content folder, including themes, plugins, and uploads
  • Database with posts, pages, settings, users, and plugin data
  • Configuration files such as wp-config.php
  • Custom .htaccess rules if the site uses Apache redirects or security rules

In Plesk or a similar control panel, you can usually generate a full subscription backup or website backup. If you have SSH access, you may also archive files and export the database manually. Keep the backup off the server when possible, so you can restore it even if the old account becomes unavailable.

Step 3: Prepare the new hosting environment

Set up the destination hosting account before copying the site. Create the domain or subdomain in the control panel, assign the correct document root, and make sure the target PHP version matches the needs of your WordPress installation.

Check these items first:

  • PHP extension support for WordPress and key plugins;
  • database server availability and credentials;
  • file permissions for the web root;
  • temporary domain or preview URL for testing;
  • HTTPS support and certificate installation options.

If the new hosting platform includes a staging feature, use it. A staging copy is ideal for verifying the migrated site without affecting the live domain.

Step 4: Copy files and database to the new host

The exact method depends on your environment, but the principle is the same: copy the WordPress codebase, then import the database into the new account.

Using a migration plugin

Migration plugins can package the site, transfer it, and update URLs automatically. They are useful for smaller sites and for users who prefer a guided workflow. However, always verify that the plugin supports large databases, custom tables, and any caching or security plugins used on the site.

Using manual migration

Manual migration is often more reliable for larger sites or advanced setups:

  1. Export the database from the old host.
  2. Upload all WordPress files to the new web root.
  3. Create a new database and user on the destination host.
  4. Import the SQL dump into the new database.
  5. Update wp-config.php with the new database credentials.

If you are moving from one Apache-based environment to another, make sure any .htaccess rules are transferred correctly. If the new server uses Nginx in front of Apache or different rewrite handling, the redirect logic may need adjustment.

Step 5: Test the site before changing DNS

This is the most important part of a no-downtime migration. The new site must be tested while the public domain still points to the old host.

Common ways to test include:

  • Temporary URL provided by the host;
  • Hosts file override on your local computer;
  • Staging subdomain such as staging.example.com;
  • Preview links in a hosting control panel.

What to verify during testing

  • homepage and inner pages load correctly;
  • navigation, menus, and search work;
  • images, CSS, and JavaScript are loading from the correct path;
  • forms submit successfully;
  • shop checkout or booking flow works, if applicable;
  • admin login is accessible;
  • caching and performance settings behave as expected;
  • SSL certificate is active and the site loads over HTTPS.

Pay special attention to mixed content issues. After migration, some sites still reference old URLs in the database or hard-coded theme settings. This can cause browsers to show security warnings or broken assets.

Step 6: Update site URLs if needed

When a WordPress site moves to a new domain, subdomain, or different path, the database often needs a search and replace operation. This is not always required for a same-domain server move, but it is common in real migrations.

Review these areas:

  • site URL and home URL in WordPress settings;
  • serialized data used by plugins or themes;
  • image URLs inside page builder content;
  • custom CSS or JS files with hard-coded links;
  • internal links in posts and menus.

Use a tool that supports serialized data when performing search and replace. A simple database query can break plugin data if it changes values without understanding structure.

Step 7: Install SSL and confirm HTTPS

For a modern WordPress site, HTTPS should be ready before the switch. Most hosting platforms and control panels support automatic certificate issuance through Let’s Encrypt or a similar provider.

Check the following:

  • the certificate matches the domain and www version if needed;
  • HTTP requests redirect to HTTPS correctly;
  • the site does not loop between www and non-www versions;
  • browser warnings are not present;
  • admin area and login page also use HTTPS.

If the old site already used HTTPS, copy the redirect logic carefully. If the new environment uses different Apache rules, the redirect may need to be recreated in the control panel or in .htaccess.

Step 8: Switch DNS with minimal disruption

Once testing is complete, change the DNS A record or nameserver settings to point the domain to the new server. If you only changed the A record, propagation is usually faster and easier to control. If you changed nameservers, propagation can take longer depending on caching at registry and resolver level.

For a smooth switch:

  • make the DNS change during a low-traffic window;
  • keep the old hosting account active for a short overlap period;
  • do not change content on both sites at the same time unless you have a sync plan;
  • monitor logs and uptime after the switch.

Some visitors may still reach the old host for a short time because of DNS caching. That is normal. Keeping the old account live for at least 24 to 48 hours helps avoid errors during propagation.

Step 9: Handle new content during propagation

If the website receives updates while DNS is changing, you can lose posts, orders, or form submissions unless you manage the transition carefully. This is most relevant for active WordPress sites, especially WooCommerce stores or membership websites.

Best practices for active sites

  • pause editorial changes during the final cutover if possible;
  • put the site into maintenance mode only if absolutely necessary and for a short period;
  • export recent orders or entries if the system does not sync automatically;
  • check contact form delivery after the migration;
  • ensure cron jobs and scheduled tasks are running on the new host.

If you cannot freeze changes, consider a content delta approach: after the initial copy, migrate only the last database changes before switching DNS. This is more advanced, but it reduces the risk of missing user-generated content.

Common issues after migration

Even when the migration is done correctly, a few problems may appear. Most of them are configuration-related rather than data-loss related.

Broken images or missing CSS

This usually means paths were not updated correctly, permissions are wrong, or the cache still points to old URLs. Clear the WordPress cache, browser cache, and any CDN cache.

Login redirects or loop errors

Check the site URL, home URL, SSL setup, and redirect rules. A mismatch between http and https or www and non-www is a common cause.

Database connection errors

Confirm the database name, username, password, and host value in wp-config.php. In some hosting environments, the database host is not localhost.

Slow performance on the new host

Compare PHP versions, object cache support, opcode cache settings, and plugin load. A site can migrate successfully but still need tuning for the new server stack.

Email not working

If the domain also handles mail, verify MX records, SPF, DKIM, and SMTP configuration separately. Web hosting migration does not always move mail automatically.

Recommended migration checklist

  • Lower DNS TTL 24 to 48 hours before migration.
  • Create a full backup of files and database.
  • Prepare the new hosting account and database.
  • Copy WordPress files and import the database.
  • Update configuration and URLs if required.
  • Test on a temporary URL or staging domain.
  • Install and verify SSL.
  • Change DNS only after successful testing.
  • Keep the old host active during propagation.
  • Monitor logs, forms, and performance after launch.

When to use staging instead of direct migration

Staging is the safest option when the site is complex, heavily customized, or updated frequently. It allows you to test compatibility with themes, plugins, and server settings before users see the new version.

Use staging if:

  • you are migrating a WooCommerce store;
  • the site uses custom post types or page builders;
  • there are many active plugins;
  • the site is tied to payment gateways or API integrations;
  • you need to validate Apache rules, caching, or PHP settings.

For simple brochure websites, a direct file and database migration may be enough, as long as testing is done properly before DNS changes.

FAQ

Can WordPress be migrated with zero downtime?

In practice, you can get very close to zero downtime by preparing the new site in advance and switching DNS only after testing. A brief propagation overlap may still happen because of DNS caching, but visitors should continue reaching either the old or new version without an outage.

How long does WordPress migration usually take?

The technical copy can take minutes to a few hours depending on site size and database volume. The full process may take longer because of testing, DNS propagation, and SSL verification. Large shops and membership sites need more planning than small blogs.

Do I need maintenance mode?

Not always. For a carefully planned migration, you can keep the public site live until the final DNS cutover. Maintenance mode is useful only if you need to freeze changes briefly to prevent lost content during the switch.

What is the safest way to move a WordPress site?

The safest method is to clone the site to the new hosting environment, test it on a temporary URL or staging domain, verify SSL and functionality, and then update DNS after lowering TTL in advance.

Will my SEO be affected?

If the domain stays the same and the migration is clean, SEO impact should be minimal. Problems usually happen when pages go missing, redirects break, or the site becomes unavailable for too long. Keeping URLs consistent and monitoring for errors helps protect rankings.

Can I migrate WordPress from shared hosting to managed hosting?

Yes. In fact, moving from shared hosting to managed hosting is a common use case. The main difference is that the new platform may have stricter PHP settings, different caching layers, and control panel-based configuration, so testing is important.

Conclusion

Migrating WordPress without downtime is mainly a process of careful sequencing: prepare the new environment, clone the site, test it fully, and only then switch DNS. When done correctly, visitors keep using the current site while you validate the new one in parallel. For hosting environments in Europe, this approach is especially useful because it supports business continuity, protects SEO, and reduces risk during launch or platform changes.

If you are moving a WordPress site on a hosting control panel such as Plesk or to a managed hosting platform, take time to confirm PHP, SSL, database access, rewrite rules, and DNS before the final cutover. A well-planned migration is usually less about speed and more about avoiding surprises.

  • 0 Users Found This Useful
Was this answer helpful?