Cloud Platform
Migrate 8: DrupalCon Post-Mortem
At DrupalCon Austin, I led a Core Conversation panel, Status of Migrate in 8, along with chx, ultimike, Ryan Weal, and bdone. The conversation was well-received, and we fielded some good questions. To summarize what we went over, updated for continued developments:
Traditionally, major version upgrades of Drupal used the same update.php method as minor updates - Drupal would be updated in place, with direct database queries modifying the live database (hopefully having been put into maintenance mode first). As Drupal has become more complex, this method has become more unwieldy, and the Drupal 6 to Drupal 7 upgrade path in particular was painful for many people. Also, the usual policy has been for official support for a version to be dropped upon the second following major release - i.e., Drupal 6 support would be dropped when Drupal 8 is released - and there has been a great deal of concern among those still on Drupal 6 over the prospect of needing to do a two-stage upgrade - to Drupal 7 in the near future, and eventually to Drupal 8.
So, the decision was made to use a migration approach for major upgrades - rather than upgrade in place, a new Drupal 8 site will be installed, and then the configuration and content of the legacy site imported into that site. This will provide more flexibility to the upgrade process, and also will support jumping a version - in particular, Drupal 6 site owners will be able to migrate directly to Drupal 8 without going via Drupal 7. The framework for the core upgrade process will also ease contributed support for migration from other Drupal versions (not to mention migration from other systems). This framework takes as its starting point the contrib migrate and migrate_d2d modules I've developed (with community contributions, of course) over the past several years.
Thus, going forward, contrib modules will no longer implement update hooks for major version upgrades - instead, they will provide migration configuration in YAML files, which should be fairly simple in most cases. Contrib modules with more complex data may need to implement custom migration plugins.
Release-wise, the underlying framework (the classes implementing the actual moving of data) should be in Drupal 8.0.0. A simple UI for performing Drupal 6 and Drupal 7 upgrades is being developed in contrib - a decision will be made before the Drupal 8 release candidate whether this will be shipped with 8.0.0, or wait for a minor feature release (such as 8.1.0).
Now, it's important to note that out of the box with core alone, at least on initial release, there will be no customization of the upgrade path - you will provide the database credentials and web address of your source site, click a button, and everything will be imported. The ability to customize your Drupal-to-Drupal migrations will be supported in contrib. We can feel comfortable providing a bare minimum level of functionality because Drupal 8 is adopting semantic versioning - this means that, rather than try to anticipate every important use case up front and implement every one (and not have the UI ready into 8.2.0), we can start with the bare minimum and let our real-world experiences tell us what more may be needed in core. For example, we may find after 8.0.0 goes out with one-click upgrades that many people want the ability to separately import configuration and content. Guided by that experience, we could add toggles for configuration and content to the upgrade form in 8.1.0 or 8.2.0.
The migrate and migrate_drupal modules are in core and being tested and tweaked. Note that migrate_drupal supports Drupal 6 sources only at this point, Drupal 7 is to be added.
The migrate_upgrade module is in contrib and basically functional for site configuration, content, and public files (private file import is not yet implemented) - my personal site (Drupal 6) successfully imported (in a live demo at DrupalCon!) with the alpha12 core release, the migrate_upgrade module, plus one core patch to make files work.
The migrate_plus module is not yet started - my plan is to address the current open issues for migrate_upgrade, then launch the migrate_plus effort.
We need to work on the DX and documentation for contrib modules - how to write configurations and plugins - and get some contrib modules using and testing the upgrade path.
The biggest thing we need at this stage is testing. Lots of testing. Testing with real-world D6 and D7 sites.
The Friday sprint at DrupalCon Austin was very productive - Michael Anello (ultimike) led people spread across two tables in testing the D6-to-D8 migration path, adding to the core issues, including a few patches. Meanwhile, Bojhan Somers (Bojhan) and Angie Byron (webchick) sat with me to review the nascent state of the UI and gave a lot of great feedback, instantiated in a long list of issues consolidated in a meta issue in the core queue.
You don't have to be an experienced Drupal developer (or a developer at all) to help. It's critical to run a wide variety of legacy Drupal sites through the upgrade process - if you have a Drupal 6 (or, once we've got its upgrade path committed, Drupal 7) site, you can help simply by trying. See Michael Anello's post on setting up a Drupal 8 environment in general for testing, or Angie Byron's post on getting Drupal 8 set up on Acquia Cloud.
If you are a developer, you can contribute work to open migration tickets in the core queue. You can also contribute to the upgrade UI - note that at this writing there are a bunch of issues tagged "Novice", that would make good stepping stones for people new to Drupal 8 development. Get to them quick, they'll go fast!
Cloud Platform