End-of-Life Drupal 8 and the upgrade to Drupal 9

The Drupal 8 EOL date is November 2nd 2021. This is because Drupal 8 has a dependency on Symfony 3 which has an end-of-life in November. That means there will be no further security fixes implemented, so to keep your project safe and secure against potential threats, it is strongly advised to upgrade to the latest version of Drupal.

No “migration” needed?!

Correct! With the upgrade from Drupal 8 to Drupal 9 – there is no need for migration; the new features for Drupal 9 were gradually released inside Drupal 8. The main change that Drupal 9 brings is the removal of deprecated code, much like getting a hair-cut.

However, this was not the case with the change from Drupal 7 to Drupal 8. From Drupal 7, there was a multitude of different changes that resulted in requiring a comprehensive and often complex migration. This led to many clients opting for a complete rebuild from the ground up to take full advantage of new features such as “workspaces” that arrived in Drupal 8.6.0.

What about contrib modules?

The “Drupal 9 deprecation” dashboard overview shows the overall compatibility status of all contributed modules to the Drupal ecosystem. Over 88% of the top 1000 contrib modules are explicitly compatible with Drupal 9, meaning they have a Drupal 9 release.

Additionally, more than 50% of all Drupal modules are compatible with Drupal 9, and a further 20% require only the info.yml file and/or the composer.json file to be upgraded to make them compatible with Drupal 9.

How do we upgrade our projects?

At Amazee Labs, we deal with a diverse range of clients – all of which have their own distinctive requirements – so we  construct elegant solutions tailored to their unique business needs.

With such a diversity of projects, we developed a solid plan to upgrade each project to Drupal 9. Our maintenance team’s strategy involves the following three stages:

1. Analyse
2. Tackle
3. Deploy

Analyse

The Analysis stage involves scanning the project server and codebase to identify the complexity of the upgrade process. Some of the information we gain from this analysis answers the following questions:

1. What version of PHP is the server using?
2. What version of Drupal Core is installed?
3. Is the Drupal Core Media module enabled?
4. How many contrib modules are installed?
5. How many of those contrib modules are outdated?
6. How many custom modules have been created?  

We have a few pre-conditions that the project must pass before we can continue:

1. The server is running on PHP version 7.4
2. Drupal Core 8.8.x is installed or ideally the latest release from the Drupal Core 8.9.x branch
3. Drupal Core’s Media module is enabled

If we have detected that the PHP running on the server is lower then version 7.4, then we need to update this first. If the project is hosted on Lagoon, by amazee.io, then this is generally a breeze to update, as it is highly developer-friendly.

If we detect an older version of Drupal Core released before version 8.8.x, then we create a task to upgrade Core to the latest 8.9.x version. Within the web maintenance team, we have taken over some very outdated projects and meticulously updated each one, always involving the client within our Agile workflow, to build trust throughout the entire development process.

To ensure Media in Core is enabled, the process to migrate from the contrib Media Entity modules to Drupal Core Media is outlined over on the FAQ page on drupal.org.

During this initial investigation, we install the Upgrade Status and Upgrade Rector modules, then generate a report containing information on what modules require updating. Furthermore, we generate fixes for deprecated code in the custom modules.

Tackle

With our web maintenance service offering, we ensure the longevity and reliability of our clients’ projects by keeping their websites up to date and secure.

With the results from the analysis stage, we then create individual tasks to tackle the challenges that lie ahead. The drupal.org documentation has some information on how to upgrade from Drupal 8 to Drupal 9 or higher.

The Upgrade Rector module helps us to perform automated fixes on the codebase. For contrib modules that lack a Drupal 9 release, we contribute back to the community by submitting fixes and collaborating with maintainers to aid them in releasing a new version of their module.

Many Open Source communities have found that to support their growth and ensure long-term sustainability they’ve opted to utilise platforms that pay contributors or embrace corporate sponsors. Underrepresented groups, in particular, do not always have the privilege of free time to contribute to Open Source outside of work hours. At Amazee Labs, we can take advantage of providing contributions to the Drupal community during work hours. Gábor Hojtsy has an extensive overview of articles aimed at helping to push contributed modules to a successful Drupal 9 release.

Deploy

So we have gone through and analysed the code, updated the modules and exported the configuration, now how do we deploy our changes to the production environment?

Our workflow for the majority of our projects tends to be as follows:

• All projects have at least two environments:

  • production and development with their respective databases
  • Some benefit from Lagoon's Pull-Request environment feature

• A production git branch, often named “prod” for short

• A development git branch, often named “dev” for short

Here is our 13-step guide

1. A developer first checks out the project codebase locally.
2. The developer then fires up a local instance either with Docker or with native PHP. - For Docker, they would either use Pygmy or Lando’s Lagoon beta. For native PHP, they would simply run “drush serve” with an SQLite database.
3. The developer then creates a feature branch on git from the latest changes on the prod branch.
4. Using the composer tool, the developer upgrades the necessary modules as well as upgrades Drupal Core.
5. Then they run the update database command in Drush and export the configuration changes.
6. After this, they commit all changes: configuration changes, composer JSON and lock file changes, as well as any other changes to the custom modules or custom theme.
7. They push their local git branch to the remote origin and create pull-request into the prod branch.
8. If PR environments are available, then this would automatically spin up a new environment with all the changes, ready to be tested by another developer.
9. If the project does not have PR environments available (i.e. if it is not hosted on Lagoon), then the developer will merge their changes into the development environment so that another developer can test.
10. If the second developer does not find any specific issues during their testing process, then the project manager is informed that they can test the changes with the client.
11. If the project manager and the client find no specific issues with the changes, then the pull-request is approved for deployment to production.
12. The original developer is empowered to deploy on their own (but the team is always there for one another). The developer will trigger the deployment by simply merging the pull request they made into prod.
13. Once the deployment is completed, the developer informs the project manager and client that their website is now running on the latest version of Drupal.

Accomplishments

Once we have gone through and updated the modules, upgraded Drupal to the latest stable release, and deployed everything to the production environment, then...we celebrate our accomplishment internally with the rest of the team – a job well done!

In retrospect, the upgrade from Drupal 8 to Drupal 9 is a piece of cake compared to the upgrade from Drupal 7. It feels like we are modernising the website in small bites instead of trying to gobble down a brand new refreshed website all at once.

Ready to talk about your upgrade needs? Whether you’re operating on Drupal 7 or 8, We’re ready to help. Get in touch with us and upgrade to Drupal 9 today!