Migrating a live website to a new host feels riskier than it needs to be mainly because people try to do it in one risky step — pointing the domain at the new host before confirming everything actually works there. This guide walks through the sequence that avoids downtime almost entirely.
Key takeaways
- The new host should be fully set up and tested before you touch your domain’s DNS settings at all.
- A temporary preview URL or local hosts-file edit lets you verify the new environment works before going live.
- DNS changes take time to propagate globally — plan around that delay rather than assuming an instant switch.
- Keep the old host active until you’ve fully verified the new one under real traffic, not just a quick glance.
Why migrations go wrong
Most migration downtime happens because someone switches the domain’s DNS to point at the new host before confirming the site actually works correctly there — discovering a problem only after the old site is already unreachable.
Step 1: set up and fully test the new host first
Get the site fully running on the new host under its temporary hosting URL or IP address, without touching your live domain at all yet. Test every major page and function there before proceeding.
Step 2: preview using a local hosts-file edit
Editing your own computer’s hosts file lets you preview your actual domain name pointing at the new host’s IP address, without affecting anyone else’s access to the live site, which is still pointing at the old host during this test.
# Example hosts file entry (your OS’s own file, not a server change)<br />
203.0.113.10 yourdomain.comStep 3: lower the DNS TTL in advance
Time-to-live (TTL) controls how long DNS changes take to propagate. Lowering it a day or two before the actual migration means the eventual real DNS switch propagates much faster when you make it.
| Step | Timing |
|---|---|
| Lower DNS TTL | 1-2 days before migration |
| Set up and test new host | Before touching DNS |
| Switch DNS to new host | After full verification |
| Monitor both old and new host | For several days after switching |
Step 4: migrate the actual DNS switch
Once fully verified on the new host, update your domain’s DNS records to point at it. With a lowered TTL, most visitors will resolve to the new host within a few hours rather than the default 24-48 hours.
Keep the old hosting account active for at least a week after switching DNS — some visitors’ devices and ISPs cache DNS longer than expected, and having the old site still reachable avoids any gap.
Step 5: monitor and confirm before canceling the old host
Watch traffic, error logs, and email deliverability (if email is hosted there too) on the new host for several days before canceling the old hosting account entirely.
If your email is hosted through the same provider as your website, migrating website hosting without also carefully migrating email DNS records (MX records) can break your email delivery entirely.
Frequently Asked Questions
How long does a website migration typically take?
Will search rankings be affected by a hosting migration?
Do I need technical help to migrate a website?
What's the biggest risk during a migration?
Conclusion
A website migration done in the right order — full setup and testing on the new host, a local preview, a lowered DNS TTL, then the actual switch with careful monitoring — avoids downtime almost entirely. The risk isn’t the migration itself, it’s skipping the verification step before pointing your domain at the new host.
- DNS propagation and TTL documentation from major DNS providers
- Hosting providers’ official migration guides
Continue reading
Related guides
How to Choose a Web Hosting Provider: The Complete Checklist
The specific factors worth checking before you commit to a hosting provider, beyond the homepage pricing table.
Read Article
Shared Hosting vs VPS vs Cloud Hosting: A Complete Beginner’s Guide
The real differences in control, cost, and who each hosting type is actually built for.
Read Article
AWS vs Google Cloud vs Azure: Which Cloud Platform Should You Choose?
A practical comparison built around real workloads and pricing, not vendor marketing.
Read Article
Discussion
No comments yet — be the first to ask a question about this guide.