Big news came out of the Drupal Europe conference last week. Drupal 9 will come out in 2020. Support for both Drupal 7 and Drupal 8 will end in 2021. Drupal creator Dries Buytaert reaffirmed what has been a key part of the plan for years: the main difference between 9 and 8 will be upgrades of internal dependencies like Symfony and the removal of deprecated code. Dries ended his post by emphasizing that Drupal 7 site owners now have more clarity around the decision they have faced since Drupal 8 came out: upgrade now or wait?
Many colleges and university web teams have chosen to wait and stay on Drupal 7 for a simple reason. They feel like the benefits of Drupal 8 to their end users (the content editors and site visitors) are not large enough to justify the cost and risk of rebuilding and migrating. It’s entirely possible to for a university to spend a year or more rebuilding functionality in Drupal 8 that they already have in Drupal 7. Even in Drupal 8, it is likely that they will use the "Seven" administrative theme first written in Drupal 7.
The Frontend Forcing Function
Justifying the cost of a rebuild and migration almost certainly means including a public-facing redesign. I have always suspected that one of the hidden drivers of Drupal 7 adoption was that its release roughly coincided with the rise of responsive design. Just as Drupal 7 became a viable option, so did responsive design supplant "m." subdomains as the default way to have one site serve multiple form factors. Doing responsive design well often meant rebuilding an entire site anyway. Many teams decided that they might as well rebuild in Drupal 7.
Drupal 8 has a similar forcing function with the urge to use a decoupled frontend or at least keep Drupal in sync with a static style guide. However, the business case for decoupling now is just not as strong right now as responsive design was in 2012 or 2013. Plenty of university web teams will choose to wait until Drupal 9 is released in 2020 when patterns pairing Drupal with frontend libraries like React are more established.
Rebuild Once or Maybe Twice
University web teams need to be careful about what they call a project that moves from one major version of Drupal to another. For your content editors you may want to refer to it simply as a "redesign" because the public facing visuals will change but their content types and they way they edit fields will basically be the same. But to allocate the budget needed to do the project well, you may need to emphasize that the project is a re-platforming that includes distinctly a rebuild of existing functionality, a migration of data, and a redesign of the public-facing side.
Setting those expectations well is hard. Going to Drupal 8 now and Drupal 9 a year later complicates those expectations. Drupal 8 to Drupal 9 promises to be an "easy upgrade." It should be as easy as the upgrade from 8.5 to 8.6, but I can't blame anyone who wants to avoid explaining internally why 7 to 8 will take a year and 8 to 9 will take a day. I expect many web teams will opt to simply wait to go straight to 9 unless they get a compelling reason to go to 8 now.
Why Upgrade Now?
For all the reasons there are to wait, the Drupal core team is providing plenty of reasons to try out 8 now. Ever since 8.0.0 in 2015 there have been lots of reasons developers would want to switch. In my opinion, the biggest improvement in Drupal 8 developer experience is the reliable, consistent importing and exporting of configuration. Twig template files are a close second for DX wins. Twig files are easier to write than the old PHPTemplate files. More importantly, for universities they are easier to maintain. Drupal 8's codebase was overhauled to use more objects, plugins, and dependency injection. That change caused a lot of angst amongst longtime Drupal developers but I think it has proven to be a change that supports the "ambitious digital experiences" that Drupal has strived toward.
The promise of all of these under-the-hood changes was that they would enable the biggest change of all in Drupal 8: a new release cycle. Minor versions (8.1.0, 8.2.0, etc) have come out every six months adding new features that benefit developers, site builders, content editors, and end-users of Drupal sites. At DrupalCon New Orleans in 2016, my colleague Andrew Taylor and I presented on how such a cycle had greatly helped WordPress serve their users. For Drupal these releases have added features like Settings Tray, Content Moderation, and Layout Builder that all make Drupal Core more powerful for those using the UI.
Just this month we got what long-time Drupal Core contributor Gábor Hojtsy calls "The most significant update to Drupal 8 in its history". 8.6.0 contains a number of enhancements that will be especially beneficial to higher ed.
Drupal Core now includes the option to install a fully built demonstration website. Installing Umami can help you persuade stakeholders and provide a reference for building in D8.
Drupal 7 to Drupal 8 migrations can now be done directly from the the user interface in 8.6.0. While migrations have been possible for a long time, this change will lower the level of effort to experimenting with and reconfiguring migrations.
8.6.0 also has a number of experimental modules that show how Drupal Core can incorporate some of the best ideas from contrib modules.
8.6.0 has oEmbed support allowing remote media like YouTube videos to be added to a media library.
The Workspaces module allows you to work on lots of content changes at once without making them public. Those changes can be previewed throughout the site by content administrators and made live all at once.
Layout functionality pioneered in contrib modules like Display Suite and Panelizer is now in core with a unified API.
I have written so far under the assumption that sites on Drupal 7 will be moving to 8 or 9 eventually. That is not the case for everyone. WordPress continues to rise in popularity across the web and especially so in higher education for nearly all the same reasons Drupal has traction there. Some universities will also consider Backdrop, a fork of Drupal that essentially offers many of the same enhancements as Drupal 8 with a smoother migration path because of an architecture that is essentially the same as Drupal 7. If you have content editors asking for WordPress or administrators wanting to keep the cost of moving low, you should investigate these options.
That said, I still think most teams on Drupal 7 will get to 8 or 9. My last piece of advice for those teams is to start small. Experiment first with a low-risk site. I’ve had many conversations in my time at Pantheon with higher education teams managing a large fleet of Drupal 7 sites or one very complex Domain Access/Organic Groups/Multisite site who are operating under the assumption that they need to move everything at once.
Try one simple site in Drupal 8 before moving 10, 100, or 1000 sites. On Pantheon you can spin up a Drupal 8 sandbox without swiping a credit card. Getting your hands dirty with configuration management and Composer for one or two sites will greatly inform how you do the rest. Then when you’re ready to move the fleet, let us know if you need some help.
You may also like:
[Blog] Drupal 8 File Migrations
[Webinar] Is Drupal Right for Universities?