Issues I found during WordPress.com to .org migration

Whilst migrating from wordpress.com to an installation of the open source WordPress, I hit some gotchas that I couldn’t easily find information about elsewhere. So, I figured I’d document my findings in case anyone else has issues.

The migration itself

Everywhere I’ve seen documents using the “Export” tool from the WordPress admin panel to generate a zipped-up XML file called a WXR file. You can then use the “Import” tool with the “WordPress Importer” plugin to import this file. Making sure that you have the same theme installed and active first, if that is possible.

What should happen at this stage is the media from your old site is copied over to the new site, with metadata inserted into the database. Then the posts themselves are inserted.

What actually happened is that I kept hitting server timeouts before the import could get anywhere. The PHP configured timeouts were very large, so this was likely something beyond my control. My blog isn’t huge, only just over 250 posts and about 3 GB of media files at the time of writing. So, I was surprised this didn’t work.

After some online searching, I found whispers that wp-cli is better for this. So, I ssh’d into my new host and ran the following:

wp --path=<PATH TO MY WORDPRESS INSTALLATION> import wordpress-backup.xml --authers=skip

This started to import things properly, showing progress as it was going. It was not fast, taking probably a total of 5 hours. It was also killed by something on my hosting provider a few times, but re-running the command continued from where it left off.

Fixing things

I was expecting a few breakages, watching 404’s in the logs helped show me what they were. The first was that my .com site used the form /year/month/day/post-name for the path to the post. The new WordPress installation just used /post-name. By the time I figured this out, the site was already live. So, I added the following to .htaccess to re-write the URLs:

<IfModule mod_rewrite.c>
RewriteEngine On
RedirectMatch 301 ^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(?!page/)(.+)$ https://linuxjedi.co.uk/$4
</IfModule>

If I wasn’t live already, I could have changed the configuration in WordPress to keep the paths the same. I figured this was a good enough workaround. In hindsight, given the next issue, some of them may have been incorrect anyway, so it was probably best to do things this way.

There were also a couple of images that had broken. These were on posts that started in one month and were published in the next month. My .com site had put the media in a path where the post was first created, such as 2023/12. If the post was published in the following January, the import put them in 2024/01. This led to them being 404s. Thankfully, it is easy to modify the path WordPress is using to find the individual images when you edit the post.

If you click on the image, then click “Replace”, it will show you the path being used for the image, along with an icon to manually edit it. I think this only applied to two or three posts.

There were other minor things as well, such as having to set the title image again, but I wasn’t expecting those things to migrate over. I was surprised that most of my theme block setup had migrated.

Plugins needed

A few extra plugins were needed to add back some missing functionality. I don’t know if I picked the right ones, but they seemed like they did the job. These were:

• Anti-Spam by Cleantalk – For automatic comment spam filtering (my site gets a lot)
• SyntaxHighlighter Evolved – I use syntax highlighted code in some of my posts, this unbreaks those blocks
• Site Kit by Google – Visitor statistics
• Accelerated Mobile Pages – Adds AMP support
• The SEO Framework – To make sure things like cards when pasting in social media work well, probably optional.

Conclusion

I think my site is now roughly where it was before the migration. I do feel like I have more control over it now too, whilst some of the maintenance type tasks that I don’t have time for are handled for me.

I hope this helps anyone else wishing to try a similar migration.

Feature image: Migration by Nick Youngson, used under a CC BY-SA 3.0 license.