Moving a WordPress site to a new host is where I’ve seen more good sites break than almost anywhere else. Not because migration is technically hard, it isn’t, but because most people skip the one step that actually prevents downtime: keeping the old site alive while the new one gets tested.
After 10+ years building WordPress sites and handling 950+ Fiverr client projects, I’ve migrated sites for slow shared hosting upgrades, agency handoffs, and clients who got scared off their host after a security scare. The process below is the exact one I use. It works whether you’re moving from shared hosting to managed WordPress hosting, or just switching providers because your current one is too slow.
Why Most WordPress Migrations Break Something
Here’s the mistake I see constantly: someone copies the files and database to the new host, updates DNS immediately, and just hopes for the best. For the next 24 to 48 hours, depending on DNS propagation, some visitors land on the old site and some land on the new one. If they’re not identical (and they rarely are, because nobody tests before switching), you get broken checkouts, missing images, or a client convinced their “site is down” when really only half their visitors can see it properly.
The fix isn’t a fancier plugin. It’s sequencing: prepare, test, then cut over only once you know the new site works.
What You Need Before You Touch Anything
Don’t start moving files until you have these ready:
- A full backup of your current site (files and database). I don’t move a client site without one, no exceptions, and I’ve written about the backup plugin I actually use if you don’t already have automated backups running.
- Login credentials for the new hosting account, ideally with SSH or SFTP access, not just a file manager.
- Access to your domain’s DNS settings (through your registrar or wherever DNS is managed).
- A migration plugin if you’re going that route: Duplicator and All-in-One WP Migration both work fine for most sites under a few GB.
- 30 to 60 minutes of uninterrupted time for the actual cutover, even though the full process spans a day or two.
The Zero-Downtime WordPress Migration Process
This is the order that actually keeps your site online the entire time. Skip a step and you’re back to the “half your visitors see the old site” problem.
- Lower your DNS TTL 24 hours before you start. Standard TTL is often 86,400 seconds (24 hours). Drop it to 300 seconds. This means when you finally point your domain at the new server, the change propagates in minutes instead of up to a full day.
- Set up the new hosting environment first. Create the hosting account, database, and PHP version matching (or exceeding) your current setup before you move a single file.
- Copy files and database to the new host. Use a migration plugin, or manually via SFTP for files and phpMyAdmin/WP-CLI for the database export and import.
- Update
wp-config.phpwith the new database credentials on the new server, since the database name, username, and password will almost always be different from the old host.
If your domain itself isn’t changing (you’re just switching hosts, which is the most common case), you don’t need to touch the URLs in the database at all. If you are changing anything about the URL, adding SSL and forcing HTTPS, moving off a temporary staging domain, switching from www to non-www, run a proper search-replace with WP-CLI instead of a manual find-and-replace in a text editor. WordPress stores serialized data that breaks with naive text replacement:
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid --dry-runRun it with --dry-run first to see what it would change, then run it for real without that flag once you’re confident.
- Test the new site before touching DNS, using your local hosts file. This is the step almost everyone skips, and it’s the one that actually makes the migration zero-downtime. More on this below.
- Fix anything broken on the new server, missing PHP extensions, wrong file permissions, plugin conflicts with the new host’s caching setup, before anyone but you sees it.
- Once the new site checks out, update your domain’s DNS to point at the new server’s IP address.
- Keep the old host active for at least a week. Because of DNS propagation and caching on ISPs and devices, a small percentage of visitors will still hit the old server for a few days. Both need to serve a working site during that overlap.
- Monitor 404s and uptime for the first week, then cancel the old hosting once everything’s been stable for several days.
The Hosts File Trick That Makes This Actually Zero-Downtime
Here’s the part that separates a clean migration from a stressful one. Before you touch DNS, edit your computer’s local hosts file to point your domain directly at the new server’s IP address, just on your machine.
On Mac or Linux, edit /etc/hosts. On Windows, it’s C:\Windows\System32\drivers\etc\hosts. Add a line like:
203.0.113.10 yourdomain.com www.yourdomain.comNow when you visit your domain in a browser, you see the new server, while everyone else in the world still sees the old one through normal DNS. You can click through every page, test the checkout, submit a contact form, check that emails still send, all without a single visitor noticing anything happened. This is the difference between finding a broken plugin at 2 PM with zero visitors affected, versus finding it after DNS has already switched and half your traffic is seeing a broken cart.
I don’t cut over DNS on a single client site until I’ve clicked through this checklist on the hosts-file version of the new site. It takes 15 extra minutes and has saved me from at least a dozen “why is the site broken” calls over the years.
Common WordPress Migration Mistakes That Break Sites
A few patterns show up in almost every broken migration I’ve had to fix for a client after they tried it themselves:
- Forgetting the
wp-config.phpdatabase credentials after moving files, so the site just shows a database connection error on the new server. - Not checking the PHP version on the new host matches what your plugins need, which causes white screens or fatal errors that only show up after cutover.
- Skipping SSL setup on the new server before switching DNS, so visitors hit a certificate warning the moment the domain resolves to the new host.
- Not clearing caching layers like Cloudflare or a caching plugin after the move, so visitors keep seeing a cached version of the old site. If you’re running your DNS through Cloudflare, get the proxy and cache settings right before you switch, not after.
- Migrating a live site directly instead of testing on staging first. If you’re not comfortable improvising fixes on a production site, do a practice run on a staging copy before you touch the real thing.
Migration Plugin or Manual Move: Which Should You Use?
For most small to medium WordPress sites, a migration plugin is the right call. Duplicator and All-in-One WP Migration both package your files and database into a single archive and handle the search-replace for you. It’s faster and less error-prone than doing it by hand, especially if you’re not comfortable in the command line.
I go manual (SFTP plus WP-CLI) on larger sites, usually anything over 2 to 3 GB of media, because plugin-based exports get slow and occasionally time out on shared hosting resource limits. If your site is a typical business site under a few hundred MB, don’t overthink this part. Use the plugin.
After the Migration: Don’t Skip These
Once the new site is live and stable, a few things still need attention:
- Reset your DNS TTL back to a normal value (like 3600 or 86400) once propagation is confirmed.
- Resubmit your sitemap in Google Search Console if the domain or URL structure changed at all.
- Confirm scheduled backups are running on the new host. Don’t assume the old backup schedule carried over.
- Check that transactional emails (order confirmations, password resets) still send correctly from the new server.
Migrating a WordPress site without downtime isn’t about finding a magic plugin. It’s about testing the new environment fully before a single visitor’s DNS resolves to it. Follow that order and hosting migrations stop being scary.
Frequently Asked Questions
The hands-on work, copying files, setting up the database, testing, usually takes 1 to 3 hours for a typical business site. But the full process, including lowering DNS TTL beforehand and keeping the old host active during propagation, spans 24 hours to a week for a truly safe cutover.
Not if your domain and URLs stay the same. Moving hosts without changing your domain has no direct SEO impact. The risk to rankings comes from downtime or broken pages during a botched migration, not the migration itself. If you also change your domain, that’s a separate process involving 301 redirects and a Search Console change-of-address request.
Duplicator’s free version handles most small to medium sites well. All-in-One WP Migration is a solid alternative, though its free tier caps upload size on the destination site unless you buy an extension. For sites over a few GB, I’d skip plugins entirely and move files via SFTP with the database handled through WP-CLI.
Yes, in almost every case. Your domain’s DNS A record points at your current host’s server IP. Moving to a new host means that IP changes, so DNS has to be updated to point at the new server. The only exception is if both hosts share the same IP infrastructure, which is rare.
A straightforward site (no custom code, standard plugins) can usually be migrated by a comfortable DIY user with a migration plugin, following the steps above. If your site runs custom code, a complex WooCommerce setup, or has grown messy over the years, it’s worth bringing in a developer, one mistake in the database search-replace step can corrupt content across the entire site.
Leave a Reply