Move WordPress to a New Host Without Downtime or Broken Links

You can migrate a WordPress site to a new host with zero downtime by copying your files and database to the new server, updating the site URL and database credentials, then flipping DNS only after the new environment is fully tested. Done in the right order, visitors never see an error and no links break. The trick is the sequence — specifically, keeping the old server live until DNS has fully propagated and every URL has been verified.

This guide walks through the entire process in plain English: what to prepare, how to move everything safely, how to handle the URL change, and how to smoke-test the new site before you cut over. It covers both the manual method and the plugin-assisted route, so you can pick whichever matches your comfort level.

What "downtime" and "broken links" actually mean here

During a migration two things can go wrong that are easy to conflate:

• Downtime — visitors hit an error, a blank page, or a "site not found" message because DNS has moved but the new server isn't ready.
• Broken links — internal links, images, and embeds hardcoded to the old domain or an old subdirectory stop resolving after the move.

Both are avoidable. Downtime is prevented by never changing DNS until the new site is confirmed working. Broken links are prevented by doing a careful URL search-and-replace in the database — at the right moment, not before.

Before you touch anything: the pre-migration checklist

1. Take a full backup of the live site — files and database — and download it somewhere you control (not just the host's own backup). This is your safety net regardless of what goes wrong.
2. Confirm your new host is provisioned and you have SFTP/FTP credentials and database access (phpMyAdmin or a CLI).
3. Note the current PHP version on the old host. Provision the new server to match it initially — you can upgrade later.
4. Check whether the new host requires a specific document root (usually public_html or www) and confirm SSL is available.
5. Write down the current values of siteurl and home in the database (or in Settings → General). You'll need these during the URL swap.

Step 1 — Copy all files to the new server

Connect to the old host via SFTP and download the entire WordPress root (the folder containing wp-config.php). Upload that same folder to the document root on the new host. This includes your theme, plugins, uploads, and all core files.

If the site is large, use a migration plugin (see the plugin route below) or ask your new host whether they offer a server-side transfer — many do it for free and it's faster than a local copy.

Step 2 — Export and import the database

On the old host, open phpMyAdmin, select your WordPress database, and export as SQL using the default settings. On the new host, create a fresh database and a database user, assign full privileges, then import the SQL file.

Do not run a URL search-and-replace yet. You still need the old URLs intact while you test on the new server via a temporary preview URL or a hosts-file trick (explained in Step 4).

Step 3 — Update wp-config.php

Open the wp-config.php you uploaded to the new server and update these four lines to point to the new database:

define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_db_user' );
define( 'DB_PASSWORD', 'new_db_password' );
define( 'DB_HOST', 'localhost' ); // confirm with your new host

Save the file. Do not change the site URL constants yet.

Step 4 — Preview the new site before touching DNS

This is the step most guides skip, and it's the most important one for achieving zero downtime.

Some new hosts provide a temporary staging URL (like yoursite.newhost.com). If yours does, use it. If not, you can preview the new server by temporarily editing your local hosts file to point your domain to the new server's IP — only on your own computer, invisible to the rest of the world.

On macOS/Linux, open /etc/hosts with sudo. On Windows, find it at C:\Windows\System32\drivers\etc\hosts. Add a line like:

123.45.67.89   yourdomain.com www.yourdomain.com

Replace 123.45.67.89 with the new host's IP. Save the file, flush your DNS cache, then visit your domain in a browser. You're now seeing the new server while everyone else still sees the old one.

Test thoroughly: homepage, a few posts, the contact form, the shop (if applicable), admin login, and a media upload. If something is broken, fix it now while traffic is still hitting the old server.

Step 5 — Run the URL search-and-replace (carefully)

If the domain name is changing (e.g., you're also switching from HTTP to HTTPS, or from a www subdomain to bare domain), you need to update every hardcoded URL in the database. The safe tool for this is Search Replace DB or the WP-CLI command:

wp search-replace 'http://olddomain.com' 'https://newdomain.com' --all-tables

Run this on the new server's database only, after you've finished testing and are ready to go live. It handles serialised data correctly, which a plain SQL REPLACE() does not.

After the replace, open Settings → General in the new site's WordPress admin and confirm both the WordPress Address and Site Address fields show the correct final URL.

Step 6 — Provision SSL on the new host

If the new host uses Let's Encrypt (most do), install the certificate before you change DNS. Confirm HTTPS loads correctly on the temporary URL or via your hosts-file preview. Trying to issue a certificate after DNS has moved can fail during the brief propagation window and cause a mixed-content or redirect loop.

Step 7 — Lower the DNS TTL, then change the nameservers

At least 24–48 hours before your planned cutover, log into your domain registrar and lower the TTL on your A record to 300 seconds (5 minutes). This means when you do flip DNS, propagation will be fast — typically under 30 minutes rather than up to 48 hours.

When you're ready, update the A record (or nameservers) to point to the new host. Keep the old server live and leave it untouched for at least 48 hours after the DNS change. Some visitors' ISPs cache the old IP longer than expected; if the old server is still up, those visitors still land on a working site.

Step 8 — Verify after DNS propagates

Remove the hosts-file entry you added earlier and visit the live site from a normal browser. Check:

• Homepage loads over HTTPS with no mixed-content warnings
• A few internal links — especially image URLs in post content
• Admin panel login and a test page save
• Any redirects (e.g., www → non-www)
• Google Search Console — add the new property if the domain or protocol changed

Run a crawl with a tool like Screaming Frog or the free Broken Link Checker to catch any remaining hardcoded old URLs in content. Fix them with another targeted search-replace or manually in the editor.

The plugin route: when to use a migration plugin

If you'd rather not do this manually, plugins like Duplicator, All-in-One WP Migration, or Migrate Guru handle the file copy, database export, and search-replace in a guided flow. They work well for most sites under a few gigabytes. The main caveats:

• Free tiers of some plugins cap file sizes — confirm before you start.
• You still need to manage SSL, DNS TTL, and post-migration verification yourself.
• The hosts-file preview step is just as important with a plugin as without it.

The manual method gives you more control and a clearer mental model of what actually moved, which makes debugging easier if something breaks.

Common problems and how to fix them

White screen or critical error after import

Almost always a wp-config.php database credential mismatch or a PHP version difference. Double-check your DB constants and temporarily match the PHP version to the old server. See the WordPress White Screen of Death fix guide for a deeper walkthrough.

Images broken after the move

The search-replace didn't catch every URL, or it ran before you were on the final domain. Run the replace again targeting the specific old URL pattern you can see in the broken image src.

Redirect loop on the new site

Often caused by siteurl or home still pointing at the old domain while WordPress is now served from the new one, or an SSL redirect conflict. Check the options table and your .htaccess. The WordPress login redirect loop guide covers the same underlying mechanics.

Admin login broken

Check that cookies are set to the correct domain. If you changed from www to non-www (or vice versa), old session cookies may conflict. Clear all browser cookies and try again.

How to prevent migration problems in future

• Avoid hardcoding absolute URLs in theme templates or custom CSS — use get_site_url() or relative paths.
• Run a staging environment that mirrors production so you can test any big change before it touches the live site.
• Keep regular off-site backups. A migration gone wrong is unrecoverable without them.

When to hand this off to a professional

A straightforward migration to a new host is manageable for most site owners who are comfortable with SFTP and phpMyAdmin. But if your site is running WooCommerce with live orders, a large multisite network, or a custom server configuration, the margin for error gets thin fast — and a mistake during a commerce migration can cost far more than a professional fix.

If you've started the migration and something has gone wrong — broken admin, 500 errors, or a white screen — the 500 error fix guide may point you in the right direction. If you're stuck and need it resolved today, Mend's Quick Fix service is a flat $129, most migrations are sorted the same day, and every fix comes with a plain-English report of exactly what changed. There's also a free Diagnosis if you're not sure what you're dealing with yet — no card required.

Done carefully and in the right order, moving a WordPress site to a new host is a predictable, low-risk procedure. The sequence matters more than the tools: copy everything, test before you touch DNS, do the URL replace at the right moment, keep the old server live during propagation. Follow those principles and you'll have a clean cutover with no downtime and no broken links.