Drupal 10 end of life on 9 December 2026: what to do now

The official Drupal 10, 11 and 12 timeline

All dates below come from the official drupal.org, php.net and symfony.com pages, checked on 26 September 2026. A "week of" date is a planned release window and can move.

Drupal 10: end of life on 9 December 2026

The 10.6 branch is the last Drupal 10 minor release. Its security support ends in the week of 7 December 2026, and Drupal 10 reaches end of life on 9 December. After that, no release and no fix is published for Drupal 10 core.

Drupal 11: supported until mid-late 2028

The Drupal 12 platform requirements announcement of 14 January 2026 states that Drupal 11 "will continue to be supported until mid-late 2028, at least until the release of Drupal 13" (drupal.org).

Mind the minor-release rule: each minor version is supported for one year, with bug and security fixes for six months, then security fixes only for six more. New minors ship roughly every six months, in June and December (drupal.org release process). Reaching Drupal 11 is not the end of it: you then need to follow minor releases to stay covered.

Drupal 12: planned for the week of 7 December 2026

The official schedule plans Drupal 12.0.0 for the week of 7 December 2026, the same week Drupal 10 reaches end of life. That date depends on progress. The June 2026 window was dropped in March in favour of August (drupal.org post of 23 March 2026), and the schedule then moved to December. As of 26 September 2026, the releases page lists only 12.0.0-alpha1, although beta1 was planned for the week of 14 September (drupal.org releases). We will update this guide at each milestone.

PHP, Symfony and database requirements

Sources: PHP requirements, database server requirements, 10.2.0 release notes, 11.0.0 release notes and the Drupal 12 requirements announcement (drupal.org). Drupal 12 will also need Apache 2.4.7 or nginx 1.1 at least, will not support IIS, and recommends Composer 2.9.3.

A site left on Drupal 10 with PHP 8.1 or 8.2 carries two debts: PHP 8.1 is no longer listed as supported, and PHP 8.2 gets no security fixes after 31 December 2026 (php.net). For PHP 8.5, which Drupal 12 will require, see our PHP 8.5 guide.

What actually changes on 10 December 2026

No more core security fixes

The site does not go offline. It keeps rendering and working. But a core vulnerability discovered after that date will not be fixed for Drupal 10. The risk grows over time, because each advisory published for supported versions may affect code that is still identical in Drupal 10.

Contributed modules move on

Maintainers focus on supported versions. New module releases will gradually drop Drupal 10 compatibility, and fixes will stop reaching the branches that keep it. This is often where the debt shows first: a payment, SSO or forms module that no longer follows. Our article on Drupal private files security shows what an open vulnerability can cost.

Hosting follows: PHP and Symfony

Drupal 10 runs on Symfony 6.4, whose security fixes end in November 2027 (symfony.com). PHP 8.2 loses support after 31 December 2026. Staying on Drupal 10 often means staying on an ageing PHP stack as well, which makes operations and audits harder.

Audits, insurance and contracts

An unsupported component can be flagged in a security audit or a penetration test. Ask three questions. Does your security policy ban unsupported components? Do your client contracts or your insurer require it? Who signs the exception if the upgrade slips into 2027?

Drupal 11 or Drupal 12: which target?

Aim for Drupal 11, for four reasons.

• You cannot skip a major version: there is no direct path from Drupal 10 to Drupal 12.
• Drupal 12 removes all core updates prior to 11.3.0, so a site must be on Drupal 11.3 or later before moving to Drupal 12 (drupal.org).
• Drupal 12 will ship, at best, in the week Drupal 10 reaches end of life, and it will require PHP 8.5.
• Contributed modules will need time to publish Drupal 12 compatible releases.

The recommended path: move to the latest 10.6.x release, upgrade to an up-to-date Drupal 11 (11.3 at least), then prepare Drupal 12 during 2027 as part of regular maintenance, with no deadline pressure.

Include Drupal 12 in the audit as well. It removes six modules from core: Ban, Contact, Field Layout, History, Migrate Drupal and Migrate Drupal UI (drupal.org). If your site uses the core contact forms (Contact module), plan for its contributed version or another form before Drupal 12.

Upgrade or migration: what are we talking about?

The two words are often mixed up in quotes, and the confusion inflates budgets.

For a Drupal 7 site, target Drupal 11: the core Migrate Drupal and Migrate Drupal UI modules, used to bring over a Drupal 7 site, are removed from Drupal 12 (drupal.org). See our Drupal 7 to Drupal 11 migration service.

Where does your site stand? A one-hour check

Before any quote, collect four facts. You need access to the site administration and, ideally, to the server.

1. The exact Drupal version: Reports, then Status report in the administration, or the drush status command.
2. The PHP and database versions, shown in the same status report.
3. The list of contributed modules, custom modules and the theme, with their versions.
4. The output of the Upgrade Status module, installed on a copy of the site and never in production: it lists what blocks the move to Drupal 11.

You will land in one of three cases.

• The site runs 10.3 or later on PHP 8.3, with little custom code: a standard upgrade.
• The site runs an old Drupal 10, or many modules lack a Drupal 11 release: plan a clean-up batch before the upgrade.
• Nobody can answer, the vendor has gone or the site is unstable: start with a takeover.

Upgrade, take over or rebuild: a decision table

Find your situation in the table. The last column points to the right next step.

The Drupal 11 upgrade checklist

Thirteen items in five stages, ready to paste into your ticketing tool. Commands come from the official upgrade documentation (updated on 21 August 2026).

1. Prepare

1. Record the Drupal, PHP, database and Composer versions.
2. List contributed modules, custom modules and themes.
3. Run Upgrade Status on a copy of the site.
4. Check that hosting provides PHP 8.3 or 8.4 and a compatible database: MySQL 8.0, MariaDB 10.6 or PostgreSQL 16 at least.
5. Find any use of the modules removed from Drupal 11 core (Actions UI, Activity Tracker, Book, Forum, Statistics, Tour): uninstall them or plan their contributed version.
6. Prepare acceptance testing with anonymised data.

2. Update the code

7. Move to the latest 10.6.x release (10.3.0 is the required minimum).
8. Fix deprecated code with Drupal Rector, then review the changes.
9. Update contributed modules to releases compatible with Drupal 10 and 11, and check the theme and Twig templates. For a headless site, also check the JSON:API or GraphQL modules and the front end.

3. Upgrade

10. Run the documented commands, then export the configuration.

composer require 'drupal/core-recommended:^11' \
  'drupal/core-composer-scaffold:^11' \
  'drupal/core-project-message:^11' --no-update
composer update --dry-run
composer update
drush updatedb:status
drush updatedb

The documentation also gives commands for specific cases: updating Drush, the development tools (core-dev), or only core and Drush. It does not include a configuration export. We add that step to commit the configuration changed by the database updates.

drush config:export

4. Test and switch

11. Test critical user journeys, run automated tests and static analysis, measure performance, check accessibility non-regression (WCAG 2.2, or RGAA 4.1.2 in France) and SEO: URLs, redirects, sitemap, meta tags.
12. Prepare a switch with rollback: database and files backup, versioned code, a window outside any release freeze.

5. After the switch

13. Watch the logs (drush watchdog:tail), subscribe to Drupal security advisories, plan maintenance to stay on a supported minor release, then prepare Drupal 12.

To test each step safely, we use on-demand test environments for every update.

How long does it take and what does it cost?

What drives the effort

• Contributed modules without a Drupal 11 release, and custom code to fix.
• A custom theme and old Twig templates.
• Integrations: SSO, CRM, payment, internal APIs.
• Multilingual, multisite and a headless front end.
• Hosting: whether PHP 8.3 is available, and who upgrades it.
• Your acceptance, security and internal sign-off requirements.

Three site profiles

The firm quote comes out of the Drupal 11 compatibility audit, based on the actual inventory of your modules and code.

The cost of doing nothing

It cannot be priced upfront, but its items are known: emergency fixes under pressure, security exceptions to obtain and renew, possible incidents, and a heavier upgrade later. A site left on Drupal 10 will have to go through Drupal 11 before Drupal 12: two steps instead of one.

Not ready by 9 December? Plan B

If the upgrade cannot land before the deadline, reduce the risk and set a date.

• Stay on the latest 10.6.x release until the end: it receives the last fixes.
• Shrink the attack surface: admin accounts, unused modules, back-office access restricted by IP address or VPN.
• Add a web application firewall and log monitoring.
• Schedule the upgrade in the first quarter of 2027 with a firm date approved by management.

Document the decision as well: planned end date, accepted risks, compensating measures and owner. You will need it at your next security audit.

On extended support: as of 26 September 2026, no Drupal Association partner publishes an extended support offer for Drupal 10. HeroDevs, which presents itself as the first Drupal Extended Security Support partner of the Drupal Association, offers coverage for Drupal 7; its NES for Drupal page does not mention Drupal 10. We will check again at every update.

Specific cases

Banks and insurers in Morocco and the region

Three constraints come up every time: the change advisory board, a possible year-end release freeze, and hosting. On premises or on OpenShift, the PHP version depends on an image approved by security, so request the PHP 8.3 image early. Plan a penetration test after the switch and acceptance testing on anonymised data, in line with Moroccan data protection law 09-08 (text published by the CNDP, in French). VOID supports Drupal portals on Red Hat OpenShift, such as those of Al Barid Bank since 2020 and Diriddik since 2021.

If your change advisory board meets once a month, build its dates into the plan: the switch date often depends on that calendar more than on the technical effort.

European companies working with a nearshore team

Scope the work as a project: perimeter, acceptance, switch, warranty. Run acceptance tests on fictitious or anonymised data. France's data protection authority recommends it for development and testing (CNIL guidance, in French), and it follows the data minimisation principle of the GDPR (Article 5). Add an accessibility non-regression check against the standard that applies to you. Ask for reversibility too: code, access and documentation must be handed back on request. VOID delivers these upgrades from Casablanca, on Paris working hours (0 to 1 hour time difference depending on the season). Working languages: [TO PROVIDE: languages in which the VOID team can run meetings, write deliverables and handle support]. See our nearshore development in Morocco page.

Before signing, ask for a week-by-week schedule, a written rollback plan and the list of what is out of scope.

Headless Drupal with Next.js

Upgrading the back office does not touch the front end as long as the API stays stable. Check the JSON:API or GraphQL modules, authentication between the front end and Drupal, and caching. VOID has published several headless Drupal projects with Next.js, including the Wafa Assurance portal on Drupal 10, the Casablanca Stock Exchange and RMA Assurance.

Multisite platforms

A shared codebase is upgraded once for all sites, so acceptance testing must cover every site before the switch. Since 2018, VOID has supported the multisite Drupal portal of Elsan, a French private hospital group, which federates 140 healthcare facilities.

How VOID can help

We offer four packages: a Drupal 11 compatibility audit, the Drupal 10 to 11 upgrade, a takeover of your Drupal site when the vendor has changed or disappeared, and a Drupal 7 to Drupal 11 migration. Updates are tested before production in dedicated environments on our VOID DevOps Platform (DDEV, Docker, Playwright, SonarQube). Our team in Casablanca keeps Paris working hours, with a 0 to 1 hour time difference depending on the season. 22 of the 24 projects published on our site use Drupal, and VOID's Drupal.org profile lists 6 maintained projects and 19 credits. See also our Drupal expertise.

Frequently asked questions

Sources

Official pages checked on 26 September 2026.

• drupal.org: Drupal core release schedule (updated on 27 August 2026)
• drupal.org: Releases for Drupal core
• drupal.org: Release process overview
• drupal.org: Announcing Drupal 12.0.0 platform requirements (14 January 2026)
• drupal.org: Help us reach Drupal 12's second release window in August (23 March 2026)
• drupal.org: PHP requirements and Database server requirements
• drupal.org: How to upgrade from Drupal 10 to Drupal 11 and How to upgrade from Drupal 11 to Drupal 12 (updated on 21 August 2026)
• drupal.org: 10.2.0 release notes and 11.0.0
• php.net: Supported Versions
• symfony.com: Symfony 6.4
• HeroDevs: NES for Drupal
• W3C: WCAG 2.2, accessibilite.numerique.gouv.fr: RGAA 4.1.2 and CNDP: law 09-08 (in French)
• EUR-Lex: Regulation (EU) 2016/679 (GDPR), Article 5, and CNIL: “Sécurité : Encadrer les développements informatiques” (14 March 2024, in French)