Live from the sweatshop…

We have been running Movable Type for over three years and for number of reasons (far better platform, CWL integration, the support overhead and availability of plugins, to name a few) decided to move to WordPress.

Since last summer we have pretty smooth, CWL-enabled, pilot WPMU installation available to selected UBC faculty, staff and students; so far, things look pretty good!

Now that we are at ease with our ability to run the new system, we are planning to migrate more than a thousand MT users  and blogs to WP.  We are expecting that only the small number of people will actually want to move their blog – for the rest… well, we are thinking about it as the great autumn-cleaning opportunity. Anyways, EVERY blog will be backed up and saved in case users come in the future to restate their blogs.
Here is the process with its requirements and challenges along with the ideas on how to go around them:

Setup: There are three environments in which the migration takes place:

• Original MT (Source)
• Verification WP (Check-point)
• Production WP (Target)

The process:

1.       Notifying the Users and Project Tracking.
We will send the email to users describing the migration process and inviting them to create an account and a blog on the Production WP, which is the new location for their blog. We have classified all the users on the scale of 1 to 5, based on the importance of the blog (we have tons of abandoned blogs) and we also have special VIP list – those blogs get extra attention!
Here are the fields of our migration tracking database:
blog_id, blog_name, entries_count, blog_site_url, author_id, author_name, author_email, other_blog_owners, blog_description(tags), priority_rating, migration_notes,  vip, new_author_name, other_authors_translation, new_url.
You can sense the complexity of this operation by just looking at these fields!

2.       User reports back
Upon creating the account, blog user gets back to us with the account and blog info (details instructions on how to do this were sent in an email). We then proceed with the next step of migration:

3.       The Import to Verification WP
MT blogs and users’ info are exported from MT to Verification WP by using WeblogsMigrator plugin that Michael Ha and Seth Tee have specifically developed for this purpose. This WP plugin actually queries the MT database and retrieves all the information on the given blog and user and then stores them in the Verification WP. So, we end up with blogs, authors and comments, all properly imported within WP Verification. Users from MT keep the same username in WP Verification. It is worth mentioning that in this process, all the links that point to the other posts within same blog are being re-written to point to the new URLs. It is even cooler that we are grabbing all the media files (images, movies) and storing them automatically in WP Verification.

4.       Finalizing the Look and Feel and dealing with blogs’ extras.
Here, we apply theme that look close to one in MT, for look and feel consistency. For VIPs, this may involve additional tweaking or creation of the new theme. If needed, we consult with users on how to proceed with extra content (if there is any) of their MT blogs. Usually, this means dealing with side bar content and advising on how to recreate these in WP (through using widgets).

5.       From WP Verification to Production
After examining the blog and round of QA, we do another round of export/import; this time using slightly changed WeblogMigrator. Things get hairy with blogs that have multiple authors; for this reason, we made sure that this plugin, which looks very much like standard WP to WP import, also provides username matching. With this, we make sure that the original users keep ownership of their posts after the blog is migrated. It is expected that many users will have different usernames from those on MT, that’s why we cannot automate this process. This is only important for multi user blogs.

6.       Redirecting old URLs
One of the major requirements of this process is to make sure that every post will automatically redirect to the new post’s URL.  In the process of importing (step 3), we record the old and the new URL for each post and store it in the database. This table is now queried to produce the  .htaccess file that will, for every post, redirect to the new post URL.

7.       User takes control
At this point user has the complete control over their blog. We are expecting that owners of more complex blogs will require additional support that we can provide through pointing to various WP support websites and examples online, or via direct support.