The migrate module provides a flexible framework for migrating content into Drupal from other sources (e.g., when converting a web site from another CMS to Drupal). Out-of-the-box, support for creating core Drupal objects such as nodes, users, files, terms, and comments are included - it can easily be extended for migrating other kinds of content. Content is imported and rolled back using a bundled web interface (Migrate UI module) or included Drush commands (strongly recommended).
Support note - Mike Ryan is going off on vacation, so until the week of June 3 any support in the issue queues will be peer-to-peer.
Migrate 2.6 beta1 is now available. The main theme of this release is UX - the existing UI has been significantly rearranged, and a new API has been introduced to allow other modules to easily developed wizard-style UIs targeted to non-developers.
The most significant changes in Migrate 2.6:
- #1826112: Wizard framework
- #1833380: Support basic and advanced UIs
- #1860450: Support for triggering drush import/rollback from UI
- #1928956: Straighten out constructor parameters/arguments
- #1896096: DB storage of field mappings
- #1996602: Default field handler
- #1835822: Hash source rows to detect changes
- #1839644: Extending group objects
- #1896920: Remove auto-registration, and make sure migrations are only registered when explicitly asked
- #1901980: Convenience functions for encryption/decryption
For a more complete list of changes, see the issues tagged as Migrate 2.6.
Besides the UI changes, there are significant changes around migration registration and construction that are somewhat risky - before upgrading to the latest -dev or git code, be sure you backup your database. Please report any problems you have in upgrading in the issue queue - we want to be sure the upgrade to the final 2.6 release is as clean as possible.
Looking ahead, after Migrate 2.6 I will be focusing on work for Migrate 3 on Drupal 8 (the work for Migrate 2.6 is actually to some extent a POC of some ideas for Drupal 8). Feature requests for Migrate 2 that don't directly support that work will have their best chance for consideration if they come with patches from the community.
Support for contributed modules
The place to implement migration support for a contributed module is in that module, not in the Migrate module. That way, the migration support is always self-consistent with the current module implementation - it's not practical for the Migrate module to keep up with changes to all other contrib modules.
Historically, if this did not seem practical, or as an intermediate step before submitting it to the contrib module itself, support for some contrib modules has gone into the Migrate Extras module. We're now deprecating this module - every effort should be put into integrating migration support directly into the target module.
Specialized migration modules
These modules use the Migrate framework to implement imports from specific sources.
- Andrew Morten's (drewish) slides and video from a Drupalcon Denver session explaining the Migrate module in technical terms.
- Mike Ryan's slides and video from a Drupalcon Denver session explaining the migration process in non-technical terms.
- Migrating old HTML files into Drupal, by Four Kitchens
- The Economist.com data migration to Drupal
The Migrate module is maintained by Mike Ryan who works for Acquia. Past sponsors include:
- GenomeWeb, and The Economist - Initial development of Migrate 1.
- Examiner.com - Initial development of Migrate 2 on Drupal 7.
- Martha Stewart Living Omnimedia - Backport of Migrate 2 to Drupal 6.
- World Economic Forum
- Warner Music Group
Thanks to Frank Carey for the Migrate Extras module.