Last updated November 9, 2012. Created on October 22, 2012.
Edited by jaspher, mikeryan. Log in to edit this page.

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) {

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

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

$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-%', 'LIKE');
// Add fields from a custom table
$query->innerJoin('myextradata', 'd', 'u.uid=d.uid');
$query->fields('d', array('favorite_food', 'favorite_song'));

Looking for support? Visit the forums, or join #drupal-support in IRC.