Move WordPress to a New Host Without Losing a Thing

Move WordPress to a New Host Without Losing a Thing

You’re staring at your current host’s renewal invoice and something feels wrong. The price jumped. Support took 18 hours to reply to a simple ticket. Or maybe the site’s just slow and you’ve had enough. So you Google something like “how do I move my WordPress site to a new host without it going down” — and you land here.

Good. I’ll walk you through exactly what I do for clients. No theory. No padding. Just the actual process I’ve used to migrate WordPress sites to new hosts hundreds of times without anyone noticing the switch happened.

Before You Touch Anything — Run Through This Checklist

Seriously, don’t skip this part. I’ve seen people jump straight into copying files and then spend three days fixing things that a five-minute check would have prevented. Your wordpress migration checklist doesn’t need to be long. It needs to be honest.

Here’s what I verify before I start:

• PHP version on the new host (your site may need 7.4 or 8.1 — check your current version in cPanel under “MultiPHP Manager” or “PHP Selector”)
• Whether the new host supports the same database collation — usually utf8mb4_unicode_ci, but occasionally a mismatch causes garbled characters after import
• That your wp-content/uploads folder isn’t enormous — I had one client with 14 GB of media because nobody ever compressed anything, and that changes the plan
• Whether email is hosted with the same provider or separately — this matters a lot for what comes next
• Current TTL on your DNS records. Log into your domain registrar right now and drop the TTL to 300 seconds (5 minutes). Do it 24–48 hours before you plan to migrate.

That last point about TTL is the one most people miss. DNS changes propagate based on the TTL value that was set before you made the change, not after. If your TTL is sitting at 86400 (24 hours), you’ll be waiting a full day for the cutover. Drop it early. Always.

Plugin vs Manual — Here’s My Actual Opinion

People ask me this constantly. The wordpress migration plugin vs manual debate has a clear answer in my mind, and I’m not going to sit on the fence about it.

For most small-to-medium WordPress sites under 2 GB, use a plugin. I usually reach for All-in-One WP Migration or Duplicator Pro. They handle the database serialization automatically — meaning URLs inside post content, widget settings, and theme options get updated properly instead of still pointing to the old host. Doing that manually with a SQL find-and-replace is fine too, but one wrong character in a regex and you’ve broken serialized data in ways that don’t show up until three weeks later when a form stops working.

That said, I go manual when: the site is large, the host has file upload limits that make plugin exports impractical, or I’m moving to a VPS where I have SSH access. In those cases, I export the database through phpMyAdmin, rsync the files, import and do a serialized search-replace with WP-CLI:

wp search-replace 'https://oldsite.com' 'https://newsite.com' --all-tables --precise

The --precise flag is important. Skip it and WP-CLI uses regex mode, which is faster but can miss edge cases in serialized data. I’ve cleaned up that mistake before. Not fun.

Honestly, for most of the US and Australian small business clients I work with — a dentist, a real estate agent, a Shopify-to-WordPress convert — the plugin route is perfectly fine and saves everyone time and money.

The DNS Cutover Strategy That Actually Works

This is where a zero downtime migration either succeeds or falls apart.

Once the site is fully set up and tested on the new host — and I mean tested, not just “the homepage looks fine” — here’s the sequence I follow to move wordpress to new hosting without anyone noticing:

1. Point the domain to the new host’s nameservers OR update the A record to the new IP, depending on how DNS is managed
2. Leave the old hosting account active for at least 48–72 hours after the cutover
3. Monitor both servers during that window — some visitors will still hit the old one while DNS propagates
4. Don’t make content changes during propagation — you’ll end up editing the wrong version
5. Only cancel the old host once you’ve confirmed all traffic is hitting the new server (check with a tool like whatsmydns.net)

The reason I keep the old hosting live for 72 hours is simple: propagation is unpredictable. I’ve seen ISPs in regional Australia cache DNS for longer than they should. Keeping both servers up means no visitor ever hits a dead end, regardless of which copy of DNS their ISP is serving them.

One more thing — if your client has email hosted on the same server you’re migrating away from, sort out the MX records separately and first. I once handled a migration for a business in Wilmington where their email and website shared the same cPanel account. By adjusting MX record priorities ahead of the domain cutover and keeping the old mail server accepting messages during the transition, not a single email was lost. The client told me they’d give me 11 out of 10 if they could. That’s the kind of result that comes from slowing down for five minutes to think through the email piece before touching anything else.

After the Migration — Don’t Close the Ticket Yet

The site is live on the new host. Everything looks good. You’re tempted to call it done. Wait.

Run through these before you fully sign off:

• Check SSL is active and all pages load over HTTPS — some hosts need you to re-issue the certificate
• Submit your sitemap to Google Search Console so it knows the site didn’t disappear
• Test contact forms end-to-end, not just visually — form submissions break more often than anything else after a migration
• Confirm caching plugins (WP Rocket, W3 Total Cache, etc.) are configured for the new server environment
• Check wp-config.php has the correct database credentials and that WP_HOME and WP_SITEURL reflect the live domain

One thing I always do: a quick scan for any hardcoded old URLs left in the database. Even after a WP-CLI search-replace, theme options or page builder data occasionally hold onto old references. A tool like Better Search Replace (free in the plugin repo) lets you do a dry run first, which I appreciate.

If somewhere in this process you discovered your site has been sitting on a neglected server for years and things look suspicious, it might be worth reading how to remove malware from WordPress manually before you migrate anything — moving a compromised site to a new host just moves the problem.

A WordPress site migration done carefully isn’t dramatic. It’s methodical. Lower the TTL early, copy everything before you cut over, keep both servers live through propagation, and test properly before you cancel anything. That’s it.

If you’d rather hand this off to someone who’s done it more times than they can count, I take on migrations at swsDreams — just get in touch and I’ll tell you honestly what the job involves.