What changes with Drupal 12? Features, requirements, and migration

Drupal 12.0.0 is planned for the week of December 7, 2026¹. Two days later, on December 9, 2026, Drupal 10 reaches its End of Life. Together, these two dates, rather than the new major version itself, rewrite the priorities of an IT roadmap for the next four quarters.

Platform requirements are already official: PHP 8.5 as the minimum runtime, Argon2id as the default password hashing algorithm, and six core modules being removed. This means preparation can begin today, rather than becoming an emergency as release day approaches.

Upgrading to Drupal 12 is not a migration project: it is an infrastructure modernization and custom code cleanup project. As such, and depending on your starting version, it should be launched months in advance, not in the weeks leading up to the release. Below are the verified requirements, the official timeline, an operational checklist with typical owners for each task, and the reason why core AI capabilities will arrive well before December 2026.

What really changes with Drupal 12: requirements, security, and a leaner core

Drupal 12 raises the minimum runtime to PHP 8.5, adopts Argon2id for password hashing, removes six modules from core, and recommends Composer 2.9.3. It is not an architectural rewrite: it is the removal of deprecated code accumulated throughout the Drupal 11 lifecycle.

It is worth looking at the column of what isn’t changing as well. The web server layer and browser policy remain stable: no network infrastructure migration, no work on reverse proxies, ingress controllers, or CDNs.

Drush² deserves special mention. For years it has been the de facto standard for command-line administration, created to fill major limitations in Drupal core’s CLI. Today, the direction has reversed: Drupal 11.4 introduces an extensible native CLI (vendor/bin/dr), allowing modules to register commands directly in core³, and the community has already published an official guide for porting Drush commands to the new interface⁴.

The stated intention is to write Drupal commands directly, making it likely that the migration will be complete with Drupal 12. At the same time, the initial draft of the Drupal 12 upgrade documentation⁵ features Drush 13 in its example code snippets, signaling that support might continue. There is no official confirmation on this point yet: we will have to wait for the documentation to mature to understand how things will evolve.

On the security front, the switch from bcrypt to Argon2id⁶ is the most notable change. Argon2id is a memory-hard algorithm: it deliberately saturates RAM during hash calculation, making GPU-accelerated brute-force attacks ineffective, which is precisely bcrypt’s weakness. Re-hashing existing password hashes occurs transparently upon each user’s first login, with an automatic fallback to bcrypt if the PHP environment lacks the necessary support: no forced password resets, no downtime.

This brings up a point that official documentation does not cover. PHP container images must include libsodium support or the argon2 extension; otherwise, the site silently remains on bcrypt without throwing any visible errors. Furthermore, PHP-FPM pods must be reviewed regarding memory limits, as authentication spikes will consume more RAM than before. Anyone working in regulated industries will find useful context in how Drupal core addresses compliance and data protection requirements, as reducing the attack surface is part of the same strategy.

Six modules leave core and move to contrib (Ban, Contact, Field Layout, History, Migrate Drupal, and Migrate Drupal UI): if your site uses even one of them, replacing it or installing its contrib version must be put on the roadmap now, not when the upgrade is already underway (especially if your site uses Contact for official forms, making it a business priority). The benefits of a leaner core are tangible: a smaller attack surface, lighter builds, and faster CI/CD pipelines.

Completing the picture are Gin as the default administration theme and alignment with Symfony 8, as even-numbered Drupal major releases are anchored to Symfony LTS (Long Term Support) releases, a key factor for organizations seeking extended lifecycles.

When is Drupal 12 released, and why is Drupal 10 the real deadline?

Drupal 12.0.0 will be released the week of December 7, 2026, alongside Drupal 11.5.0. Drupal 10 reaches End of Life on December 9, 2026⁷. Drupal 11 will remain supported until mid-to-late 2028. Those on Drupal 10 face a hard deadline at the end of 2026; those already on Drupal 11 have roughly two years of runway.

There are four key verifiable milestones in the cycle:

1. September 11, 2026: deadline for completing beta requirements.
2. Week of September 14, 2026: release of Drupal 12.0.0-beta1 and 11.5.0-beta1.
3. Week of November 9, 2026: release of rc1 for both release lines.
4. Week of December 7, 2026: stable release.

Maintenance windows remain fixed: bugfixes on the first Wednesday of the month, security releases on the third Wednesday. Having this level of predictability twelve to twenty-four months in advance is rarely emphasized in comparisons with proprietary DXPs, yet for an IT Director, it is worth more than any individual feature: it allows allocating budgets within already-approved financial cycles.

The real risk, however, isn’t missing the launch of Drupal 12: it is facing a double hop. The minimum source version for upgrading is Drupal 11.3.0⁸, because all previous update scripts have been removed from the Drupal 12 codebase.

If you enter December 2026 on Drupal 10, you will have to execute two sequential updates under pressure, not one. The lessons from previous cycles (from Drupal 7 end of support on January 5, 2025, to Drupal 9 reaching EOL in November 2023⁹) mirror what we gathered in our analysis of the transition to Drupal 10: the cost of an upgrade increases with delay, not with the technical distance between versions.

The overlap between Drupal 11 and Drupal 12 is therefore a governance lever, not a technical detail. With Drupal 11 supported until mid-to-late 2028 and the most impactful deprecations from Drupal 11.3 deferred to Drupal 13, the upgrade fits into routine maintenance. In budget terms: teams on Drupal 10 must complete their move to Drupal 11 by Q3 2026 to avoid overlapping with the December release window.

How to prepare a Drupal site today for the upgrade to Drupal 12

Preparation consists of four parallelizable tracks: updating the site to Drupal 11.3 or higher, auditing deprecated APIs using Upgrade Status and Drupal Rector, updating runtime and container images to PHP 8.5, and adding compatibility checks into the CI/CD pipeline. None of these four steps requires waiting for release day.

Here is the operational checklist, along with the typical owner for each item:

1. Alignment with Drupal 11.3.0 or higher (Drupal tech lead): non-negotiable prerequisite.
2. Audit of custom code and contrib modules with Upgrade Status (tech lead + developers): yields the deprecation inventory.
3. Automated refactoring with Drupal Rector¹⁰ (developers): applies transformation rules across the codebase.
4. Updating container images to PHP 8.5 (platform/DevOps team), verifying extensions required for Argon2id.
5. Verification of managed databases (platform team): checking RDS/Aurora and Cloud SQL against new minimum versions of MariaDB and PostgreSQL.
6. Replacement of the six removed core modules (analyst + developers), starting with Contact.

The key fact that mitigates perceived risk is Project Update Bot’s coverage: over 80% of deprecated APIs in Drupal 12 are handled by automated Rector rules¹¹ (some generated with AI assistance), with patches submitted directly to issue queues and final control left to maintainers.

However, that 80% applies to the contrib ecosystem. For enterprise custom code, where business value and technical debt converge, automated coverage is lower: proprietary integrations, custom themes, and tailored modules are what truly dictate upgrade duration and effort.

This is where automation ends and engineering begins. Custom themes must be checked against Gin as well as the new Styles API and Design Tokens API introduced in Drupal 11.3 and 11.4¹², which decouple theming from the application layer. Custom modules must be covered by automated tests running in pipelines. And Composer dependency management must be treated as a software supply chain security concern, not just a build step: the recommended Composer 2.9.3¹³ itself stems from a security patch. We have summarized the full methodological framework for code cleanup in our guide to upgrade planning and Drupal CMS migration.

A note from our experience: we have managed numerous enterprise upgrade projects, such as Caleffi, where we oversaw the transition from Drupal 7 to Drupal 10 and subsequently to Drupal 11. In that context, we also open-sourced the Drush pre-deploy module, which executes custom hooks before update:db during multi-environment deployments¹⁴. It is precisely this kind of control that turns a major version upgrade from a manual event into a repeatable operation.

The core AI wave: why Drupal 11.4 is the bridge to Drupal 12

The capabilities destined to transform daily workflows on Drupal projects (AI workflows, Context Control Centre, new design APIs) are not waiting for Drupal 12: they arrive in minor releases of Drupal 11. Updating today delivers functional innovations immediately while preparing for the upgrade in a single work cycle.

There is an old misconception to dismiss: major Drupal releases today remove deprecated code; they do not introduce features. For decision-makers, the takeaway is clear: postponing updates “while waiting for Drupal 12” means missing out on available features for twelve months without gaining any additional stability.

What is already available or coming to core and the broader ecosystem:

• Hundreds of AI modules (a year ago, when the Drupal AI Initiative was announced, there were already 290+ modules).

• The Context Control Centre in Drupal CMS 2.1 (based on core 11.3), which codifies brand voice, design systems, and regulatory requirements once, ensuring all AI outputs remain compliant¹⁵.

• The Human in the Loop pattern as recommended governance: AI generates drafts, humans review and approve before publishing¹⁶.

• Native HTMX¹⁷ integration in Drupal 11.3¹⁸, reducing the JavaScript payload¹⁹ for browser-server interactions by up to 71% by taking over from Drupal’s AJAX API; BigPipe remains in place to handle progressive server-side rendering.

• Drupal Canvas, the visual component-based page builder, and the experimental native command-line interface in Drupal 11.4²⁰.

There is also data that will resonate with CFOs: Drupal core 11.3 (on which Drupal CMS 2.1 is built) delivered the biggest performance boost in a decade across the ecosystem²¹, cutting database queries on uncached pages by 50% and significantly optimizing other operations, directly lowering cloud infrastructure costs and improving traffic spike management²². This is a benefit unlocked by updating minor versions, not by waiting for Drupal 12 in December.

In terms of contributions, you can already leverage the Guardrails system we contributed to the Drupal AI 1.3 module: an architecture that intercepts and filters communications with LLMs by applying pre- and post-processing validation rules to prevent sensitive data exposure²³. In the same realm sits search_api_typesense, our module for semantic search. We delve into this in detail in our overview on the evolution of Drupal AI and LLM integration. Further announcements are expected at DrupalCon Rotterdam, running September 28 to October 1, 2026.

The underlying discipline is identical: maintaining a continuous update process that brings AI features into production is precisely what turns the Drupal 12 upgrade into a non-event.

What to put on your roadmap now

1. If you are on Drupal 10 (or earlier), the upgrade to Drupal 11 must be completed by Q3 2026: after that, the window overlaps with the December release.
2. If you are on Drupal 11, initiate the deprecation audit and container updates to PHP 8.5 over the next two quarters.
3. In both cases, unlock AI capabilities and new design APIs by keeping up with minor updates, rather than waiting for December 2026.

If your Drupal release process is not automated via CI/CD with compatibility testing, upgrading to Drupal 12 won’t be a code problem; it will be an organizational one. Official documentation and upgrade guides cover commands. They do not cover your custom infrastructure or custom codebase.

For a readiness assessment of your custom code, themes, and infrastructure, speak with our Drupal team: as a Drupal Gold Certified Partner with deep Cloud Native expertise, we can evaluate what needs to be done and establish a quarter-by-quarter execution plan.

Notes and sources