How to Migrate a WordPress Site to New Hosting Without Breaking Anything (A Practical Checklist)

Byadmin

Disclosure: This post contains affiliate links. If you sign up through one, I may earn a commission at no extra cost to you.

Most migration disasters don’t come from anything inherently complicated about moving a WordPress site. They come from skipping a prep step. Here’s the actual sequence, in order.

Before you touch anything

  • Full backup, stored off the old host. Files and database both, saved somewhere other than the server you’re leaving — a local drive or cloud storage, not just “on the host” where it’s no help if that host disappears mid-migration.
  • Document your current PHP version and any non-default server configuration: cron jobs, redirect rules, anything custom in your .htaccess file.
  • List every active plugin, especially any with unusual or non-default settings you’d need to recreate manually if something doesn’t transfer cleanly.
  • Confirm you have access to your domain registrar and DNS settings before you start. You’ll need this at the end, and “I’ll figure out my login later” is how migrations stall for days.

Doing the actual migration

Most managed hosts — Cloudways, Kinsta, and WP Engine all do this — offer either a built-in migration plugin or a free white-glove migration for new accounts. Use it. Manual file transfer plus a database export/import works, but it’s where serialized data and search-replace operations on URLs most commonly go wrong if done by hand. Let the host’s tooling handle that part.

Test before you cut over DNS

Every host gives you a temporary URL to preview the site on the new server before your domain actually points there. Use it to check, specifically:

  • Forms actually submit and deliver
  • Login works for both you and any other users
  • Images and media load correctly
  • Internal links aren’t broken
  • SSL is valid (it may not be yet — that’s normal pre-cutover, see below)

The DNS cutover

If your registrar allows it, lower your DNS TTL 24-48 hours before the actual switch — this speeds up how fast the change propagates once you make it. Then update your domain’s A record (or nameservers, depending on setup) to point to the new host. Propagation can take anywhere from a few minutes to about 48 hours depending on your registrar and that TTL setting.

After cutover

  • Verify SSL is active on the new host. Most providers issue a free certificate automatically, but it usually can’t provision until DNS is actually pointing there — check this rather than assuming it’s done.
  • Resubmit your sitemap in Google Search Console, just to prompt a recrawl.
  • Keep the old host account active for at least a week or two as a safety net, even though it’s tempting to cancel immediately. If something surfaces three days later, you want the old version still reachable.
  • Monitor for 48-72 hours rather than walking away the moment the new site loads correctly.

What actually breaks, and why

  • Mixed content warnings — leftover hardcoded http:// references in the database when the site is meant to be all https://.
  • Broken images — absolute URLs pointing to the old domain or an old file path instead of relative paths.
  • Email stops working — if your old host was also handling email delivery, that’s a separate migration most people forget entirely until messages start bouncing.
  • A temporary ranking dip — normal, and it typically recovers within days to a couple of weeks as long as your URL structure and redirects stayed intact.

If you’re moving off shared hosting specifically because you’ve hit a performance ceiling, Cloudways and WP Engine both include migration assistance for new signups — worth using rather than doing this entirely by hand your first time through.

Similar Posts