I got a call at 9 PM on a Friday from a client whose previous developer had just “finished” a migration. The site was up, but nobody could add anything to the cart and half the images were throwing 404s. The developer had run a basic export-import tool and walked away. Fourteen years of doing this, and the move itself has never been the thing that breaks a site. It’s always the details someone decided to skip.
Most people searching for a WordPress migration checklist think the job is moving files from A to B. The hard parts are data integrity and environment parity, plus keeping your SEO intact while you do it. With that client, the first thing I found was old staging URLs buried in serialized strings in the database, and a raw SQL search-replace had butchered the data. My instinct was to write a script to patch the strings. Wrong call. I should have rolled back to the backup and used a tool that understands serialization. Three hours of untangling for something a proper workflow handles in ten minutes.
What a WordPress migration checklist should cover
The standard guides, including the one on WordPress.com, give you the basics: back up, move, test. Test is where most people fall over, because clicking around a few pages is not a test. Verify checksums, check the header responses, and make sure the server-side constants in wp-config.php aren’t pointing at a directory that doesn’t exist on the new host.
During the migration window itself I force a 503 so search engines don’t crawl a half-broken site. It tells Google to come back later instead of letting it index a broken homepage.
function bbioon_force_maintenance_mode() {
if ( ! current_user_can( 'edit_themes' ) || ! is_user_logged_in() ) {
wp_die(
'Site is undergoing a scheduled migration. We will be back in 10 minutes.',
'Maintenance in Progress',
array( 'response' => 503 )
);
}
}
// Uncomment the line below during the actual migration window
// add_action( 'get_header', 'bbioon_force_maintenance_mode' );DNS propagation catches more people than anything else here. Someone changes the nameservers, starts editing what they assume is the new site, and works out ten minutes later that local caching had them on the old server the whole time. Check with something like dnschecker.org before you touch a plugin setting, so you know which server you are actually on.
The audit after the move
Moving the files is half the job. Afterwards, run a crawl: I use Screaming Frog to compare the old sitemap against the new one. A WordPress migration checklist without a full link crawl leaves you guessing about what survived. Check the 301s, especially if the URL structure changed, because one missed redirect on a high-traffic post costs a client real money. The one that catches people twice is robots.txt, which often still carries the staging rules that blocked the whole site. Read it before you call the job done.
Migrations get complicated quickly. If you would rather not spend a Friday night debugging someone else’s export-import job, get in touch with my team. We have cleaned up a few of these.
The short version
- Environment parity: match PHP versions and database engines between the two hosts, or you get silent failures.
- Serialized data: skip the raw SQL search-replace for URLs and use WP-CLI or a migration plugin that handles it.
- The 503: signal a temporary outage to search engines instead of letting them hit a 404 or a database error page.
- Local caching: flush your local DNS and check the move in a private window.
