Migrate WordPress Without Losing Email, SSL or Rankings

Moving the files and the database is the easy part, and it’s where most guides finish. The failures happen afterwards, and all three are quiet.

Before anything else: for most people the right answer is to pick a host that does the migration for you and stop reading. Skip to the table at the end if that’s you.

Failure 1: email stays behind

Your MX records are separate from your A record. Moving the website moves neither your mailboxes nor your mail routing.

If your email lived on the old host, mail keeps arriving at a server you’re about to cancel. Two weeks later you cancel it, and correspondence starts bouncing.

There’s a nastier variant. If the new server considers itself authoritative for your domain, mail sent by WordPress itself — contact forms, password resets, WooCommerce receipts — can be delivered into a local mailbox on the new box that nobody will ever open. The form says “message sent.” Nobody receives it.

The fix, in order:

1. Decide where email will live before you touch the website. If it’s staying put, note the current MX records and verify they’re unchanged after migration.
2. If it’s moving, move it as its own project first, and verify delivery both ways.
3. On the new server, configure WordPress to send through a proper SMTP provider rather than the local mail transfer agent. This solves deliverability and the local-mailbox trap at once.
4. After cutover, send a test message through an actual site form and confirm it arrives.

Failure 2: the SSL gap at cutover

The standard sequence produces an unavoidable window: you flip DNS, then request a certificate on the new server — and until it’s issued, visitors get a full-page browser warning.

That’s because the usual HTTP-01 validation requires Let’s Encrypt to fetch a file from your domain, which only works once the domain already points at the new server. You cannot get the certificate first.

Unless you use DNS-01 validation instead. DNS-01 proves control by placing a TXT record at _acme-challenge.yourdomain.com. Validation checks DNS, not your web server — so you can issue a valid certificate for the new server while the domain still points at the old one.

That closes the gap entirely:

1. Issue the certificate on the new server via DNS-01, before cutover
2. Install it and confirm it’s serving
3. Flip DNS
4. Visitors arrive at a server that already has a valid certificate

Most control panels default to HTTP-01, so this usually means asking the host or configuring your ACME client for a DNS-01 challenge. It takes a few minutes and removes the most visible failure in the whole migration.

If DNS-01 isn’t available to you, minimise the gap instead: have the certificate request ready to fire the moment DNS resolves, and do the cutover at your lowest-traffic hour.

Failure 3: rankings drop quietly

This one has no error message at all, which is why it’s the most damaging.

URLs must be identical. Not equivalent — identical. The three that change without anyone deciding to change them:

• Trailing slashes. /about/ and /about are different URLs. A permalink or server config difference between hosts flips this silently.
• HTTP to HTTPS, or www to non-www. If the old host redirected one way and the new one doesn’t, or redirects differently, every inbound link now takes an extra hop or breaks.
• Uppercase and lowercase in paths, if you moved between server software with different case sensitivity.

Mixed content is the other silent one. If your database contains hardcoded http:// asset URLs, pages load with warnings and browsers block resources. A search-replace across the database at migration time — done properly, handling serialised data — prevents it.

The post-flight checks that catch all of this:

• Crawl the new site and compare the URL list against a crawl of the old one, before you cancel anything
• Check Search Console coverage for a spike in 404s or redirect errors over the following fortnight
• Run a mixed-content scan on several page types, not just the homepage
• Verify your redirect chains — old URL should reach new URL in one hop, not three
• Confirm robots.txt didn’t come across from a staging environment. A stray Disallow: / will deindex the site, and it’s the single most expensive mistake on this page

The order that avoids all three

1. Decide the email plan. Not a step to defer.
2. Lower DNS TTL to 300 seconds, 48 hours ahead.
3. Copy files and database to the new host while the old one still serves.
4. Search-replace the database for hardcoded URLs, handling serialised data properly.
5. Preview via your local hosts file — point your machine at the new server’s IP and browse the real domain. Check the checkout, the forms, the admin.
6. Issue the SSL certificate via DNS-01 while DNS still points at the old host.
7. Check robots.txt and permalink settings on the new server.
8. Freeze changes on the old site. For a shop, take a brief maintenance window — during propagation, writes land on whichever server the visitor reached, and two divergent order tables cannot be merged.
9. Final delta sync, then flip DNS.
10. Send a test through a site form and confirm delivery.
11. Keep the old host live for at least 48 hours, ideally two weeks. It’s the cheapest rollback available.
12. Watch Search Console for a fortnight.

Or let the host do it

For most readers this is the correct answer, and it’s free more often than people realise.

Hostinger has the most generous policy here — unlimited free transfers, which is worth real money if you’re moving a portfolio rather than one site.

SiteGround provides a migrator plugin that makes it largely self-service, which is quick if your site is standard.

GreenGeeks includes one on shared hosting; price the whole move if you’re bringing several sites.

At the managed end, Kinsta, Nexcess, Rocket.net and Cloudways all position migration assistance as part of onboarding. We haven’t verified the specific terms for those four — how many sites, whether it’s included or paid — so confirm before you rely on it.

Even with a free migration, three things stay yours: the email decision, the robots.txt check, and watching Search Console afterwards. No host does those for you.

If you’re moving because of a renewal price rather than a problem, what switching actually costs covers the prepaid term you may be forfeiting. If you’re moving off shared hosting onto a VPS, that migration has its own guide.

How we checked this

The distinction between Let’s Encrypt’s HTTP-01 and DNS-01 challenge types — HTTP-01 requiring a file served from the domain, DNS-01 proving control via a TXT record at _acme-challenge and therefore working before DNS points at the new server — is from Let’s Encrypt’s own challenge-type documentation. This is the technically correct fix for the SSL gap, and it’s why we’ve recommended it over the usual advice to simply reissue after cutover.

Hostinger’s unlimited free migrations, SiteGround’s migrator plugin and GreenGeeks’ one-free-plus-$15-per-additional-site policy are from those providers’ published terms, read across this series. Kinsta, Nexcess, Rocket.net and Cloudways are named without specifics because we did not verify their migration terms for this article.

What we did not do: we have not performed a WordPress migration for this article. The sequence is ordered so that nothing is cancelled or deleted until the replacement is verified — which is the property that matters if a step differs for your stack — but it is a documented procedure rather than a migration we ran and timed.

The failure modes are drawn from how these systems work rather than from our own incident log: MX records genuinely are separate from A records, HTTP-01 genuinely does require the domain to resolve to the requesting server, and trailing-slash and protocol differences genuinely do create distinct URLs. What we can’t tell you is which of them will bite you, which is why the post-flight list is a list rather than a warning.

The hosting links above are affiliate links. The advice to pick a host that migrates for you and stop reading is the one we’d most want followed.

FAQ

How do I migrate WordPress without downtime?

Lower DNS TTL 48 hours ahead, copy files and database while the old host still serves, preview via your hosts file, issue SSL by DNS-01 before cutover, freeze changes, do a final delta sync, then flip DNS and keep the old host live for at least 48 hours.

Will my email move when I change hosts?

No. MX records are separate from your A record, so mail keeps arriving at the old server. Decide the email plan before touching the website, and configure WordPress to send through an SMTP provider rather than the local mail agent.

How do I avoid SSL warnings during migration?

Use Let’s Encrypt’s DNS-01 challenge, which validates via a TXT record rather than a file on your server — so you can issue and install the certificate before DNS points at the new host. HTTP-01 can’t do this.

Will migrating hurt my SEO?

Only if URLs change. Watch trailing slashes, HTTP-to-HTTPS and www-to-non-www redirects, and check robots.txt didn’t arrive from staging with Disallow: /. Crawl both sites and compare before cancelling anything.

Which hosts migrate WordPress for free?

Hostinger offers unlimited free migrations, SiteGround provides a migrator plugin, and GreenGeeks includes one on shared plans with additional sites at $15 each.

How long should I keep the old host running?

At least 48 hours, ideally two weeks. It’s the cheapest rollback available, and DNS stragglers can reach it for longer than the TTL suggests.

What breaks if my database has hardcoded URLs?

Mixed-content warnings and blocked assets. Run a search-replace across the database at migration time using a tool that handles serialised data — a plain SQL find-and-replace corrupts serialised WordPress options.