Sector(s)
The group runs more than 25 sites on a single Drupal multisite codebase: country sites, service sites, corporate sites and an e-commerce site with online payment. A major upgrade therefore affects the whole fleet at once. Parker+Parker upgraded the platform from Drupal 9 to Drupal 10 and is applying the same method to the Drupal 11 upgrade, ahead of Drupal 10 end of life on December 9, 2026. Maintenance and projects continue during each upgrade.
About the project
Results
- More than 20 sites, the whole fleet at the time, upgraded together from Drupal 9 to Drupal 10, on one shared codebase.
- Nearly 300 modules and plugins audited for compatibility.
- More than 150 test cases in six batches, each validated by the developer, the project manager and the client.
- The same method now applies to the Drupal 11 upgrade, while maintenance releases continue.
Goal
Keep every site on a supported Drupal version, on a schedule set by Drupal's end-of-life dates, without freezing the client's roadmap.
Challenge
All sites share the same codebase. An upgrade affects every customer journey, every content type and every site-specific feature at once, including a checkout with online payment. Testing every page of every site is not realistic. Maintenance and new projects continue in parallel.
Solution
- Scoping workshop. Scope, timeline, risks, rollback scenarios and test coverage are agreed with the client.
- Compatibility audit. Every module is checked: is a compatible release out, and is it stable? Modules are sorted by type, risk, business value and origin, contributed or custom.
- Rebuild or replace. An abandoned module is replaced by an equivalent or rebuilt, then adapted. Unused obsolete modules are removed.
- Cross-fleet acceptance testing by site type. A sample of each site type (country sites, service sites, corporate sites) is tested on every customer journey, every content type and the checkout. Test cases are split into batches so the client can start testing early.
- Timed cutover. Databases are copied to a hidden production environment. The cutover follows a timed plan with a rollback scenario. Every site is checked after go-live.
Standards and continuity
The method keeps the platform on versions covered by security fixes and aligns the upgrade schedule with the end-of-life dates published by Drupal. For Drupal 12, the rule is to wait about six months to a year after its release, until the contributed ecosystem has caught up.
What editors do without developers
Editors keep the same back office and the same content model from one version to the next. Content entry continues on production until the cutover window.
Why Drupal was chosen
Drupal was already the group's platform. The question was how to stay on it safely. Drupal's predictable release cycle made planning possible: each major version has a published end-of-life date, and upgrades between recent major versions are incremental. The deprecation process makes it possible to find incompatible code months in advance. Thanks to the contributed module ecosystem, most features have a maintained path to the next version. The few modules without an equivalent can be replaced or rebuilt. With a multisite codebase, a single upgrade covers every site. For a group with more than 25 sites, this is the main reason to stay on Drupal.
Technical Specifications
Drupal version:
Key modules/theme/distribution used:
Paragraphs powers the block library shared by all sites. Every content type that uses it was retested during the upgrade. Drupal Commerce runs the checkout, covered by cross-fleet acceptance testing. All sites share one codebase through Drupal core's multisite feature, so a single upgrade covers the whole fleet.
