Migrating book module nodes is one of the more difficult tasks to accomplish with Migrate module. This is due largely to certain workflow issues that can come up during migrating book nodes, and the fact that book node hierarchy is stored within menu links (Drupal 6 and later). The following code is an example of how to deal with this.

I'm currently working my way through setting up a migration from vBulletin 3.8 to Drupal 7 using the migrate module (2.2). Here's the code that I'm using that will hopefully be of use to other vBulletin users.

First of all, I've created a 'vbulletin_migration' folder in the sites/all/modules/migrate folder and added .module and .info files

I've named the .module file vbulletin_migration.module and it contains the following code:

// $Id: migrate_example.module,v 1.1.2.4 2010/12/18 16:04:59 mikeryan Exp $

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

I've named the .info file as vbulletin_migration.info and it contains the following code:

<?php
name = "Migrate vBulletin"
description = "Module to migrate vBulletin content to Drupal 7"
package = "Development"
core = 7.x
dependencies[] = migrate
dependencies[] = migrate_extras
dependencies[] = field
dependencies[] = file
dependencies[] = image
dependencies[] = number
dependencies[] = text
dependencies[] = options
dependencies[] = taxonomy
dependencies[] = date
dependencies[] = link
dependencies[] = media

files[] = vbulletin_roles.inc

To migrate content into Drupal taxonomy terms, use the MigrateDestinationTerm class:

$term_options = MigrateDestinationTerm::options($language, $text_format);
$this->destination = new MigrateDestinationTerm('tags', $term_options);
$this->addFieldMapping('name', 'source_name');
...

The first argument is the bundle (vocabulary machine_name) you wish to migrate source content into.

Fields

tid - The Drupal term ID. Usually this will be unmapped - the tid will be automatically assigned when the term is created, and the map table will record the source key that generated this ID. You would map the tid when the system-of-record is DESTINATION (i.e., the purpose of your migration is updating existing terms rather than importing new terms). Note also, tids cannot be created on an initial migration. Drupal does not allow for specifying term ids upon creation. If this is tried then no error will be thrown, instead Migrate will say that everything updated just fine. However, no data will be inserted and you may need to manually truncate the migrate_map_[machine name] table. See http://drupal.org/node/1516244 for explanation.

pre/post Import/Rollback methods

You can execute code before or after an import or rollback operation by implementing the Migration class methods preImport(), postImport(), preRollback(), or postRollback(). Each of these is called once per individual Migration - that is, if you implement preImport() in an article node migration class, it will be called after any previous migrations you're running, and immediately before the first row of your article node migration is called.

Typical actions can be the enabling / disabling of certain modules or changing configurations.

class ArticleMigration implements Migration {
...
  public function preImport() {
    parent::preImport();
    // Code to execute before first article row is imported
  }
...
  public function postImport() {
    parent::postImport();
    // Code to execute after the last article row has been imported
  }
...
  public function preRollback() {
    parent::preRollback();
    // Code to execute before first article row is deleted
  }
...
  public function postRollback() {
    parent::postRollback();
    // Code to execute after the last article row has been deleted
  }

A practical example can be found here.

This Cookbook shows, how you import one CSV file into a Drupal 7 site, creating new users, each with Profile2 fields.

The trick is to create two separate migrations from one source. The first creates the users, the second creates the profiles.

The second migration connects up the profiles it creates with the users that now exist by mapping the source unique key, MID, to the user uid. This is achieved by applying the line
$this->addFieldMapping('uid', 'MID')
to the code.

Remark
The intention of this cookbook is, with detailed notes on this page and comments in the code to explain the function of each component of this migration as a working demo. For your first try use a fresh installed 'drupal 7 with default profile' and then start with step 1.

Some field types are more complex than others - in particular, they support a number of options controlling their behavior, or subfields providing additional data. These options or subfields can be mapped like regular fields - for example, to map the summary subfield of a text field:

$this->addFieldMapping('field_text', 'main_text');
$this->addFieldMapping('field_text:summary', 'teaser_text');

You can view all of the available subfields either in the migrate UI under the destination's tab for a specific migration or by using the drush migrate-fields-destination command. Just like regular field mappings if you leave a subfield un-mapped it will assume the Drupal default value for that column which varies depending on the type of field in question.

One common example is the 'language' subfield - this indicates the value of the field when requested for a given language and many fields have this additional data. The default is LANGUAGE_NONE ('und') - the default value when a specific language is not requested. If you were importing translated data you may want to set the appropriate language code with something like the following:

$this->addfieldMapping('field_name:language')->defaultValue('de');

Text fields