Drupal

As a newly-minted midwestern Drupal shop, having this year's MidCamp taking place the very week of my transition was irresistible. So, on St. Patrick's Day I hopped on the Saluki to Chicago (alas, too late to see the green river). I did, however, arrive in time to catch a couple hours of the training day sprint, where I met dawehner face-to-face for the first time (one of the great things about cons and camps is, of course, putting faces to names). Topped off the day with a meat & three at County BBQ - their brisket was if anything even more tender than Pat's back home in Murphysboro, but not quite as tasty.

All things must pass... After four and a half years with Acquia, the time is ripe for me to return to the consulting world. I've resurrected a pre-Drupal d.b.a., Virtuoso Performance, and will be doing Drupal migration consulting under that moniker going forward. I appreciate my time at Acquia - I've learned a lot, and worked with some great people - but I miss the freedom and flexibility of consulting.

Business models

Generally, in the past I've been involved in migration projects from end-to-end:

1. Analyzing source data, and working with site-builders and stakeholders to work out what legacy data maps to what Drupal entities.
2. Architecting the migration implementation - figuring out an optimal class hierarchy, constructing the initial implementation, etc.

Now that Drupal 8.0.0 is released, let's take a look at all the components of the Drupal migration ecosystem and where they stand now. To provide context to those familiar with migration under Drupal 7, I will show where the pieces came from. First, general migration support:

Feature	D7	D8	D8 status
Basic migration framework	migrate (contrib)	migrate (core), plus destination plugins in core modules	Experimental
General-purpose drush commands	migrate (contrib)	migrate_tools (contrib)	The most common commands (ms, mi, mr, etc.) are working

For anyone currently using the migrate_tools (drush and UI tools for managing migrations) or migrate_source_csv (CSV source plugin) submodules of migrate_plus with their Drupal 8 migration projects, a heads-up - they're being split off into separate projects.

What's happening

New projects have been created for migrate_tools and migrate_source_csv. The plan is to create real (beta or RC) releases for these projects by next Monday, November 16. On that day, a release of migrate_plus will be cut that no longer contains those two modules.

What do I do about it?

So, perhaps you've been reading Upgrading to Drupal 8 using the UI and thinking "hey, what about us cool kids who use Drush for everything?". Or, maybe you just know drush is better than a UI for running long processes like migrations. Well, this blog post is for you... We do have drush commands for running and rolling back upgrades, currently in the migrate_upgrade module (but which should land in Drush itself by Drupal's 8.1 release at the latest).

Now that the second Drupal 8 release candidate (RC2) is available (with a significant fix for those upgrading from Drupal 6), it's time to start planning for your upgrade from Drupal 6 or Drupal 7. As I previously wrote, the migration system is "experimental" in 8.0, and at this time (mid-October 2015) the tools for upgrading are in a contributed module, Drupal Upgrade. The plan is that the upgrade path will be fully supported in core for Drupal 8.1 - to reach that goal, however, we need the path to be tested on a wide variety of sites in the meantime. So, we encourage everyone with a Drupal 6 or Drupal 7 site to start testing the upgrade path today - you don't want Drupal 8.1 to come out and only then discover your site has some quirk that's not fully accounted for. Even better, you might fight the upgrade path works just fine for your site and you can upgrade in the Drupal 8.0 timeframe! The current documentation for performing your upgrade from Drupal 6 or 7 to Drupal 8 is on drupal.org - I'll walk through the process as it exists today, but should you be referring to this blog post after October 2015, be sure to review the official documentation for any changes. This post explains running the upgrade process through the Drupal 8 web interface - if you'd prefer to use Drush, please see Upgrading to Drupal 8 using Drush.

It's been a breathless past several weeks in Migrateland - with the core committers as a whole focused on trimming the criticals list for Drupal 8 to zero, Angie "webchick" Byron has given quality time to help the Migrate team get unblocked, triggering a flurry of activity. All along I've meant to post a status update, but things have been moving so fast it's been "well, after this next commit..." Let's review where we stand at the moment, as of September 18, 2015.

Upgrade path

From the initial decision to replace the traditional update-in-place (update.php) approach to major version upgrades with a migration-based (import into a fresh site) approach, it was made clear that the initial Drupal 8 release would not be blocked on the upgrade path. If the upgrade path was not "ready", Drupal 8.0.0 would release without it and be available for building new sites only. The plan was as Drupal 8 approached RC status the decision would be made over migration support in 8.0.0. That decision has been reached and published. By all means go ahead and read the official policy as well, but tl;dr: the migrate API and the Drupal 6 upgrade path (and possibly the Drupal 7 upgrade path as well) should be part of the Drupal 8.0.0 release, but marked as "Experimental".

A quick update on where the migration-related modules I maintain on Drupal 7 (migrate, migrate_d2d, and wordpress_migrate) stand now, to help set people's expectations of the level of support they can expect in the issue queues. There are two main points:

1. I am now officially working full-time on migration in Drupal 8, for the time being (I'll have a blog post with details on that work shortly).
2. I feel that the Drupal 7 migration modules are pretty much functionally complete.

Well, what with an increase in client work and a move halfway across the country (Somerville Mass to Murphysboro Illinois), I'm afraid I've fallen further behind on the issue queues for migrate, migrate_d2d, and wordpress_migrate. It's been a bit of struggle to triage the queues, so to somewhat automate the which-issue-to-work-on-next process, I'm reducing it to an algorithm (each step of which will be applied to migrate, migrate_d2d, and wordpress_migrate in that order).

1. Bug reports with patches (needs review, rtbc), oldest to newest
2. Other bug reports, oldest to newest
3. Other issues with patches (needs review, rtbc), oldest to newest
4. Triage of support requests to make sure no bugs are lurking there

At that point, I plan on cutting release candidates for all three modules. Hopefully at that point I'll be able to start doing a better job of responding to new issues as they come in. Hard to say when I'll have a chance to review and respond to older support and feature requests, though, it'll depend on my workload (but of course I'm not the only one in the community capable of helping out with support requests - hint hint). Thank you. Edit: Let's keep track of where I am... I'll also note that not all issues will necessarily get committed/closed, there will be some triage as I go along and not everything will make the cut for Migrate 2.6 and the corresponding migrate_d2d/wordpress_migrate releases.

1. Bug reports with patches, migrate

Just had to share this major milestone - 10 minutes ago (as I type this, not as I publish it) I performed the first complete^* migration of my Drupal 6 site into my Drupal 8 development environment (running the ui_poc branch of the IMP sandbox, plus a few patches to be submitted/committed). ^* "Complete" meaning all user accounts, nodes, comments, and files (including image references within nodes) were migrated - plenty of details yet to be worked out. Here's a shot from the D8 homepage: Yes, clearly there's a timezone issue to deal with in importing the dates...