The best hosting migration is one nobody notices. No downtime, no bounced email, no "the website looks weird" message two days later. It's entirely achievable, and it comes down to doing things in a specific order and resisting the urge to rush the last step.
Before you touch anything
Find out where everything actually lives
Registrar, DNS host, web host and mail host can all be four different companies. Establish which is which before you start, because the assumption that they're all in one place is where most migrations go wrong.
Write down the current DNS
Every record, exactly as it is now. This is your rollback and your checklist. Pay particular attention to MX records and to the TXT records handling SPF, DKIM and DMARC — those are the email ones, and they're the ones people forget.
Lower the TTL, days ahead
The single most useful preparation step. Drop the TTL on the records you'll change to five minutes, at least 24–48 hours before the move. That way, when you switch, the world picks it up in minutes rather than a day — and so does a rollback, if you need one.
The move itself
- Copy everything to the new host — files and database — and leave the old one running untouched.
- Test on the new server before any DNS changes. Use a hosts-file entry or a temporary URL to load the real site from the new host. Click through it properly: forms, checkout, logins, anything dynamic.
- Install the SSL certificate on the new host and confirm it's valid before you send any live traffic there. Switching DNS to a server with no certificate is a full-page browser warning for every visitor.
- Do a final content sync immediately before the switch, so anything changed during testing comes across.
- Switch the DNS — the A record, and AAAA if there is one. Leave MX alone unless email is genuinely moving too.
- Watch it. Uptime, error logs, form submissions. The first hour tells you most of what you need to know.
- Leave the old host running for at least a week. It costs one more month of hosting and it's the cheapest insurance in the business.
The traps
Email, treated as an afterthought
If mail is hosted with the old provider and you move the whole domain without thinking, mail stops. Decide deliberately whether email is moving, and if it isn't, make sure the MX and authentication records survive the change untouched.
Hard-coded URLs
Absolute URLs in the database pointing at the old host, or at http:// instead of https://. These cause mixed-content warnings and broken images that only show up once you're live. Search and replace properly, in the database, not just in the templates.
Cron jobs and scheduled tasks
Backups, imports, scheduled sends. They live on the server, not in the site files, and they don't come across in a file copy. Nobody notices for a month, and then a scheduled report doesn't arrive.
Switching on a Friday
Don't. Move early in the week, early in the day, when the people who can fix things are awake.
Afterwards
Once it's settled — a week or so — put the TTL back up, decommission the old host, and confirm backups are running on the new one. Then check the site's still being monitored. A migration is exactly the kind of event that quietly breaks an uptime check nobody re-pointed.
We move sites onto our hosting and monitor them from day one.
Managed hosting →