Should You Upgrade to Drupal 8?
Drupal 8 has been out for quite a while now, and although it represents a major shift in architecture and signals the eventual phasing out of Drupal 7, we’ve seen a hesitance to adopt it.
UPDATE: You can find a newer post on the subject of Drupal 9 and the end of life for Drupal 7 + 8 here.
Here, I’ve laid out some honest answers to how a Drupal 8 upgrade might affect you.
As a Developer, What Do I Gain?
In my opinion, the case for Drupal 8 is strongest from the point of view of the developer.
Drupal has obviously established itself as an enterprise-class CMS, but under the hood, the architecture and coding practices are more suited to PHP tinkerers than true software engineers. Spaghetti PHP, mostly procedural code, and config-in-the-database meant that Drupal just didn’t feel like the kind of system you’d expect to work on as a developer in 2017.
Drupal 8 represents a fundamental rethinking of Drupal’s architecture, and although it was and continues to be contentious, the shift toward object orientation, Twig-based templates, config-in-files, and a host of other changes make it something that can attract and maintain the attention of more seasoned developers. Combine it with PHP 7, and you’ve got an architecture and development framework that feels much more contemporary than anything Drupal 7 could hope to offer.
As a System Administrator, What Do I Gain?
The most obvious answer to what Drupal 8 offers the system admins/IT folks is futureproofing. Drupal 7 will eventually go the way of Drupal 6, left like an Apollo service module to float into space — appreciated, but no longer needed (or supported). You’re going to have to upgrade at some point, and planning for that upgrade can’t happen soon enough.
Drupal 8 should also offer you the ability to implement a more well-governed devops workflow: the move from config-in-the-database to config-in-files makes versioning, staging, and feature updates much more practical. That said, your developers will still need to make use of those features for them to be valuable to you. Make sure they’re using the config exporter and the Features module and that they’re being smart about compartmentalizing their code. Otherwise, you’re in for the same Drupal 7-style devops workflow: “keep a text document that lists the steps, and repeat the changes in both databases on deployment.”
As a Content Manager, What Do I Gain?
As a content manager, Drupal 8 probably won’t feel like a drastically different world. It uses CKEditor for editing body copy, which is probably the same editor you’re already using in Drupal 7. Probably the most compelling content management modules that you’re not using — Quickedit and Paragraphs — are also available for Drupal 7, so you can get this “new” functionality without upgrading to Drupal 8.
Drupal 8 uses almost all of the same terms you’re used to: content types, nodes, taxonomy, views, etc., which means you won’t have to retrain yourself on how to manage content. However, it also means that from your perspective, it’s hard to make the case that you simply must upgrade to Drupal 8 as soon as possible.
As a content manager, one of the most important things for you to know about upgrading is this: Drupal is really a collection of modules, and your site’s administrative back end is the product of how all of those modules are configured to interact with one another. If you have complaints about your Drupal 7 back end, just upgrading to Drupal 8 probably won’t solve them. Rather, you should also outline the specific problems you have and review them with your developer. There are likely solutions for your issues in Drupal 7, even if there are potentially better solutions in Drupal 8. In any case, when you do take the Drupal 8 plunge, don’t assume that your problems will be solved by the upgrade. Make sure your developer knows your specific pain points and works with you to address them.
What About the End User?
Because Drupal is so flexible, the end user’s experience will depend heavily on how well crafted and intuitive the front end of your website is. That said, Drupal 8 brings with it a host of performance improvements, especially when teamed up with PHP 7 (the latest version of Drupal’s underlying programming language). So you can expect a lot less sluggishness when serving pages. Additionally, Drupal 8 plays very will with a lot of the modern front-end frameworks (e.g., AngularJS, React), so your developers have a lot of freedom in how they craft the design and user experience.
Are the Modules I Need Ready for Prime Time?
We’ve been keeping track of this pretty closely, and while I would’ve said “maybe” a few months ago, I feel good as of this writing about most of the modules you’re likely to need. Feeds is still in beta but the Migrate module (now in core) should accommodate most of your needs for moving data around. The wonderful YAML Form module has replaced (and been renamed to) Webform. Workbench is still in alpha, which is a bit scary, but not all sites require it.
For the most part, you should have the modules you need to create even a fairly complex site without needing to custom code workarounds.
Will the Upgrade Be Easy This Time?
Probably not. A lot has changed in Drupal 8, and the upgrade paths aren’t always clear. If you’ve got a Drupal site that consists of only a small set of very common modules, it will be easier for you, but plan for some complexity. Also, the theme engine has changed drastically, so you’ll have some work to do if you want to convert custom templates to Twig (assuming you’re not using an out-of-the-box theme). Plan early for your upgrade and don’t underestimate the effort.
