How to Migrate WordPress Without Downtime

Moving a WordPress site to a new host has a reputation for going wrong. Pages break. Orders get lost. The site sits on a holding page for a day while DNS sorts itself out and customers bounce.

It does not have to be that way. You can migrate WordPress without downtime if you do the move in the right order. The trick is simple: you never take the old site offline until the new one is fully live and tested. This guide walks through exactly how that works, step by step, whether you do it yourself or hand it to someone who does it for a living.

What “Zero Downtime” Actually Means

First, an honest definition, because some hosts oversell this.

True zero downtime means visitors never hit an error, a maintenance page, or a half-broken site at any point during the move. They keep seeing your working site the whole time. The moment the switch happens, they land on the new server without noticing a thing.

The one variable nobody fully controls is DNS propagation, the short window where the internet updates its records to point your domain at the new server. Done properly, this causes no visible downtime at all, because both the old and new server are serving the same working site during that window. Done carelessly, it is where most “downtime” actually comes from.

So the real goal is this: keep the live site running untouched, build and test a perfect copy on the new host, and only flip the switch when the copy is ready. Get the order right and the move is invisible to your visitors.

The Core Principle: Build First, Switch Last

Almost every migration disaster comes from doing the steps in the wrong order. People point their domain at an empty or half-finished server, then try to fix the site while it is already live and broken.

Reverse it. The safe order is always:

1. Build a complete copy on the new host.
2. Test that copy hard, before any visitor can see it.
3. Lower your DNS TTL ahead of time so the switch is fast.
4. Switch the domain over only when the copy is proven.
5. Watch the new site closely for the first day.

Your old site stays live and untouched the entire time. If anything goes wrong on the new server, no real visitor ever sees it.

Step 1: Take a Full Backup First

Before you touch anything, back up the current site completely. That means all of it: the WordPress files, the uploads folder, the themes and plugins, and the full database. Keep that backup somewhere off the server.

This is your safety net. If the worst happens, you can restore the original exactly as it was. You will almost certainly not need it, but a migration without a backup is a gamble, not a plan.

Step 2: Set Up the New Server and Copy the Site Across

On the new host, set up a clean environment for the site: the right PHP version, a web server tuned for WordPress, and a database ready to receive the import.

Then move the site across:

• Copy all the WordPress files and the uploads folder to the new server.
• Export the database from the old site and import it into the new one.
• Update the site’s config (wp-config.php) with the new database details.

At this point you have a full copy of your site sitting on the new server. Nobody can see it yet, because your domain still points at the old host. That is exactly what you want.

Step 3: Preview the New Site Before You Go Live

Here is the part that makes the move safe. You need to see the new copy working before the public does.

You can do this without changing your domain at all. The usual method is to edit your computer’s local hosts file to point your domain at the new server’s IP address, just for you. Your visitors still see the old site. You see the new one. Many hosts also give you a temporary preview URL or staging address that does the same job.

Either way, you now have a private window into the new site while the live site keeps running for everyone else.

Step 4: Test Everything on the New Server

Now test the copy properly. This is where you catch problems while they are still invisible to the public. Check:

• Every key page loads and looks right, with images and styling intact.
• Internal links and the menu work.
• Contact forms send and arrive.
• Logins work for you and your team.
• If it is a store, the cart and checkout work end to end.
• SSL is installed so the site loads on https with no warnings.

Fix anything broken now, on the copy, while your real site is still happily serving visitors from the old host. Take your time here. Nothing is live, so there is no pressure and no risk.

Step 5: Lower Your DNS TTL Before the Switch

This is the single step most people skip, and it is the one that decides whether the cutover is clean.

Your domain’s DNS records have a TTL, a “time to live” that tells the internet how long to cache them. If your TTL is set to a long value like 24 hours, then when you switch hosts, some visitors can keep hitting the old server for up to a day.

So a day or two before you plan to switch, lower the TTL on your domain’s records to something short, like 300 seconds. Then wait for the old long value to expire. When you finally make the switch, the change spreads across the internet in minutes instead of hours. The shorter the TTL, the faster and cleaner the cutover.

Step 6: Do the Cutover

Now you switch. Point your domain’s DNS records (usually the A record, or a CNAME) at the new server. Because you lowered the TTL, this propagates fast.

Here is why it causes no downtime: both servers are still running the same fully working site. As DNS updates, visitors quietly move from the old server to the new one. The few who are still cached on the old host keep seeing a working site until they catch up. Nobody hits an error. Nobody sees a maintenance page.

One practical tip: avoid making content changes during the cutover window. If a customer places an order or leaves a comment in the gap, it could land on whichever server they happened to reach. Picking a quiet traffic period keeps that risk near zero.

Step 7: Keep the Old Server Running for a Few Days

Do not cancel the old hosting the moment you switch. Leave it running for a few days while DNS fully settles everywhere in the world.

During this window, both servers serve the same site, so it does not matter which one a visitor reaches. Once you are confident all traffic has moved to the new server, and you have a clean backup, you can shut the old one down.

Common Mistakes That Cause Downtime

Most “WordPress migration without downtime” attempts fail for the same handful of reasons:

• Switching DNS before the new site is ready. This is the big one. Always build and test first.
• Forgetting to lower the TTL. A long TTL turns a clean switch into hours of mixed, inconsistent traffic.
• Missing the uploads folder or part of the database. A partial copy looks fine until a customer hits the page you forgot.
• Hard-coded URLs in the database. Old absolute links and paths can break images and redirects after the move. They need updating as part of the import.
• No SSL on the new server before cutover. Switch to a server with no certificate and visitors get a security warning instead of your site.
• Cancelling the old host too early. Give DNS time to settle worldwide before you pull the plug.

None of these are hard to avoid. They just need doing in the right order, with attention.

Or Skip All of This and Let Forge Do It for You

Everything above is doable yourself. It also takes care, the right server setup, and a clear head on cutover day. Most people would rather not spend their weekend editing hosts files and watching DNS records.

So Forge does the whole thing for you, for free.

Every Forge plan includes a free WordPress migration, and we run the entire move end to end. We build your site on your own dedicated server, configure the web server, caching, SSL, and security, test every page on a staging URL first, then handle the DNS cutover at a time that keeps downtime to a minimum. We watch the new site for the first 24 hours and give you 7 days of post-migration support in case anything looks off.

You do almost nothing. You give us access to your current site, and we take it from there. No hosts files, no TTL math, no nervous cutover day.

Forge pricing is flat, from Starter at $39/month to Enterprise at $209/month, and free migration is included on every tier. The price you start on is the price you stay on, with no renewal increase.

If you have been putting off a move because of the downtime risk, that risk is now ours, not yours.

Start a free migration