Drupal 10 end of life: plan your upgrade through Drupal 11 to Drupal 12

Release information reviewed September 29, 2026.

Drupal 10 reaches end of life on December 9, 2026. Drupal 12 is scheduled for the week of December 7, 2026, according to the official core release schedule. As of this review, Drupal 12 is not yet a stable production release. A sensible plan separates the immediate need to leave Drupal 10 from the later decision about adopting Drupal 12.

Novus Digitech helps organizations upgrade existing Drupal websites, including sites developed by another agency. The first step is to understand your current dependencies and prepare a supported path, rather than treating a major upgrade as a one-line version change.

The supported route is Drupal 10 to 11 to 12

Drupal major versions cannot be skipped during an in-place upgrade. A Drupal 10 site must pass through Drupal 11 before moving to Drupal 12. The official upgrade overview specifies Drupal 11.3.0 or later as the intermediate requirement because earlier database updates are removed from Drupal 12.

Treat that requirement as a compatibility floor, not a recommendation to install an old minor release. Choose a currently supported release at each stage and follow its upgrade instructions. Complete and verify the database updates for the intermediate version before progressing.

These stages can be rehearsed together in a test environment, but each needs its own evidence. Check that content, permissions, configuration, and essential workflows behave correctly after each transition. When something fails, this makes it easier to identify which change introduced the problem.

Why waiting for Drupal 12 creates avoidable pressure

The Drupal 10 support deadline and planned Drupal 12 release fall in the same week. Waiting until then leaves little room to discover an incompatible module or an unavailable hosting upgrade. Prepare the move to Drupal 11 now, with enough time for testing and business approval.

End of life does not mean your website switches off on that date. It means the community-supported release lifecycle has ended. Continuing to run that version creates an operating decision that should be visible to the people responsible for the site. Review the dependency and support position instead of relying on the fact that pages still load.

Moving to Drupal 11 can provide a supported destination while you assess Drupal 12 readiness. The Drupal 12 platform announcement says Drupal 11 support is planned through at least the Drupal 13 release in mid-to-late 2028. Keep checking the published schedule as the project evolves.

Start with an inventory and readiness review

• Core and dependencies: record the installed Drupal release, Composer packages, contributed modules, themes, and patches.
• Custom code: identify deprecated APIs, unsupported assumptions, and business rules that need regression tests.
• Hosting: confirm available PHP and database versions, required extensions, and a safe testing environment.
• Content and integrations: list imports, forms, search, scheduled tasks, authentication, and external systems.
• Recovery: locate source code, database and file backups, access owners, and deployment instructions.

Classify each finding as ready, requiring an update, requiring replacement, or needing investigation. A maintained module with a compatible release is a different task from an abandoned extension that owns important data. Uninstalling an extension without understanding that data can make an upgrade harder, so establish a replacement or migration plan first.

Use automated compatibility checks to find likely issues, then inspect the affected code and behavior. A clean scan is useful evidence, but it does not prove that a custom integration or an editorial workflow will behave correctly under the new runtime.

Prepare the platform for Drupal 12 deliberately

The announced Drupal 12 requirements include PHP 8.5. Minimum database versions include MySQL 8.0, MariaDB 10.11, PostgreSQL 18, and SQLite 3.45. Confirm the current details in the official platform requirements, then check your actual hosting plan and application dependencies.

Changing PHP and the database can affect code outside Drupal core. Test command-line jobs, image processing, authentication libraries, and other integrations under the intended runtime. Schedule infrastructure changes with the hosting owner, including backups and a tested recovery route. Do not assume that a host offering a PHP version has already enabled it for every environment.

Use clear acceptance checks for each release

Build a representative staging copy with appropriate protection for personal data. Rehearse the upgrade and record the steps. Test public pages and the tasks that are easy to miss: editing translated content, reviewing a draft, submitting a form, processing a queue, finding a result in search, and viewing private information with the correct permissions.

Include mobile layouts, keyboard navigation, important redirects, metadata, and performance in the review. An upgrade is complete when the service works for its users, not simply when the update command exits successfully. Ask the relevant business owner to review the journeys that support enquiries or daily operations.

For the production change, agree a deployment window, final backup, content-editing arrangements, and the conditions for recovery. Check the live site immediately afterwards and review logs and failed jobs during the following days. Keep the release record with the code so a future maintainer can understand what happened.

Common questions before approving the work

Does an upgrade require a complete redesign?

Not necessarily. A compatibility upgrade can preserve the existing experience where the theme and components can be brought forward safely. A redesign may be useful when the current site no longer meets business needs, but it should have its own scope and acceptance criteria. Separating the decisions can reduce pressure around the support deadline.

Can we estimate the project from the Drupal version alone?

The version identifies the starting point, but custom code, contributed extensions, integrations, and test coverage often determine the effort. An initial assessment should produce a list of blockers and uncertainties. Use that evidence to estimate the work and reserve time for content-owner review.

What if one module is not ready?

Investigate whether a compatible maintained release, a supported alternative, or a carefully scoped custom change can meet the requirement. Confirm how its stored data will be preserved. Avoid installing an unreviewed patch simply to make a dependency check pass.

When should you move from Drupal 11 to Drupal 12?

Assess that move after Drupal 12 has a stable release and the dependencies your site needs are ready. A test environment can be used for earlier compatibility work, but a prerelease should not be presented as an ordinary production upgrade. Set the date around readiness, business constraints, and support coverage rather than a version number alone.

Novus Digitech can help review your Drupal 10 site, resolve blockers, and plan the staged transition. Visit our Drupal upgrade service or request an upgrade discussion. Include your site address, current version, hosting provider, and any known custom modules so we can start with the likely dependencies and an achievable sequence.