Search form

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.

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.

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.

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.

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.

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.

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.

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!

Plain text

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.