Drupal 10's December 2026 Deadline: Start With the Upgrade Inventory

By Greg Nowak. Last updated 2026-06-26.

Drupal 10 now has a planning date that should be on every site owner's calendar. As of June 26, 2026, Drupal.org lists Drupal 10's end-of-life date as December 9, 2026. It also names Drupal 10.6.0 as the final Drupal 10 minor release, with no new Drupal 10 releases after that date.

That does not mean every Drupal 10 site is in trouble today. It does mean the useful conversation has changed. The right question is no longer, "Will we upgrade eventually?" It is, "What do we need to know before the Drupal 11 upgrade can be scheduled with confidence?"

The deadline exposes hidden project work

For business owners, operations leads, and agency teams, the risky part is rarely the last Composer command. The risk is all the hidden dependency work that has to be understood before that command is safe.

The official Drupal 10 to 11 upgrade path expects a site to be on Drupal 10.3.x or later before moving to Drupal 11. It also expects the hosting environment to meet Drupal 11 platform requirements, PHP 8.3.0 or later, command-line access with Composer and Drush, and the ability to adjust file permissions during the upgrade.

There is also site-specific cleanup. Drupal's guide notes that all core files change, including .htaccess, so any scaffold customizations need to be found and documented. Several extensions deprecated in Drupal 10 are removed in Drupal 11, including Actions UI, Activity Tracker, Book, Forum, Statistics, and Tour. If a live site still depends on one of these, the upgrade inventory needs to decide whether to remove it, replace it with a contributed version, or change the business process around it.

Run readiness checks before upgrading

The Upgrade Status project is useful because it treats major-version readiness as an assessment, not a guess. It checks whether the current Drupal version supports the next major upgrade, whether the system meets the next version's requirements, and whether contributed projects can be updated while the site is still on the current major version. It also runs PHPStan-based compatibility checks, understands several Drupal-specific deprecations, and can be used through Drush for command-line or CI workflows.

Timing matters. Upgrade Status should be run on the current Drupal 10 site against Drupal 11 readiness. After the site has already been upgraded, many deprecated APIs and libraries are gone, so there is less left to inspect. The same project documentation also makes clear that skipping multiple major versions is not supported by Upgrade Status or Drupal core's upgrade path. In practical terms: do not treat Drupal 10 to Drupal 12 as a shortcut.

Composer debt belongs in the estimate

Composer readiness is not just a developer convenience. It is part of delivery risk. Drupal 10 requires Composer 2.3.6 or higher; Drupal 11 requires Composer 2.7.0 or higher. If local machines, CI runners, release scripts, or production install steps still assume older tooling, the upgrade is not operationally ready.

A useful inventory keeps the commands close to the work. Start by exposing what is stale or unsafe:

• composer outdated "drupal/*" shows Drupal projects with available updates.
• composer audit checks PHP dependency advisories, not just Drupal modules.
• composer why-not drupal/core ^11 helps identify constraints blocking Drupal 11.
• composer update --dry-run previews dependency changes before files are changed.

For major module upgrades, a simple update is often not enough. Drupal's Composer guidance says a new major version should be required explicitly, for example composer require drupal/modulename:^2.0 --with-all-dependencies. For upgrade preparation, Drupal's core guide also uses --no-update when changing constraints first, so dependency conflicts can be resolved deliberately instead of halfway through a release window.

A practical project shape

1. Confirm the baseline: core version, PHP, Composer, Drush, hosting, permissions, backups, and deployment workflow.
2. Build the inventory: contributed modules, themes, custom code, direct Composer dependencies, removed core extensions, and scaffold customizations.
3. Run Upgrade Status: capture environment findings, contributed-project findings, and custom-code deprecations.
4. Remediate in order: update what can move on Drupal 10, handle major-version constraints, remove obsolete dependencies, and fix custom code.
5. Execute with verification: back up the database, dry-run Composer, perform the update, run database updates, rebuild caches, export configuration, test workflows, monitor logs, and run cron.

For agency teams, this structure also makes handoff cleaner. The inventory can become a scoped backlog instead of a vague warning. For owners and operations leads, it gives the upgrade a budget, risk profile, and sequence.

Need a steady owner for the upgrade?

If your Drupal 10 site has unclear module compatibility, old Composer constraints, custom code that has not been checked against Drupal 11, or a deployment process that only one person understands, this is a good moment to turn the unknowns into a plan. Greg can help audit the site, run readiness checks, separate quick fixes from real blockers, and shape the work into a controlled upgrade project. Talk to Greg about your Drupal upgrade inventory.

Related on GrN.dk

• WordPress 7.0 Collaboration Readiness: Why Legacy Meta Boxes and Hosting Assumptions Can Still Stall Your Upgrade
• CMS Upgrades in 2026: A PHP Roadmap for WordPress and Drupal Sites
• Drupal CMS 2.0 Speeds Marketing Site Rebuilds, but It Is Not Autopilot

Need help with this kind of work?

Plan your Drupal upgrade inventory Get in touch with Greg.

Sources

• Drupal core release schedule
• How to upgrade from Drupal 10 to Drupal 11
• Upgrade Status
• Composer requirements
• Updating Modules and Themes using Composer