How to Move Your Website to a New Host Without Downtime

Moving a website to a new host sounds terrifying — one wrong step and your site vanishes, emails bounce, and Google finds a ghost town. In reality, a migration with no downtime is a well-understood routine built on one principle: never take the old site down until the new one is proven working. Both copies run in parallel, and you switch visitors over only at the end, using DNS — the internet’s address book.

This guide walks through the whole process for a WordPress site: choosing the migration method, moving files and database, testing secretly on the new host, and flipping the switch safely.

Quick Answer

To move your website to a new host without downtime: set up the new hosting account, copy your site’s files and database there (via your new host’s free migration service, a migration plugin like Migrate Guru or UpdraftPlus, or manually), test the copy using a temporary URL or a hosts-file trick, then update your domain’s DNS to point at the new server. Keep the old hosting active for at least 48 hours while DNS spreads worldwide, verify everything works, and only then cancel the old plan.

Why Downtime Happens (and Why It Doesn’t Have To)

Downtime during moves comes from one mistake: changing where the domain points before the new site is ready — or deleting the old site before the world has caught up. DNS changes don’t apply instantly; they propagate over a few hours (occasionally up to 48). During that window, some visitors still reach the old server while others reach the new one. If both servers have a working copy of your site, nobody sees a broken website — that’s the entire secret. (One exception: a busy store or forum can receive orders/posts on the old copy during propagation. Plan moves for quiet hours, and check the old site for stray orders afterwards.)

Step 1: Prepare

1. Buy the new hosting but do NOT cancel the old plan yet. You’ll run both for a few days.
2. Take a full backup of the current site — files and database — and download a copy to your own computer. If everything goes wrong, this is your parachute. Our guide on backing up your WordPress website safely covers the reliable methods.
3. Note your current setup: PHP version, SSL status, email arrangement (crucially: is your email hosted with the old host too? If so, email must be migrated or moved to a separate provider, or it will break when you cancel).
4. Lower your DNS TTL (optional, 24h ahead): In your DNS settings, set the TTL for your domain’s A records to 300 seconds. This makes the later switch propagate faster because servers refresh their address books more often.

Step 2: Copy the Site to the New Host

Option A: Free host migration (easiest)

Many hosts will move your site for free to win your business. You provide your old login details, they copy everything, and they usually test it too. Ask before buying — and remember this handles the website, not always email.

Option B: A migration plugin (best DIY method)

1. On the NEW host, install a fresh, empty WordPress.
2. Install a migration plugin on both sites — Migrate Guru or All-in-One WP Migration are the standards. (For larger sites, UpdraftPlus’s restore-to-new-site method also works well.)
3. Run the export/migration from the old site, import on the new one, and let it finish completely.
4. The plugin handles files, database, and the fiddly URL replacements automatically.

Option C: Manual migration (full control)

1. Download all files from the old host via FTP (or a zipped archive from its file manager) and upload them to the new host’s public folder.
2. Export the database from the old host’s phpMyAdmin, create a new database on the new host, and import the SQL file.
3. Edit wp-config.php on the new host with the new database name, username, password, and host.
4. If the domain is staying the same (it usually is), no URL changes are needed in the database.

The WordPress project’s own moving WordPress documentation details the manual route file by file for anyone who wants the authoritative version.

Step 3: Test the New Site Before Anyone Sees It

1. View it secretly: Use the new host’s temporary URL if they provide one. If not, use the hosts-file trick: add a line like 123.45.67.89 yourdomain.com www.yourdomain.com (with the NEW server’s IP) to your computer’s hosts file. Your browser — and only yours — now loads the new server when you visit your domain.
2. Click everything: Homepage, posts, images, contact form, search, login, and checkout if you sell anything. Test on your phone too.
3. Fix SSL: Install a free Let’s Encrypt certificate on the new host now (a temporary mismatch warning during hosts-file testing is normal if the certificate isn’t issued yet).
4. Remove the hosts-file lines when testing is done.

Step 4: Switch DNS and Monitor

1. At your registrar (or wherever your DNS lives), update the domain’s A records for @ and www to the new server’s IP address — or change the nameservers if your new host instructs that instead.
2. Wait and watch: propagation typically takes 1–6 hours, up to 48 worst case. Tools like dnschecker.org show the new IP spreading across the world.
3. During propagation both sites are live and identical, so visitors are unaffected.
4. Once fully switched, log in to the NEW site’s dashboard, confirm you can publish a test change, check forms and email, and verify SSL shows the padlock everywhere.
5. Wait at least 48 hours after full propagation, check the old site for any stray orders, comments, or form submissions made during the overlap, and only then cancel the old hosting.

Common Migration Mistakes

• Cancelling the old host first: The moment the old plan dies, so does your safety net — and, during propagation, half your visitors’ website.
• Forgetting email: If email lives on the old host, it must be migrated or set up separately, and its MX records checked, or mail silently bounces after the move.
• Skipping the test phase: Every problem is easier to fix while the public still sees the old site. The hosts-file test is five minutes that save five hours.
• Changing domain AND host at the same time: Do one, stabilize, then the other — troubleshooting two simultaneous changes is misery.
• Deleting the backup after a successful move: Keep the final pre-move backup for a month. Storage is cheap; regret is expensive.

Conclusion

A zero-downtime migration is just discipline: prepare a backup, copy the complete site to the new host while the old one keeps serving visitors, test the copy privately until it’s perfect, then change DNS and let both sites overlap while the internet catches up. Cancel nothing until the new home has proven itself for at least two days. Follow that order, and your visitors — and Google — will never notice you moved at all.

Frequently Asked Questions

How long does it take to move a website to a new host?

The copy itself takes 30 minutes to a few hours depending on site size and method. DNS propagation after the switch takes 1–6 hours typically, up to 48 in the worst case. Plan a full day of elapsed time for a calm, verified move.

Will moving hosts hurt my Google rankings?

Not if done properly. Keeping the same domain, URLs, and content means Google sees the same site at a new address. Brief speed differences during propagation don’t matter. Rankings suffer only when moves change URLs without redirects or cause extended downtime.

Can my new host really migrate my site for free?

Many do — it’s a common customer-acquisition offer, usually for one site per account and sometimes only on higher plans. Always confirm what’s included (email rarely is) before relying on it.

What happens to my email when I move hosts?

If your email is hosted with your old host, it stops working when you cancel unless you migrate it or move email to a separate provider (Google Workspace, Microsoft 365) first. If email already lives elsewhere, just make sure the MX records stay correct after the DNS change.

What if something goes wrong during the migration?

Point DNS back to the old server (which is still running, because you didn’t cancel it) and you’re live again in the time propagation takes. That’s exactly why the overlap-and-backup approach exists — every step is reversible.