How to move your website to a new host with zero downtime

The scary part of a host move was never the copying. It's the moment you point DNS at the new server and hope. Good news: you can migrate a website with no downtime if you follow one rule above all others, which is copy first, switch last. Don't delete or break anything on the old host until the new one is proven, live, and serving real traffic. Do that, and the ugliest case you'll hit is a few minutes where some visitors land on the old server and some on the new one, and both of them work fine.

I've run hundreds of these. Tiny WordPress blogs, busy vBulletin forums where the database dwarfed the file tree, a couple of Magento shops that made me sweat. The playbook below is the one I actually use, and it's deliberately boring. Boring is what keeps your site up.

The core idea: two working copies during the switch

DNS is not instant. When you change where your domain points, that change ripples across the internet over minutes to hours, depending on who cached what. During that window some people resolve to the old IP and some to the new one. If both servers hold your full site and both talk to a working database, nobody notices anything. That overlap is the entire trick.

So the plan reads like this. Build a complete, working copy on the new host while the old one keeps running, untouched. Test that copy privately. Flip DNS. Leave the old host powered on for a day or two. Only then pull the plug.

Step 1: Lower your DNS TTL first

Everyone forgets this one, and it's the step that saves you hours. Your A record carries a TTL (time to live) that tells resolvers how long they're allowed to cache it. Defaults are usually 3600 seconds (an hour) or, worse, 86400 (a full day). Flip DNS with a 24-hour TTL still in effect and some visitors keep hitting the old IP well into tomorrow.

1. Log into wherever your DNS actually lives (your registrar, or a separate DNS provider like Cloudflare).
2. Find the A record for the bare domain and the one for www.
3. Drop the TTL to 300 seconds, so five minutes.
4. Save, then wait at least as long as your old TTL before you migrate. If it was an hour, wait an hour. That lets the low value propagate before you need it.

Do this a full day ahead when you can. Then, when you finally switch, propagation is a coffee break instead of an afternoon. Bump the TTL back to 3600 once the move has settled.

Step 2: Copy the files

Now pull a complete copy of the site's files onto the new server. For most sites that means the web root: HTML, PHP, the uploads folder, themes, all of it. FTP works, but it crawls through thousands of tiny files, and a real WordPress uploads directory will bring a plain FTP client to its knees. If you have shell access, reach for rsync or a compressed tarball.

1. On the old host, archive the web root: tar czf site.tar.gz public_html or whatever your directory is called.
2. Move it to the new host with scp, or through the panel's file manager.
3. Extract into the new web root, then sanity-check permissions. Files land at 644, directories at 755.

Full file and FTP access on the new box makes this painless, which is exactly why we hand you that on every VASTROX plan instead of walling you off from your own site.

Step 3: Export and import the database

Static sites get to skip this bit. Anything dynamic keeps its content in a database (WordPress, a shop, a forum), and that has to cross over clean.

1. Export from the old host. Use mysqldump if you have shell access, or phpMyAdmin's Export tab for small databases.
2. Create a fresh database and user on the new host, and write down the name, user, and password.
3. Import the dump.
4. Point your app's config at the new credentials. For WordPress that's wp-config.php: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.

Here's a gotcha with big databases. phpMyAdmin will time out or slam into the upload limit on anything past roughly 50 MB, and it tends to fail quietly in the browser rather than telling you plainly. Past that size, do it on the command line. It isn't a preference at that point.

Step 4: The WordPress wrinkles

WordPress carries two quirks worth knowing before you switch. The site URL lives in the database, in the wp_options table (the siteurl and home rows). And absolute URLs are baked into post content and serialized option blobs, so a naive find-and-replace can shred that serialized data and leave you with a half-broken site.

Since a host move keeps the same domain, you usually don't touch URLs at all. Same domain in, same domain out. If you do end up testing under a temporary URL, don't hand-edit URLs in SQL. Run WP-CLI: wp search-replace 'oldurl' 'newurl' walks serialized data correctly. Honestly, WP-CLI earns its keep on that one command alone.

Flush any caching plugin after the import, too, and double-check DB_HOST in wp-config.php. On plenty of hosts it's localhost, but not everywhere, so confirm instead of assuming. If part of the reason you're moving is a sluggish old server, our notes on choosing fast WordPress hosting cover what genuinely shifts page speed.

Step 5: Test before DNS knows anything

This is the part that lets you sleep. You can view the new site under its real domain on your machine only, before you touch a single public DNS record, by editing your local hosts file. That tricks just your computer into resolving the domain to the new server's IP while the rest of the world carries on with the old one.

1. Grab the new server's IP address.
2. Open your hosts file: /etc/hosts on macOS and Linux, or C:\Windows\System32\drivers\etc\hosts on Windows (launch your editor as administrator, or the save will bounce).
3. Add a line with the new IP, a space, then your domain. Add a second line for the www version.
4. Save, flush your DNS cache, and load the site in a private window.

You're now staring at the new server through your real domain. Click around. Log in. Submit the contact form. Load an image straight out of the uploads folder. Confirm HTTPS works and the certificate is valid, not some default self-signed thing. When it all checks out, pull those hosts lines back out. This single test catches most migration surprises before one visitor is affected.

Step 6: Flip DNS, then leave the old host running

Once the copy passes, change the public A record to the new IP. With TTL already sitting at 300, most resolvers pick it up within a few minutes.

Do not cancel the old hosting yet. Keep it live and serving for 24 to 48 hours. Stragglers with cached DNS still land there, and since both servers work, they get a working site regardless. The one thing to watch during overlap is data divergence: if people can post comments or place orders, those writes could hit either database. For most sites the trickle is nothing. For a busy store, throw up a maintenance page for the couple of minutes the switch actually takes, or run the move at your quietest hour of the week.

Step 7: Verify, then clean up

1. Confirm the world sees the new IP (a lookup from an outside checker tells you propagation is done).
2. Set up SSL on the new host if it isn't already (Let's Encrypt, usually one click in the panel).
3. Test the contact form, checkout, and login on the live site, not the cached copy in your head.
4. Raise the TTL back to 3600.
5. Only now, after a clean day or two, cancel the old plan.

That's the whole method. Copy, lower TTL, sync files and database, test through your hosts file, switch DNS, keep the old host warm. The same seven steps carry a five-page brochure site and a database-heavy WordPress build alike, which is the nice thing about doing it this way: you learn it once.

If the manual route is more than you signed up for, you don't have to go it alone. We run free migrations for new customers, so moving to our web hosting (or the WordPress hosting plans if that's your stack) means we handle the file sync, the database import, and the DNS timing. Whoever does the work, the golden rule doesn't budge: keep the old site breathing until the new one has quietly earned its place.