Given that the blogging platform Movable Type has more or less vanished into the hinterlands of history, it is no longer a common occurrence to be put in the position of having to migrate a blog from Movable Type to the present dominant platform of WordPress. The tools for such a move, never great to begin with, have fallen into disuse and tend not to work for large migrations, or at all in many cases. I put together a post last year that covers the use of the WXR WordPress import/export format to migrate larger Movable Type 4 or 5 sites, but recently I ran into a site that this approach couldn't handle. The import and export process were so failure-prone that the better investment in time and effort turned out to be writing a database migration script.

Movable Type and WordPress have more similarities than differences in their schema, so putting together a PHP migration script did not require a great deal of innovation: it was largely a matter of digging through documentation in order to correctly map values and working around a few awkward mismatches. Since there is little point in keeping this to myself, I've documented and published the result at GitHub. Hopefully it will aid the few other people in the world who will ever find themselves having to migrate one or more Movable Type 4.*/5.* sites to WordPress 4.*. It is certainly a lot faster and easier than using the WXR method. It similarly preserves IDs and slugs for posts, pages, and comments, and can be configured to preserve the GUID used in feeds so that feed readers don't treat migrated posts as duplicate entries.

Performing a Migration

You will need to set up the following:

• A recent version of PHP, 5.4 or later.
• Access to both the old Movable Type database and the new WordPress database.
• The PHP CLI.
• The WordPress command line tool WP-CLI, as you will need it to set user passwords following migration.
• A cloned copy of the migration script GitHub repository.
• The Medoo database framework library.

The new WordPress installation should be clean, without any plugins installed or content added. Many plugins add metadata for posts, comments, and pages, and the migration script cannot account for that. Install the desired plugins after the migration is complete.

Copy the Medoo database framework library to an accessible location, and update configuration.php in the migration script repository to set the absolute path to that library. Then update the rest of configuration.php with the appropriate values for your migration: database connection details, and so forth. Some of the configuration involves amending function definitions. The defaults will work for most Movable Type installations, but if you were using some of the less usual content options, such as Textile 2, you will have to write code to translate that content into HTML.

To run the migration:

cd /path/to/movabletype-to-wordpress-database-migration
php migrate.php

It batches updates, so should complete fairly rapidly even for large databases. Once done, use WP-CLI to set the password for one of the migrated users, and log in to the WordPress administration interface to check the results. You will have to set passwords and permissions for all migrated users, as they are all given adminstrative permissions by default, and none will have passwords set at the outset.

Asset files will have to be copied over separately. If their location changes in the webroot, as seems likely, then the corresponding attachment records in wp_posts must be updated to reflect that change.

Limitations of the Migration Script

Movable Type asset records are converted to WordPress attachment records, and thus the asset IDs cannot be preserved as the schemas are too different. Assets live in their own table in Movable Type, but attachments use wp_posts in WordPress, alongside posts and pages. Migration of the asset files must be carried out separately, and if the path in the webroot changes, as is likely, then the database records in wp_posts will need to be updated as well.

Page slugs determine page URIs. Not all page slugs, meaning entry_basename in Movable Type and post_name in WordPress, can be preserved in order to maintain the same URI. Movable Type uses underscores as a delimiter, and thus has slugs containing dashes when post titles contain dashes, and multiple consecutive delimiters when titles contain non-ASCII characters. WordPress uses dash as a delimiter and portions of its codebase will treat consecutive dashes as a single dash, so a post_name with multiple consecutive dashes in the database will result in the generation of invalid links. The migration script will convert all such slugs to use a single dash, so my_-_post will become my-post rather than my---post. This will change the URI for that page.

The range of options for users and authentication in Movable Type makes a comprehensive migration script prohibitively complicated. In the present version only content creators and administrators are migrated. Comments are migrated, including user names, email addresses, and URLs, but associated user records for registered commenters are not migrated. Passwords for content creators and administrators are also not migrated and must be updated manually or via a tool such as WP-CLI.

All posts in WordPress are stored as HTML. In Movable Type a variety of formats are used, and the migration script only accommodates the default line break conversion and HTML formats. Markdown, Textile 2, and Rich Text formats are not supported as written. To migrate a Movable Type site using these less common options, extend the generatePostContent function in order to convert that content to HTML.

Lastly, I have only tested and used this script for a Movable Type 4.* to WordPress 4.* migration. It should work for Movable Type 5.* since there is little difference between 4.* and 5.* versions, but inevitably there will be issues. Some effort would be required to make it work for other Movable Type versions.