Skip to content Skip to footer

How to Migrate a WordPress Site to a New Host

Why Your Migration Strategy Matters

Migrating a WordPress site can feel like moving a glass house across a rocky road. One wrong turn, and you face the “White Screen of Death,” broken database connections, or worst of all, a sudden drop in your hard-earned SEO rankings.

However, staying on a subpar hosting provider is often a bigger risk. Whether you are chasing faster server response times, superior technical support, or better cost-efficiency, a professional website migration is a necessary step for your business growth.

The Goal: A Zero-Downtime Transition

The gold standard of any website migration is simple: your visitors (and Google’s crawlers) shouldn’t even notice it happened. Our primary goal is to transfer every byte of data while maintaining your site’s integrity and search engine visibility. By focusing on a seamless transition, you ensure that the move to a new environment strengthens your digital presence rather than disrupting it.

Key Concept: Manual vs. Plugin Migration

Before we dive into the steps, you need to choose your “vehicle” for this journey:

  • Plugin-Based Migration: Best for beginners and standard sites. Tools like All-in-One WP Migration or Duplicator automate the process, essentially “zipping” your entire site and “unzipping” it on the new server.
  • Manual Migration: The “pro” choice for large, complex sites or those with strict security protocols. This involves manually moving files via SFTP and exporting/importing your database via phpMyAdmin. It gives you total control but requires a bit more technical “under-the-hood” knowledge.
WordPress Site Migration to a New Host

Pre-Migration Checklist (Don’t Skip This!)

Think of this phase as your flight safety check. Even if you are using a migration plugin, skipping these steps is the most common cause of “broken” sites after a move.

1. Perform a Full, Verified Backup

Never trust an automated plugin backup alone.

  • The Manual Way: Use SFTP to download your entire public_html folder and use phpMyAdmin to export a .sql dump of your database.
  • The Plugin Way: Use UpdraftPlus or ManageWP to create a fresh snapshot.
  • Pro Tip: Verify the file size of your backup. If it’s 0KB, something went wrong.

2. Deactivate Caching & Security Plugins

Before you create your migration package, disable plugins that interfere with file structure:

  • Caching Plugins: (e.g., WP Rocket, W3 Total Cache). These generate temporary files that will confuse the migration process.
  • Security/Firewall Plugins: (e.g., Wordfence, iThemes Security). They may block the migration plugin’s access to your database or server.
  • Why? These plugins are “server-aware.” Moving them to a new environment without resetting them will likely cause 500 errors.

3. Audit Your Domain & DNS Access

Ensure you have the keys to the castle before you start:

  • Confirm you have direct access to your Domain Registrar (e.g., Namecheap, GoDaddy, Cloudflare).
  • Do not start the migration if your DNS settings are locked or you don’t have the login credentials for your name servers.

4. Benchmark Your Current Speed

You are moving to a new host for better performance, right? Prove it works!

  • Run your current site through or .
  • Record these metrics: Time to First Byte (TTFB), Largest Contentful Paint (LCP), and Total Blocking Time. You’ll want these numbers to verify your new host is actually faster after the migration.

5. Check Your PHP & Database Versions

  • Make sure your new hosting environment supports the same (or newer) versions of PHP and MySQL that your current site uses.
  • Warning: If you are running an outdated PHP version (like 7.4) on your old host and try to move to a server running PHP 8.3, your site will break. Update your site to be compatible with PHP 8.x before you migrate.

You can also read the article – WebSite Migration Checklist

Migrate a WordPress Site to a New Host

Choosing Your Migration Method – How to Migrate a WordPress Site to a New Host

Once you’ve verified your backup, it’s time to choose your path. The method you select depends on your technical comfort level and the size of your database.

Option A: The “Easy” Way (Plugin-Based Migration)

For 90% of WordPress users, a dedicated migration plugin is the safest, most efficient route. These plugins handle file compression, database serialization, and URL replacement automatically.

Top Recommendations:

  • All-in-One WP Migration: Extremely user-friendly, great for standard sites under 512MB.
  • Duplicator: Excellent for creating a “package” that you can manually deploy on the new server.
  • MigrateGuru: The “heavy lifter” – best for large, complex sites (over 2GB) because it performs the transfer on their external servers, putting zero load on your CPU.

The Workflow:

  1. Install the plugin on your source site.
  2. Export a migration package.
  3. Install the same plugin on your destination site.
  4. Import the package.

Option B: The “Pro” Way (Manual Migration)

If you’re moving a high-traffic site, have a massive database, or simply want to avoid plugin bloat, manual migration is the gold standard.

  • Step 1: Export Database via phpMyAdmin Locate your database on the old host’s control panel (usually cPanel or hPanel). Select your database and click “Export” in the top menu to download a .sql file.
  • Step 2: Transfer Files via SFTP Use a tool like FileZilla or Cyberduck. Connect to your source server and download the entire public_html directory to your local machine. Upload these files to the new server’s root directory.
  • Step 3: Edit wp-config.php This is the “glue” that connects your site to the new database. After importing your .sql file on the new server, edit the wp-config.php file in your root folder with the new database name, username, and password provided by your new host.
How to Migrate a WordPress Site to a New Host

The “Magic” Preview (The Hosts File Trick)

Most tutorials will tell you to just flip your DNS switch and “hope” everything works out. That is a great way to end up with a broken site for half the day. Professionals don’t rely on luck; we use a “hosts file” trick to preview the site on the new server before the rest of the world sees it.

Think of this as a private window. You are essentially telling your own computer to look at the new server’s IP address while everyone else is still seeing the old, live site. To do this, you just need to grab your new server’s IP address from your hosting dashboard. On Windows, you open your hosts  file in your System32 folder as an Administrator, and on Mac or Linux, you just run a quick terminal command. You add one simple line at the bottom: your new IP address followed by your domain name. Once you save that, your browser will load the site directly from the new host. You can click every button, check your forms, and verify that your database is connected – all without a single visitor knowing you’re tinkering under the hood.

Pro Tip: If your site is currently behind Cloudflare, this trick won’t work automatically because your browser is looking at Cloudflare’s servers, not your hosting IP. To make this work, you need to turn off Cloudflare’s “Orange Cloud” proxy (set it to “DNS Only” or “Grey Cloud”) temporarily. This bypasses their servers so you can test your actual origin server directly. Most generic guides miss this entirely, but it is the only way to guarantee a zero-downtime launch.

Flipping the Switch (Going Live)

Once you’ve confirmed everything is working in your private preview, it’s time to move the public traffic. Before you touch anything, there is a secret pro move that makes the transition almost invisible: lower your TTL (Time To Live).

Think of TTL as the “refresh rate” for the internet. By default, many domains have a TTL of 24 hours, meaning if you change your site’s location, some parts of the world might not see the update for an entire day. About an hour before you move, go into your DNS settings and drop that number down to 300 seconds (which is just five minutes). This tells every internet provider on the planet, “Check the location of this site every five minutes.”

When you’re ready, you have two ways to flip the switch. If you are just changing the hosting server, you update your “A Record” to point to your new server IP. If you are moving your entire DNS management (for example, if your new host provides its own DNS), you update your “Nameservers” at your domain registrar. After that, just watch the magic happen. You can use a tool like DNSChecker.org to see the update spreading across the globe in real-time. It’s like watching a wave move across a map. Just keep that old hosting account active for about 48 hours – it’s your safety net in case a tiny bit of traffic gets stuck in an old server’s cache.

How to Migrate a WordPress Site to a New Host

Post-Migration SEO & Performance Audit

Don’t just “set it and forget it.” Perform this quick audit immediately after your DNS propagation is complete.

1. Fix Broken Links and Assets

Even if you copied every file, permissions can change during a move.

  • Scan for 404s: Use a tool like to crawl your site. It will instantly flag any broken images, CSS files, or internal links that didn’t transfer correctly.
  • Check .htaccess: If you are on an Apache server, make sure your permalink structure is working. If your sub-pages return a 404 while your homepage works, it’s almost always a corrupted or missing .htaccess file.

2. Verify Your SSL/HTTPS Certificate

Search engines prioritize HTTPS. A common post-migration error is an “Insecure Connection” warning because the SSL certificate wasn’t re-issued or properly installed on the new host.

Use to see if you have any “mixed content” errors (where some elements are served via http instead of https).

3. Check Google Search Console (GSC)

Log into your GSC account to monitor the transition.

  • Crawl Errors: Keep an eye on the “Indexing” report. If you see a spike in 404 errors, fix them via 301 redirects immediately.
  • Robots.txt: Sometimes migration plugins add a “no-index” tag to your site to prevent Google from crawling it during the move. Make sure this is removed so Google knows it’s safe to index your new server.

4. Speed Test Comparison: The “Victory Lap”

Remember that benchmark we took back in Phase 1? Now that your site is settled on its new home, it’s time to see the results. Run your site through or one more time.

You’re looking for three key improvements:

  • Time to First Byte (TTFB): This is the “speed limit” of your server. If this number dropped, your new host is doing its job.
  • Largest Contentful Paint (LCP): This tells you how fast your site’s main content is loading. A lower number here means a much happier visitor.
  • Total Blocking Time: If this improved, your new server is handling your scripts and plugins more efficiently than the old one.

If you don’t see an immediate speed jump, keep in mind that performance optimization is an iterative process. Often, a few tweaks to your caching settings or CDN configuration are all it takes to make your new server fly.

5. Check Site Health

Use the built-in WordPress Site Health tool to identify critical issues after migration.
Go to Tools → Site Health in your dashboard – it will highlight problems with:

  • missing or inaccessible files
  • REST API issues
  • loopback request failures
  • incorrect permissions
  • PHP or server configuration problems

This is especially useful because it catches issues that a crawler won’t detect.

How to Migrate a WordPress Site to a New Host

Troubleshooting: Don’t Panic!

If something feels “off” after the migration, take a deep breath. 90% of migration issues are common, and they’ve happened to every developer at least once – even the pros. You haven’t ruined your site; you’ve just run into a small configuration hiccup. Here is how to fix the big three:

  • The 500 Internal Server Error: This is the most common “scary” error, but it’s usually just a simple file conflict. Most of the time, your .htaccess file is just struggling with the new server environment. Try renaming it to .htaccess_old and see if your site comes back to life. If it does, you just need to regenerate your permalinks in WordPress settings.
  • Database Connection Error: This sounds catastrophic, but it’s almost always just a typo in your wp-config.php file. Open that file in your root folder and double-check your database name, username, and password. Even a single hidden space or a wrong character will cause this error. It’s a classic mistake, so don’t be hard on yourself!
  • The “White Screen of Death” (WSOD): This usually happens because your new server is running a different PHP version than your site is ready for. Check your hosting panel to make sure your PHP version matches the requirements of your theme and plugins. Often, simply bumping your PHP version to 8.2 or 8.3 (or rolling it back if you’re on an older site) fixes the screen instantly.

Expert Tip: If you’re still stuck, look for your wp-debug.log file. It’s like a “black box” flight recorder for your site – it will tell you exactly which plugin or file is causing the hiccup so you don’t have to guess.

Before checking logs, make sure debugging is turned on in WordPress.
Edit your wp-config.php file and set:

define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);

This will log all errors to /wp-content/debug.log without showing them to users.

How to Migrate a WordPress Site to a New Host

FAQ: Why Migration Matters for Your SEO

Will I lose my Google rankings when moving?

If done correctly with zero downtime, your rankings shouldn’t drop. However, if your site stays offline for hours or you introduce hundreds of 404 errors, Google will penalize you. That’s why the “Hosts File” testing method we used earlier is your best insurance policy.

Can I migrate my WordPress site for free?

Absolutely. Manual migration (SFTP + phpMyAdmin) is free, and there are excellent free plugins like All-in-One WP Migration. You only need to pay for your new hosting plan.

How long does the actual DNS propagation take?

It can be instant, but it’s safest to allow 24–48 hours for global propagation. During this time, some visitors might see the old site, and some will see the new one – which is why keeping your old hosting active is non-negotiable.