The fear that stops most people from changing their web host is simple: if I move my site, will it go down — and for how long? The honest answer is that a website migration only causes downtime when you do the steps in the wrong order. Copy the files while the old site still serves visitors, test the copy, and switch the address last — there's no window where your site is unreachable.
The takeaway up front: to migrate a website without downtime, treat it as a sequence, not a leap — copy first, cut over last, and never delete the old host until the new one is fully proven. Reverse that order — point your domain at an empty or half-configured server before the new site works — and you get the migration outage everyone fears. This guide walks the safe sequence for a zero downtime migration, the DNS trick that shrinks the cutover from hours to minutes, and how to keep a clean rollback throughout.
What a migration actually moves
A website is two things on a server: your files (code, theme, images, uploads) and your database (posts, settings, users, orders). To change your web host you copy both to a new server, then change where your domain points — a website migration is really just those two moves, in that order. The whole no-downtime trick is to keep the old host as your safety net: it serves traffic at full speed while you build and verify the copy elsewhere, and you switch the domain only once that copy is proven.
Before you touch anything: a clean snapshot and a plan
Two things must be in place before you copy a single file.
- Take a full backup — files and database both. This is your restore point if anything goes sideways. Download it off the server, not just to another folder on the same host.
- Inventory what makes the site work. Note the PHP (or runtime) version, database credentials, cron jobs, redirect rules, environment variables, email accounts on the domain, and SSL setup. A migration that copies the files but forgets the cron jobs or redirects looks fine on the homepage and breaks three clicks deep.
If this move is also a chance to reconsider what kind of hosting you need — shared, VPS, cloud, or dedicated — settle that first. Our guide to web hosting types lays out which setup fits which traffic and control level, so you migrate onto the right tier once instead of twice.
Step 1 — Build a complete copy on the new host
On the new server, recreate the site fully before the domain knows it exists:
- Match the environment. Set the new host's runtime to the same major PHP/Node version the old site used, and create a database with the same character set. Mismatched versions are a leading cause of "it worked on the old host" breakage.
- Upload the files and import the database. Copy the full file tree and import your database dump. For stacks like WordPress, update the site's config file with the new database name, user, and password.
- Rebuild the machinery, not the content. Point config at the new database, fix any absolute file paths, and recreate cron jobs, redirects, and environment variables from your inventory.
The live domain stays untouched throughout — visitors are still served by the old host.
Step 2 — Test on the new server before any switch
This step separates a calm migration from a scramble, and it's the one people skip. You can exercise the new server fully while the public still uses the old one by pointing only your own computer at it — edit your local hosts file to map the domain to the new IP:
203.0.113.10 example.com www.example.com
Now your browser loads the real domain from the new server while everyone else still hits the old one. Click through as a visitor and an admin: load pages, submit a form, log in, and run a test checkout if you sell anything. Watch for mixed-content or SSL warnings, broken links, and database errors, and confirm images and downloads resolve. When you're done, remove the hosts entry. Move on only once the copy works end to end — private testing exists to surface problems before visitors can.
Step 3 — Lower your DNS TTL a day ahead
TTL (time to live) controls how long DNS resolvers cache your records before rechecking. If yours is a typical few hours, then after you switch hosts some visitors keep getting the old address for that whole window — the cached-DNS lag people mistake for downtime.
Shrink that window in advance. At least a day before the cutover, lower the TTL on the records you'll change (usually A, plus AAAA for IPv6) to a small value such as 300 seconds:
; lower TTL ahead of the cutover so the switch propagates fast
example.com. 300 IN A 198.51.100.20 ; old host, low TTL
The catch: the old TTL applies until it expires, so this only helps if you do it early. A day ahead is enough — then resolvers pick up the cutover in minutes, not hours.
Step 4 — Cut over, then keep the old host alive
The switch itself is the fast part:
- Update the DNS record to the new server's IP (the
A/AAAArecords). A record-only edit is the gentler cutover; changing nameservers or registrar takes longer. - Leave the old host running, untouched, for at least 24–48 hours. This is your rollback. Until every resolver worldwide expires its cache, a slice of visitors still lands on the old server, so it must stay live and identical. Cancelling the old plan the same day is the classic way to turn a clean migration into real downtime.
- Freeze content changes during the overlap. Avoid new posts, orders, or comments in the cutover window, or you risk writing data to the old database that never reaches the new one. On a busy store, schedule the cutover for a quiet hour.
Once old-host traffic drops to near nothing and the new site has run clean for a day or two, retire the old plan.
FAQ
Can I migrate a website without downtime at all?
Yes, if you keep the order right. The old host serves real traffic until the moment you flip DNS, so there's no unreachable window. Downtime only appears if you point the domain at the new server before it's ready, or kill the old host too early.
Do I need to lower DNS TTL before changing hosts?
Not strictly, but it makes the cutover far smoother. Without it, some visitors keep resolving to the old server for as long as your old TTL — often hours. Lowering it to around 300 seconds a day in advance shrinks that window to minutes. It only takes effect once the previous TTL expires, so do it early.
What is the most common mistake that breaks a migration?
Reversing the safe order — pointing the domain at the new host before the site is fully copied and tested there. A close second is cancelling or wiping the old host the same day, which removes your rollback and cuts off visitors still routed there by cached DNS. Keep it live for 24–48 hours past the switch instead.
How do I move WordPress to a new host without breaking it?
The same copy-first sequence applies, plus two WordPress specifics. Copy the full file tree and export the database, then edit wp-config.php on the new host with the new database name, user, and password. And because WordPress stores its own address in the database, mismatched URLs are the usual cause of redirect loops or missing styling — so run the private hosts-file test on the real domain before cutover, which keeps that stored URL correct. A reputable migration plugin can automate the copy, but the verify-then-flip order is unchanged.
Next step
A no-downtime migration is not a feat of timing — it's a checklist followed in order. Back up off-server, build and privately test a full copy on the new host, lower your DNS TTL a day ahead, then flip the record and leave the old host running until propagation completes. Follow that sequence and visitors never notice the move. When you're ready to migrate onto hosting sized to your site, see what Just-Server offers.
