D7 & D8 End of Life (EOL): What Does It Mean, What Are My Options?

[00:00:05] Let's get started, and thank you all for joining us for our talk on Drupal 7 and Drupal 8 end of life. My name is Michael Meyers. I've been working with Drupal for a little over sixteen years. I founded the first venture-backed Drupal-based startup, with the CTO of the first top-50 Drupal website, and I've spent a lot of time trying to get enterprises to collaborate and fund Drupal and other open source development.

[00:00:57] I'm joined by Jeremy Andrews, who's been working with Drupal for nineteen years, since the very beginning, and is one of the very few people who have contributed to Drupal core for every major version. Outside Drupal he is the author and maintainer of Goose, the most scalable load-testing framework available, written in Rust and of course open source, and his background is in Unix kernel hacking and firewall development. For those not familiar with Tag1, we work with a lot of technologies outside Drupal, but we're best known for being the number two all-time contributor to Drupal, with more core committers, framework managers, and subsystem maintainers than any other organization. We're one of two providers currently offering Drupal 6 long-term support, and we've been approved to provide Drupal 7 extended support.

[00:02:12] We're also a Platinum sponsor of DrupalCon, a supporting partner of the Drupal Association, and we donate a full-time resource to help maintain the project's infrastructure, tooling, and websites. I want to make a plea: if you make a living or a profit, in whole or in part, from your association with Drupal, please donate to the Drupal Association and help support the project so it can continue to thrive.

[00:02:51] Today we'll cover what Drupal end of life means, when it's going to happen, and how things differ between Drupal 7 and 8, why widely used versions are being retired, the practical implications for you and your sites, what Drupal vendor extended support is and how it works, and why it only covers Drupal 7 and not 8. Please put your questions in the chat and we'll answer them at the end.

[00:03:34] Let's start with what end of life is. It takes a lot to create and support a version of Drupal core: formal roadmaps and releases, strict guidelines and processes, and enforcement by both people and technology. On the technology front there's in-depth automated quality assurance testing. To give you a sense of the scale, the Drupal automated QA system does over 90,000 hours of testing in a single year, the equivalent of ten years of work in parallel every year. It's a big part of the acceleration of Drupal development and enterprise adoption, and it's expensive to run and takes people to maintain, just as development does.

[00:04:54] So let's talk about end of life. Simply put, all the things I just described are going away. The Drupal community will no longer support or work on Drupal 7 and 8. Core development stops entirely; in fact the issue queues where Drupal 7 and 8 development happens will be locked, so you won't be able to post changes to core on Drupal.org. When Drupal 6 went end of life, the Drupal 6 contrib space was not locked, and people were free to keep developing, and we expect the same for 7 and 8. But to set expectations, almost no development happened in the Drupal 6 contrib branch, and a lot of maintainers closed their branches because they didn't want to be inundated with support requests.

[00:06:17] The testing infrastructure will most likely be decommissioned for Drupal 7, given the costs, though there hasn't been a final decision. Without a free, shared community testing infrastructure, module development is hampered. Individuals can run the core test suite locally, but without that infrastructure most people don't have automated tooling in place, so testing likely won't be enforced. Less testing leads to buggy code, regressions of past problems, and so on.

[00:07:22] Complicating things further, there will be no security team participation in Drupal 7 and 8. All the security reviews, updates, and announcements will stop. Any new vulnerabilities found in current versions like Drupal 9 and 10 have a high likelihood of also affecting Drupal 7 and 8, as we've seen with Drupal 6. These will be known vulnerabilities with no official patches from the Drupal security team, so your site will be open to them. It doesn't take an expert hacker; there are tools that fingerprint Drupal websites and automate attacks against known vulnerabilities. If you don't maintain versions that are end of life, it's not a matter of if you'll get hacked so much as when.

[00:08:21] Lastly, dependencies are an issue. Drupal 7 has a few, like PHP, and Drupal 8 has a lot. The current version of PHP that Drupal supports is also going to go end of life, and the community won't be providing PHP security patches. It doesn't matter how up to date you keep Drupal if PHP is insecure and out of date. It's possible to update Drupal to support newer versions of PHP, and we have done it, but it's non-trivial and out of reach for most organizations.

[00:09:05] So when will Drupal 7 and 8 reach end of life? Historically, the policy up to Drupal 7 was to maintain two major versions at any one time, so Drupal 7 should have gone end of life last month when Drupal 9 was released. But there was a stay of execution, extending it to November 2021, given the large user base. Then, given the cost of migrations and the impact of COVID-19 on organizations, it was recently announced that end of life would be extended again to November 2022, almost two and a half years from today, hopefully giving you plenty of time to manage your path forward.

[00:10:03] Things are different for Drupal 8. As of Drupal 8, we changed the policy for how we support legacy versions, because Drupal 8 was the first version based on a large number of dependencies like Symfony, Guzzle, and Twig. Symfony 3, which Drupal 8 depends on, is going end of life and will stop receiving security patches in November 2021. That makes it extremely difficult for Drupal to stay on Symfony 3. Also, Drupal 9 is essentially Drupal 8 with some code removed and a little added, so the upgrade path should be relatively easy. Given the dependencies, Drupal 8 will still go end of life in November 2021 as planned.

[00:10:35] Why are heavily used versions being retired? Drupal 7 is the most popular version ever; there are probably more people using it than all other versions combined. So why cut it off? Drupal 7 is almost ten years old now, and by end of life it will be twelve years old as a release, and development started years before that. That's an impressive lifespan for technology. Simply put, the community doesn't have the bandwidth to do Drupal 9 and 10 while also supporting 7 and 8. People aren't paying for Drupal 7 and 8 support; it's free software, and statistically almost nobody here is being paid to work on Drupal, paying someone to, or financially supporting Drupal development in a substantial way.

[00:12:52] The people who are paid are being paid to upgrade to Drupal 9 and work on the future. Individuals just don't have the interest in working on a legacy platform that's ten-plus years old; core contributors are great developers who need to keep their skills sharp on modern technology. Frankly, it's what's best for Drupal, even if it isn't best for individual users of legacy platforms. Drupal has grown over twenty years because it continually innovates and launches new releases, and if we want it around for another twenty years, the community needs to focus on the future.

[00:13:46] The situation for Drupal 8 is entirely different. There was a philosophical shift in Drupal 8 development: historically we did almost everything ourselves, and the goal was to get off our self-contained island by integrating other systems. That added a lot of great functionality, but those dependencies are going end of life, and forking and supporting new versions is challenging. The best approach is to upgrade Drupal to support new versions, going from Symfony 3 to Symfony 4. Another change was semantic versioning: when you make core API changes, you have to release a new major version, and upgrading dependencies like Symfony 3 to 4 is very likely to involve those changes. Hence Drupal 8 becomes Drupal 9. If you've kept up, upgrading should be pretty easy, because 9 is 8.

[00:15:31] So what are your options? With Drupal 7 you have two and a half years and many options, some high cost and some low cost. The obvious one is to do absolutely nothing, and I'm shocked at how many organizations offer this approach, but please do not do it. The costs and risks are extremely high. Choose one of the other options: you can migrate to Drupal 9, or migrate to another CMS platform or framework. The effort to migrate is substantial regardless of direction, so plan for training your teams on new technologies and potential new resources. It takes planning from a technology, organizational, and resourcing standpoint.

[00:16:43] There are low-cost options too. You could kill the website and shut it down if you don't need it anymore. You could crawl the site, make it static, and archive it, keeping the static version available. But probably the best option, and what we're talking about today, is leveraging what's been made available for Drupal 7 extended support, D7ES. Extended support is not new. It was originally launched as Drupal 6 long-term support when Drupal 6 went end of life, first introduced in 2016, and two companies are currently approved and providing it.

[00:17:48] At Tag1 we offer a product called Tag1 Quo, a SaaS product rather than services, that enables you to run and use Drupal 6. We've proven this model with many years of experience, so we're in a good place as a community to offer it for Drupal 7. It's been a huge success: tens of thousands of organizations are still running Drupal 6 and benefiting from long-term support, and we still have customers signing up. Originally Drupal 6 long-term support was promised for a year, then extended three years, and given continued demand, both My Droplet Wizard and Tag1 have committed to providing it indefinitely, at least another two years with no end date in sight. If there's enough commercial demand and it's technically feasible, it will be provided.

[00:19:12] What is Drupal extended support? There's a core option that everyone must provide, and services that vendors can offer on top. The core of Drupal 7 vendor extended support is security. Approved vendors must provide a minimum set of services: tested security patches. If there's a security update needed for Drupal 7, like a bug backported down from Drupal 9, or an end user reports a bug, extended support vendors will fix it. The same is true with specific contributed modules. There isn't a list identified yet, but there will be one before the end-of-life date, probably a small list of the most popular contributed modules. Note that security teams and vendors typically don't proactively scan legacy versions; it's based on what's reported and what we discover.

[00:20:43] Vendors must also commit to providing Drupal 7 extended support for at least three years, to give you confidence it's worthwhile. And a really exciting thing: if you're an extended support vendor, you have to commit to releasing all of your patches as open source, and this isn't limited to the core offering. If a customer comes to Tag1 with a development request or a bug fix on a contributed module outside that specific list, we're obligated to release that fix as open source. That's an awesome commitment that will benefit users of Drupal 7 during long-term support.

[00:21:37] If all these patches are available as open source for free, why would you pay for extended support? The reality is you don't have to, just like you don't have to pay for Drupal. You can monitor the vendor updates, which must be posted to the Drupal 7 extended support issue queue on Drupal.org, and vendors will maintain a public repository linked from the extended support vendor pages. You have access to all these patches and can update your sites yourself. But I implore you: supporting vendors matters, and there are inexpensive options. When there were three vendors approved for Drupal 6, it wasn't commercially viable for one large organization, so they dropped out. Expect that if people don't support Drupal 7 extended support.

[00:23:00] Vendors are also going to offer enhanced services you'll need or want, so it's up to us to provide compelling value. We're not looking for your goodwill, though it would be nice; we're going to make it worth your while. Beyond the minimum list, one of the biggest benefits is tools that monitor your sites, alert you to updates, and even apply patches for you, so there can be a full-service model. We'll continue to offer Drupal 7 services, enhancements to core and contrib, and help with your code, which becomes more important over time. Think about Drupal 6: there aren't many developers meaningfully involved anymore, so if you need help you really depend on an extended support vendor.

[00:24:16] We'll help with your proprietary code too, which comes into play particularly when we upgrade Drupal to support a new version of PHP, where changes are needed to contrib modules and proprietary code. Sometimes hosting companies will no longer support a legacy version of Drupal, and companies come to us for help migrating to a host that does. On top of this, vendors provide tools and capabilities: Tag1 Quo offers a rich interactive dashboard, so if you have many Drupal sites you get insight and management to see what's up to date and where to put work. It comes down to basic economics: if there's demand and money behind it, you'll find vendors that want to support it.

[00:25:54] How do you trust that your extended support vendor is qualified? Official vendors are vetted through an application process by the Drupal security team and the Drupal Association, which approves only a limited set. This list will be publicly posted before the end-of-life date. Organizations need real qualifications and a commitment to the community. First, your organization must have at least one person meaningfully engaged in the Drupal security team, reviewed by that team to ensure they're doing great work, so you can be assured they are security experts. It's also critical that they participate in Drupal core, with a public demonstration of issue queue work.

[00:27:24] You simply aren't in a position to provide extended support for a platform if you aren't meaningfully engaged in its development. You also have to honor your commitment: you're committing to do this for three years, and if you aren't contributing to building the patches, you'll get kicked out of the program. Vendors are expected to contribute so no one company takes on the whole burden. It's important to have a lot of eyes on the code and a competitive marketplace, so you have options and can pick the best vendor for you.

[00:28:00] How does it work in practice? Where do you get your patches once the issue queues are locked? For a version under active development like Drupal 9, you go to Drupal.org and the issue queues. With extended support, vendors are obligated to commit their modules and patches to the extended support issue queue on Drupal.org, which is a running conversation and can be hard to follow, so their public repositories are probably the best place to look because they're well organized. And if you're using their services, they provide alerts.

[00:28:54] Another important thing: vendors can have their own naming conventions. Drupal 7 and 8 have formal versioning policies, but that goes out the window with extended support. If the last release before end of life is 7.75, a vendor can do 7.75.1.2 or 7.76, whatever they want. That means if one vendor is on 7.9 and another on 7.10.3, there's no comparison; the higher number doesn't mean more up to date. Because of this, vendor updates are not compatible with each other, since one vendor may support contributed modules another doesn't. You can switch from one vendor to another, but it requires some lifting, so it's a good idea to vet your vendors and pick a great one.

[00:31:11] Vendors can also choose how they deliver updates, whether automatic notifications, pull requests, or emails, and there's no formal release schedule outside of security releases. When a Drupal 9 version has a critical security vulnerability, you're normally alerted as part of the security team services, but that won't happen for end-of-life versions, so it's up to you to monitor the issue queue or work with a vendor to notify you. And you have to be on the last release of Drupal 7 before end of life to apply any extended support patches, because they assume you're on that version. So the first thing you need to do is upgrade to that. I assume you're all keeping your sites up to date, so that's not a problem for anybody, right?

[00:32:37] Drupal 7 has to follow the same security policies as any version, and this is important: security team members are not allowed to communicate or discuss known vulnerabilities under development before release, and violating that results in termination from the security team and, for an extended support vendor, probably being kicked out of the program. A hole in Drupal 7 could impact 9 and vice versa, so the security team has to be able to work on and release these things so the whole community is protected.

[00:33:22] Even though extended support vendors are involved in creating these fixes, we can't release any updates to you until the official security release happens. We're well poised because we're involved in the process and ready to pounce as soon as they're released, but you will not receive advanced notification or patches; you'll get them at the same time as everyone else in the community. Extended releases and security patches will come out either at the same time as the official release or shortly thereafter, and with Drupal 6 we've done a great job maintaining that, so you're in a good position to remain secure.

[00:34:23] Is there really not going to be Drupal 8 vendor extended support? For any number of reasons, not everyone will upgrade from Drupal 8 to 9, and that's a problem. I want to beat this home: there is no officially sanctioned or approved Drupal 8 extended support. That said, nothing stops any vendor from offering it; it just isn't official, and given the security concerns, be wary of a vendor offering unvetted extended support. Think back to the dependencies. If you want to keep Symfony 3 running with Drupal 8, you have to fork it and maintain security patches. If you're not an expert in Guzzle, Symfony, Twig, and all these dependencies, you're not positioned to keep it secure, and I doubt many vendors are experts in all of them.

[00:35:49] It's possible vendors could offer Drupal 8 support if, say, Symfony had a vendor providing extended support and there were a partnership, but it's unlikely. You really can't and shouldn't plan on it. You should be investing in upgrading to Drupal 9; you have over a year. Please do not plan on or assume there will be a Drupal 8 extended support program. Focus on getting to Drupal 9.

[00:36:32] To wrap up: Drupal 7 is an awesome platform that will continue to meet the needs of many organizations for a long time. Migrations are costly, and it may make a lot of sense to stay on Drupal 7. If 7 is anything like 6, and this is my personal guess, you'll see hundreds of thousands of sites on Drupal 7 after end of life, which means a strong, vibrant, and robust economy of users and vendors providing support. You'll be able to run Drupal 7 for five to seven years after end of life. You are not being forced to upgrade if it meets your needs; this should be a business decision. And don't let Drupal 8 end of life scare you, because Drupal 9 really is Drupal 8 with some deprecated code and a few features removed.

[00:38:03] If you've kept up with the minor releases, upgrading to Drupal 9 should be easy, and the same will be true of Drupal 10. Just yesterday Dries announced Drupal 10 will be released in June 2022, two years away, so you'll see much more frequent and faster releases because of the semantic versioning change and keeping up with dependencies. Please keep up with the minor version releases; you should be keeping your site up to date and secure anyway, and if you do, migrating from 8 to 9 and 9 to 10 should be a relatively easy process. Let's hop into questions.

[00:38:49] Stephen said it seems like a lot of security updates in the Drupal 6 long-term support were backported from Drupal 7, and asked how Drupal 7 extended support will discover security holes. The entire purpose of the vendor program is exactly that. Once we're aware of a security issue, the question is whether it affects an earlier version, and the last four and a half years have been spent doing that for Drupal 6. We've backported fixes from Drupal 8 to Drupal 6 already, so it's absolutely possible.

[00:39:49] Pooja asked whether you have to be associated with a single vendor. You do not; the patches are all open source, and individual vendors maintain their patches publicly, so you can switch, though it can add complexity because of how things are versioned. On pricing, what I can tell you is that our product Quo starts at $150 a month for Drupal 6 and it will be no more than that, and we're looking at ways to bring the price down. Every vendor will publish their own pricing.

[00:40:18] Dory mentioned this seems like a black eye for the open source model. I think it's the converse. If you look at Michael's slides, he did a good job explaining why, after twelve years, it's difficult for the community to support a very old release. It's actually fantastic that it's possible to stay on something after twelve years for another five-plus years and have the support you need, guaranteed to be there as open source even if you don't pay for it. To me that's quite impressive.

[00:41:22] Duncan noted there are around 672,000 sites running Drupal 7, which is seventy percent more than 8 and 9, and asked whether stopping support could be a problem for Drupal as a secure framework. We're not stopping support; we're continuing to offer it for another five to seven years, so I don't think that's a problem. Anthony asked whether it's possible to migrate from Drupal 8 to Drupal 10 along with modules. Yes, though it's easier to go with each release, because every step from 8.1 to 8.2 and so on becomes bigger. Taking the step more frequently is easier than a larger jump from 8 to 10, but it's definitely possible and well documented.

[00:42:28] Stephen asked what we recommend sites running Drupal 7 extended support do for contrib modules not covered by extended support. With Drupal 6 extended support, we cover contrib and core, and our plan is to do exactly what we've done with Quo: if any paying customer has a contrib module with a security vulnerability we find, we'll provide a patch, as long as they're using the latest official release. So vendors will provide support for not just core but also contrib.

[00:43:17] Someone asked how the contract works and whether it's annual. That's vendor by vendor. Quo is month by month with no commitment whatsoever, and we'll even give you a free month or more of support to try it out. I imagine other vendors will be competitive with the same concepts. To flip it around, we do have customers who want annual contracts, and we're happy to sign annual or even two-year contracts if that's necessary for your needs. With the monthly contract it's month to month, you can terminate any time, and other vendors are similar. We follow the open source ethos; you shouldn't be locked in.

[00:44:33] Thank you all so much for hanging with us and participating. If you have additional questions, feel free to reach out to Jeremy or me. The vendors have not all been announced yet, because it's still two and a half years away, so that will be finalized over the next two and a half years. Thanks, everyone.