To move a WordPress site to a new host without downtime, take a full backup, set the site up and test it on the new host first, record every DNS record (especially email) before you change anything, then switch DNS and check the result from several regions. Visitors keep reaching the old host until DNS updates, so if both copies work, nobody notices the move. In 2025 I moved five UK client sites this way, without lost email or extended downtime.
Why do WordPress migrations go wrong?
From the hosting migrations I have done, the failures are predictable:
- Email stops, because the mail records were not recreated on the new DNS.
- Forms stop sending, because the new host handles mail or caching differently.
- Some visitors still see the old site, because DNS was only checked from one location.
- The site has errors, because the PHP version or server settings differ.
- SSL is missing on the new host for the first visitors.
- Staging gets indexed and competes with the live site.
Each one has a check in the method below.
What is the step-by-step method?
- 1
Full backup
Files and database, stored off both servers. This is your way back if anything goes wrong.
- 2
Record DNS
Export or screenshot every DNS record at the current provider: A, CNAME, MX, TXT and any others.
- 3
Stage on the new host
Install the site on the new host and reach it through a temporary URL or a hosts-file override.
- 4
Verify there
Pages, forms, logins, checkout, scheduled tasks and SSL readiness, before any visitor arrives.
- 5
Cut over DNS
Point the domain at the new host, with mail records checked before and after.
- 6
Check from several regions
Confirm every region resolves to the new host, then test forms and email again.
- 7
Keep the old host briefly
Do not cancel the old hosting until traffic has fully moved and the new site is confirmed healthy.
Which migrations has this method been used on?
| Site | Move | Risk handled |
|---|---|---|
| Samko Holdings | Staging to GoDaddy hosting, 24 and 25 March 2025 | Full launch from staging with forms wired to the group inbox |
| Ravens Ait | GoDaddy staging to the live domain, April 2025 | Launch of a full venue site with HubSpot enquiry forms |
| Raasa | Staging to the live domain, overnight | A hard deadline: live by the next morning |
| Sun Shoppers | To a new Hostinger account with GoDaddy DNS, October 2025 | Microsoft 365 email on the same domain |
| Media and Screen | To Hostinger with names.co.uk DNS | Old host still served in some regions after cutover |
How do you keep email working during a migration?
If business email runs on the same domain, email is the real risk, not the website.
For Sun Shoppers, the store moved to a new Hostinger account while DNS stayed at GoDaddy and email ran on Microsoft 365. I mapped every Microsoft 365 record before touching the zone and kept the MX records intact, so mail never dropped.
| Record | What it does | Check |
|---|---|---|
| MX | Routes incoming mail | Identical before and after |
| TXT (SPF) | Says which servers may send mail for the domain | Includes the new host if the site sends mail |
| CNAME (autodiscover and DKIM) | Mail client setup and signing | Recreated exactly |
| A record | Points the website at a server | The only record that should change |
Then send and receive a test email from outside the company after the switch.
Should you change nameservers or only the DNS records?
Changing only the A record (and www) keeps the zone where it is, so mail and other records stay untouched. That is the lower-risk option, and it is what I did for Sun Shoppers with GoDaddy DNS.
Changing nameservers moves the whole zone to a new provider. Sometimes that is right, for example moving DNS to Cloudflare, but every record has to exist at the new provider first.
What should you test after the cutover?
- Resolution from several regions. For Media and Screen, some regions were still served the old host after the cutover. It took a geo-DNS fix to correct, and it showed why checking from a single location is not enough.
- Every form. On two sites, GoDaddy's Airo Plus cache was swallowing form submissions. It looked like a form plugin bug but was the host's optimisation layer, and upgrading PHP from 8.0 to 8.3 fixed it at the root.
- Email, sending and receiving.
- SSL on both the bare domain and
www. - Redirects, including
httptohttpsand the non-preferred host to the preferred one. - Payments and webhooks, such as Stripe, if the site takes money.
- Search settings. The live site is indexable and staging is not. On Wow Vastra I de-indexed the staging site so it could not compete with the live store.
Should you upgrade PHP during a migration?
Usually yes, and test on staging first. A new host is a natural moment to move to a supported version. Easy Parenting Hub went live on the client's Hostinger server with PHP 8.3. On the GoDaddy sites, the PHP upgrade fixed the form problem and kept each site on a supported version.
What should you have at the end of a migration?
- Hosting in your own account, not the developer's.
- DNS and mail you understand, with the records written down.
- A full backup or export. For Samko Holdings I produced a full backup and export for the client, which they can hand to any future developer.
After the five moves in 2025, each client ran on hosting they control, with DNS and mail they understand.
Moving a site soon? I handle migrations, DNS and ongoing care through my hosting, migrations and maintenance service. Send me the domain and I will reply with a migration plan.
