Migrating WordPress to a New Host Without Losing a Day of Business

Moving hosts sounds like it should be simple: copy the files, copy the database, point the domain. In practice most migrations go wrong in one of four predictable ways, and every one of them is avoidable with sequencing.

Here is how to migrate WordPress to a new host without a day of downtime, a week of missing email, or a month of SEO recovery.

The four ways it goes wrong

Worth naming up front, because the whole process is designed around avoiding them.

1. DNS switched before the new site was tested, so visitors land on a broken site
2. Email forgotten, and messages bounce for days
3. Old host cancelled immediately, removing any way back
4. Redirects and configuration lost, quietly damaging search rankings

Before you touch anything

Take a complete backup — files and database — stored somewhere that is neither host.

Document the current setup. PHP version, any custom .htaccess rules, cron jobs, redirect rules, and every third-party service pointing at the site. These are what get lost.

Establish where email lives. This is the single most important question. If your email is on the same hosting account, moving the site moves your email, and that needs planning as a separate exercise. If it is on a separate provider, you only need to preserve the relevant DNS records.

Email causes more migration pain than the website ever does. Websites go down and come back. Bounced email is gone.

Set up on the new host first

The key principle: build and test everything on the new host while the old one is still serving visitors. Nothing is switched until the new site is proven.

1. Create the hosting account and match the PHP version to what the site currently runs
2. Upload the files and import the database
3. Update database credentials in wp-config.php
4. Recreate custom .htaccess rules, cron jobs and any server configuration
5. Install the SSL certificate

Testing before the switch

You need to see the new site on the real domain without the world seeing it. Two ways.

Edit your hosts file — the cleanest method. Point your own machine at the new server's IP for your domain. You see the new site on the correct domain; everyone else still sees the old one.

Use a temporary URL if your host provides one. Easier, though some things behave differently on a different hostname.

Then test properly rather than glancing at the homepage:

• Homepage and several inner pages
• Contact form — submit it and confirm the email arrives
• Checkout, with a test transaction, if you sell online
• Login and the admin area
• Images and media loading correctly
• Search, filters, and anything database-driven
• Mobile
• Browser console for errors

The DNS switch

Timing is what makes this seamless.

24 hours before: lower your DNS TTL to 300 seconds. This is the step that makes the switch fast — with a default TTL, changes can take a day to propagate.

Just before: take a final backup and sync any content changed since you copied.

At the switch: change the A record to the new IP. Leave every other record alone unless you are deliberately moving it — MX records especially.

After: both hosts serve traffic during propagation, which is why the old one must stay running. Monitor both.

Switch at a quiet time for your business, and not on a Friday.

Immediately afterwards

1. Confirm the site loads and the certificate is valid
2. Submit a test enquiry through the contact form
3. Place a test order if applicable
4. Check that redirects still work
5. Confirm email is sending and receiving
6. Watch Search Console for crawl errors over the next fortnight
7. Re-save permalinks if any pages 404 — see our guide to WordPress 404 errors

Restore your DNS TTL to a normal value after a few days.

Keep the old host for two weeks

The cheapest insurance available. If something surfaces a week later — a missing file, a configuration nobody documented, an integration that broke — you still have the original to check.

Cancelling the old account the same day is the most common regret in migrations. Two more weeks of hosting costs very little against the alternative.

Protecting your SEO

A migration that keeps the same domain and URLs should have minimal search impact. Problems arise when something changes silently.

Confirm URLs are identical — any change needs a 301 redirect. Check that robots.txt came across correctly and is not blocking anything. Make sure no noindex setting was left enabled from a staging configuration. Verify the site is not noticeably slower than before.

That third point is a classic: a site migrated from staging with "discourage search engines" still ticked, quietly deindexing itself for weeks before anyone notices.

A note on migration plugins

Migration plugins handle most of this and are genuinely useful. Two cautions.

They frequently miss hidden files — .htaccess being the important one. And large sites often exceed PHP limits mid-transfer, leaving a partial database import that looks fine until you find missing content.

Verify rather than assume: check your post and product counts on both sides before switching.

One thing worth checking while you migrate

You are about to copy every file to a new server. It is a natural moment to check what you are copying.

If there are PHP files in your uploads folder, or files nobody can account for, do not migrate them. Moving a compromised site to new hosting relocates the problem and usually results in a suspension somewhere else. Our guide to removing malware from WordPress covers what to look for.

If you would rather not do this yourself

Migrations are one of those tasks that are straightforward when they work and genuinely stressful when they do not — particularly the email portion, which affects the whole business rather than just the website.

Our managed website plans include migrations handled properly, with testing before the switch and the old host kept running while it settles.

Get in touch and tell us where you are moving from and to — and whether your email is on the same account. That answer shapes everything else.