I got a call at 9 PM on a Friday from a client whose previous developer had just “finished” a migration. The site was technically up, but nobody could add items to the cart, and half the images were throwing 404s. The developer had used a basic export-import tool and walked away. Total nightmare. 14 years in this game, and I’ve learned that it’s never the move itself that kills you—it’s the details you thought you could skip.
Most beginners look for a WordPress migration checklist and think it’s just about moving files from A to B. It’s not. It’s about data integrity, environment parity, and not nuking your SEO in the process. When that client called me, the first thing I noticed was that their database still had references to the old staging URL buried in serialized strings. A simple SQL search-replace had butchered the data. My first thought? Just run a script to fix the strings. But that was a mistake—I should have rolled back to the backup immediately and used a tool that handles serialization properly. I spent three hours untangling a mess that a proper workflow would have avoided in ten minutes.
The Technical WordPress Migration Checklist You Actually Need
If you’re following a standard guide, like the one over at WordPress.com, you’ll see the basics: back up, move, test. But as a senior dev, I’m telling you the “test” phase is where most people fail. You don’t just “click around.” You verify checksums. You check header responses. You make sure your server-side constants in wp-config.php aren’t pointing to a directory that doesn’t exist on the new host.
Here is how I actually handle the critical “During Migration” window to ensure search engines don’t get confused by a half-broken site. I force a 503 status code. This tells Google, “Hey, we’re busy, come back later,” instead of letting them 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' );Trust me on this: the biggest point of failure is DNS propagation. People change their nameservers and immediately start editing the “new” site, only to realize ten minutes later they were still looking at the old server because of local caching. Always use a tool like dnschecker.org to confirm you’re actually where you think you are before you touch a single plugin setting.
Why Your Post-Migration Audit Matters
Once the files are moved, the job is only half done. You need to run a crawl. I use Screaming Frog or a similar tool to compare the old site map against the new one. If your WordPress migration checklist doesn’t include a full link crawl, you’re flying blind. Check for 301 redirects especially if you changed your URL structure. A single missed redirect on a high-traffic post can cost a client thousands in lost revenue. Here’s the kicker: even if the site “looks” fine, your robots.txt might still be blocking the entire site from your staging days. Check it twice.
Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work without the Friday night heart attacks, drop my team a line. We’ve seen these nightmares before, and we know how to wake you up from them.
So, What’s the Real Takeaway?
- Parity is King: Ensure your PHP versions and database engines match between hosts to avoid silent failures.
- Serialized Data: Never use a raw SQL search-replace for URLs. Use WP-CLI or a dedicated migration plugin.
- The 503 Rule: Always signal a temporary outage to search engines; never let them see a 404 or a database error page.
- Local Caching: Flush your local DNS and use a private browser window to verify the move.
Leave a Reply