Migrating a WordPress site between hosting providers seems like a routine operation: copy files, copy database, point DNS, done. The reality is that each step has subtle failure modes that produce intermittent problems if not handled correctly. A migration that "succeeded" can still leave you debugging email delivery, caching anomalies, or SSL warnings for weeks.

The sequence that consistently produces clean migrations isn't different from the standard advice in broad strokes. It differs in the specific verification steps that catch problems before they affect users.

Step 1: complete pre-migration audit

Before touching anything, capture the current state of the site. Save the wp-config.php with redacted credentials, the active plugin list with versions, the active theme, the .htaccess if present, the cron schedule from WP Crontrol, and screenshots of the WordPress admin showing media library count, post count, and user count.

Take a sample of 10 representative URLs and capture their current state: rendered HTML, response headers, and any specific dynamic behavior. These become the verification corpus after migration.

Step 2: prepare the destination

On the new host, set up PHP version, MySQL version, and any specific extensions (Imagick, Redis, opcache configuration). Match the source where you can. Differences are fine but should be intentional, not accidental.

Create the database with proper character set (utf8mb4 in 2026, not utf8). Create the database user with appropriate privileges. Don't reuse the production database name as the destination database name during migration; use a temporary name to avoid confusion.

Step 3: copy files and database

For files: use rsync or a migration plugin (Duplicator, All-in-One WP Migration, WP Migrate). For sites under 500MB, plugin-based migration is fine. For larger sites, command-line tools are more reliable.

For databases: export with mysqldump or a migration plugin. Verify the export size matches expectations (a 100MB database shouldn't export as a 50KB file). Compress the export to reduce transfer time.

Update the wp-config.php on the destination with the new database credentials. Set WP_DEBUG to true during migration and switch it off when verification completes.

Step 4: search-and-replace database for the new domain

If the migration involves a domain change (staging.example.com to example.com), run a serialized-safe search-and-replace on the database. WP-CLI's wp search-replace command is the safest tool because it handles PHP-serialized data correctly. The naive SQL replace breaks serialized arrays and produces subtle bugs that show up weeks later.

If the migration keeps the same domain, skip this step. Don't run search-and-replace defensively if the domain didn't change.

Step 5: verify on the destination before DNS cutover

This is the step most migrations skip. Use a hosts file entry on your local machine to point the production domain to the new server's IP. Then browse the site as it would appear after DNS cutover, but without affecting any real users.

Run through the verification corpus from step 1. Compare rendered HTML and headers between hosts. Submit a test form, log into admin, take a few admin actions. Check that emails actually send (a test WordPress email through wp_mail).

If any step fails, fix it before DNS cutover. Fixing problems while users are hitting the new server is worse than fixing them while still on the old server.

Step 6: DNS cutover with low TTL

Several hours before cutover, lower the DNS TTL on the relevant records to 300 seconds. This makes the cutover propagate faster. After cutover and verification, you can raise the TTL back to a normal value (3600 seconds).

Cut DNS during low-traffic hours if possible. Some users will hit the old server for up to TTL minutes after cutover; this is normal and not a bug. Keep the old server running for at least 48 hours after cutover so late-cache users still see the site.

Step 7: post-migration verification

Re-run the verification corpus on the live site. Submit forms, log in, take admin actions. Watch the error log on the new host for the first 24 hours for any unexpected entries.

Check that Google Analytics and Search Console are still receiving data (the tracking code didn't get lost in migration). Check that the sitemap is reachable and contains expected URLs. Submit the sitemap in Search Console to nudge re-crawling.

The post-migration cleanup

After 48 hours of clean operation, delete the source database backup, lower error reporting back to production levels, and turn off WP_DEBUG. Update any references that pointed at the old host (uptime monitors, integration webhooks, backup services).

The migration is done when the new host has been serving production traffic for a full week with no errors and the old host has been deactivated. Anything sooner is "looks done" rather than "is done."

WordPress Hosting Migration: A Clean Sequence That Works