TopSyde
Start Free Trial

How to Migrate a WordPress Site: The Complete Guide

A step-by-step guide to migrating WordPress sites — covering pre-migration checklists, DNS propagation, manual and plugin-based methods, common pitfalls like serialized data and mixed content, and zero-downtime migration strategies.

Rachel Nguyen

Rachel Nguyen

Senior WordPress Engineer

··12 min read

Last updated: April 21, 2026

Hero image for How to Migrate a WordPress Site: The Complete Guide

WordPress migration is the process of moving a WordPress site — files, database, and configuration — from one hosting environment to another without losing data, breaking functionality, or incurring downtime. Whether you're escaping slow shared hosting, consolidating client sites, or upgrading to managed hosting, the method you choose and the preparation you do beforehand determine whether the migration is seamless or catastrophic.

Pre-Migration Checklist

Skipping preparation is the #1 cause of failed WordPress migrations. Complete this checklist before touching any files.

1. Audit your current site

  • Document your WordPress version, PHP version, and MySQL version
  • List all active plugins and themes with their version numbers
  • Note any server-specific configurations (custom .htaccess rules, cron jobs, PHP ini overrides)
  • Record your current DNS settings — A records, CNAME records, MX records, and TXT records (especially SPF/DKIM for email)
  • Check for hardcoded URLs in theme files, custom CSS, and plugin settings

2. Verify the new environment

  • Confirm PHP and MySQL versions match or exceed your current setup
  • Ensure required PHP extensions are installed (curl, gd, mbstring, xml, zip, intl)
  • Verify WordPress file size and upload limits (upload_max_filesize, post_max_size, max_execution_time)
  • Confirm the new host supports your SSL certificate (or will issue one)
  • Check that email settings (SMTP) won't be disrupted by the server change

3. Take a complete backup

  • Export the full database using mysqldump --single-transaction or WP-CLI (wp db export)
  • Download the entire wp-content directory (themes, plugins, uploads)
  • Save wp-config.php and any custom server configuration files
  • Store backups locally and in cloud storage — never rely solely on the old host

4. Lower your DNS TTL

At least 48 hours before migration, reduce your DNS TTL (Time to Live) to 300 seconds (5 minutes). This ensures that when you switch DNS to the new server, the change propagates within minutes instead of days. Most registrars default TTL to 86400 seconds (24 hours), which means stale DNS caches could send visitors to the old server for up to a day after the switch.

Migration Method 1: Manual Migration

Manual migration gives you full control and works regardless of your hosting provider. It's the method every WordPress developer should understand, even if you use migration plugins for convenience.

Step 1: Export the database

# Via WP-CLI (recommended)
wp db export site-backup.sql --single-transaction

# Via mysqldump directly
mysqldump -u db_user -p --single-transaction db_name > site-backup.sql

The --single-transaction flag is critical for live sites — it creates a consistent snapshot without locking tables, preventing disruption to site visitors during export.

Step 2: Transfer files

# Compress wp-content for faster transfer
tar -czf wp-content-backup.tar.gz wp-content/

# Transfer via rsync (fastest for large sites)
rsync -avz --progress wp-content-backup.tar.gz user@new-server:/var/www/html/

# Or via SCP
scp wp-content-backup.tar.gz user@new-server:/var/www/html/

For sites over 5 GB, use rsync over scp — it supports resume on interruption and only transfers changed bytes if you need to re-run.

Step 3: Import the database on the new server

# Create the database
mysql -u root -p -e "CREATE DATABASE new_db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# Import
mysql -u db_user -p new_db_name < site-backup.sql

Step 4: Update wp-config.php

Update database credentials, table prefix (if changed), and any environment-specific constants:

define('DB_NAME', 'new_db_name');
define('DB_USER', 'new_db_user');
define('DB_PASSWORD', 'new_secure_password');
define('DB_HOST', 'localhost');

Step 5: Search and replace URLs

This is the step most people get wrong. See the serialized data section below — do not use a SQL REPLACE() query.

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --precise --all-tables --report-changed-only

Step 6: Set file permissions

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html

Migration Method 2: Plugin-Based Migration

Migration plugins handle file transfer, database export/import, and URL replacement in one workflow. They're ideal for non-developers and sites where SSH access is limited.

Top migration plugins:

PluginFree Tier LimitHandles Serialized DataServer-to-Server TransferBest For
All-in-One WP Migration512 MBYesNo (file-based)Small sites
Duplicator ProUnlimitedYesYesLarge sites / developers
Migrate Guru200 GBYesYes (direct transfer)Large sites / no storage needed
UpdraftPlus (Premium)UnlimitedYesYes (via cloud)Sites already using UpdraftPlus

Plugin migration steps:

  1. Install the migration plugin on the source site
  2. Run the export — the plugin packages files and database into a transferable archive
  3. Install WordPress on the destination server (fresh install)
  4. Install the same migration plugin on the destination
  5. Import the archive on the destination
  6. Verify the site loads correctly

Key limitation: plugin-based migration requires WordPress to be functional on both ends. If your current site is crashed, hacked, or unreachable, you'll need manual migration or host-assisted migration.

Migration Method 3: Host-Assisted Migration

Most managed WordPress hosts offer free migration as part of onboarding. The quality varies enormously — from a basic Duplicator import to full white-glove migration handled by the host's engineering team.

What to expect from a quality host-assisted migration:

  • Pre-migration environment audit — the host verifies compatibility before starting
  • Direct server-to-server transfer — no intermediate downloads or file size limits
  • Serialized data handling — proper search-replace that preserves serialized strings
  • SSL provisioning — certificate installed and tested before DNS switch
  • Post-migration QA — the host verifies pages load, forms work, and functionality matches the original
  • DNS guidance or management — step-by-step instructions or direct DNS switch on your behalf
  • Rollback plan — the old site remains live until you confirm the new environment is perfect

TopSyde's managed hosting includes free white-glove migration with every plan. Our engineers handle the entire process — file transfer, database migration, URL replacement, SSL setup, DNS configuration, and post-migration testing — with zero downtime and a full rollback guarantee.

The Serialized Data Problem

Serialized data is the single most common cause of post-migration WordPress breakage. Understanding it prevents hours of debugging.

WordPress stores some settings, widget configurations, and plugin data as serialized PHP strings in the database. A serialized string looks like this:

s:29:"https://old-domain.com/image";

The s:29 means "string of 29 characters." If you do a simple SQL find-and-replace changing old-domain.com to new-domain.com (same length — fine) or to new-hosting-domain.com (different length — broken), the character count becomes wrong and PHP can't unserialize the data. The result: broken widgets, lost plugin settings, corrupt theme options, and WooCommerce checkout failures.

Never do this:

-- THIS BREAKS SERIALIZED DATA
UPDATE wp_options SET option_value = REPLACE(option_value, 'old-domain.com', 'new-domain.com');

Always use tools that handle serialization:

# WP-CLI (recommended)
wp search-replace 'old-domain.com' 'new-domain.com' --precise --all-tables

# Or use the Search Replace DB tool by Interconnect/IT (delete it after use — it's a security risk if left accessible)

According to WP Engine's 2025 Migration Report, serialized data corruption accounts for 34% of all migration-related support tickets. The fix is simple — use the right tool — but the debugging when you don't is painful.

Mixed Content Errors After Migration

After migrating to a server with SSL (HTTPS), you may encounter mixed content warnings — the browser blocks HTTP resources loaded on an HTTPS page. This happens when images, scripts, or stylesheets are referenced with hardcoded http:// URLs in the database or theme files.

Diagnosis:

Open your browser's developer console (F12) and look for warnings like:

Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure resource 'http://example.com/wp-content/uploads/image.jpg'.

Fix:

  1. Run a search-replace for the protocol:
wp search-replace 'http://example.com' 'https://example.com' --precise --all-tables
  1. Check theme files for hardcoded URLs — search for http:// in your theme's PHP and CSS files
  2. Add a redirect in .htaccess or Nginx for any remaining HTTP requests:
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}
  1. Verify with a tool like Why No Padlock or Chrome DevTools Security tab

DNS Propagation and Zero-Downtime Migration

DNS propagation — the time it takes for DNS changes to spread across global nameservers — is the final migration hurdle. Even with a low TTL, some ISPs and corporate networks cache DNS records aggressively, meaning some visitors may reach the old server for hours after the switch.

Zero-downtime migration strategy:

  1. 48+ hours before: lower DNS TTL to 300 seconds
  2. Migration day: set up the complete site on the new server, verify everything works using a hosts file override or temporary URL
  3. Pre-switch: ensure both old and new servers are running identical site versions
  4. DNS switch: update A records (and AAAA for IPv6) to point to the new server's IP
  5. Post-switch: keep the old server running for 72 hours to serve visitors with stale DNS caches
  6. Verification: monitor both servers' access logs — when traffic to the old server drops to zero, decommission it

Testing before DNS switch:

You can preview the new server without changing DNS by modifying your local hosts file:

# Windows: C:\Windows\System32\drivers\etc\hosts
# Mac/Linux: /etc/hosts
203.0.113.50  example.com  www.example.com

This forces your machine to resolve example.com to the new server IP, letting you test the full site — SSL, forms, checkout — before any visitor is affected.

Post-Migration Testing Checklist

Rushing through post-migration testing causes more downtime than the migration itself. Verify every item:

  • Homepage and key pages load correctly — check for broken layouts, missing images, and CSS issues
  • All internal links work — run a crawl with Screaming Frog or wp doctor check for 404s
  • Forms submit successfully — test contact forms, email notifications, and form-to-CRM integrations
  • WooCommerce checkout works end-to-end — if applicable, run a test purchase through payment gateway
  • SSL certificate is valid — no mixed content warnings, padlock shows in browser
  • Email delivery works — send test emails from the site's SMTP/transactional email service
  • Cron jobs are running — verify wp cron event list shows scheduled tasks executing
  • Search functionality works — WordPress search and any custom search (Algolia, ElasticSearch)
  • Redirects are intact — check .htaccess/Nginx redirect rules and any plugin-based redirects
  • Performance baseline — run PageSpeed Insights and compare against pre-migration scores
  • CDN is configured — if using a CDN, purge caches and verify assets serve from CDN URLs

TopSyde's post-migration QA process covers all of these checks automatically. Our engineers verify functionality, performance, and SEO signals before marking the migration complete — and your old site stays live as a fallback until you approve the cutover.

Frequently Asked Questions

How long does a WordPress migration take?

A small site (under 1 GB) can be migrated in under an hour. Large WooCommerce stores with 10+ GB of data take 2–6 hours depending on transfer speed and complexity. DNS propagation adds another 24–72 hours before all global visitors reach the new server. Host-assisted migrations from TopSyde are typically completed within 24 hours including QA and DNS cutover.

Will my site go down during migration?

Not if you follow a zero-downtime approach. Keep both servers running identical sites and switch DNS only after the new environment is verified. Visitors on stale DNS caches continue hitting the old server, which remains live. The only scenario that causes downtime is pointing DNS to a new server before it's fully configured.

Can I migrate WordPress without losing SEO rankings?

Yes — if URLs remain identical and redirects are properly configured. Google's John Mueller has confirmed that changing hosting providers does not inherently affect rankings. The risks are broken pages (404 errors), slow page speed on the new host, or lost redirect rules — all preventable with proper testing. Run a full crawl comparison before and after migration to verify URL parity.

What happens to my email when I change DNS?

If your email uses the same domain (e.g., you@example.com via Google Workspace or Microsoft 365), your MX records must be preserved during DNS migration. When updating your A record to the new server, ensure MX, SPF, DKIM, and DMARC records are copied exactly. Missing MX records means incoming email stops — often for hours before anyone notices.

Should I use a migration plugin or migrate manually?

Plugins like Duplicator Pro and Migrate Guru are reliable for most sites and require minimal technical skill. Manual migration is better when the site exceeds plugin file-size limits, when SSH access is available on both ends, or when you need granular control over the process. For business-critical sites, host-assisted migration removes the risk entirely.

How do I handle serialized data during migration?

Never use SQL REPLACE() queries to change URLs in a WordPress database — they corrupt serialized strings by breaking character count references. Use wp search-replace (WP-CLI) with the --precise flag or a migration plugin that handles serialization natively. This preserves widget settings, plugin configurations, and theme options that store data as serialized PHP strings.

Rachel Nguyen
Rachel Nguyen

Senior WordPress Engineer

8+ years WordPress & WooCommerce development

Rachel is a senior WordPress engineer at TopSyde specializing in WooCommerce performance and plugin architecture. She has built and maintained high-traffic e-commerce sites processing millions in annual revenue.

Related Articles

View all →

Stop managing your WordPress site

Let our team handle hosting, speed, security, and updates — so you can focus on what matters.

Get Started Free