Skip to content

Case study · Public sector

Migrating an institutional website from Drupal 9 to Drupal 10, with no loss and no regression

How we move a DSFR website from an end-of-life Drupal 9 to Drupal 10 — auditing deprecations, dependencies, configuration and tests, under white label.

Role: Migration & version upgrade — subcontracted Client: A national public operator — institutional website (anonymised)
9 → 10major Drupal version upgrade
0remaining deprecated API (static analysis)
Isofunctionality preserved (tests + CI)
No losscontent & configuration
Role
Migration & version upgrade — subcontracted
End client
A national public operator — institutional website (anonymised)
Technical foundation
Drupal 9 → 10 · PHP 8.1 · DSFR
Scope
Compatibility audit (upgrade_status), dependency updates, fixing deprecated APIs, configuration migration, tests & CI, DSFR/RGAA compliance
Drupal 109→10 migrationupgrade_statusPHPStanCodeceptionDSFRconfig_splitGitLab CI
In short: moving an institutional website from an end-of-life Drupal 9 to Drupal 10 is not a matter of “clicking update”. It is a project in its own right: auditing deprecated APIs and dependencies, replacing or patching incompatible modules, fixing custom code, migrating configuration without losing content, and proving through tests that the website remains functionally identical — all while keeping DSFR / RGAA compliance. Role: migration and version upgrade, as a subcontractor.

The problem: an end-of-life Drupal 9

Drupal 9 is no longer maintained: staying on it means building up security debt and cutting yourself off from new developments. But migrating a live institutional website to Drupal 10 is daunting, and rightly so — modules that break, removed APIs, a theme to rework, the risk of losing content or degrading accessibility. The challenge is not “installing Drupal 10”, but taking a live website across the version with no breakage and no regression.

Audit before touching the code

A successful migration starts with a diagnosis, not an update. We map what exists with the right tools: upgrade_status (the official tool that inventories modules and themes and flags what is not ready for Drupal 10) and targeted static analysis of deprecated APIs (PHPStan deprecation rules). The result is a clear map: what migrates as is, what has a compatible version, what must be patched, and what must be rewritten. This diagnosis becomes the prioritised migration plan.

The real work: dependencies

Most of the effort goes into contributed modules. Each one must be brought to a Drupal 10-compatible version; some have been absorbed into core and must be removed; others do not yet have a stable version and need a tracked patch (documented, replayable Composer patches). The work is methodical: we move forward dependency by dependency, keeping a clean composer.json and a reproducible installation — not one big, risky leap.

Fixing the custom code

In-house code — modules and theme — often uses APIs that disappeared between Drupal 9 and 10. Rather than discovering them in production, we track them down at the source with static analysis, then fix them: updated signatures, replaced services, rewritten deprecated calls. The theme is reworked to stay compatible and clean. The goal: zero remaining deprecated APIs at go-live.

Configuration and content: losing nothing

An institutional website means years of content and fine-tuned configuration. The configuration is versioned and managed per environment (config split), which makes it possible to replay it cleanly on the new version rather than rebuilding it by hand. Content is preserved and checked. The rule is simple: after migration, editors find their website — the same content, the same templates, the same permissions — but on an up-to-date foundation.

Proving nothing has broken

The question that worries everyone in a migration: “has something broken somewhere else?” We answer it with proof — functional tests (Codeception / PHPUnit) that replay the key journeys, run in continuous integration, and a quality chain (tooled code review, static analysis) that blocks any regression before go-live. The migration is only signed off once the website is shown to be functionally identical.

Keeping compliance during the migration

On a public-sector website, the version upgrade must not degrade accessibility or compliance with the DSFR. We keep the French government design system at a compatible version, check that components remain compliant after migration, and treat accessibility as an acceptance criterion, not a blind spot. You come out of the migration with a more modern website — and one that is still compliant.

Taking over or delegating a Drupal migration

Many agencies have a portfolio of Drupal 9 websites to migrate and are looking for back-up able to do it cleanly and at scale. That is exactly our territory: we audit with upgrade_status, prioritise, deal with dependencies and custom code, replay the configuration, prove it through tests, and deliver a compliant Drupal 10 site. Whether the migration is still to start or already under way, we can take over without breaking anything.

Frequently asked questions

Isn’t migrating from Drupal 9 to 10 just an update?

No. It is a major version change: APIs are removed, modules must change version or disappear, and custom code and the theme must be adapted. Without an audit or tests, you break production. With the right method, you migrate without loss.

How can you be sure nothing breaks elsewhere on the website?

Through automated tests (Codeception / PHPUnit) replayed in continuous integration, and static analysis that tracks down deprecated APIs. The migration is only signed off once the website is shown to be functionally identical.

Is any content or configuration lost in the migration?

No, if it is done properly. Content is preserved and checked, and the versioned configuration (config split) is replayed on the new version rather than rebuilt. Editors find their website, on an up-to-date foundation.

Do you work under white label for agencies?

Yes. We work as subcontractors on Drupal migrations (9→10 and beyond), under white label — audit, version upgrade, tests and takeover, under your brand.

In short: a successful Drupal 9→10 migration comes down to method, not luck — auditing, dealing with dependencies, fixing deprecations, replaying the configuration and proving functional parity through tests. The result: a website that is up to date, secure, compliant and ready for what comes next.

9→10major version upgrade of an institutional website in production
0remaining deprecated API — tracked down by static analysis
Isofunctionality preserved, proven by tests & CI
f
FullDo

Full-stack & AI web development studio — Drupal, WordPress, accessibility.