Drupal 9 was recently released, Drupal 8 will reach end-of-life November 2021, and Drupal 7’s life will expire in November 2022 (the date was extended due to COVID-19). With a window of a little under a year and a half to upgrade from 7 to 9, it's time to make a plan, or pursue other options if that timeline isn't viable. But what other options are there?
Migrate Drupal 7 to another CMS
Drupal 8 and Drupal 9 aren't the only migration options to get sites off a no-longer-supported Drupal 7. Another option is to move to a different CMS before Drupal 7 reaches end-of-life.
One possibility is to switch to Backdrop CMS. Backdrop CMS is a fork of Drupal 7, which offers a built-in upgrade path for Drupal 7 sites. That means migrating to it from Drupal 7 should be relatively easy. While there are some changes in the way things work in Backdrop CMS, it should be a familiar option for longtime Drupal 7 developers.
While Drupal has been making strides in the enterprise space and working to deliver content through multiple channels(e.g. mobile apps, marketing platforms, decoupled backends), Backdrop targets smaller budget projects that are primarily concerned with websites that deliver content through traditional HTML pages.
For users looking to buy time before upgrading to Drupal 9, Backdrop may not be the right solution because it's intended to be a permanent alternative to Drupal. While Drupal 7 and Backdrop are very similar, there currently no migration path available to move from Backdrop to Drupal 9.
There are other CMS options out there, but few provide an automatic or easy migration path from Drupal 7. WordPress offers migration plugins to expedite the move from Drupal 7, but the mental paradigms don't map directly, and developing for WordPress involves a learning curve for longtime Drupal developers. The difficulty of a transition to any other CMS will vary depending on the complexity of your Drupal site and the solution you choose, but most will probably require some time and effort to migrate existing Drupal 7 data into a new destination.
Build a custom CMS
Another option is to build and migrate to a completely custom CMS. We’ve seen industries, for instance, the media industry, decide to develop proprietary CMS solutions that address their unique needs and demands.
Building and maintaining a custom CMS is a huge commitment of time and money: the cost is higher, development is slower, and security is more likely to suffer. The result may be weird legacy paradigms and mounting technical debt as the number of years in a custom platform increases. There is no direct path to migrate from Drupal 7 to a custom CMS, so migrations will be custom. In some cases, the move will entail disposing of legacy content and data entirely and starting over because the complexity of migrating content is substantial.
Time will tell whether businesses will continue to invest in maintaining and developing these custom CMS platforms, or whether they'll return to mainstream platforms like Drupal 9. Generally, though, the cost of building and maintaining a secure, scalable, robust custom solution will likely dwarf the cost of building with Drupal, even a highly customized Drupal site.
Retire a Drupal 7 website
Another solution is to convert some or all of the existing Drupal 7 website to a static site to eliminate the need to maintain it. For a deeper dive into the technical details of transforming a dynamic Drupal site into a static site, check out Sending a Drupal Site Into Retirement.
Event sites for events that have passed may be good candidates for retirement. Organizations that want to retain historical event information and session summaries, but no longer want to actively support or make updates to these sites, may find that converting them to static sites is a good option.
Another case for converting a site to a static site includes retiring a site that is infrequently or never updated, where the site maintenance costs more than the value of the site. This would be a good fit for an old sub-section of a site that won't be updated anymore or a department that has been closed or doesn't need to provide new information.
Start with a clean slate
For organizations with a lot of custom code, organizations that are doing a big redesign, or organizations that are dramatically changing their information architecture, starting an entirely new version of the site with a clean slate is a good option. Starting fresh is particularly helpful for organizations who want to clean up, rewrite, or remove old content anyway.
If there is a desire to maintain some of the old site content as an archive or for historical purposes, some old material could be preserved as a static site as described above, while creating new content in a fresh install.
Stay on Drupal 7 with an Extended Support agreement
Organizations that are unable to upgrade to Drupal 9 before Drupal 7 reaches the end-of-life deadline should consider an Extended Support (ES) agreement. The Drupal 7 ES program involves partnering with a Drupal Association-vetted vendor, assures that the vendor coordinates responsible disclosure of security issues and fixes, and ensures that the work toward fixes is shared publicly. While the bug and security fixes that Drupal 7 ES vendors create are released to the public so non-customers can apply them, there are advantages to being a customer of a D7ES vendor. Those benefits will vary by vendor but include, for example: prioritizing the fixes a customer needs, applying the public fixes, performing usual site maintenance, providing custom development, helping with critical site outages, etc.
While this solution is an excellent short-term option — in fact, it's probably the best option for organizations that don't have the budget to complete a large migration project at this time — it’s not a long-term solution. The Drupal 7 ES program is projected to run for three years, so enterprises must migrate or move to another platform by November 2025.
The ongoing cost associated with Drupal 7 life support is a maintenance cost, unlike development work that might get amortized over the years for a replatforming. However, it's a necessary cost in today's world where organizations can't afford to be without security updates, and using a platform without security support is actually against many enterprise security policies.
Use Drupal 7 without support
Finally, it is theoretically possible for organizations to continue to use Drupal 7 after end-of-life without an ES agreement. Drupal 7 won't instantaneously break when that fateful day in November 2022 arrives. However, the fact that Drupal 7 is already getting less community support as attention shifts to Drupal 8 and Drupal 9 means it's already falling behind as a platform. As a CMS designed in 2011, it's not optimized to deal with the changes in site usage and the internet in general that have taken place in the last decade. In short, it's not an ideal CMS platform to tackle the next decade.
More critically, the lack of official community security support is a dealbreaker for many organizations. Many simply can't use a platform that doesn't get security updates; it's against security policies.
Security is an increasing concern for websites that store and use personal information; GDPR, CalOPPA, CCPA, and PIPEDA all stipulate that enterprises must protect personal data. Sites that don't stay up-to-date with security patches and fixes face major liability risks.
These risks are a concern for any site that contains sensitive personal information but might be a particular concern for .edu and .gov sites. Millions are paid out due to security breaches under violations of the federal Drivers Privacy Protection Act (DPPA), the Federal Education Privacy Rights Act (FERPA), and the Health Insurance Portability and Accountability Act (HIPAA). Therefore, both .gov and .edu sites must maintain high-security standards to mitigate legal liability in the event of a data breach.
Beyond liability considerations and security policies, it's also bad business to maintain websites that aren’t actively getting security fixes. Reputation damage when personal information is compromised costs organizations substantial revenue opportunities. Security exploits can also compromise the websites themselves, giving outsiders the ability to alter or take down a website. These security considerations are risks that organizations can't afford to take.
In short, while you can use Drupal 7 without support after end-of-life, you shouldn't. So now is the time to come up with a plan for whether to upgrade to Drupal 9 or to pursue some other option for your Drupal 7 site.
Prepare a path forward
Regardless of the direction chosen, organizations that aren't ready to upgrade to Drupal 9 must make a decision and devote development resources to preparing a path forward. For most, that means planning for a Drupal upgrade; for others, that means retiring an existing Drupal site. With an end to official security support, there just isn’t a third option. (This article was updated 7/10/2020)