How to Migrate WordPress to a New Host Without Downtime or Lost Orders

Short answer: To migrate WordPress to a new host without downtime, keep the old site running while you build an exact copy on the new server. Test that copy through your computer’s hosts file so the site’s URLs never change. Then pause orders and edits, copy the database one last time, and point DNS at the new server. Keep the old server untouched until traffic, email and scheduled tasks have all moved. Most failed moves come from what gets left behind (email records, a final batch of orders, scheduled tasks still running on the old copy), not from copying the files.

Our guide to WordPress hosting benefits covers why a site might need a better host and what to look for in one. This article covers what comes next: the move itself, step by step, for a WordPress site that keeps its domain name. If you’re still deciding whether to switch providers or just upgrade your plan, start with our guide to upgrading your web hosting plan, which also gives a short general checklist for any host move.

What are you actually moving?

A WordPress site is more than its files and database. A host move can touch up to eight separate things, and only the first two live inside WordPress:

Write down which of these apply to your site before you start. The domain registration is a separate item again. 4GoodHosting’s guide to transferring a domain makes the point directly: transferring the registration is separate from moving website files. You don’t need to transfer the domain to move the site, and doing both at once adds a second moving part. Move the site first, then transfer the registration later if you want everything with one provider.

Should your new host do the migration, or should you?

If the new host offers to move the site for you, that’s usually the lower-risk route. The host does migrations regularly and can see both ends of the copy on its own servers. 4GoodHosting’s migration guide describes its offer like this:

• It can migrate site, email, CMS and databases.
• The free migration requires prepaid annual (or longer) billing.
• It covers up to 20 GB at no charge.
• You open a ticket after signup with the old host’s login details (or a cPanel token), the list of domains, and your preferred cutover time.

Even when the host does the copying, the decisions in this guide are still yours. You choose the cutover time, check the new copy, decide when to pause orders, and decide when the old server can go. Ask the host which of those steps it handles and which it leaves to you.

Doing it yourself makes sense when the site is small, you’re comfortable with SFTP and a database tool, or the host doesn’t offer migration help. There are three common DIY routes:

• A migration plugin packages files and database on the old site and unpacks them on the new one. It’s usually the easiest route for a small site. Check the plugin’s size limits against your site before you rely on it.
• A manual copy: download the files over SFTP, export the database, create a new database on the new host, then upload and import. 4GoodHosting’s SFTP guide covers the FileZilla settings (SFTP on port 22, with the site usually in public_html).
• A cPanel backup restored on the new host, when both hosts use cPanel. 4GoodHosting’s DIY checklist lists restoring a cPanel backup as an alternative to uploading the files over SFTP.

Whichever route you choose, take a full backup first and keep a copy off both servers. Our website backup strategy guide explains what a complete backup includes.

How to migrate WordPress to a new host: the zero-downtime timeline

Visitors only notice a move when the old site is switched off before every visitor and service has reached the new one. The timeline below avoids that gap by keeping both copies working and switching DNS only once the new copy has been tested. The timings are a typical pattern, not a rule.

Step 1: Lower the TTL and copy your DNS zone

Every DNS record has a TTL (time to live), which tells resolvers how long they can keep a cached copy. Google’s guide to changing your web hosting recommends lowering it to a conservative low value, such as a few hours, at least a week before the move, so DNS caches refresh faster when you switch.

There are two ways to point the domain at a new server, and they behave differently:

• Change the A record (and AAAA, if there is one) at your current DNS provider. The TTL you lowered applies to that record, so the switch spreads quickly. Every other record (email, verification, subdomains) stays where it is.
• Change the nameservers to the new host’s. This moves the whole DNS zone. The new host’s zone has to contain every record the old one had, or anything you forgot (an MX record, a TXT verification, a subdomain) stops working when the switch completes. 4GoodHosting’s domain pointing guide says nameserver changes usually take a few hours, and up to about 24 hours worldwide.

Before a nameserver change, export or screenshot the full zone at your current DNS provider. Check each record in the new host’s DNS editor before you switch. Pay particular attention to:

• MX records and any mail-related TXT records (SPF, DKIM, DMARC), especially if your email is with Google Workspace or Microsoft 365 rather than your web host.
• TXT records that verify the domain with Google Search Console, Microsoft or other services.
• CNAME records for subdomains, email marketing tools and CDNs.
• CAA records. cPanel’s guide to SSL explains that CAA records restrict which certificate authorities can issue certificates for a domain. If your old zone has a CAA record for one provider only, the new host’s automatic certificate may be blocked. Add a record for the new provider, or remove the old one.

If you use Cloudflare, decide early who will host DNS. 4GoodHosting’s Cloudflare guide describes both setups. With Cloudflare running DNS, you change the A records in Cloudflare to the new server’s IP address, and mail-related records must stay correct. The guide warns that a wrong Cloudflare proxy setting on mail hostnames breaks email.

Step 2: Copy the files and database without changing the URLs

If the domain stays the same, the move is simpler than many guides suggest. WordPress’s own migration handbook says that when the database and URLs stay the same, you can move the site by copying the files and database. If the database name or user changes on the new host, edit wp-config.php to match. A site that keeps its address needs no search-and-replace on the database.

That matters because search-and-replace is where many moves go wrong. The same handbook warns that some themes and widgets store values with the length of the URL recorded, so a plain find-and-replace across the database can break that serialized data. If you do have to change URLs (a new domain, or a move from a subfolder), use a tool that handles serialized data. WP-CLI’s search-replace command is one: its documentation says it handles PHP serialized data, and it has a –dry-run option to preview changes first.

On the new host, before you import anything:

• Match the PHP version to the old server’s, even if the old one is outdated. Change one thing at a time. Upgrade PHP after the move, on a staging copy, once you know the migrated site works. Our WordPress hosting benefits guide lists which PHP versions still get security fixes. The PHP project’s supported versions page shows security support for PHP 8.2 ending on December 31, 2026, so a site moving now on 8.2 needs that upgrade soon after the move.
• Check the database server version. WordPress’s requirements page recommends PHP 8.3 or later and MariaDB 10.11 or later, or MySQL 8.0 or later.
• Create the database and user, then note the name, username, password and host for wp-config.php.

Step 3: Test the new copy through your hosts file

You need to see the new copy before visitors do. One option is a temporary URL from the host. WordPress’s handbook warns, though, that testing on a different address means temporarily changing the “siteurl” and “home” values in the database, and changing them back afterwards. That’s two more edits, each a chance for a mistake.

A hosts-file entry avoids this. It tells only your computer to load your real domain from the new server’s IP address, while everyone else still reaches the old server. The URLs never change, so the database you test is the one that goes live.

As an example, if the new server’s IP address were 203.0.113.10 (an address reserved for documentation), the lines would be:

203.0.113.10 example.com
203.0.113.10 www.example.com

On Windows, the hosts file is C:and has to be edited as an administrator. On macOS and Linux, it’s /etc/hosts. Remove the lines when you finish testing, or you’ll keep seeing the new server after the switch and won’t notice if something is wrong for everyone else.

Expect one warning while testing this way: the new server may not have a valid certificate for your domain yet. cPanel’s AutoSSL only includes domains that pass a domain control validation (DCV) test. Let’s Encrypt’s challenge types page explains that its common HTTP-01 check fetches a file from your domain over port 80, which can’t succeed while the public DNS still points at the old server. A certificate warning during hosts-file testing is normal. A warning after the switch is not.

Test the journeys that make money or generate leads, not just the homepage:

• Log in to wp-admin, and open the settings pages of your main plugins.
• Submit every form, and confirm the message arrives.
• Add to cart and go through checkout in the payment gateway’s test mode, if it has one.
• Open a sample of older posts and image-heavy pages. Missing images usually mean the uploads folder didn’t copy completely.
• Check plugins tied to a licence key, an API key or an IP address allowlist (payment gateways, shipping, backup and security services).
• Check that the new copy isn’t blocking search engines. Google’s hosting-move guide says to make sure the new server’s firewall or denial-of-service protection doesn’t block Googlebot. It also says to make sure your Search Console verification will keep working after the move.

Step 4: Freeze changes and do a final sync

From the moment you copy the database, the two copies start to drift apart. Every order, comment, form entry, new user or edit on the old server is missing from the new one. For a brochure site, that drift doesn’t matter much: avoid editing for a day and copy the database again just before the switch.

For a WooCommerce store, membership site or booking system, plan a short freeze:

1. Pick the quietest hour you can find in your own analytics.
2. Pause checkout, or put the store into a maintenance mode that blocks orders while visitors can still browse. Tell staff not to edit products or content.
3. Export the database again from the old server, and import it over the copy on the new one.
4. Check that the latest orders, users and entries appear on the new copy.
5. Switch DNS, then reopen checkout on the new server.

Move the database whole. WooCommerce’s guidance on backups and migrations with Subscriptions recommends keeping the database intact between hosts: move the database and files, then update wp-config.php. It warns that exporting and importing content separately risks problems such as saved payment tokens no longer working.

Step 5: Switch DNS and get HTTPS working

At your chosen quiet hour, make the DNS change: update the A record, or switch the nameservers. Then, as soon as the new server starts receiving traffic:

• Get the certificate issued. On cPanel hosting, the SSL/TLS Status page shows domains with AutoSSL problems. cPanel’s SSL/TLS Status documentation gives the example of a domain that doesn’t resolve to an IPv4 address on the internet. If HTTPS doesn’t come up once DNS has updated, check for a CAA record left in the zone, then ask the host to run AutoSSL. 4GoodHosting’s Cloudflare guide notes that when Cloudflare runs DNS, AutoSSL may need a DNS-based check or a Cloudflare API token, and it asks customers to open a ticket if HTTPS fails to issue.
• Turn on the HTTPS redirect once the certificate is valid. 4GoodHosting’s guide to forcing HTTPS covers the cPanel setting.
• Re-save the permalinks under Settings > Permalinks if posts return 404 errors. WordPress’s handbook says permalink rewrites may need to be reconfigured when the site goes live on the new server.
• Clear every cache: the caching plugin, any CDN, and the host’s server cache, if it has one.

Step 6: Move email without losing messages

If your email is with Google Workspace, Microsoft 365 or another outside provider, the move shouldn’t change it. Your only job is to make sure the MX and related TXT records exist, unchanged, in whichever DNS zone is live after the switch.

If your email is hosted with your old web host and is moving too, it needs its own short plan:

• Create every mailbox and forwarder on the new host before the switch.
• Copy the existing messages across. A host-run migration can do this. 4GoodHosting’s migration offer includes email.
• Expect new mail to arrive on either server while DNS updates, and check the old mailboxes for a few days afterwards.
• Update the mail server settings on every phone, laptop and mail app. 4GoodHosting’s migration guide specifically lists computers and phones that used the old mail server hostnames.
• Fix authentication records on the new server. 4GoodHosting’s guide to SPF, DKIM and DMARC explains how cPanel’s Email Deliverability tool repairs them. It notes that the repair applies automatically only when the domain uses 4GoodHosting’s nameservers. If DNS is hosted elsewhere, you add the values yourself. Then send test messages to Gmail and Outlook addresses and check they don’t land in spam.

WordPress sends its own email too: contact form notifications, order emails, password resets. If those stop after the move while your mailbox email still works, check the SMTP plugin settings and the SPF and DKIM records before anything else.

Step 7: Watch both servers, then shut the old one down

For the first day or two, some visitors and services will still reach the old server. Google’s hosting-move guide recommends:

• Monitor traffic on both the old and new hosting.
• Shut down the old hosting only when you’re confident that all users, including Googlebot, are getting content correctly from the new one.
• Expect a temporary drop in Googlebot’s crawl rate right after the move, followed by a steady increase over the next few days. Google calls this normal.

4GoodHosting’s migration guide likewise says to keep the old host for a few days as a rollback.

Keeping the old server doesn’t mean leaving its copy fully active. There’s a trap here that’s specific to WordPress. WP-Cron, WordPress’s scheduler, runs due tasks whenever a page loads, according to WordPress’s cron documentation, and WordPress also documents how to run it from the server’s task scheduler instead. So the old copy can keep sending scheduled emails, running imports or processing renewals for anyone or anything still reaching it.

WooCommerce Subscriptions has a safeguard for cloned sites. Its documentation on staging sites and migrations explains that it switches off automatic payments and subscription emails when the site’s URL differs from the URL where it was first activated. In a host move that keeps the domain, the URL doesn’t change, so that check has nothing to catch, and both copies may behave as the live site.

Once DNS has settled and you’ve copied any late orders or entries across:

• Remove any server cron job on the old host that runs WordPress tasks.
• Put the old copy into maintenance mode, or disable its payment gateways and email-sending plugins.
• Compare orders, form entries and mailboxes on both servers one last time.
• Then cancel the old hosting. Download a final full backup first and keep it.

Common problems after a WordPress move

If the site goes down completely after the switch and the cause isn’t obvious, our guide to what to do when your website is down maps each error message to the layer that failed. 4GoodHosting’s guide to opening a support ticket lists what to include in a ticket so the host can help faster: the domain, when it started and what changed, the exact error text or a screenshot, and the steps you’ve already tried.

Where 4GoodHosting fits

If you’re moving a WordPress site to 4GoodHosting, its knowledgebase covers each stage of this guide:

• Migration options: free host-run migration on annual billing, or a DIY checklist.
• Nameserver changes.
• Cloudflare setups.
• Email authentication.
• Forcing HTTPS.

After the move, its WordPress Toolkit guide shows how to clone the site to a staging copy in cPanel. That’s a safe place to make the PHP upgrade and test plugin updates you deferred during the move. 4GoodHosting has servers in Vancouver and Toronto, and its contact page lists 24/7 phone support at 1 866 708 4678, as well as live chat.

Frequently asked questions

Will moving my WordPress site to a new host hurt my SEO?

Not if the URLs stay the same and the new server is reachable and fast. Google’s hosting-move guide says a temporary drop in crawl rate right after a move is normal, followed by a steady increase over the next few days. Avoid the real risks: a test copy left blocking search engines, a firewall blocking Googlebot, and a Search Console verification that breaks when the old server goes.

How long does a WordPress migration take?

Copying a typical small business site takes minutes to a few hours, depending on its size and the method. The move as a whole usually runs about a week: a few days to lower the TTL and test, a quiet hour for the switch, and a few days of overlap before the old server goes. DNS changes usually take a few hours, and up to about 24 hours worldwide.

Do I need to transfer my domain to the new host?

No. The domain registration and the hosting are separate. You can move the site by changing DNS records or nameservers while the domain stays with its current registrar, and transfer the registration later if you want both with one provider.

Can I test the new site before switching DNS?

Yes. Add the new server’s IP address and your domain to your computer’s hosts file, and your browser will load the new copy while everyone else still sees the old one. Unlike a temporary URL, this doesn’t require changing WordPress’s site address in the database.

Should I upgrade PHP during the move?

It’s safer not to. Match the new server’s PHP version to the old one, confirm the moved site works, and then upgrade PHP on a staging copy. If something breaks, you’ll know whether the move or the upgrade caused it.

What happens to my email during the move?

If your email is with an outside provider such as Google Workspace or Microsoft 365, nothing changes, as long as the MX and related records are in the live DNS zone after the switch. If your email is hosted with your old web host, create the mailboxes on the new host first, copy the messages, update every device’s settings, and check the old mailboxes for a few days while DNS updates.

Key takeaways

• List everything that’s moving first: files, database, DNS records, email, certificate, scheduled tasks and third-party connections.
• Lower the DNS TTL about a week ahead, and copy every DNS record, including MX, TXT and CAA records, before any nameserver change.
• If the domain stays the same, copy the files and database as they are. No search-and-replace is needed.
• Test through your hosts file so the database you test is the one that goes live.
• Match the PHP version first, and upgrade it after the move on a staging copy.
• For stores and booking sites, pause orders, copy the database one last time, then switch DNS.
• Expect a certificate warning while testing. Fix HTTPS right after the switch.
• Keep the old server for a few days, but stop its scheduled tasks and payments once DNS has settled.

Sources

• WordPress.org: Migrating WordPress, Requirements, Cron and WP-CLI search-replace
• PHP: Supported versions
• Google Search Central: Changing your web hosting and SEO
• Let’s Encrypt: Challenge types
• cPanel: Guide to SSL and SSL/TLS Status
• WooCommerce: Restoring backups with WooCommerce Subscriptions and How Subscriptions handles staging sites and migrations
• 4GoodHosting knowledgebase: Migrating your website, Transferring a domain, Using Cloudflare, SFTP with FileZilla, Forcing HTTPS, SPF, DKIM and DMARC, WordPress Toolkit and Opening a support ticket

About the author: This article was written by the team at 4GoodHosting, a Canadian web hosting company operating since 2002 with servers in Vancouver and Toronto.