BTMash

Over the past 2 weeks, I have been working on a project whereby the site owners wanted to update the look and feel of their site (along with adding a slew of new features in there - I will be posting about it once the site launches). In talking with my coworkers, we (I) essentially decided that instead of updating their current site (which was in Drupal 6), it would now be done in Drupal 7. What we (I) also decided is that instead of running the site through a site upgrade path, we would create a fresh install of Drupal 7 and copy the content from the old site into the new one. However, we were dealing with nearly 800 nodes and, while that isn't a particularly high number, would make the client feel like they would need to go through this each time there was a site refresh. So for this project, I gave the Migrate module a try.

Upon going through everything regarding the migrate module, I was able to surmise a few things. It was very powerful. And it was very confusing for someone who was, in a way, performing a site upgrade. There is an example migration module included with migrate but it is nonetheless quite confusing. As a result, I wrote up a series of blog posts that can serve as some level of documentation for how to approach the migrate module.

First things first, you define your own module (let's call it redcat_migration). After you set up the info file, your module file should have:

/**
 * You must implement hook_migrate_api(), setting the API level to 2, for
 * your migration classes to be recognized by the Migrate module (for the 7.x-2.x branch).
 */
function redcat_migration_migrate_api() {
  $api = array(
    'api' => 2,
  );
  return $api;
}

From this point, you are now ready to actually implement classes for things to get migrated.

For my project (and for this documentation), I broke up the migration process that was created into parts tackling:

• Basic users
• Basic nodes (pages) (Updated June 4, 2011 for Migrate 2.1)
• Nodes with dates (events) using a custom field handler (Updated June 4, 2011 for Migrate 2.1)

This **should** cover a chunk of the migrations and I will be posting them as parts over the next few weeks.

I have also posted the ENTIRE migration module used in the tutorials above (REDCAT Migration - since it is a sandbox, you will need git to copy/paste the code by hand to go through) so you can review the code along with any other resources :)

If I think about the amount of time I put into learning migrate and performing a proper migration (2 weeks!), it would have been much faster to do this by hand (we had interns that had done just this for the launch of CalArts.edu). HOWEVER:

• I manage a slew of other sites and whenever we decide to perform an upgrade/migration for them down the line, it will make more sense to use migrate for them (and the other sites have a lot more content than this site does (one of them has 100k nodes - not a fun task to migrate that by hand))
• Upgrading a site was an option; however, this will provide us with the flexibility of creating a fresh site using new features in Drupal.
• The current site can continue functioning the way it is and we can suck in new content from it in a much simpler manner - meaning we just need to suck in any new content they create between now and the date of launch (or roll back and migrate it all in as new content).

Ultimately, I simply want to say that instead of rolling your own migration module for a particular site, you should strongly consider the migrate module (or feeds - that is one other solid approach to migrating content from a web site). Despite its lack of documentation (and the documentation that is there in the example modules is somewhat overwhelming), it is very flexible and the built in functionalities it provides (rolling back the users and nodes would be my second most used function) are very powerful (so you can avoid doing a lot of work that already exists out there).