You migrate a WordPress site without downtime by building a complete working copy on the new server first, testing it privately while the old site stays live, then switching DNS once everything checks out. Visitors keep seeing the old server until the DNS change reaches them, and by then the new one is ready. The only real risk window is content added during the move, which you handle with a short freeze or a final sync.
This is the process we follow when moving client sites between hosts, including the order of steps, the commands and plugins that make it easier, and the problems that catch people out: serialised data, email, SSL and forgotten cron jobs.
Key takeaways
- Build and test the new copy before touching DNS.
- Lower the DNS TTL a day or two before the switch.
- Use your hosts file to preview the new server on the real domain.
- Search and replace URLs with a tool that handles serialised data.
- Freeze content edits, or plan a final database sync, on cutover day.
- Keep the old hosting running for at least a week afterwards.
Why migrations usually cause downtime
Most outages during a move come from doing things in the wrong order. Someone changes the nameservers, then starts uploading files, and for a few hours (sometimes a couple of days) half the visitors land on an empty server or a database connection error. Others cancel the old hosting on the same day and discover a missing upload folder when it is too late.
The fix is boring: the new server should be fully working before any visitor can reach it. DNS is the last step, not the first. If you are moving because your current host is slow or unreliable, our guide to choosing web hosting in the UK covers what to look for in the new one.
Before you start: an inventory of the old site
Spend half an hour writing down what the site actually depends on. Sites that have been around for years collect hidden parts.
- PHP version on the old server, and whether the new one runs the same or newer. Check plugins are compatible before you move rather than after.
- Email: is mail for the domain hosted on the same server? If so, the MX records and mailboxes need a plan of their own.
- Cron jobs set in the hosting panel, not just WP-Cron. Booking reminders and feed imports often live here.
- Custom server rules in .htaccess or the Nginx config, such as redirects, IP blocks or caching headers.
- Third-party connections that whitelist your server IP: payment gateways, CRMs, stock feeds, SMTP relays.
- Full DNS zone: export every record (A, CNAME, MX, TXT for SPF, DKIM and DMARC, Google or Microsoft verification) before you change anything.
That last one matters more than people think. If you move nameservers and forget a TXT record, email quietly starts landing in spam.
Step 1: copy files and database to the new server
You need two things: the wp-content folder (themes, plugins, uploads) plus WordPress core, and a dump of the database. There are several ways to get them across.
| Method | Good for | Watch out for |
|---|---|---|
| WP-CLI and rsync over SSH | Any size of site, repeatable, fast | Needs SSH on both servers |
| Migration plugin (Duplicator, All-in-One WP Migration, Migrate Guru) | Small to medium sites, no SSH | Free tiers cap archive size; large uploads folders time out |
| Host's own migration tool | Moving into managed hosting | Less control over timing and what gets copied |
| Manual SFTP and phpMyAdmin | Last resort | Slow, easy to miss files, import limits |
Where we have SSH, the core of it looks like this: wp db export on the old server, rsync -avz the whole site folder across, then wp db import on the new one. Update wp-config.php with the new database name, user and password. rsync is useful later too, because running it a second time only copies files that changed.
Step 2: test the new copy on the real domain using your hosts file
This is the step that removes the guesswork. Your computer's hosts file lets you tell your own machine that the domain points at the new server's IP, while everyone else still sees the old one.
- Find the new server's IP address in the hosting panel.
- Edit the hosts file (on Windows it is C:\Windows\System32\drivers\etc\hosts, on a Mac /etc/hosts) and add a line with the IP followed by the domain and the www version.
- Flush your DNS cache and open the site in a private window.
Because you are browsing on the real domain, you do not need to change any URLs in the database yet, and you see exactly what visitors will see. Click through properly: the homepage, a few posts, forms, the basket and checkout if it is a shop, the login page, and anything that relies on a plugin licence. A quick way to confirm which server you are on is to drop a temporary text file into the new server's web root and load it.
Remember to remove the hosts entry when you are finished, or you will be confused for weeks.
Step 3: search and replace, only when the domain changes
If the domain stays the same, skip this. If you are also changing domain, or moving from a staging subfolder, you need to update URLs inside the database.
Do not run a plain find and replace on the SQL file. WordPress stores a lot of settings as PHP serialised arrays, which record the length of each string. Change the length without updating the count and the setting breaks, usually widgets, theme options or page builder layouts. Use wp search-replace 'https://old.example' 'https://new.example' --all-tables --precise, or a plugin such as Better Search Replace, both of which handle serialisation. Run it with --dry-run first to see how many rows it will touch.
Elementor sites also need their CSS regenerated afterwards (Elementor, Tools, Regenerate CSS), otherwise some styles still point at the old address. If you work with page builders a lot, our notes on WordPress page builders explain why they store data the way they do.
Step 4: SSL, DNS TTL and email ahead of the switch
A day or two before cutover, lower the TTL on the domain's A record to something short, such as 300 seconds. Resolvers that cached the old value will then check again within minutes instead of hours when you make the change.
SSL is the awkward part. Let's Encrypt usually validates over HTTP, which means it cannot issue a certificate for the new server until DNS points there. Options:
- Use DNS validation if your host or DNS provider supports it, so the certificate is ready before the switch.
- Copy the existing certificate and key across if you have access to them.
- Accept a few minutes after the switch while the new host issues the certificate, and do the change at a quiet time.
For email, if mailboxes are moving too, create them on the new server first and migrate the messages with the host's tool or imapsync. If mail is with Microsoft 365 or Google Workspace, you only need to make sure the MX and TXT records come across exactly.
Step 5: cutover day
Pick a quiet period. For most B2B sites that is early morning; for shops, look at your analytics for the lowest-traffic hour.
- Tell anyone who edits the site to stop publishing. On a WooCommerce site this is the hard bit, because orders keep arriving.
- Run rsync again to pick up any new uploads, then export and import the database one last time.
- Update the A record (or switch nameservers if you are moving DNS hosting too, which takes longer to settle).
- Check the site from a phone on mobile data, which will often resolve the new IP before your office network does.
For busy shops, a content freeze is not always realistic. In that case, either put the old site into maintenance mode for the final sync (a few minutes on most sites), or note the last order ID on the new server and copy across any orders placed on the old one after the switch. The second option is fiddlier and only worth it if even five minutes of downtime costs real money.
After the move: what to check in the first week
- Search Console: no spike in crawl errors, and the sitemap still fetches.
- Forms send and arrive. Test every one, and check spam folders.
- Scheduled tasks run. Install WP Crontrol to see whether events are firing, and recreate any server cron jobs.
- Caching and the CDN are configured on the new host, and the old caching plugin is not fighting with server-level cache.
- Backups are running on the new server. People forget this constantly.
- Page speed is at least as good as before. Run a few pages through PageSpeed Insights and compare.
Keep the old hosting active for a week or two. Some resolvers ignore TTLs, and having the old copy to hand if you find a missing file is worth one more month's bill. After that, take a final backup and cancel it.
If the site has no maintenance routine yet, a move is a good moment to start one. Our website maintenance guide covers the monthly checks.
When to do it yourself and when to hand it over
A brochure site with a contact form, on a host with a decent migration tool, is a reasonable DIY job if you follow the order above. It is worth paying for help when the site takes orders or bookings, when email lives on the same server, when there are custom integrations that whitelist IPs, or when the move also involves a PHP upgrade that could break old plugins. The cost depends mostly on database size, how many moving parts there are and how much downtime the business can tolerate, not on page count.
We handle migrations as part of our web development work, and often pair them with a move to managed WordPress hosting.
Frequently asked questions
How long does it take to migrate a WordPress site?
The copy and testing usually takes a few hours for a typical small business site, longer for large shops or sites with many gigabytes of uploads. DNS changes then take anywhere from minutes to a day to reach everyone, depending on the TTL you set beforehand.
Will moving hosts affect my Google rankings?
Not if the domain, URLs and content stay the same and the site stays up. Google sees a change of IP address, not a new site. Rankings can drop if the new server is much slower or if pages return errors during the move.
Do I need a plugin to migrate WordPress?
No. With SSH access you can do it with WP-CLI and rsync, which is faster and more reliable on big sites. Plugins are useful when you only have FTP and a control panel, but free versions often limit archive size.
What happens to my emails when I change web host?
If your mailboxes are on the old web host, they need to be recreated and the messages copied to the new one, and the MX records updated. If you use Microsoft 365 or Google Workspace, email is unaffected as long as you copy the DNS records exactly.
Why does my migrated site show a database connection error?
The details in wp-config.php do not match the new database. Check the database name, user, password and host. Some hosts use a database host other than localhost, which is easy to miss.
Moving your site to a new host
If you would rather not risk the cutover yourself, get in touch with details of the site and where it is going, and we will plan the move around your quietest hours.
