Drupal 10 ends on December 9: move to Drupal 11 in time

On December 9, 2026, Drupal 10 reaches end of life: after that date, no new Drupal 10 releases will be made, including security releases (Drupal.org). A large part of the installed base is affected, because 43.2 percent of installations from Drupal 8 onward that report to Drupal.org still ran Drupal 10 in the week starting October 4, 2026 (Drupal.org). The path leads through Drupal 11, because a major version cannot be skipped during an upgrade (Drupal.org). This guide shows which platform Drupal 11 requires, how to check modules and custom code, and how to fit the upgrade into a realistic schedule before December. If you would rather not handle it yourself, our Drupal agency takes care of the implementation.

What ends on December 9, 2026

Drupal 10.0.0 was released on December 15, 2022 (Drupal.org). Almost four years later, on December 9, 2026, it is over: according to the release schedule of the Drupal core release managers, Drupal 10 reaches end of life on that day, and no new Drupal 10 releases will be made afterward (Drupal.org). Drupal 12 will be released in the same week (Drupal.org).

The last minor release is Drupal 10.6.0 (Drupal.org). Drupal publishes security releases in fixed windows, usually on the third Wednesday of the month (Drupal.org). These windows currently apply to Drupal 11.4.x, 11.3.x and 10.6.x (Drupal.org). Under this rule, the last regular security window before end of life falls on November 18, 2026. In rare cases, a security release can also be published outside the windows; a public service announcement is then published beforehand (Drupal.org).

Drupal 10 will reach end of life on December 9, 2026. This is the same week that Drupal 12 will be released. No new releases of Drupal 10 will be made after this date.

Drupal.org, Drupal core release schedule

Several dates converge in December, as the overview of the branches shows.

What end of life means in practice is defined by the policy of the Drupal security team: security advisories are only made for stable releases in the supported major version branches (Drupal.org). Supported means two things: supported by Drupal core and by the respective project maintainer (Drupal.org). After December 9, Drupal 10 drops out of this circle, for core as well as for the contributed modules running on it.

How many websites still run Drupal 10

The usage statistics on Drupal.org show how large the installed base is. They count, for each week, the installations that report which version they use (Drupal.org). In the week starting October 4, 2026, that was 531,499 installations from Drupal 8 onward. Of these, 229,721 ran Drupal 10, or 43.2 percent (Drupal.org). Drupal 11 accounted for 208,459 installations or 39.2 percent (Drupal.org).

Within Drupal 10, the installed base is unevenly distributed. 170,190 installations reported Drupal 10.6, which is 74.1 percent of Drupal 10 installations (Drupal.org). The remaining 59,531 installations or 25.9 percent ran 10.0 to 10.5 (Drupal.org), minor releases for which the release schedule already provides no security window (Drupal.org). For these websites, the first step is overdue. In addition, 17.4 percent of reporting installations run Drupal 8 or 9 (Drupal.org), which reached end of life on November 17, 2021 and November 1, 2023 (Drupal.org).

Why the path only leads through Drupal 11

Drupal does not let you skip a major version during an upgrade (Drupal.org). The reason is technical: only the updates between consecutive major versions are included, and older ones are removed (Drupal.org). This concerns configuration, database schema and fields. A Drupal 10 website therefore cannot move straight to Drupal 12 in December, even though both dates fall in the same week.

For the first step, Drupal 11 requires at least Drupal 10.3.0 as the starting point, because all core updates prior to 10.3.0 have been removed in Drupal 11 (Drupal.org). The same principle applies one level up for the second step: before upgrading to Drupal 12, a website must be on at least Drupal 11.3.0 (Drupal.org). The path therefore runs from 10.6 to 11.4 and later to 12. Anyone still running an older Drupal 10 minor release first brings it up to the current 10.6 release.

Drupal 11 is not a short stopover either. Major versions are released every two years (Drupal.org), and each is supported until two further major versions have been released (Drupal.org). When Drupal 12 is released, Drupal 11 gets a maintenance minor release with the same API and enters a long-term support phase (Drupal.org). The release schedule does not yet give a fixed end date for Drupal 11.

Platform first: PHP and database

Drupal 10 requires at least PHP 8.1 (Drupal.org), while Drupal 11 requires PHP 8.3 or later (Drupal.org). A Drupal 10 website on PHP 8.1 or 8.2 therefore has to switch its PHP version before the upgrade. The table shows which PHP versions Drupal supports per release according to Drupal.org and how long the PHP project provides security fixes for them.

This suggests a sensible order: PHP 8.3 and 8.4 run with Drupal 10.6 as well as with Drupal 11.3 and 11.4 (Drupal.org). Switching the PHP version while still on Drupal 10 separates two changes. The security window of a Drupal minor release applies as long as a supported PHP version is used (Drupal.org). If dependencies drop an older PHP version, Drupal can no longer ensure security coverage for those installations (Drupal.org). PHP 8.1 has been without security fixes since December 31, 2025, and PHP 8.2 follows on December 31, 2026 (php.net). Our article on the end of support for PHP 8.2 describes the checks for such a switch, using WordPress as the example.

The database server has to fit as well: Drupal 11 requires MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later, or SQLite 3.45 or later, and Drupal 12 raises MariaDB and PostgreSQL once more (Drupal.org). If you use MySQL, check the database server at the same time, see our article on MySQL 8.0 at end of support.

Modules, themes and custom code

Drupal 11 removed several core modules that were already deprecated in Drupal 10: Actions UI, Activity Tracker, Book, Forum, Statistics and Tour (Drupal.org). If you use one of them, there are two options: stop using the module before the upgrade, or replace it with the contributed version of the same name while still on Drupal 10.3 or later (Drupal.org). For themes, the next change is already set: the administration theme Claro is deprecated as of Drupal 11.5.0 and removed from core in Drupal 12.0.0 (Drupal.org), and the same applies to the front-end theme Olivero (Drupal.org). If you change the theme as part of the upgrade, check accessibility as well; more on that under accessibility optimization.

For contributed modules and custom code, the documentation names two tools from the Drupal project: Upgrade Status shows where Drupal 11 compatibility is missing, and Drupal Rector replaces code deprecated in Drupal 10 (Drupal.org). Both are open source and belong in the test environment, not on the live website. The documentation advises checking for Drupal 11 versions manually as well, because the report may not identify every compatible version (Drupal.org).

• Note the core version and PHP version of the website
• List active modules and themes, separated into core, contributed and custom
• Check for each contributed module whether a Drupal 11 release exists
• Search the installation for removed core modules such as Book, Forum or Statistics
• Document customized scaffold files such as .htaccess, because all core files change during the upgrade (Drupal.org)
• Clarify command-line access with Composer and Drush (Drupal.org)
• Match the PHP version and database server against the Drupal 11 requirements

A few commands on the command line of the test environment are enough for the inventory. The last one shows which packages still stand in the way of an upgrade to Drupal 11.

When a module is not ready yet

• Search the module issue queue for a Drupal 11 patch (Drupal.org)
• Pull in modules that only work with a patch through the Drupal Lenient Composer endpoint (Drupal.org)
• Allow two major versions of a module in composer.json, such as ^6.1 || ^7.0, to bridge the transition (Drupal.org)
• Work with the module maintainers and contribute the fix
• Replace or remove a rarely used module instead of letting the upgrade fail because of it
• Implement business-critical functions as a custom module, for example through our custom programming

The upgrade in five steps

The documentation on Drupal.org describes the upgrade for installations managed with Composer and recommends performing it locally first and only then deploying it to the server (Drupal.org). We work in this order, with each step done in the test environment first:

1. Update Drupal 10: core to the current 10.6 release, contributed modules to their latest releases.
2. Raise PHP and database: PHP 8.3 or 8.4, database server according to the Drupal 11 requirements.
3. Replace removed modules and adapt code: work through the Upgrade Status report, use Drupal Rector for custom modules and themes.
4. Raise core with Composer: set the core packages to Drupal 11, dry run, then update and run database updates (Drupal.org).
5. Check and roll out: file permissions, logs, cron and tests, then transfer to the live website (Drupal.org).

# Open write permissions for the settings files
chmod u+w web/sites/default
chmod u+w web/sites/default/*settings.php
chmod u+w web/sites/default/*services.yml

# Set core packages to Drupal 11, without updating yet
composer require 'drupal/core-recommended:^11' \
  'drupal/core-composer-scaffold:^11' \
  'drupal/core-project-message:^11' --no-update
composer require drush/drush --no-update

# Since Drupal 11.4, symfony/runtime is a Composer plugin
composer config allow-plugins.symfony/runtime true

# Dry run, then update
composer update --dry-run
composer update

# Run database updates
drush updatedb:status
drush updatedb

# Restore permissions
chmod 755 web/sites/default
chmod 644 web/sites/default/*settings.php
chmod 644 web/sites/default/*services.yml

If Composer cannot resolve the dependencies, the documentation suggests a more specific constraint such as ^11.4 instead of ^11 (Drupal.org). Since Drupal 11.4, core also ships symfony/runtime as a Composer plugin that has to be allowed explicitly (Drupal.org); otherwise the update stalls at a prompt.

What to check after the upgrade

• Restore and check file permissions of the settings files (Drupal.org)
• Follow the logs while clicking through, for example with drush watchdog:tail (Drupal.org)
• Run cron once manually (Drupal.org)
• Run existing automated tests (Drupal.org)
• Test forms, search, the editorial interface and language versions manually
• Clear caches and compare the load times of the most important pages with the state before the upgrade

Schedule until December 9

This article is published on October 30, 2026, which leaves 40 days until Drupal 10 reaches end of life. For a website with a manageable number of modules, that is usually enough if the inventory starts now. It is important to factor in the dates of the release schedule:

1. By mid-November: inventory, PHP switch to 8.3 or 8.4 and module review in the test environment.
2. November 18, 2026: under the rule of the release schedule, the last regular security window before end of life (Drupal.org). If a security release for 10.6 is published there, it still gets installed.
3. By the end of November: complete the upgrade to Drupal 11.4 in the test environment, get sign-off from the editorial team, set the date for the switch.
4. Early December: switch the live website, ideally before the week of December 7, in which Drupal 12.0 and 11.5 are released (Drupal.org).
5. Afterward: schedule Drupal 11.5 in the usual maintenance cycle. Each minor release is supported for one year, six months with bug and security fixes and another six months with security fixes only (Drupal.org).

The buffer before the week of December 7 has another reason: in a week in which a new core major or minor release comes out, no security releases are issued for contributed projects (Drupal.org). If you also run a store, further deadlines come up around the turn of the year, for example for e-invoicing, see ZUGFeRD straight from Shopware.

And if time runs short? A website that misses the date keeps running on December 10, but without new Drupal 10 releases (Drupal.org). Then the task is to shrink the attack surface: uninstall unused modules, restrict access to the administration, watch the logs and firmly schedule the upgrade for January. This should not become a permanent state.

Upgrade or switch systems?

For some site owners, end of life is the occasion to question the system altogether. As a rule, upgrading within Drupal is the shorter path: content model, URLs and permissions stay in place, and the technical base changes. Switching to another CMS, by contrast, is a migration project with a content audit, URL mapping and redirects, as we describe in the article on CMS migration. For a larger website, such a switch can hardly be completed by December 9. In that case it makes sense to move to Drupal 11 first and settle the system question afterward without time pressure.

Comparable steps for other systems are described in the articles on upgrading to TYPO3 14 LTS and on the end of support for Magento 2.4.7. Our page on CMS solutions gives an overview.

How we support the upgrade to Drupal 11

As a Drupal agency, we handle the upgrade from the inventory to operation afterward. The inventory results in a plan with effort, order and date.

If you want to clarify beforehand whether an upgrade or a rebuild fits your website better, that starts with consulting. For the upgrade itself: the sooner the inventory is done, the more buffer remains before December 9.