How to Move a WordPress Website to a New Host Without Downtime

Moving a website often sounds more daunting than building it in the first place. You may have years of pages, images, plugins and search rankings invested in WordPress, plus contact forms or business email that simply cannot stop working.

The safest approach is not to cancel your current hosting and hope the new account works. It is to run the old and new environments in parallel, validate the replacement and switch traffic only when you are satisfied.

At MyFastWebHosting, we offer UK hosting for WordPress and website migration assistance. This guide explains the steps worth understanding whether you migrate yourself or ask a hosting team to help.

1. Plan the WordPress migration before touching DNS

Start by making a short inventory of what currently works. This sounds basic, but it prevents the common mistake of transferring the visible website while forgetting the email, scheduled jobs or third-party integrations that keep it running.

It is also worth choosing a quiet period for the final switch. A brochure website can usually be moved more easily than a busy WooCommerce shop, where a new order could arrive while you are exporting the database.

2. Create a full WordPress backup

Before moving anything, save a recoverable copy of your WordPress installation somewhere independent of both hosting accounts. A complete backup normally includes two separate parts:

• Website files: themes, plugins, uploads, WordPress files and configuration such as wp-config.php.
• Database: posts, pages, users, settings, menus, WooCommerce data and other database-stored content.

You can create these backups using a suitable migration plugin, your existing hosting control panel or a combination of secure file transfer and a database export. Check that the backup finishes successfully and can actually be restored.

The official WordPress backup documentation explains why both files and database matter.

3. Choose how to move WordPress

There is no single best migration method for every website. The right choice depends on the size of the installation, server access and how much content changes while you work.

For a straightforward brochure site, either approach may work well. If you use WooCommerce, a membership plugin, a multisite network or specialised integrations, agree a more detailed plan before cutover.

Moving from cPanel to DirectAdmin? The change involves more than a different dashboard. Mailboxes, databases, DNS records and site configuration must be checked. Our cPanel vs DirectAdmin comparison explains how the panels differ.

4. Prepare the new hosting account

Set up the destination hosting while your existing website continues to serve visitors. Match the important technical requirements before restoring or importing WordPress:

• Choose a compatible PHP version and confirm the extensions your plugins require.
• Check available storage, database support, memory limits and file-upload limits.
• Create the database and database user if your migration method requires it.
• Make sure the intended website directory and domain are correctly configured.
• Arrange a valid SSL certificate for the domain before or during cutover, as supported by the host.

When moving the site manually, the new database name, username and password may differ from those on the old server. If so, update the relevant values in wp-config.php. Keep that file private: it contains sensitive credentials.

WordPress’s official migration guide documents the file, database and configuration work involved.

5. Test the new website before the public switch

This is the most important stage for reducing downtime. Before touching your domain’s public DNS, arrange a way to view the new copy of the website using a local hosts-file override or a staging/preview method supplied by your new host.

Preview methods vary. A temporary URL does not always behave like the final domain, and a local hosts-file change needs the new server to be configured for the correct hostname and HTTPS.

Run through the website as a visitor would:

• Open the homepage and several important internal pages.
• Check photos, downloads, menus and links.
• Confirm WordPress login and the administration dashboard work.
• Test forms, email notifications and any SMTP plugin.
• Check mobile presentation, caching, redirects and HTTPS.
• For WooCommerce, test checkout safely in the payment provider’s test mode where possible.

6. Change DNS without rushing the cutover

Once the new site has passed its checks, update the relevant DNS records so visitors begin reaching the replacement host. Often this means changing the website’s A record (and AAAA record if IPv6 is used) while leaving unrelated records alone.

Understand DNS caching

DNS records have a time to live (TTL), which influences how long resolvers cache them. Where your DNS provider permits it, lowering the relevant record’s TTL well before the migration can reduce the time visitors continue using an old address. Lowering it at the last minute does not instantly clear earlier cached answers.

For example, you might arrange a 300-second TTL a day beforehand if your provider supports that value. Even then, caches and network behaviour vary; it is not a five-minute guarantee. Cloudflare’s TTL reference explains the difference.

Do not cancel the old hosting yet

During the changeover, some visitors may still reach the old server while others reach the new one. Keep the old site online and avoid making new edits in both places. Check the actual results from different networks rather than relying on one browser refresh.

If the old and new installations can accept separate transactions, comments or user registrations, you need a coordinated cutover or data-sync strategy. Simply running both copies publicly can lead to diverging databases.

7. Protect your domain email during the move

A website migration and an email migration are separate jobs, even when both services come from the same host. Before changing DNS, identify where messages are currently delivered.

• If email stays with Microsoft 365, Google Workspace or another provider, preserve its MX and relevant TXT records.
• If email moves to the new hosting account, create and test destination mailboxes and plan how existing messages will be copied.
• Review SPF, DKIM and DMARC settings to avoid mail delivery and authentication problems.
• Check the website’s contact form and transactional email after cutover.

Switching the domain’s nameservers can replace the entire managed DNS zone, not just the website address. If that is necessary, copy and verify all required website and mail records first.

8. Carry out the post-migration checks

After DNS changes begin taking effect, check the site again from a normal browser without a hosts-file override. Confirm that you are seeing the new server and then work through this final list.

If you kept the same domain and URL structure, you normally do not need sitewide 301 redirects simply because the server changed. Redirect planning becomes important when URLs or domains change as well.

Keep the old account available until traffic, transactions and mail delivery are confirmed stable, and allow time for older DNS caches to expire. Retain an independent backup even after you cancel the previous hosting.

Can you really move WordPress with zero downtime?

For a relatively static site, carefully preparing the new server, testing it and retaining the old server through the DNS transition can make the migration effectively seamless for most visitors.

For dynamic sites, however, zero downtime and zero data loss are separate goals. A store accepting orders every few minutes may require database replication, a final synchronisation or a brief period in which new orders are paused. The precise method depends on the application and how it stores changes.

That is why a migration plan should describe what will happen to both web traffic and new data, rather than simply promise that DNS will update quickly.

Frequently asked questions