A client came to me last week with a site that had been running on WordPress.com for nearly a decade. The platform is 20 years old now, and it has come a long way since Matt and Donncha launched it in 2005. For this client, though, the success had turned into a bottleneck. They had outgrown the “walled garden” and needed a real WordPress hosting migration to a self-hosted environment so they could run the custom third-party API integrations a managed plan could not support.
The site was a beast: thousands of posts, a huge media library, and years of legacy metadata. My first instinct was the standard Tools > Export XML route, and I have watched plenty of devs make the same call. Pull the content, let the new server fetch the images, done. It timed out halfway through and left me with a fragmented database and thousands of broken image links. Not my finest hour. When you are moving a decade of history, the easy way is usually the broken way.
Running a WordPress hosting migration at scale
Migrating away from a platform that has “democratized publishing” for 20 years, as the recent anniversary post on the WordPress.com blog puts it, is awkward because the underlying architecture handles media and paths in ways a standard VPS setup does not expect. Search and replace across the database is not enough on its own, especially where serialized data is involved.
So instead of the XML export I moved to a structured SQL migration plus a custom script for the media sidecar files and the metadata that WordPress.com’s export tends to strip. Here is a filter I use to keep legacy media paths mapped correctly during the switch, so SEO-critical assets do not start returning 404s.
/**
* Ensure legacy media paths map correctly during migration
*
* @param string $url The original media URL.
* @return string The corrected URL for the new environment.
*/
function bbioon_fix_legacy_media_paths( $url ) {
if ( strpos( $url, 'files.wordpress.com' ) !== false ) {
// Logic to replace the remote CDN path with your local uploads directory
$new_base = wp_upload_dir()['baseurl'];
$url = preg_replace( '/https:\/\/.*\.files\.wordpress\.com/', $new_base, $url );
}
return $url;
}
add_filter( 'wp_get_attachment_url', 'bbioon_fix_legacy_media_paths' );That keeps you out of the “death by a thousand 404s” situation, where the new server keeps referencing a CDN it no longer has access to. We also had to work through the “Jetpack-lite” features that are baked into the WordPress.com environment and simply missing on a raw .org install. Audit every feature you take for granted on the hosted side before you pull the plug.
What to account for before you move
None of this means WordPress.com is bad. It is a genuinely good starting point for most sites. But once you need deep control over your stack, the migration turns into a technical project rather than a marketing one. You need to account for:
- Database serialization issues during search-and-replace.
- The loss of platform-specific metadata during standard XML exports.
- Server-level configurations (like Nginx rules) that the managed host handled behind the scenes.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
Are you still running a decade-old legacy setup, or are you ready to take full control of your stack? Drop a comment and let’s talk shop.
