Drupal 12 Slipped to December. Drupal 10 Still Runs Out of Road

By Greg Nowak. Last updated 2026-08-07.

Drupal 12 is now scheduled for the week of December 7, 2026. Drupal 10 reaches end of life on December 9. At first glance, those dates seem to support a tidy plan: stay on Drupal 10, wait for Drupal 12, then modernise the site once.

Unfortunately, Drupal's upgrade path does not work that way. Major versions cannot be skipped. A Drupal 10 site must move to Drupal 11.3.0 or later before it can move to Drupal 12.

Waiting until December would not remove the Drupal 11 upgrade. It would squeeze two major upgrades, two rounds of testing and any necessary platform changes into the same week that Drupal 10 support ends.

A more workable target is to put Drupal 11.3 or later into production well before December, then prepare and rehearse the Drupal 12 move separately. That gives the project a stable checkpoint instead of turning the final release into an end-of-life rescue.

The dates leave little room for discovery

The current core schedule sets September 11 as the deadline for Drupal 12 beta requirements. Beta 1 is planned for the week of September 14, followed by a release candidate in the week of November 9. Drupal 12.0.0 and Drupal 11.5.0 are due in the week of December 7.

Security support for Drupal 10.6.x and Drupal 11.3.x also ends that week, with Drupal 10 reaching full end of life on December 9.

Those milestones are useful, but they do not create more time for delivery. A real production upgrade can uncover unsupported contributed projects, custom-code deprecations, Composer conflicts, PHP changes, database compatibility issues and failed regression tests. If those problems first appear in December, maintainers, hosting providers and business owners have almost no room to respond.

September should therefore be treated as a readiness checkpoint, not the day work begins. By the beta milestone, the team should already understand which dependencies are uncertain, which platform changes are required and how much custom code still needs attention.

Workstream	What should be achieved	Evidence needed
Application audit	Map core, contributed projects, custom code, Composer constraints, PHP and database dependencies.	Upgrade Status results, static-analysis findings and a prioritised blocker list.
Drupal 11 production move	Run the live site reliably on Drupal 11.3 or later.	Passing tests, updated database state, validated integrations and a rehearsed rollback.
Drupal 12 rehearsal	Maintain a separate branch that can follow beta and release-candidate changes.	Repeatable builds, reviewed automated fixes and a shrinking exception list.
Release decision	Move to Drupal 12 when the application and its dependencies are ready.	Stable compatible releases, a supported runtime, completed regression testing and deployment approval.

Separate the supported production upgrade from Drupal 12 readiness work, while keeping both moving.

Drupal 11.3 is the bridge, not a detour

Drupal provides update paths between consecutive major versions rather than every possible historical combination. Its upgrade documentation explains that Drupal 12 removes updates for configuration, database schemas, entities and fields up to Drupal 11.2. A Drupal 10 site must run those updates by reaching Drupal 11.3.0 or higher before attempting Drupal 12.

This is not merely a Composer constraint to work around. Database and configuration changes need to happen in the intended order. Combining too many changes at once also makes failures harder to diagnose. The cause could sit in core, an extension, custom code, the PHP runtime or stored data.

Running Drupal 11.3+ in production creates a useful control point. Editorial workflows, scheduled jobs, search, authentication, APIs, payments and any other relevant integrations can be checked without Drupal 12 changes muddying the picture. The team also gets to prove its deployment and rollback process. Drupal 12 testing can then begin from a known, working baseline.

Audit the whole application

Core is only one part of the upgrade. A credible assessment needs to cover contributed modules and themes, custom modules and themes, patches, Composer repositories, locked dependencies, PHP extensions, database versions and environment-specific deployment logic.

Contributed-project readiness also needs a closer look than a simple compatible-or-incompatible label. Acquia's Drupal 12 deprecation-status view identifies projects whose next step is to improve release stability. A project might declare Drupal 12 compatibility or show no detected deprecation errors while its available release is still an alpha, beta or release candidate. That is useful progress, but it may not meet an organisation's production stability policy.

The practical question is: does a release that the business is prepared to deploy support Drupal 12, and will Composer install it alongside every other required package?

Answering that means checking direct and transitive dependencies, abandoned packages, possible replacements, releases available from maintainers and the business importance of each feature. A single module supporting checkout or authentication deserves more attention than several unused administrative conveniences. Prioritise by operational impact, not module count.

Use automation early, then review the result

Drupal's refreshed Project Update Bot combines Upgrade Status for analysis with Drupal Rector for fixes. Its Drupal 12 rules cover more than 80% of the deprecated API uses introduced for the release. The refreshed analysis also resolves submodule dependencies, reducing failed scans and false errors that affected earlier results.

That can clear a substantial amount of mechanical work. It does not complete the migration. Generated patches still require code review, automated tests and functional verification. Static analysis can also expose custom behaviour for which there is no safe automatic fix.

Run these tools while there is still time to act on what they find. Sort the results, apply the changes that can be reviewed confidently and isolate the exceptions that need engineering judgement. The result is a concrete backlog rather than a vague compatibility concern.

Repeat the analysis as dependencies change. Readiness is a moving picture, especially between beta, release candidate and stable releases.

Plan the PHP changes alongside Drupal

The runtime transition is large enough to deserve its own workstream. Drupal 10.5 and 10.6 support PHP 8.1 through 8.4. Drupal 11.3 and 11.4 support PHP 8.3 through 8.5. Drupal 12.0 requires PHP 8.5.

That has two immediate consequences. A Drupal 10 site still using PHP 8.1 or 8.2 must change runtime before or during the Drupal 11 move. A site that reaches Drupal 11 on PHP 8.3 or 8.4 will still need another PHP upgrade for Drupal 12.

Drupal 12 also expects PHP to be compiled with Argon2 support for password hashing. The requirements documentation says this should normally be present with PHP 8.5, but it is worth checking rather than assuming. The same applies to PHP extensions, database connectors, command-line PHP, build images, hosting support and monitoring agents across development, staging and production.

It may make sense to separate the Drupal 11 application upgrade from the final move to PHP 8.5 and Drupal 12. The right sequence depends on the site's current runtime and dependency constraints. Tested Composer builds should settle that decision before anyone reaches the deployment window.

Run production and readiness as two tracks

The production track has a focused job: resolve Composer constraints, remove Drupal 11 blockers, update the database safely, test business-critical behaviour and deploy Drupal 11.3 or later with a rehearsed rollback. This establishes the mandatory stepping stone and proves the first major upgrade on its own.

A separate Drupal 12 branch can then follow beta and release-candidate changes without destabilising production. It should use reproducible dependency resolution, the intended PHP 8.5 environment, repeated static analysis and a documented list of exceptions. Keeping that branch aligned with the proven Drupal 11 baseline prevents the experimental work from drifting into a second, unrelated project.

This is the sort of upgrade programme Greg can coordinate: building the inventory, investigating Composer conflicts, running Upgrade Status and static analysis, reviewing automated deprecation fixes, checking PHP and database requirements, guiding the production move to Drupal 11.3+ and keeping a Drupal 12 rehearsal branch usable.

Drupal 12 has slipped, but Drupal 10's deadline has not moved out of the way. The extra months are valuable only if they are used to remove uncertainty. Get the site onto Drupal 11.3 or later, surface the remaining Drupal 12 blockers early and leave December for a considered release decision rather than an emergency upgrade.