How to Migrate WordPress to a New Host (Without Losing Traffic or Data)

Your current host is slow, support doesn’t reply, or you found a better deal — so you’re switching. But move it wrong and you risk downtime, lost emails, or a broken site mid-migration. Here’s how to migrate WordPress to a new host with zero downtime, even if you’ve never touched a server before.

Why Migrate WordPress Carefully

Most WordPress site migrations go sideways not because of technical complexity, but because of skipped steps. Before diving into the how, it helps to understand what can go wrong and why the order of operations matters so much.

Common triggers for migration: your shared host is throttling your site, load times have crept up to 4+ seconds, support tickets go unanswered for days, or you’ve outgrown shared hosting and need a VPS or managed WordPress environment. Sometimes it’s simpler — a competitor is offering better specs at half the price.

What goes wrong when migration is done carelessly: DNS gets updated before the new site is tested, leaving visitors hitting a broken install during propagation. Database connection strings in wp-config.php still point to the old server. MX records get wiped so email stops working. SSL isn’t reissued on the new host, triggering mixed content warnings. And if your domain URLs change during the move, serialized data in the database breaks — killing page builders like Elementor and WPBakery.

The good news: with the right sequence, downtime can be near-zero. You test everything on the new host before a single DNS record changes.

The Quick Answer

If you need the short version:

  1. Install a migration plugin (Duplicator or All-in-One WP Migration) on your old host.
  2. Export your site as a package (installer + archive files).
  3. Install WordPress on the new host, then import the package.
  4. Test the new site via a temporary URL or hosts file edit before going live.
  5. Update DNS only after the new site is fully confirmed working.
  6. Keep old hosting active for 24–48 hours as a fallback.

For the full breakdown — including the manual method, DNS switching without downtime, and a troubleshooting section — keep reading.

What You’ll Need Before You Start

Before touching a single file, have these ready:

  • New hosting account with WordPress support, ideally matching your old host’s PHP version (check this under cPanel or your host’s PHP settings — mismatched versions break plugins).
  • FTP/cPanel or hosting panel access for both old and new hosts. You’ll need to upload files and create a database on the new host.
  • A fresh backup of your site — even if the migration plugin is doing the heavy lifting, always have a manual backup sitting somewhere safe.
  • Domain registrar login (GoDaddy, Namecheap, Google Domains, etc.) so you can update DNS records when the time comes.
  • 30–60 minutes of focused time. Plugin migrations run fast. Manual migrations take longer. Either way, don’t start this mid-traffic spike.

Method 1: Migrate WordPress Using a Plugin (Easiest)

Best for: Beginners, small-to-medium sites, shared or managed hosting
Time needed: 20–40 minutes
Cost: Free (Duplicator, All-in-One WP Migration) or paid for larger sites

Step 1: Choose Your Migration Plugin

Three options dominate the WordPress migration plugin space:

  • Duplicator — recommended for most sites. The free tier handles sites under roughly 500MB and creates a self-contained installer + archive package. Clean, reliable, widely tested.
  • All-in-One WP Migration — great UI, beginner-friendly. Free tier is capped at 512MB export size, which is enough for most blogs and small business sites.
  • WP Migrate — paid, built for developers and agencies. Handles large, complex sites and has database search-replace tools that properly handle serialized data.

Step 2: Install the Plugin on the Old Site

Log into your old WordPress dashboard. Go to Plugins → Add New, search for Duplicator (or your chosen plugin), install it, and activate it. Takes 60 seconds.

Step 3: Create a Migration Package

In Duplicator: go to Duplicator → Packages → Create New. The plugin will scan your site for any issues — large media folders, PHP timeout risks, unusual file sizes. Review any warnings before proceeding. Once the scan completes, build the package. When it’s done, download two files: the Installer (a PHP file) and the Archive (a .zip of your entire site + database).

Step 4: Set Up the New Hosting Environment

On your new host, create a MySQL database. Note down the database name, username, password, and database host (usually localhost). Then upload both the Installer and Archive files via FTP or your host’s File Manager to the root directory of your new site (usually public_html).

Step 5: Run the Installer on the New Host

Visit yourdomain.com/installer.php in your browser — or use your new host’s temporary URL or IP address if DNS hasn’t switched yet (recommended). The installer walks you through entering the new database credentials and runs the full import automatically, including a URL/path search-replace.

Step 6: Test Before Going Live

This step is non-negotiable. Use your new host’s staging subdomain, or edit your local hosts file to point your domain to the new server’s IP — so only your machine sees the new site while everyone else still hits the old one. Check the homepage, key pages, forms, WooCommerce checkout (if applicable), images, navigation menus, and contact forms. Everything should look and function identically.

A plugin migration for a site under 1GB typically completes in under an hour. When everything checks out, you’re ready to switch DNS.

Method 2: Manual Migration (Full Control)

Best for: Developers, agencies, VPS or dedicated server users, complex multi-domain setups
Time needed: 1–2 hours
Cost: Free (just your time)

Use this method when plugin export size limits are a problem, or when you need precise control over file permissions, cron jobs, or custom server configurations. It’s also the right call when moving between very different server stacks — shared to VPS, Apache to LiteSpeed, cPanel to Plesk.

Step 1: Back Up Files via FTP or SSH

Download your full /wp-content/ directory, your wp-config.php, and all root-level files via FTP. If you have SSH access, rsync or scp is significantly faster for large sites:

rsync -avz user@oldserver:/var/www/html/ /local/backup/

Step 2: Export the Database

Open phpMyAdmin on your old host, select your WordPress database, and export it as a .sql file. If you have SSH access, mysqldump is cleaner and faster:

mysqldump -u username -p database_name > site_backup.sql

Step 3: Create a New Database on the New Host

In your new host’s cPanel or Plesk, create a new MySQL database and user, then assign all privileges. Import your .sql file via phpMyAdmin or via command line:

mysql -u newuser -p newdatabase < site_backup.sql

Step 4: Upload Files to the New Host

Upload all WordPress files to the new host’s public directory (public_html or equivalent) via FTP/SFTP. Use FileZilla or Cyberduck for GUI access, or rsync via SSH for speed.

Step 5: Update wp-config.php

Open wp-config.php on the new host and update the database constants to match your new server:

define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_db_user' );
define( 'DB_PASSWORD', 'new_db_password' );
define( 'DB_HOST', 'localhost' );

Step 6: Search-Replace URLs in the Database

If your domain or directory path changes, you must update all references in the database. The safest way is WP-CLI — it handles serialized data correctly, which plain phpMyAdmin find-replace does not:

wp search-replace 'https://oldsite.com' 'https://newsite.com' --all-tables

Never run a plain SQL find-replace on serialized arrays — it corrupts widget settings, Elementor layouts, and WPBakery content because the string lengths encoded in the serialized format become invalid.

Step 7: Set File Permissions

Set permissions correctly on the new server: folders to 755, files to 644, and wp-config.php specifically to 600. Incorrect permissions are a common reason sites appear broken or insecure right after migration.

Plugin vs Manual vs Host Migration: Which Should You Use?

MethodDifficultyTimeCostBest For
Plugin MigrationEasy20–40 minFree to ~3,000Most sites, beginners
Manual MigrationAdvanced1–2 hoursFreeDevelopers, VPS, large sites
Host’s Free MigrationEasy1–3 daysFreeAnyone switching to a host that offers it

Worth checking: some hosts like Hostinger, SiteGround, and various Indian hosting providers offer free assisted migration when you sign up. It takes longer since it’s human-assisted, but you do zero technical work. If you’re already evaluating new hosting options, ask the host’s support team about this before you start migrating manually.

How to Switch DNS Without Downtime

DNS switching is where most migrations go wrong. Here’s the sequence that keeps downtime near-zero:

  1. Lower your TTL 24–48 hours before migration. Log into your domain registrar or DNS provider, find your A record or nameserver TTL, and drop it to 300 seconds (5 minutes). This means when you do switch, DNS propagates globally much faster.
  2. Keep the old host active. Do not cancel it yet. You need it live as a fallback during propagation.
  3. Test the new site completely before touching DNS. Use the temporary IP or staging URL. Confirm everything works.
  4. Update your A record or nameservers to point to the new host. If switching nameservers entirely, update them at your registrar.
  5. Monitor propagation at whatsmydns.net. With a low TTL, most regions resolve within 5–30 minutes. Full global propagation can take up to 48 hours in edge cases.

Don’t Forget These After Migration

The migration itself is step one. These post-migration tasks are what keep your site healthy and your rankings intact:

  • Re-submit your sitemap in Google Search Console. Your new server has a new IP. Resubmitting helps Google recrawl from the right location faster.
  • Verify SSL is active. If your new host uses Let’s Encrypt or AutoSSL, it should issue automatically — but confirm the padlock is showing and there are no mixed content warnings.
  • Check MX records. If your email is hosted separately (e.g., Google Workspace, Zoho), make sure your MX records survived the DNS switch and weren’t overwritten.
  • Recreate custom server cron jobs. WordPress has its own WP-Cron, but if your old host had server-level cron jobs (for backups, cache clearing, etc.), those don’t migrate automatically.
  • Re-test all forms, payment gateways, and third-party API integrations. WooCommerce payment gateways, contact forms, and booking systems often have server IP or webhook settings that need updating.
  • Update hardcoded IPs in security plugins. Plugins like Wordfence or security firewalls that whitelist server IPs need the new server’s IP added.

Common Mistakes to Avoid

Mistake 1: Updating DNS Before Testing

Switching nameservers before confirming the new site works means real visitors could land on a broken installation during propagation. That window can last hours. Always test first — then switch DNS.

Mistake 2: Forgetting Email and MX Records

A site can migrate perfectly while email goes completely dead because MX records weren’t preserved. This is especially common when switching nameservers — the new host’s default DNS zone may not include the correct MX entries for your mail provider.

Mistake 3: Ignoring PHP Version Mismatches

Old host on PHP 7.4, new host defaults to PHP 8.3 — suddenly half your plugins throw fatal errors. Match the PHP versions first, then migrate. Once the site is stable on the new host, upgrade PHP deliberately.

Mistake 4: Using Plain Find-Replace on the Database

phpMyAdmin’s built-in search-and-replace doesn’t understand PHP serialized arrays. When it modifies a string inside a serialized object, the length prefix becomes wrong and WordPress can’t deserialize it. This breaks widget areas, Elementor sections, and page builder content silently. Always use WP-CLI or a migration plugin’s built-in search-replace tool.

Mistake 5: Cancelling Old Hosting Immediately

Keep old hosting active for at least 48 hours post-migration. If something surfaces after DNS switches — a broken integration, a missing file, an edge-case plugin issue — you can roll back quickly without scrambling to restore from backup.

Troubleshooting Common Migration Problems

White Screen of Death After Migration

Usually a PHP memory limit issue or a plugin incompatible with the new PHP version. Check the error log at /wp-content/debug.log (enable WP_DEBUG_LOG in wp-config.php if blank). Try deactivating all plugins via FTP by renaming the /wp-content/plugins/ folder — if the site loads, reactivate plugins one by one to isolate the culprit.

Site Loads But Images or CSS Are Broken

URL search-replace didn’t complete fully. Re-run the search-replace via WP-CLI. Also check that your .htaccess file was copied to the new host — it controls WordPress permalink routing, and a missing .htaccess breaks all URL resolution.

Mixed Content Warning or No SSL Padlock

SSL wasn’t issued on the new host, or the site URL still has http:// hardcoded in the database. Check your WordPress General Settings (Settings > General) to confirm both WordPress Address and Site Address use https://. Then run a search-replace to update any remaining http:// references in the database.

Emails Stopped Working After Migration

MX records weren’t migrated or were overwritten when you switched nameservers. Log into your DNS provider, verify MX records match what your mail host requires (Google Workspace, Zoho, or whoever handles your email), and give it time to propagate. Use whatsmydns.net to check MX record propagation globally.

What a Successful Migration Looks Like

You’ll know the migration worked when:

  • The site loads identically on the new host — same layout, same content, same speed or faster.
  • All forms, checkout flows, and third-party integrations work end-to-end.
  • SSL is active with no mixed content warnings in the browser console.
  • Google Search Console shows no new crawl errors within a week of migration.
  • You’ve waited 48 hours after DNS switch before cancelling the old host.

Frequently Asked Questions

Will migrating WordPress affect my SEO rankings?

Not if URLs stay the same and downtime is minimal. The bigger SEO risks are: changing URL structure without redirects, extended downtime during DNS propagation, or SSL not being active on the new host. Follow the steps in this guide and you should see zero ranking drop.

How long does a WordPress migration take?

Plugin migrations: 20–40 minutes for most sites under 1GB. Manual migrations: 1–2 hours depending on site size and server familiarity. DNS propagation adds another 30 minutes to 24 hours on top of that.

Can I migrate WordPress myself without a developer?

Yes — Method 1 (plugin migration) is designed for non-technical users. If you can install a plugin and access cPanel, you can migrate your site. The manual method requires comfort with FTP, databases, and command line, so beginners should stick with the plugin approach.

Do I need to update DNS immediately after migration?

No — and you shouldn’t. Test the new site thoroughly using a temporary URL or hosts file edit first. Only update DNS once you’re confident the new host is working correctly.

What happens to my email during migration?

If your email is handled by a separate provider (Google Workspace, Zoho, etc.), it won’t be affected as long as your MX records are preserved. If your email is hosted on the same server as your website, you’ll need to migrate email separately and update MX records to point to the new server.

Is it safe to use a free migration plugin for an e-commerce site?

Yes, for most WooCommerce stores under 500MB, Duplicator’s free tier handles it fine. For larger stores or complex setups (multiple payment gateways, large product databases, custom shipping integrations), consider Duplicator Pro or WP Migrate for safer, more controlled handling of large databases.

How do I migrate WordPress with zero downtime?

Lower your TTL 24–48 hours before starting. Migrate files and database to new host. Test using a temporary URL or hosts file edit. Switch DNS only after full testing. Keep old host active for 48 hours. With a low TTL, propagation happens in minutes — actual downtime is effectively zero.

Should I let my new host do the migration for me?

If they offer it for free and you’re not on a tight timeline, yes. Most quality hosts can migrate your site in 1–3 business days with zero effort on your part. The tradeoff is you have less control and visibility into the process.

Next Steps After Migration

Once your site is live on the new host, set up UptimeRobot (free tier) to monitor uptime. It pings your site every 5 minutes and alerts you by email if anything goes down useful for the first week post-migration when edge cases tend to surface.

Run a speed test at GTmetrix or PageSpeed Insights 24 hours after migration and compare scores to your old host. A good new host should show measurable improvement in TTFB (Time to First Byte).

Need help migrating your site without the technical risk? Get in touch I offer WordPress migration services with full testing and DNS handling included.

heyimprahlad

Prahlad is a digital marketer and web creator with 6+ years of hands-on experience in SEO, website development, content strategy, and online branding. Through Digital Prahlad, he shares practical insights, real-world strategies, and modern digital solutions to help businesses build a strong online presence and grow effectively in the digital space.

Leave a Comment