Drupal 10 End of Life and the Drupal 11 Upgrade: A Practical Plan

Drupal 10 reaches end of life on 9 December 2026. If your organisation runs a Drupal 10 site, that date decides how you spend the next few weeks, and the answer is usually an upgrade to Drupal 11 rather than a rebuild. This post covers what end of life means for an Australian organisation, how to check readiness, the upgrade path, what usually breaks, and when replatforming is the better call.

What end of life actually means

Drupal.org’s release cycle page states it plainly: “Drupal 10 will reach end of life on December 9, 2026.” The same page lists 10.6 as the last Drupal 10 minor release. After the date, no new Drupal 10 releases are made, and the Drupal Security Team stops publishing advisories and fixes for it.

The site does not stop working on 10 December. What changes is the risk. A security flaw fixed in Drupal 11 after that date becomes public through the fix, while Drupal 10 gets no patch. The exposure grows each month. The same applies to the contributed modules your site depends on once their maintainers stop supporting Drupal 10.

For an Australian organisation that matters in two practical ways:

• Security reviews. Whoever reviews your systems, internal or external, will ask whether the CMS is supported.
• Procurement and security questionnaires. These often ask whether software is supported, and an unsupported CMS is a hard answer to give. Also check your host’s own Drupal support policy.

Also note that minors age out earlier than the major. Security support for a minor ends about six months after the next minor is released, so a site on an older 10.x minor may already be outside support. Drupal’s own schedule shows 11.2 and 10.5 leaving security support in the week of 29 June 2026, and 11.3 and 10.6 leaving it in the week of 7 December 2026. Upgrading to 11 does not finish the job if you land on a minor that is about to drop out. Plan to land on a current 11 minor.

Where Drupal 11 stands

Drupal 11.0 was released on 2 August 2024. At the time of writing, 11.4 is the current minor, and the schedule shows Drupal 12 due in the week of 7 December 2026, alongside 11.5. Sites that are clean on Drupal 11, with no deprecated API calls, are the ones best placed to move to 12 with little work. That is a reason to do the 11 upgrade properly rather than just getting it to boot.

The platform requirements are higher than Drupal 10:

	Drupal 10	Drupal 11
PHP minimum	8.1	8.3
MySQL	5.7.8	8.0
MariaDB	10.3.7	10.6
PostgreSQL	12	16
SQLite	3.26	3.45

PHP 8.4 is supported from Drupal 11.1, and PHP 8.5 from 11.3. If your server is still on PHP 8.1 or 8.2, the infrastructure upgrade is the first piece of work, and it can run ahead of the Drupal work. Our post on PHP 8.2 end of life covers that side.

Check readiness before you commit

The Drupal.org upgrade guide gives the first gate: the site must be on Drupal 10.3 or later, with PHP 8.3 or later in place for the move. Everything before 10.3.0 has been removed from Drupal 11’s update path, so an older 10.x site updates to 10.3 or later first.

Then run Upgrade Status. This contributed module reviews “Drupal major upgrade readiness of the environment and components of the site”. It checks whether your environment meets the next version’s requirements, which contributed projects need updating, and runs static analysis over your custom code for compatibility problems. It runs against the current site: a Drupal 10 site is checked for Drupal 11, and most checks cannot run after the upgrade because the deprecated APIs are gone.

The output sorts the work into three buckets, and the sizes of those buckets are the estimate:

1. Contributed modules. Which have a Drupal 11 release, which have a patch in the issue queue, and which have nothing.
2. Custom modules and themes. Which call APIs deprecated in Drupal 10.
3. Environment. PHP, database and extensions.

Spend an afternoon on this before any quote is given or accepted. A scoping conversation without an Upgrade Status report is guesswork.

The upgrade path

The Drupal.org guide sets out the sequence, and ours follows it.

1. Reach the starting point. Get core to 10.3 or later and PHP to 8.3 or later.
2. Retire what core removed. Modules removed from Drupal 11 core, such as Book, Forum, Statistics and Tour, need replacing or dropping before the upgrade.
3. Deal with contributed modules. Update to Drupal 11 compatible releases, apply patches from issue queues where a release is not out yet, or replace the module. Composer’s lenient endpoint helps with modules that work on 11 but have not yet declared it.
4. Fix deprecated code. Drupal Rector automates a large share of the mechanical changes in custom code, and Upgrade Status finds the rest. Review Rector’s output rather than accepting it wholesale.
5. Run the Composer update. Require the Drupal 11 core packages, run a dry run first, then update, then drush updatedb.
6. Test and deploy. Regression test on staging, user acceptance testing, then a production release with a documented rollback.

We do the work on a staging copy first, sprint by sprint, so that each step has a known state to return to.

What usually breaks

The order of pain is fairly consistent.

Contributed modules. This is where schedules slip. A module that is stable and widely used usually has a Drupal 11 release. A niche module, or one that one volunteer maintains, may not, and then you choose between a patch, a fork, a replacement and dropping the feature. Each of those is a decision for someone in the business, not only a developer task.

Custom code. Deprecated APIs removed in 11 cause fatal errors, and the volume depends on how long ago the code was written. Rector clears the easy cases. Code that reaches into core internals needs hand work.

Themes. Twig and JavaScript changes, library updates and base theme compatibility cause visual regressions that automated checks do not catch. Compare pages side by side.

Search, integrations and configuration. Search API with an external index, SSO, payment and CRM integrations each need a test pass. Configuration that was exported from an older core can also need review.

Environment. A PHP 8.3 jump often exposes old extensions and Composer constraints that nobody had touched for years.

A recent example: AEMC

We are partway through this on the Australian Energy Market Commission’s site. We implemented and support their publishing platform, and the Drupal website was on 10.1.8. The upgrade was scoped against Drupal 11.3.10, with a safe production deployment and a rollback plan as part of the scope. Because 11.3 leaves security support in the week of 7 December 2026, we are working through which minor to release on, and the same check applies to any site you plan.

The work was planned in six phases over 16 sprints. We have completed the infrastructure and PHP upgrade, the core upgrade, and the upgrade of all 30 contributed modules on staging, including Paragraphs, Webform, Search API with OpenSearch, Metatag and Media. That ran under the existing support arrangement. Code fixes, regression testing, user acceptance, performance checks and the production deployment are the remaining phases, so we are not claiming a finished production release here.

What made the staging stage tractable was working sprint by sprint, with each sprint’s modules settled before the next. It also shows why the readiness check matters: 30 modules is a long list, and every one of them was a separate question.

Timeline shape

Every upgrade looks different in detail, but the shape is consistent:

Stage	What happens
Readiness	Upgrade Status report, decisions on at-risk modules
Environment	PHP and database upgrades, usually in parallel
Staging upgrade	Core, contributed modules, Composer, database updates
Code fixes	Rector, hand fixes for custom modules and themes
Test	Regression, user acceptance, performance
Release	Production deployment, monitoring, rollback ready

The readiness stage is short and the testing stage is the one that gets squeezed. Work backwards from 9 December and leave room for testing; if the calendar already makes that impossible, say so now, because the answer may be an interim plan, such as a documented risk acceptance and extra monitoring, rather than a rushed release.

When to replatform instead

An upgrade is the right answer when the site’s content model and design still serve the organisation. Compare a replatform fairly when:

• most of the contributed modules you depend on have no Drupal 11 path;
• the site’s structure is the problem, not the version, and a content redesign is overdue anyway;
• the custom code is large, untested and effectively unmaintainable;
• the organisation wants to move away from Drupal for reasons unrelated to the upgrade, such as hosting cost or skills.

A replatform is usually a bigger project than an upgrade, so it does not solve a December deadline. If you want out of Drupal, you still upgrade first to stay supported while you plan the move. For help judging a codebase that has become hard to change, see our project rescue approach, and our wider note on framework version upgrades.

Sources: Drupal core release cycle, How to upgrade from Drupal 10 to Drupal 11, PHP requirements, Database server requirements, Upgrade Status module and Drupal Rector, checked November 2026.