Accueil / Permalien du commentaire

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.


  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.


Posted on by Erich (non vérifié).

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

Posted on by Anonymous (non vérifié).

D6 and D7 both in 8.0?

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


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 (non vérifié).

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 (non vérifié).

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 (non vérifié).

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 (non vérifié).

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 (non vérifié).

If I can , I will publish it with your link at
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 (non vérifié).

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)

Posted on by Martin Williams (non vérifié).

I've been looking at info re upgrading from Drupal 6 for some time. I'd done D5 to D6 without too much grief; but now looks a whole lot scarier, including to Drupal 8.
My impression is that this is because of Drupal leaving behind a "hobbyist" [rather than hardcore developer n enterprise clients] user base. Nice Drupal is taking off like this; too bad if leaving people behind.

Even now, on homepage, I see: "Why Choose Drupal?
Use Drupal to build everything from personal blogs to enterprise applications. Thousands of add-on modules and designs let you build any site you can imagine. Join us!"
- still looks to appeal to people like me, who may have lots of content to put online, but are hardly developers.
If you are intent on leaving such people behind, maybe indicate more clearly on homepage; not fair to sucker people into building a site that later proves a huge headache as Drupal leaps ahead [either upgrade, or be left without security checks].

If not, well, I hope more effort can go into this migrate venture, which seems laudable but still not enticing, still scary!

Ajouter un commentaire

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

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.
  • Pour publier des morceaux de code, entourez-les avec les balises <code>...</code>. Pour du PHP, utilisez. <?php ... ?>, ce qui va colorier le code en fonction de sa syntaxe.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
By submitting this form, you accept the Mollom privacy policy.