Last updated November 9, 2012. Created by mikeryan on October 22, 2012.
Edited by jaspher. 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:

<?php
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:

<?php
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:

<?php
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'));
    return
$query;
  }
}
?>

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