Extending migrate_d2d classes

The migrate_d2d classes can be used as-is for migrating core data (e.g., user email, username, password, created date, etc.) with sensible defaults, but what about custom fields?

Suppose in your legacy system you had field_published on your article nodes, and in the new D7 system the equivalent field is field_published_date. You can map these fields by implementing a custom class overriding the provided node class and adding the mapping:

class ExampleArticleMigration extends DrupalNode6Migration {
  public function __construct(array $arguments) {
    parent::__construct($arguments);

    $this->addFieldMapping('field_published_date', 'field_published');
  }
}

To make use of your custom class, pass its name rather than DrupalNode6Migration when registering your classes:

Migration::registerMigration('ExampleArticleMigration',
  $article_node_arguments['machine_name'], $article_node_arguments)

Another common use case for overriding migration classes is modifying the base query. Each of the migrate_d2d classes has a query() method, returning the query object used to pull source data. By doing this rather than hard-coding the query into the constructor, you have the opportunity to customize the query for your application:

class ExampleUserMigration extends DrupalUser6Migration {
  protected function query() {
    // Get the default query (all rows in the users table other than uid 1)
    $query = parent::query();
    // Exclude test accounts
    $query->condition('name', 'test-%', 'NOT LIKE');
    // Add fields from a custom table
    $query->innerJoin('myextradata', 'd', 'u.uid=d.uid');
    $query->fields('d', array('favorite_food', 'favorite_song'));
    return $query;
  }
}

For more information on extending migration classes, see the Getting started with Migrate documentation page.