Drupal 8 - Improved upgrade process

It is my pride and pleasure to announce that Drupal 8 will ship with a migration path from both Drupal 6 and Drupal 7. This is a first for Drupal, and is quite uncommon for most software projects. We love our elderly Drupal sites, and want them to be reborn as shiny new Drupal 8 sites.

Behind this announcement is a major technical change in how Drupal implements major version upgrades. Drupal traditionally uses its update.php page and hook_update_N() functions to update a database to the next version. With each release, this process became more and more awkward to maintain. We were trying to run Drupal 7 on a Drupal 6 database, without the old APIs that understood the data. In the end, the hook_update_N() system only worked for basic sites. Everyone else had switched over to using Migrate module for major version upgrades. So we bit the bullet and brought migrate module into Drupal 8 core.

Migrate is great as it frees you to build a brand new destination site (Drupal 8, in this case), and configure it to your liking. You are liberated to change your Drupal architecture, building upon the lessons learned while operating a D6/D7 site. You can drop the old modules that aren't working for you, and adopt shiny new ones in D8. Once you have D8 installed and nominally configured, you can start migrating your content and configuration from your source site to your destination site. Drupal 8 provides a basic admin web form for initiating this, or you can initiate the migration via Drush. The web form collects simple details — namely your DB credentials for the D6/D7 site. The Drush approach is more powerful and reliable, as you skip the overhead of the batch system. Furthermore, Drush can migrate only parts of your site (e.g. "the first 30 users") and roll them back as you refine the logic of your upgrade. Best of all, Drupal 8 supports incremental migrations so you can stay live on D6/D7 and keep on migrating added/edited content to Drupal 8 on an every x minutes basis. This near real-time migration gives QA and business folks confidence that their new Drupal 8 site meets requirements and is ready for live traffic. Cutting over to Drupal 8 is as simple as pointing your web traffic to the D8 server. You can then retire your source site after enjoying some tasty beverages.

The D8 Migrate code has been updated for D8 conventions like plugins, the state system, the Entity API, etc. Furthermore, "migrations" are now config entities that are represented as easily editable .yml files. Otherwise, this is the Migrate module many of you have known and loved. Migrate was introduced by Mike Ryan and Moshe Weitzman 5 years ago at Drupalcon D.C.. I'm thrilled to see it finally find a home in Drupal core.

Notes:

  1. Minor version updates are unchanged. Developers continue to use hook_update_N() for those.
  2. Contrib and custom modules are encouraged to ship with migrations of their data from D6/D7 to D8. Use core modules as your model.
  3. The underlying Migrate API is source-agnostic. You can easily migrate into D8 from MS SQL, Oracle, piles of HTML files, XML feeds, CSV files, etc.
  4. Similarly, Drupal 4.x and Drupal 5.x sites are able to migrate using this same approach. Let's collaborate on source plugins for these platforms.
  5. Thanks to MongoDB and Acquia for sponsoring chx and Mike Ryan respectively to work on this project. Thanks to Melissa Anderson who is project managing.

Comments

Posted on by Erich (not verified).

This is the BEST early Christmas present EVER!!! I absolutely cannot wait to start migrating sites!

Posted on by Anonymous (not verified).

D6 and D7 both in 8.0?

There seems to be a lot of ambiguity around when Migrate will actually be usable.

https://twitt er.com/chx/status/411203652427055105

Is Migrate's infrastructure all that's in core at the moment? It sounds like some people are saying that D8 may be released without any upgrade path at all, and Migrate will actually become usable after release.

Posted on by torotil (not verified).

By stating that migrate is _the_ way to upgrade to D8 your basically saying that a direct upgrade from D7 is not supported at all.

Upgrade means: plug in the new code, call some upgrade routine and be done with it.

I don't say that migrate is not a good way to go from D7 to D8 - I think we should just be honest.

Posted on by Marc van Gend.

I think switching to migrate *is* honest. I would rather say that we should have been honest in the past: there was always an upgrade path, but it never lived up to our expectations, forcing us to rebuild and migrate. I'm happy to see migrate become the official upgrade method.

Posted on by Countzero (not verified).

The advertising made me dream, but if the upgrade path involves configuring and using Migrate, it will be perfectly unusable for small businesses/sites. I understand it's good for huge sites with gazillions nodes, who can afford development time for the upgrade process, but if you have many different small sites to upgrade, it won't fit and we'll again be left alone.

Posted on by Ted Benice (not verified).

Contrib (and custom) module maintainers have always been responsible for major upgrade paths but each invented their own mechanism. I think it's great that the core team chose *something* as a recommended standard for migrations complete with examples in core.
We've used migrate many times for D6-D7 and D7-D7 migrations with much success.
I certainly hope that people embrace this.

Posted on by thekenshow (not verified).

Agree with torotil. This is not an upgrade process, it's an acknowledgement that upgrading between major Drupal versions isn't possible. Migrate is awesome but whether or not it's in core, the key point is this: a Drupal site with a significant number of custom and contrib modules/themes is going to take a lot of time & money - relative to the initial design/build - to stay inside the security coverage window.

Posted on by Vincent (not verified).

If I can , I will publish it with your link at http://drupalchina.cn/.
Thanks for your blog and waiting for your replay

Posted on by Ezra Barnett Gi....

Migrate is awesome but whether or not it's in core, the key point is this: a Drupal site with a significant number of custom and contrib modules/themes is going to take a lot of time & money - relative to the initial design/build - to stay inside the security coverage window.

Drupal 7 will continue to be recognized as a supported version of core by the Drupal Security team until Drupal 9 is released, per the Security Team policy.

Posted on by iantresman (not verified).

A migration path from Drupal 6 is very welcome.

I never upgraded to Drupal 7 because the Views D6-2.x to Views D7-3x upgrade path was broken.

Hopefully Drupal 8 will provide migration from Views D6-2.x (the Recommended veresion)

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.