How to move a WordPress site to a new host (without downtime)

01Why moving hosts feels scary (and why it isn't)

Moving a WordPress site sounds like open-heart surgery, but it's really a copy job with one careful handoff at the end. A WordPress install is two things: a folder of files (WordPress core, your theme, plugins, and uploads) and a database (your posts, pages, settings, and users). Migrating means copying both to a new server and telling that copy what its address is.

The reason migrations get a bad reputation is that people change DNS first and debug live, in front of visitors. Do it the other way around — get the copy working on a temporary URL, confirm everything, then flip DNS — and the scary part disappears. The site is already proven before any real traffic touches it.

It's worth remembering why you can do this at all: you own the site. The files, the database, and the domain name belong to you, not to your current host. No provider gets to hold your site hostage. A clean migration is just you exercising that ownership — and proving to yourself that you're never locked in.

02What to know before you touch anything

A little prep work removes most of the surprises. Before you copy a single file, get clear on what you're moving, where it's going, and how you'll roll back if something goes sideways.

Gather your access and details

• Old host access. SFTP or file manager, plus database credentials (often in wp-config.php) so you can export everything.
• New host access. A fresh hosting account with an empty WordPress-ready environment, SFTP/SSH, and a way to create a database.
• Domain registrar login. This is where DNS lives. It is frequently separate from your hosting — confirm you can actually log in before migration day.
• A current backup. A full copy of files and database, stored somewhere that is not either server. This is your undo button.

Understand the two failure points

Almost every migration that goes wrong fails in one of two places: the site URL is hardcoded to the old domain and breaks on the new server, or DNS is changed before the new copy is ready and visitors hit a half-built site. Keep both in mind and you've defused the migration's only real risks.

Lower your domain's DNS TTL (time to live) a day ahead of time if you can. A long TTL means old DNS answers linger in caches for hours after you change them; a short TTL makes the eventual flip propagate quickly. It's a small, quiet step that makes the cutover feel instant.

03Step by step: copy the site onto a staging copy first

The safest migration never tests on the live domain. You build the new site on the new host at a temporary address, prove it works, and only then point the real domain at it. Here is the sequence on a staging-style copy.

1. Export files and database from the old host

Download the entire WordPress folder via SFTP, and export the database (your old host's database tool or phpMyAdmin can produce a .sql file). A migration plugin like Duplicator bundles both into one archive plus an installer script, which can be simpler than handling the two pieces separately.

2. Recreate the site on the new host

• Manual route: create an empty database on the new host, import your .sql file, upload the WordPress files, and edit wp-config.php with the new database name, user, and password.
• Plugin route: upload the migration archive and installer to the new host and run the installer, which rebuilds the database and files and rewrites credentials for you.
• Either way: do this work against a temporary URL the new host provides, not your live domain, so nothing public changes yet.

3. Point the copy at the right URL and test

Make sure the site's URL settings match wherever you're testing, then click through it: home page, a few posts, the admin login, forms, and images. Migration plugins handle URL rewriting for you; manual movers may need a search-replace on the database. Treat this temporary copy exactly like a staging site — break it here, not in front of visitors.

04Common mistakes that cause downtime

Migrations rarely fail because the copy was hard. They fail on a handful of predictable mistakes, almost all of them around URLs and DNS. Here is what actually trips people up.

Changing DNS before the copy is ready

If you flip DNS first, visitors land on a new server that's still half-configured. Always finish and verify the copy on a temporary URL, then change DNS last. The flip should be the boring final step, not the experiment.

Hardcoded old URLs in the database

WordPress stores absolute URLs in the database, so a moved site can keep linking back to the old domain — broken images, mixed content, redirect loops. A proper search-replace (or a migration plugin's URL rewrite) fixes this. Avoid raw find-and-replace on a .sql dump, which corrupts serialized data; use a tool that understands it.

Forgetting the uploads or the database

Copy only the files and you get a site with no content; copy only the database and you get content with no theme or images. You need both. The wp-content/uploads folder in particular is easy to miss because it can be large and slow to transfer.

Deleting the old host too soon

Keep the old hosting account live for at least a week after the flip. DNS takes time to propagate everywhere, and you want a fallback if the new host surprises you. Cancelling the old plan the same day is how a recoverable hiccup becomes a real outage.

05Tie it to maintainability and avoiding lock-in

A migration is more than a one-time chore — it's proof of a principle worth building your whole site around: you should always be able to pick up your site and move it. Treat every host as replaceable and you keep the leverage.

• Keep portable backups. Regular off-site backups of files and database mean you're never more than a restore away from independence — on this host or any other.
• Avoid host-specific lock-in. Be cautious with proprietary builders or features that only run on one provider. The more standard your stack (plain WordPress, standard plugins), the easier the next move.
• Document your stack. A short note listing your theme, key plugins, PHP version, and database name turns a stressful migration into a checklist.

The freedom to move is what keeps a host honest. If support slips or prices climb, a site you can migrate in an afternoon gives you the option to leave — which is exactly the position you want to be in. Owning your site means never being trapped by a single provider.

06A note on hosting and staging

The single thing that makes migrations calm is having a staging environment — a private copy of your site where you can test the move before it's real. Hosts vary a lot in how easy they make this.

Some managed hosts include one-click staging and built-in migration tools, which take most of the manual fiddling out of the process. Cloudways, the host we partner with, offers free staging environments and a migration path, which is genuinely useful for a move like this. We'd point you to it for that reason — but plenty of hosts offer similar features, and the right choice is the one that fits your budget and stack. Compare honestly before you commit.

Whatever host you land on, the rule is the same: test on a copy, keep a backup, and flip DNS last. The tooling just makes that rule easier to follow.

07Frequently asked questions

How long does a WordPress migration take?

The copy itself is usually quick — minutes to an hour depending on how large your uploads and database are. The variable part is DNS propagation after the flip, which can range from near-instant to a day or so depending on your TTL. Plan for a slow tail even if the active work is short.

Will my site go down during the move?

It shouldn't, if you build and test the copy on a temporary URL before changing DNS. The old site keeps serving visitors the entire time you're preparing the new one. The only moment of change is the DNS flip, and by then the new site is already proven.

Should I use a plugin or migrate manually?

Plugins like Duplicator or All-in-One WP Migration are great for small to mid-size sites and spare you the URL and database fiddling. Manual migration gives you full control and handles very large sites that exceed a plugin's limits. Neither is wrong — choose by site size and how comfortable you are touching files.

What if something breaks after the flip?

This is why you kept the old host live and a fresh backup. If the new site misbehaves, you can point DNS back to the old host while you debug, then try the flip again. Nothing about a careful migration is irreversible within that first week.

This is general editorial guidance to help you plan a move, not financial or business advice — every site and host differs, so verify the specifics with your hosting provider's documentation and test on a copy before trusting it in production.