Moving your site without downtime
Most people's experience of a hosting migration is a stressful evening, a few hours of "we're down," and a week of chasing small things that broke. It doesn't have to be like that. The trick is to build the new site fully before you point anyone at it.
The mistake that causes the downtime
The bad version goes: change the domain's DNS to the new host, then start setting things up while the site is broken for visitors. DNS changes also take time to propagate — anywhere from minutes to a day — so you can't even be sure who's seeing what.
The good version never has the live domain pointing at an unfinished site.
The sequence that works
1. Build the new site on the new host, on a temporary address. Copy files and database, install the stack, get it fully working on a staging URL the new host provides. Nobody's domain points here yet.
2. Test everything on the staging URL. Every page, every form, the checkout if there is one, admin login, email sending. Fix what's broken now, with no clock running.
3. Lower the DNS TTL a day ahead. This tells the internet to check for DNS changes more often, so when you do switch, it propagates fast.
4. Do a final content sync. If the old site is still live and being updated, copy across anything that changed since step 1 — new orders, new posts, new form submissions.
5. Switch DNS to the new host. Because the new site is already working, the moment traffic arrives it's served correctly. Visitors mid‑propagation hit either the old working site or the new working site — both are fine.
6. Keep the old host running for a week. Don't cancel immediately. If something surfaces, you can point back in minutes.
The things that break if you're not careful
- Email. If email for the domain runs through the old host, plan that separately — a web migration can silently take mail down.
- SSL. The new host needs a valid certificate before the switch, or visitors get security warnings.
- Redirects. If URLs change at all, map old to new so search rankings and bookmarks survive.
- Hardcoded URLs. Databases often contain absolute links to the old domain or staging URL. Search and replace them.
- Cron jobs and background tasks. These don't migrate themselves. List them before you start.
The short version
If the new site is fully working before the domain points at it, a migration is a non‑event for visitors. The downtime stories all come from doing it in the other order.
If you'd rather hand the whole thing over, moving sites cleanly is routine work for us.