slideshare quotation-marks triangle book file-text2 file-picture file-music file-play file-video location calendar search wrench cogs stats-dots hammer2 menu download2 question cross enter google-plus facebook instagram twitter medium linkedin drupal GitHub quotes-close
Two one way signs pointing in opposite directions

Why upgrade to Drupal 9 from Drupal 7? It's a good question. Especially when the Drupal community is still divided about going through with end of life for Drupal 7.

Initially launched in 2011, Drupal 7 is now fast approaching the end of its lifecycle. In November 2022, Drupal 7 will officially retire. Even though Drupal 8 has been available for a long time, over 730,000 sites remain on Drupal 7. Are you considering upgrading to Drupal 9 from Drupal 7? Considering 2022 is in sight, we think switching to the latest version of Drupal would be wise.

Irrespective of whether you decide to upgrade to Drupal 9 or not, you need to acknowledge one crucial fact: Drupal 7 will no longer be supported after November 2022. The Drupal 7 community will no longer receive support from the Drupal Association, and Drupal.org support for Drupal 7 will cease after a decade of supporting the framework. In addition, Drupal 7 will no longer be supported by Drupal.org for automated testing and security assistance.

Drupal 7 Core will no longer be supported, and the Drupal 7 versions of many donated modules will get less attention as a result. Module maintainers are more likely to lose interest in updating their code for the Drupal 7 version once their own sites have upgraded to Drupal 8 or the latest version, Drupal 9.

Drupal 7 upgrades are more challenging than Drupal 8 upgrades

In November 2015, Drupal 8 became publicly available. At the Drupal 9 announcement, the Drupal Association discussed a significant change in the Drupal ecosystem: major Drupal version changes will no longer require a considerable amount of time and effort to re-platform but will instead be part of an iterative development process. In reality, Drupal 9 is built upon Drupal 8, by deprecating code sections and updating dependencies as necessary. Hence, migrating from Drupal 8 to Drupal 9 amounts to little more than a slight incremental change. Even though Drupal 9.0 includes a lot of deprecated code, it doesn't contain any new features; instead, it maintains Drupal 8's stable codebase, which has been thoroughly tested and validated. Drupal 9.0 is essentially a new version of Drupal 8, which is already available.

Drupal 7 differs significantly from Drupal 8 and Drupal 9 in many important ways. The transition from Drupal 7 to Drupal 9 may be a time-consuming and challenging process. Large swathes of custom Drupal code were replaced with third-party libraries. Object-oriented programming was used to transform the procedural code. The code modifications were extensive. A Drupal 7 site may be upgraded to Drupal 9 and therefore become compliant with the new upgrade paradigm; however, a significant amount of effort is involved. As a result, deciding whether to upgrade to Drupal 9 and how to do so becomes more complex.

Drupal 7 sites have the following options:

  • Migration to Drupal 9
  • Move to a different CMS (such as Backdrop CMS)
  • Creating a static version of the Drupal 7 website
  • Find an Extended Support provider (ES) for Drupal 7
  • Unsupported use of Drupal 7

The advantages of Drupal 8 and 9

Drupal 8 represents a significant departure from Drupal 7, but it also introduces many new features that will benefit users willing to learn how to use them.

Donated module functionality has now been incorporated into Drupal core.
One of the most significant advantages of Drupal 8, and primarily Drupal 9, is that many of the features that required modules in Drupal 7 are now baked into Drupal core. 

Things like:

  • Drupal 7's Panels and Display Suite lets you build custom page layouts, while Layout Builder generates custom page layouts.
  • Drupal 7 now allows field blocks to be reused, which previously was only possible using contributed modules, such as Bean.
  • WYSIWYG editors are included in the core package so you do not need to install contributed modules or third-party libraries.
  • Views are now part of the core, and the vast majority of the custom lists in the core are now entirely configurable views.
  • Media management is not an optional feature. It is an essential component. A half dozen or more complex contributed Media foundation modules, each of which may need additional setup, are required to provide a comparable level of capability in Drupal 7. By just activating the Media and Media Library modules and configuring Drupal 9 according to the default settings, you may have a reasonably good media handling experience in Drupal 9.
  • Web services, such as JSON: API, are pre-installed.
  • Customised editorial processes are now accessible in the core, replacing the need for contributed modules such as Workbench Moderation or Workflow, which previously provided the capability

That is just a small selection of the features available in Drupal 7. There are many more in the core that would need contributed modules in Drupal 7.

The maintenance of this functionality is made easier by the inclusion of more of it in the core. Managing fewer contributed modules makes it easier to maintain them in sync as you change versions and dependencies. It makes it easier to figure out what to do when a dispute arises or something fails. 

The importance of this becomes even more apparent as Drupal 7 development fades away. It may take months - or longer - to get updates to Drupal 7 contributed modules, and after that, the modules may no longer be maintained at all.

Being able to include these solutions in the core ensures that everyone is utilising the same solution, rather than diverting development attention in various areas. Furthermore, the fact that they are part of core implies that they have been well tested and maintained.

Composer to the rescue

One of the most significant changes to Drupal since the introduction of Drupal 7 is that Drupal 8 and 9 make considerable use of third-party libraries such as Symfony for key functionality, rather than depending on proprietary Drupal-specific code for everything as was the case with Drupal 7. Because of the migration "off the island," there is now a need to manage Drupal's dependency on such libraries. This is handled by another programme, a package known as Composer, installed on the computer.

Because each of these libraries is dependent on other libraries, which in turn are dependent on even more libraries, you must manage a complex spiderweb of dependencies and needs and the possibility for conflict. Maintenance becomes a headache as soon as dependencies are not properly managed. Even though it is a new technology, Composer is a fantastic dependency management. Investing the necessary effort to learn Composer provides developers with a robust new tool for dealing with dependency management issues.

Composer is capable of a variety of tasks. Adding cweagans/composer-patches makes it a very helpful tool for handling patches from Drupal.org, which is a bonus feature. You may include URLs to the patches you wish to monitor in composer.json by creating a patches section in the composer.json file. Therefore, Composer will apply the patches by itself,
 automatically, and your composer.json file will be used to document the patches you are using.

No more Features for configuration management

The Features module is frequently used to deploy configurations in Drupal 7. The use of Features for configuration management can be viewed as either a good thing or a bad thing, depending on who you ask. Developers commonly believe that Drupal 8 (and Drupal 9's, as well) Configuration Management system, which facilitates exporting database configuration files to YML files, is more straightforward than Drupal 7's Features system. The system is as complicated as Composer, but those who understand it can accomplish more with less effort. 

Secure PHP support

Deprecated versions of PHP, including versions as ancient as 5.3, may be operating on Drupal 7 sites. Drupal 7 sites should already be operating on PHP 7. However, it is possible that they are still running on earlier, extremely obsolete, and vulnerable versions of the PHP programming language. 

Drupal 7 is presently compatible with PHP 7.3, however it has issues with PHP 7.4 at this time. As PHP develops and earlier versions of the language are phased out, you may discover that you are unable to maintain your Drupal 7 site operating on a safe version of the PHP programming language. Drupal 8 and Drupal 9 both run on PHP 7.0 or above, while Drupal 9 operates on and needs a minimum of PHP 7.3, allowing for a wider range of compatibility with more secure PHP versions than Drupal 8.

Resistance to migrating to Drupal 8 and 9

There are a variety of reasons why sites are delaying this transition:

Drupal 7 contributed modules are not available in Drupal 8 editions

One of the most common Drupal 8 concerns during the early stages of the release cycle was that many Drupal 7 contributed modules did not function properly in Drupal 8. While some donated modules were updated quickly, others took a longer period to do so. On the other hand, many Drupal 7 contributed modules are no longer required in Drupal 8 as the functionality they offer is now part of the core.

For those of you who haven't been keeping up with the current status of Drupal contributed modules in the past few years, have a look at what's now available for Drupal 8. The Drupal 8 Contrib Porting Tracker allows you to view the current progress of popular Drupal 7 modules, as well as whether or not they have been released as part of a Drupal 8 stable version. It is possible that modules that were previously unavailable are now available, or that some contributed modules are no longer required because the functionality is now managed in a different manner.

The parity between Drupal 8 and Drupal 9 contributed modules will not be affected when Drupal 9 is released; provided that the Drupal 8 module in question doesn't use deprecated code, everything that was working in Drupal 8.x should also work in Drupal 9. In addition, if a D8 module is based on obsolete code, the maintainer should be made aware of this as soon as possible. There will be no surprises for module and site maintainers when Drupal 9 arrives, as deprecated code from Drupal 8.8 has been used from Drupal 9.

Maintenance overhead for small teams

Why upgrade to Drupal 9 at all? Since Drupal 8 and Drupal 9, the development paradigm has shifted to more frequent and smaller releases. Iterative development means frameworks release more frequently, and that means their releases are not supported as long. This mirrors a larger trend in software development. 

As a result, you need to keep your site updated with the latest releases. If you manage a Drupal site with a small team, you might not have the bandwidth or expertise to keep up with updates. 

Maintaining a website is easier with some tools. A module called Automatic Updates might be useful for small sites. This module is still a work in progress, and it does not yet support contributed module updates or composer based site installations. Phase 2 will include these. The project is worth monitoring, however. 

With Composer and Drush, you can handle updates yourself. The DependaBot service can also be used by any size of site to create automatic pull requests. 

We offer Drupal hosting and updates could take care of the update for you when you switch your version of Drupal.

The new way of doing things is harder, so why upgrade to Drupal 9?

The last reason why many Drupal 7 sites have been hesitant to upgrade to Drupal 8 and Drupal 9 is that the new method of doing things is more difficult. Alternatively, if tougher isn't an option, try something new. There's a lot here to unpack. This may indicate a reluctance to learn and use new tools in certain instances. In certain instances, long-time Drupal developers may have difficulty learning new paradigms. Another possibility is that developers are just unwilling to learn a new stack and are thus unable to work in new Drupal versions.

Don't forget about those specific Drupalisms

As Drupal 6 and 7 contain many Drupalalisms, or Drupal-specific, unique ways of doing things, experienced Drupal developers may find the number of things to re-learn overwhelming. Some Drupal 7 developers may learn something of use if they go on to work on their first Symfony or Laravel project, such as Composer, Twig, and PHPUnit.

Developing for Drupal 8 and Drupal 9 differs significantly from Drupal 7 and previous versions. Some developers may use this as a stepping stone to pursue other career routes, switch to a new stack, or make a more significant move. However, as the end-of-life for Drupal 7 approaches, developers who do not want to migrate to Drupal 8 or Drupal 9 must undertake some kind of transition, much as Drupal 7 sites must migrate to a contemporary platform.

Security considerations

Nowadays, enterprises must protect users' personal data on their websites, or they will be liable for costly fines. The threat of website security is looming and ongoing for many organisations. Organisations often require that services be protected by ongoing security support in enterprise security policies. Because of this, many enterprise Drupal 7 websites will no longer receive security support after Drupal 9 has been released.

What exactly does “no more security support” mean?

The Drupal community as a whole will no longer offer "official" security updates or bug patches after Drupal 7 hits end-of-life. Drupal 7 sites will no longer get assistance or Security Advisories from the Drupal Security Team. It's possible that the automated or manual methods you're presently using to update your sites won't function anymore.

However, there is some nuance to the absence of security support. The Drupal 7 ES programme entails working with a Drupal Association-approved vendor and ensuring that the vendor is managing responsible disclosure of security vulnerabilities and solutions and publicly disclosing the work being done to address such issues.

In practice, this implies that you can still receive security updates for your site even if you aren't associated with an ES provider. Websites that use modules that aren't actively maintained by ES manufacturers, on the other hand, won't have the advantage of a partner to track down and resolve problems with those modules, whether they're security-related or not. You may be left with a website with a growing number of security vulnerabilities if you have modules or other dependencies that are no longer receiving security upgrades, such as the end-of-life of the PHP version you're hosting.

Additionally, Drupal 7 core and Drupal 7 releases will be marked as not supported on all project sites after November 2021. As a consequence, third-party scans may identify Drupal 7 sites as unsafe due to the lack of official security support.

No more bug fixes or active development

As part of the end-of-life timetable for Drupal 7, active development and bug fixes are also officially suspended. While Drupal 7 was developed over several years ago, the problems with Drupal 7 still persist. Take a look at the Drupal.org issue queue for Drupal 7 core problems, for example, and you'll find issues that haven't been updated in weeks or months, compared to hours or days for Drupal 8 or the latest version development issues.

Conclusion - Why upgrade to Drupal 9 from Drupal 7?

Essentially, at some point, you'll have to. Keep in mind that your custom modules, content and configuration can be carried over to this new release of Drupal, but it might take some work.

If you're unsure about what upgrade path to take, we can help


Contact us