The best hosting migration is one nobody notices: no downtime, no bounced email, no "the website looks weird" message two days later. It's achievable, and it comes down to doing things in a specific order and not rushing the last step. We moved our own platform's databases this year, and the step that mattered most wasn't the one most checklists include.
Before you touch anything
Find out where everything actually lives
Registrar, DNS, web host and email host can be four different companies. Establish which is which before you start. Assuming they're all in one place is how email quietly stops halfway through a move.
Write down the current DNS
Every record, exactly as it is. This is your rollback and your checklist. Pay particular attention to the MX records and the TXT records carrying SPF, DKIM and DMARC — they're the email ones, and they're the ones people forget.
Lower the TTL, well ahead
TTL is how long the rest of the internet is allowed to remember your DNS answer. Drop it to five minutes on the records you'll change, then wait at least as long as the old value before moving — anything that cached the old answer keeps it until it expires, and that's often a day or two. When you do switch, the change spreads in minutes, and so does a rollback.
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 touching DNS. Use a hosts-file entry or a temporary address to load the real site from the new host, and click through it properly: forms, checkout, logins, anything dynamic.
- Install and check the SSL certificate on the new host before any live traffic goes there. Pointing DNS at a server without one puts a full-page browser warning in front of 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. One more month of hosting is the cheapest insurance in the business.
Prove it's actually using the new one
This is the step most checklists skip, and it's the one that caught us.
In July 2026 we moved five of our platform's databases onto one shared server. Every service came up healthy on the new one, which is exactly the point where it's tempting to call it done. Instead, each old database was backed up and then suspended rather than deleted, and a service only counted as migrated if it stayed healthy while its old database was unavailable.
One didn't. It had been reading the old database the whole time, through a second, older connection setting that took priority over the new one. It looked migrated and passed every health check. It would have kept working right up until the old server was deleted — and then stopped.
The same test works for a website. Once DNS has switched, change something small on the new host and confirm you can see it on the live site. "It loads" doesn't prove which server it loaded from.
The traps
Email, treated as an afterthought
If mail is hosted with the old provider and the whole domain moves without a thought, mail stops. Decide deliberately whether email is moving. If it isn't, make sure the MX and authentication records survive the change untouched.
Regions and private addresses
Hosting platforms often connect a site to its database over a private network inside a single region. Earlier this year one of our databases was created without a region set, landed in a different one from the application, and its private address simply wouldn't resolve. The error pointed at DNS, not geography. If a service can't find a server that's plainly running, check they're in the same place.
Hard-coded URLs
Absolute links in the database pointing at the old host, or at http:// instead of https://, cause broken images and mixed-content warnings that only show once you're live. Search and replace in the database, not just the templates.
Scheduled tasks
Backups, imports, scheduled emails. They live on the server rather than in the site files, so a file copy doesn't bring them. Nobody notices for a month, and then a 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 is still being monitored: a migration is exactly the kind of event that quietly breaks an uptime check nobody re-pointed. It's the part of managed hosting most worth paying someone else to own.
We move sites onto our hosting and monitor them from day one.
Managed hosting →