Drupal 10 End of Life: What to Audit Before Upgrading

Drupal 10 end of life is one date on the schedule, but sites on 10.5.x or earlier have already lost security support. The version a site runs today decides what it needs to do next.

The Drupal 10 end of life date is 9 December 2026, and Drupal.org states that no new Drupal 10 releases will follow that date. For CTOs and delivery leads, the date is fixed, but the route is not. The choice between an in-place update to Drupal 11, a move that continues to Drupal 12, or a larger modernisation depends on what the site contains.

A route chosen before an audit can be invalidated by what the audit finds, such as a module with no Drupal 11 release or a hosting platform that cannot run the required PHP version. This article sets out five audit layers to complete before Drupal 10 end of life, the findings each should produce, and how those findings map to a route. It also allocates the audit across the weeks that remain, which at the time of publication is about eight.

Drupal 10 End of Life Dates by Minor Version

The Drupal core release schedule sets the Drupal 10 end of life date at 9 December 2026. Drupal 10.6.0 was the last Drupal 10 minor release. Drupal 12.0.0 and Drupal 11.5.0 are scheduled for the week of 7 December 2026, and security support for 10.6.x and 11.3.x ends in that same week.

The effective deadline depends on the minor version a site runs:

• 10.4.x: Security support has already ended, according to the 10.6.0 release notes.
• 10.5.x: Security support ended in the week of 29 June 2026, when Drupal 11.4.0 was released.
• 10.6.x: Security support continues until the Drupal 10 end-of-life date.

A site on 10.5.x or earlier is therefore running without security coverage now. Moving to 10.6.x restores coverage until December.

What Changes for a Site After Drupal 10 End of Life

After the Drupal 10 end of life, Drupal.org makes no new Drupal 10 releases. A vulnerability found afterwards has no official fix for Drupal 10 core.

Contributed modules follow a separate pattern. Support for Drupal 10 in a given module depends on its maintainer, and Drupal core contributors have described supporting several major versions as a choice rather than an obligation in the policy discussion that fixed the December date. Each module on a site therefore needs its own compatibility check.

Drupal 11 has a longer runway. The Drupal 12 platform requirements announcement states that Drupal 11 will be supported until mid to late 2028, at least until the release of Drupal 13.

Audit Layer 1: Core Release Line and Upgrade Path Prerequisites

The first layer establishes where the site starts and which Drupal 11 versions it can reach. Drupal.org's change records state that a site must be on Drupal 10.3 or later before updating to Drupal 11. The 10.6.0 release notes add that a site on 10.6 must update to Drupal 11.3.0 or higher.

Findings from this layer:

• The installed minor version and its security support status
• The gap between the installed version and 10.6.x
• The Drupal 11 minor version that the site can target, which is 11.3.0 or higher for a site on 10.6

Audit Layer 2: Runtime and Hosting Requirements

The second layer compares the runtime of every environment with the requirements of the target version. Drupal 11 requires PHP 8.3. Drupal 12 requires PHP 8.5 and raises the minimum MariaDB and PostgreSQL versions, according to the platform requirements announcement.

The audit covers production, staging, and continuous integration environments. Each environment that falls below the target requirements becomes a change request, and the lead time for each request should be recorded in the first two weeks.

Audit Layer 3: Contributed Modules and Removed Core Modules

The third layer inventories every enabled contributed module and checks whether a release declares Drupal 11 compatibility. Modules without a compatible release fall into three groups. Some have a release in development, some need a replacement, and some are unmaintained and need removal.

Drupal 11 also removed several modules from core. Drupal.org change records document the removal of Actions UI, Forum, Statistics and Tour, and the api.drupal.org list of removed core modules also includes Book and Tracker. A site that uses any of them needs a plan for that functionality before the update.

Findings from this layer:

• The count of modules with a Drupal 11 release, in development, needing replacement, or unmaintained
• The removed core modules in use
• The functions that depend on any unresolved module

Audit Layer 4: Custom Code

The fourth layer measures the custom code. Custom modules and themes have to run on the PHP version of the target release, which is 8.3 for Drupal 11. They also need to be reviewed against the Drupal 11 entries in the Drupal.org change records.

Two numbers size the work. One is the number of custom modules, and the other is the number of findings in each. A site with few custom modules and few findings fits a contained update. A site with many custom modules, or with findings concentrated in code that few people understand, needs a larger allowance.

OpenSense Labs has published a Drupal 11 upgrade checklist that covers the mechanical steps of the update itself.

Audit Layer 5: Integrations, Content Operations and Compliance Exposure

The fifth layer covers dependencies outside the Drupal codebase. The audit lists every integration with CRM, single sign-on, search, payment, and analytics systems, together with the module or library that connects each one. It also records which of those connectors have a Drupal 11 release.

Content operations affect the schedule too. The audit records editorial workflows, scheduled publishing and any content freeze periods, because these determine when a production deployment can happen.

The last item is compliance exposure. If the chosen route cannot finish before Drupal 10 end of life, an owner needs to document the interim risk and the planned completion date.

Matching Audit Results to an Upgrade Route

The five layers produce a set of findings that point to one of four routes.

The first two routes share the same first step, so choosing the second adds no work to the Drupal 11 update. The Drupal 12 step can then be scheduled separately.

Sequencing the Audit in the Weeks Remaining

With about eight weeks to Drupal 10 end of life, the audit and the decision need to finish early enough to leave time for execution.

1. Weeks 1 and 2: Complete layers 1 and 2. Confirm versions, move 10.5.x and earlier sites to 10.6.x, and submit runtime change requests.
2. Weeks 3 and 4: Complete layers 3 and 4. Compile the module and custom code findings.
3. Week 5: Complete layer 5, then choose the route and obtain sign-off.
4. Weeks 6 to 8: Execute routes one or two in non-production first and then in production, keeping a buffer before 9 December. Routes three and four begin interim measures in this period.

The arithmetic leaves about three weeks for execution. That fits a contained update and does not fit a rebuild, which is why the findings from the first four weeks decide the route.

Teams that want the five layers covered in one structured report before Drupal 10 end of life can review the Platform Performance solution from OpenSense Labs, which includes a 48-hour technical audit of Drupal sites.

Explore Our Solution Here!