The “Old” Drupal: When It Becomes a Problem, and What to Do About It
Subscribe to receive updates with helpful tips on how to make your digital solutions thrive on the market
Drupal is a piece of content management software used to create web apps for media, the public sector, EdTech, healthcare, e-commerce and other sectors. It is generally chosen for its scalability (it adapts well to high load), flexibility (numerous out-of-the-box solutions are available for various business tasks) and its user-friendly content management system. Over its almost 20-year history, a strong community has sprung up around this open-source framework, and 3 June 2020 saw the release of the ninth major version of this CMF (content management framework).
The new version and the old versions: what’s the difference, and what do they offer?
Over time, approaches to development and the IT ecosystem as a whole change a lot, and major versions of software reflect this. For instance, the previous big release, Drupal 8, which appeared in 2016, differed from earlier versions in having an object-oriented back end using Symfony components. Implementing the standards and technical capabilities provided by Symfony-based development enabled Drupal’s creators to concentrate on perfecting Drupal-specific features. This made Drupal 8 more attractive for developers and more effective for tackling business challenges.
New Drupal releases are shaped both by global trends in web development and by changes in the components which Drupal is based on. Older versions of Drupal had fewer dependencies and links to other software, so the framework used to be developed more sporadically: a new major version would come out once every few years, and it would not be backward-compatible with the previous version. This meant developers of Drupal modules would have to almost completely rewrite their code for the new core version. To make use of the new version’s functionality, users would have to independently migrate their sites to the new version. Nowadays, to make Drupal and Symfony work better together, Drupal has adopted a six-month update cycle, gradually introducing new features and marking certain elements as legacy elements.
Old versions’ end-of-life
The main catalyst for the release of Drupal 9 was that support for Symfony 3, which Drupal 8 depends on, is due to come to an end in 2021. When support for an older version of a piece of software is discontinued, official updates, bug fixes and security updates are no longer released, which, over time, makes the system less reliable. For most businesses, it is old versions' end-of-life that is the most important reason for migrating to a new one. Self-supporting security and functionality of legacy software entails risks and increased costs.
Previously, Drupal's 7 end-of-life was also scheduled for November 2021. Despite the fact that more than half of Drupal projects are made on this version, its support runs counter to the development plans of the framework. But on June 24, 2020, the deadline was shifted. Given the impact of COVID-19 on budgets and businesses, the Drupal community decided to extend Drupal 7 support until November 28, 2022. Migrating from Drupal 7 is significantly more expensive than migrating from version 8 to version 9. An additional year will allow numerous Drupal 7 users to prepare more thoroughly for the last big migration.
The last big migration
Thanks to the way updates are currently handled, the transition from Drupal 8 to Drupal 9 should be smooth and straightforward, as should all other updates planned for the foreseeable future. It became possible thanks to the architectural similarity between the systems. However, moving an old site using Drupal 7 over to the new core will necessitate major reworking of the site’s architecture and data model. Essentially, this means creating a new site, although this should be less work than re-platforming or creating a site from scratch. Migrating site layouts and any custom functionality written for Drupal 6 or Drupal 7 could take as much as 80% of the time it initially took to create them.
Despite the existence of tools which should make this process easier than when Drupal 8 had only just appeared, migration remains time-consuming and costly. Some companies aren’t prepared to make this kind of investment and use legacy software for years, maintaining the system themselves or outsourcing developers. For instance, although support for Drupal 6 ended four years ago, data from 2020 on the usage of Drupal cores suggests that around 3% of projects are still using Drupal 6 or older versions. This approach is fair enough, but it creates a number of bottlenecks.
What problems might users of legacy versions run into?
1. Security issues
Security issues and vulnerabilities occasionally come to light in both old and new software. The difference is in who has to deal with them. Responsibility for the security of the current version of Drupal is assumed by its developers: they identify potential vulnerabilities and release free security updates. For end users, installing updates is a routine task, whereas independently monitoring and fixing security problems in a legacy system requires attention and manual labour. It’s also important to remember that Drupal exists within a whole ecosystem (PHP, its extensions, Drupal modules and third-party libraries). Having lots of old, unsupported elements in a system always increases the risk of losing data—and your users’ trust.
2. Technical issues and limitations
If you’re not bothered by potential security threats, technical limitations can make your life difficult right here and now. First, because the third-party services you need don’t “get along” with your software, you’ll have to write integrations yourself and configure them to take account of older systems’ platform particularities. Second, you’ll have to hand-configure functionality that’s often available in modules in later versions. Third, even if the module you need exists, it’s not going to get updated, so you’ll have to put in the work to keep it stable yourself: third-party services’ APIs occasionally change. Billing, inventory accounting, any CRM, ERP, logistics management, etc.—the more complex your product is, the more elements you’ll have to continuously monitor.
3. Loss of system flexibility and scalability
Supporting legacy software means a lot of custom code, and the flexibility and scalability of your system is going to take a hit from that kind of approach to development. One of the main advantages of Drupal is the abundance of different modules, which make experimenting with your product quicker and cheaper. However, there are not enough modules compatible with older versions to cover all of your current business needs. When the market changes fast and your users (clients, marketing experts, editors) need new things from your system, you won’t be able to make these changes as fast as those of your competitors who are using out-of-the-box solutions.
4. Issues with business development.
If you want to receive state investment or subsidies, your products have to fulfil certain requirements, including technical ones. Drupal 6 and earlier versions don’t meet these requirements, as they don’t tick the boxes for service security. The cost of support and limited potential for making the changes we described above will also make your product unattractive to investors.
5. High cost of support.
The code underlying Drupal 6 and Drupal 7 doesn’t conform to modern standards, so there are far fewer developers out there who can do a good job of supporting your product’s performance and security than there are for newer software. What’s more, these are mostly experienced developers with a high hourly rate—and you might end up needing a lot of hours. You might also run into problems with finding support documentation for older versions and with their compatibility with the modern ecosystem. Custom code is always more unreliable, more costly, and more labour-intensive.
How do I know if I need to migrate my product?
Despite the risks this article has outlined, we’re not saying that everyone definitely has to make the move right away. You can only make a rational assessment of how urgent it is for you to transition to Drupal 9 by taking into account the specifics of your site and your future plans for it. The November 2021 and November 2022 deadlines gives you plenty of time to evaluate whether you need to make the move, work out how much it will cost, and start working on it in a careful, orderly way. Here are a few things you should take into account to make a comprehensive assessment:
Are you expecting to make changes to the design, add new functionality, engage in marketing activities, or see an increase in user numbers? If so, compare the capabilities of the new system and your current system, and the cost of development in both cases.
- Could a more advanced system help you to cut down on manual labour? For example, Drupal 9 includes Layout Builder, which lets content managers create page designs without relying on programmers. It’s looking like Drupal is increasingly moving towards making things as simple as possible to use and automating everything, even updates. Maybe you’d recoup the costs of moving to the new Drupal sooner than you think?
- Is the speed with which you can make changes important to you? What advantages might the ability to make quick changes have for you in the future?
- What might the consequences be of your system getting hacked? How likely is this? Are you abiding by all the laws around handling personal data?
- What’s the quality of your code like now? The cost of migration, and the cost of not migrating, are largely dependent on the current state of your site.
Don’t forget that using old technologies is a sort of technological debt which grows over time and is highly likely to create problems when you try to support and develop your product down the line. Changing standards are not a problem; they’re part of the technological evolution which makes creating reliable, high-performance web products easier.