WordPress Site Migrations: The Detailed Pre-Flight Checklist

WordPress site migrations between hosts, domains, or environments produce specific failure modes that are mostly preventable through preparation. The detailed pre-flight checklist below addresses the issues that typically cause migration problems.

Following the checklist takes 1-2 hours of preparation. Skipping it produces migrations that "succeeded" technically but have subtle issues that emerge over weeks.

Pre-flight phase 1: documentation

Capture the current state of the site. The documentation becomes the verification baseline after migration.

Save the active plugin list with versions. Screenshot the Plugins page or export via WP-CLI: wp plugin list --status=active --format=csv.

Save the active theme name and version. Screenshot or note.

Save the WordPress version. Notes the version in case of upgrade during migration.

Save the PHP version. The new host should match or be a deliberate change.

Save the database size and table count. Comparison points after migration.

Save 10 representative URLs and their rendered output. Screenshot the page, save the HTML source, save the response headers. These become the verification corpus.

Pre-flight phase 2: backup verification

Before migration, ensure backups work and are accessible.

Run a fresh backup. Don't rely on the most recent scheduled backup; trigger a new one before migration starts.

Verify the backup includes files, database, and uploads. Download a sample to confirm the file structure is what you expect.

Save the backup to a location outside the source server. The cloud storage destination or a local download.

If the backup plugin's restore requires the plugin to be active, document this. Some restore procedures require specific tooling that needs to be available during recovery.

Pre-flight phase 3: destination preparation

The destination needs to be ready before migration starts.

Set up the new host with appropriate PHP version, MySQL/MariaDB version, and any required extensions.

Create the database with the right character set (utf8mb4 in 2026).

Verify file system access (FTP/SFTP) works to the destination.

If using a migration plugin, install it on both source and destination.

Document the destination credentials securely.

Pre-flight phase 4: DNS planning

If the migration involves DNS changes, plan the sequence carefully.

Lower DNS TTL on relevant records to 300 seconds (5 minutes). Make this change 24-48 hours before cutover so it propagates.

Document the current DNS records. Screenshot the DNS panel.

Identify what records need to change. A vs CNAME, the new IP or hostname.

If email is on the same domain, identify email DNS records (MX, SPF, DKIM, DMARC). These should typically not change just because hosting changes.

Plan the rollback DNS in case the migration needs to be reverted.

Pre-flight phase 5: timing

Pick a migration window when impact is minimized.

Identify low-traffic hours for the site. Migration during these hours affects fewer users.

Coordinate with internal stakeholders. The team should know the migration is happening; editorial work should pause if necessary.

Set a target completion time. Migrations that drag on without time boundaries tend to leave subtle issues unaddressed.

Plan for the verification phase after migration. Don't schedule other work for the day of migration.

Pre-flight phase 6: rollback planning

If the migration fails, the rollback path needs to be clear.

Document the exact steps to revert. Don't rely on memory.

Identify the rollback decision point. At what point during migration is rollback still feasible vs has the team committed?

Plan communication for the rollback case. Users seeing the rollback need clarity about what happened.

Migration phase 1: file transfer

Copy files from source to destination. Methods:

rsync for fast direct transfer if SSH access is available on both ends.

Migration plugin (Duplicator, All-in-One WP Migration) for moderate-sized sites.

Manual FTP/SFTP for small sites.

For files transfer: include all of wp-content (themes, plugins, uploads, must-use plugins). Skip cache directories (they regenerate).

Migration phase 2: database transfer

Export source database. Method:

mysqldump if direct database access is available.

phpMyAdmin export through hosting control panel.

Migration plugin's database export.

Import on destination.

If domain is changing, run a serialization-safe search-replace: wp search-replace 'http://olddomain.com' 'https://newdomain.com' --skip-columns=guid.

Migration phase 3: configuration update

Update wp-config.php with new database credentials on the destination.

Verify file permissions are correct (755 for directories, 644 for files, 600 for wp-config.php).

If the move includes URL changes, update Settings > General > Site URL and Home URL through the database directly (since logging in might fail if URLs are inconsistent).

Verification phase 1: staging access

Before DNS cutover, access the new server via hosts file or temporary URL.

Add a hosts file entry locally: NEW.IP example.com (where NEW.IP is the destination IP). This points your machine to the new server while DNS still points to old.

Browse the site at the production URL but on the new server.

Verify the verification corpus from pre-flight: do the 10 URLs render correctly?

Test admin login.

Submit a test form.

Take a few admin actions.

Verify emails send.

Verify analytics tracking is still firing.

Verification phase 2: production cutover

If pre-cutover verification passed, switch DNS to the new server.

Monitor for the next 30 minutes. Real users will start hitting the new server as their DNS cache updates.

Watch for any errors in the error log.

Verify uptime monitoring continues to report success.

Check Search Console for any new error reports.

Post-cutover phase: monitoring

For the first 48 hours after cutover:

Keep the old server running. Users with cached DNS may still hit it; this is fine.

Monitor error logs on the new server for unexpected entries.

Check analytics for any visitor pattern changes (sudden drop suggests something is broken for some users).

Be available to address issues that emerge.

After 48 hours of clean operation:

Raise DNS TTL back to a normal value (3600 or higher).

Take down the old server.

Update any documentation pointing to the old infrastructure.

The honest framing

The checklist looks comprehensive because migrations are comprehensive operations. Skipping steps produces failures that are dramatically more expensive than the time the checklist takes.

For experienced migrators, the checklist becomes routine. For first-time migrators, each step prevents a specific category of problem.

The discipline pays off in clean migrations rather than the months of debugging that follow improvised migrations.