Drupal 8 Community Support is Ending: Now What?

According to the official statistics, there are nearly a quarter million websites running Drupal 8. With today’s official end-of-life date, a lot of people out there may be feeling a little nervous. We have quite a number of customers who are in this position, so I wanted to take a moment to provide some advice to everyone who is operating a Drupal 8 website today.

Don’t Panic - Make a Plan

The first thing to do is to put yourself in a proactive frame of mind. If you’re reactive, you’re more likely to rush either the up-front thinking or the implementation, and that leads to mistakes. A rational risk assessment will tell you that while yes, you should prioritize moving off end-of-life (EOL) software as a best practice, there’s no clear and present danger to these sites. There’s no need to panic.

With hundreds of thousands of sites running for close to a decade, Drupal 8 has seen a lot of “burn in.” Drupal 8 has not added new features since 8.9.0 was released, along with Drupal 9 in June of 2020. so the likelihood of net new security regressions entering the codebase is low. 

Pantheon will continue to support Drupal 8 sites as long as necessary. As always, you own the code, so the timing of your upgrade is under your control. We will also continue to operate with the same high-security platform environment (immutable code deployments, all sites behind a global edge layer that can layer in Drupal Steward protection, etc). That said, you should make a plan if you don’t have one. You’ll feel a lot better once you have a timeline.

Plan A: Standard Upgrade to Drupal 9

This should probably be the default option for most users of Drupal 8 who have kept up with the point releases along the way. If you’re running 8.9.x now, the upgrade to 9 should be relatively simple. Check out our documentation on Drupal 8 to 9 upgrades for details.

In the best case, it’s a clean update with no changes required. A few hours of work for a developer. For sites that are highly customized or complex, you will still want to do a solid QA pass, and it’s likely at least a few things will need fixing, but nothing at all like past Drupal version upgrades, which were really a complete rebuild.

Much like the rest of the web, the Drupal project has left the notion that “you totally rebuild and relaunch your website every few years” in the rear-view window, and that’s great. As more point releases come and go, the quality of backwards-compatibility will continue to improve, and we expect the future Drupal 9 to 10 upgrade process (starting next summer) to be even smoother.

But let’s be real, there are also a lot of sites (about 80,000, again, according to drupal.org statistics) that are still on older versions of Drupal 8. Many of them are probably stuck because of some dependency, or may have major issues blocking them from upgrading. For these customers, it’s worth considering other options.

Plan B: Go Static?

It’s a little bit of a wildcard, but there are a lot of sites out there that are effectively static. If this describes your use-case, embracing that — even as an interim step to buy time for a bigger re-think — is something that should be on the table. It obviously isn’t an option for everyone, but for customers who are not actively posting new content, and who don’t take inbound information through their site, conversion to a static site is a fast way to secure the site and keep it online indefinitely.

There’s a community project called Tome that has gotten some good buzz, which aims to let you use Drupal like you would a static site generator. You can install it on an existing site and then run it locally and push the results up to Pantheon (flat HTML works fine). This has the benefit of still giving you a path to run Drupal to make updates, though as with any contrib module, your mileage may vary and it might not work out of the box for every site.

Of course, you can also use standard web spidering techniques like using wget to archive the site. The result is more of a one-time snapshot, but for sites that are effectively static already, this might not be a problem.

Time for a Rebuild

In the case where you have a dynamic site, but there’s no smooth Drupal 9 upgrade path, you’re looking at some amount of rebuilding. Particularly, if the site was built by a team that’s no longer available and you’re looking at some amount of engineering onramp or shopping for a new agency partner, my advice is to take a beat and reassess your needs before forging ahead.

If you’re happy with your website but custom code or contrib dependencies are blocking the easy path forward, getting to D9 “the hard way” might still be the best decision. This lets you reuse existing assets, keeps the external site visitor UX the same, and minimizes change for content editors. You might sneak in a few improvements along the way, but this is the path for continuity, and is probably the least work overall.

On the other hand, if your website and your business strategy are out of sync, or your current site leaves much to be desired, this might be the moment to fix that. If so, you should do some strategic discovery work and look at all your options. Start with the “why” before digging into the tech.

For sites that are all about publishing, and where editorial productivity is important, you should absolutely consider WordPress. It’s come a long way over the past six years, and there’s a reason it’s running over a third of all websites. If you’ve never taken it seriously, we have a good unbiased WordPress vs Drupal comparison.

If you’re really prioritizing the end-user experience, you might want to consider a “front-end first” approach using a JavaScript framework like NextJS. This requires a decoupled architecture, which adds complexity and risk, but you might find that you can get to Drupal 9 much more easily if you drop all the front-end requirements.

However, you will still need to figure out how your content goes out over an API, and how to manage the complexity of running two different applications for both front- and back-end. This is definitely a more technically challenging path, with best practices just emerging. If there’s a solid business case for this then it can be a good long-term investment, but be careful of chasing technology for its own sake; that rarely ends well. We’re helping customers find their way through this approach today, and you can learn more about our early access programs.

The Open Web is Evolving - But Some Classics Are Timeless

It’s exciting to see the web evolving, and I’m looking forward to doing more to support static sites and JavaScript front-ends, helping more customers tame the WebOps complexity that comes with decoupling. But we’re here to support your whole portfolio, wherever you’re at.

For example, there are nearly twice as many sites still running strong on Drupal 7 as ever made the leap to Drupal 8. If that’s you, just know we’ve got your back. We will be providing one-click updates and Autopilot support for sites that want to stick with Drupal 7 for the long-haul, beyond even the 2022 end-of-life date.

I fully anticipate that some of these sites are in the “ain’t broke, don’t fix it” camp and will continue running Drupal 7 for several more years. It’s just a great CMS.

But for those who are running Drupal 7 and thinking “what’s next,” the rebuild section above applies just as well, with the caveat that there’s so much difference between versions 7 and 9 — that you should put Drupal on a level playing field with every other option. As always, we’re here to help you think it through.