You are hereMigrate tour

Migrate tour

Click on the tabs below. Or lazily watch the slides advance :)

Review legacy data

In a series of meetings, Cyrve reviews the legacy data with client. here, we identify what data is to move to Drupal and what shall stay behind.

Legacy data comes in many forms, and migrate module can handle almost all of them. We've migrated from database systems like MSSQL and Oracle. We've migrated data out of web services and XML/HTML documents.

Build Drupal fields

The first step in the Cyrve migration process is to build the Drupal CCK Fields and taxonomy terms and user profile fields that are needed. These data structures receive the migrated content. We don't need a full Drupal build at this stage; just a rough data design.

Create migrations

Next, Cyrve creates a migration for each combination of legacy source data and destination Drupal object (for example, from an articles table in Oracle to a Drupal node type named Articles). Responsible parties from both Cyrve and the client are assigned to each migration (e.g, one client representative might be assigned to help identify mappings for article types, and one Cyrve engineer assigned to implement the mappings).

Map legacy data

Now, we are ready to map legacy columns to Drupal fields. These mappings are instantiated in code in a custom module. A web UI provides Cyve and the client with a shared representation of the mappings, highlighting any that require attention (input needed from the client, implementation to be completed by Cyrve, ...). Open issues can be linked to tickets in project management systems such as Unfuddle or Trac.

Import

The migrate module supports an iterative approach to developing migrations. We don't have to wait until every mapping is nailed down - the migrate module does all the bookkeeping (tracking what source row was imported into what Drupal entity) so that you can easily rollback or re-import data as the mappings and their implementations are refined. Performance details can be reported to identify bottlenecks slowing down the migration process. Errors and exceptions are recorded in the Drupal database, linked to the source record that triggered them.



Meet the Experts

Moshe Weitzman

Moshe is one of the most senior members of the Drupal community. He started committing code to Drupal in 2001. He is the second most prolific contributor in Drupal's history. View Moshe's Drupal resume. Moshe is the original author of the Node Import module, among many others.

Mike Ryan

Mike has given much to the Drupal community since first contributing in 2003. He's the wiz behind the Migrate and Table Wizard modules. He was also the original author of the Pathauto module, a terrific tool for automatically creating friendly URLs for pages and thus greatly improving SEO.