Sector(s)

Project Team

Other organisations involved:

Team members:

Visit the site

Visit the site

Organizations Involved

Community contributions

To help the community with custom migrations, some Rector plugins were developed. These helped automate code deprecations that were not covered by the community at the time of writing.

Salsa Digital and the GovCMS/Finance team automatically upgraded 300+ GovCMS sites to Drupal 10. This provided an easier pathway for GovCMS clients and websites to an updated and supported distribution.

Describe the project (goals, requirements and outcome)
Back to top

GovCMS’ challenge

With Drupal 9 coming to End-of-Life (EOL), GovCMS needed to start its D10 upgrade project. Drupal 10 introduced widespread deprecations, which meant major upgrade work. GovCMS wanted to automate the upgrade process as much as possible to reduce the burden on its clients.

Back to top

GovCMS’s transformation — an automated pathway to Drupal 10

As a starting point, we leveraged some of the work and learnings from the automated upgrade pathway from Drupal 8 to 9. However, upgrading Drupal 9 to Drupal 10 was a much bigger challenge because:

  • There were a lot more websites on the platform (300+)
  • There were more changes in the theme this time around, which meant there were more widespread issues in each SaaS site

We started with an assessment, creating and running an audit tool to assess what sites were impacted. From there, we identified common patterns between issues and worked closely with the distribution team to resolve issues broadly for the entire platform. Issues were resolved with platform tooling and distribution updates to make the upgrade process as seamless as possible. We were looking at 100s of iterations per site to try to find, resolve, and test anything that can be automated as part of a platform-wide upgrade from Drupal 9 to Drupal 10.

The high-level process was:

  1. CI pipeline spinup
  2. Generate reports and artefacts for each site to find the deprecated code
  3. Analyse the reports to:
    1. Identify improvements and resolutions that could be made at the distribution level
    2. Identify additional platform tooling to help with smooth upgrades
  4. Collaboratively fix issues with distribution code changes and platform tooling
  5. Create feature environments with fixing applied so customers can review their sites and devs can review the code
  6. Merge for final release

We started with 3,500+ deprecations identified across the 300+ sites and worked through several rounds of fixes, each time bringing down the number of deprecations. Over a 10-month period we continued with this process until we were only left with issues that needed manual remediation.

The final automated upgrade from Drupal 9 to Drupal 10 took place in October 2023.

Back to top

The outcomes — GovCMS platform and 300+ sites upgrade to D10

  • A seamless upgrade path that took responsibility away from end users (we did it centrally instead of 100s of people/clients having to do it themselves)
  • Consolidation of effort to reduce overall resource time and costs
  • An automated process for 300+ sites (to our knowledge no other platform has executed this scale of automation for Drupal upgrades)
Back to top
Why Drupal was chosen

Drupal was chosen as the preferred CMS for Australia’s Federal Government through the creation of the GovCMS platform, which was launched in 2015. GovCMS is designed to make it easier for government agencies to create modern, affordable, responsive websites. Importantly, GovCMS provides a whole-of-government platform to help consolidation across government departments. The fact that Drupal is open source means there are no expensive lock-in contracts, and GovCMS can build a Drupal/GovCMS community.

Technical Specifications

Drupal version:

Key modules/theme/distribution used:

Why these modules/theme/distribution were chosen

Ansible: Ansible is the automation tool of choice for GovCMS. Leveraging the tooling that was available made it easy to extend the feature set so that everything could be updated accordingly. Ansible was used so that it could execute commands directly against project code bases, this was used to update code segments that were not able to be caught by Rector due to many disparate implementations across the fleet of sites. Ansible was the tool runner (e.g. ran drush commands and rector against code bases) and included repeatable steps that would have had to be executed by a human after the base automation had been applied.

Drupal Rector: Rector is a tool that automates code refactoring by scanning for deprecated or outdated patterns and applying predefined transformations to modernise and optimise code.

Base images  and module stubs: A module stub is a minimal placeholder module without functionality, designed solely to maintain backward compatibility and prevent database issues during transitions. This allows the database to recognise the module's install path, preventing errors from missing modules while their deprecation is addressed.