Drupal 10 now comes with a date you can actually plan against. Drupal.org says Drupal 10 reaches end of life on December 9, 2026, that Drupal 10.6.0 is the final minor release, and that there will be no new Drupal 10 releases after that. Once that is fixed on the calendar, the conversation changes. This stops being a general intention to upgrade someday and becomes a deadline-driven inventory exercise.
On most client sites, the risky part is not the final Composer command that moves core to Drupal 11. It is everything that has to be true before that command is safe: what the site depends on, what the codebase assumes, and what the deployment process can actually support.
The deadline makes hidden work visible
The official Drupal 10 to 11 guide is fairly direct about the baseline. The supported target is Drupal 11.x, but the starting point has to be Drupal 10.3.x or later. The site needs to be on Drupal 10.3.0 or newer. The hosting environment has to meet Drupal 11 platform requirements. Composer and Drush access are expected from the command line. File permissions need to be adjustable on the server. PHP has to be 8.3.0 or later.
That is already enough to define scope for a client engagement. If a team cannot answer those questions quickly, it does not yet have an upgrade plan. It has a working assumption that the upgrade will probably be straightforward.
There is usually more surface area than non-technical stakeholders expect. The same guide notes that all Drupal core files will change, including .htaccess, so any scaffold customizations need to be documented and reapplied. It also calls out extensions that are deprecated in Drupal 10 and removed in Drupal 11, including Actions UI, Activity Tracker, Book, Forum, Statistics, and Tour. In practical terms, that means a useful upgrade inventory has to go beyond checking module versions. It needs to cover scaffold changes, removed or obsolete core extensions, direct dependencies in composer.json, and custom code that still relies on deprecated APIs.
Why the inventory has to come first
The Upgrade Status project is a good indicator that this preparation is its own phase of work. Its job is to assess major-version readiness for both the environment and the site itself. It checks whether the current Drupal version is eligible for the next major upgrade, whether the system meets the next version's requirements, and whether contributed projects can be updated in advance while the site is still on the current major version. It also runs PHPStan and other compatibility checks, and it integrates with Drush so the analysis can be run from the command line or wired into CI.
The timing matters. The project documentation says these compatibility checks need to be run on the current site against the next major version. After the site has already been upgraded, many deprecated APIs and libraries are gone, which means there is less left to inspect. The same documentation also makes clear that neither Upgrade Status nor the Drupal core path supports skipping across multiple major versions in one jump.
That shifts the economics of the work. Inventory is not admin overhead. It is the step that separates a messy unknown into specific tasks. Some contributed modules can be updated on Drupal 10 before core moves. Some need an explicit major-version change in Composer. Some need manual verification, issue queue review, or patch validation because compatibility may exist but still needs checking. For custom code, Upgrade Status can surface deprecations, and the Drupal 10 to 11 guide points to Upgrade Status together with Drupal Rector as the route for replacing code deprecated in Drupal 10. That is what turns upgrade prep into a backlog you can estimate, schedule, and test instead of a surprise inside a release window.
Composer debt is part of the job
The Composer requirements page makes another point that matters in real environments: this is not just a development task. Drupal 10 requires Composer 2.3.6 or higher. Drupal 11 raises that minimum to Composer 2.7.0 or higher. If the machine or pipeline responsible for installs and updates still assumes the older baseline, the project is not actually ready for the supported upgrade path.
The documentation for updating modules and themes also reinforces that Composer is the standard workflow. It recommends taking a database backup before updates, points to Drush 13 or later, and uses commands such as composer outdated and composer audit to expose pending version work and security issues before changes are applied.
That matters because Drupal 11 prep often starts with dependency cleanup before core changes. The update guide notes that major-version changes are not handled by a simple update command. You explicitly require the new major version and review the project page and issue queue before proceeding. The Drupal 10 to 11 guide follows the same pattern for core: prepare dependency changes without updating immediately, dry-run the Composer update, run the real update, then complete database updates and post-upgrade checks. So Composer debt is not a side issue. Version locks, direct dependencies, and stale deployment habits can decide whether the supported upgrade path works cleanly or stalls halfway through.
What this looks like as a client project
For GrN, the practical consulting move is to treat the upgrade as staged operations work rather than a one-off development task.
- Establish the baseline: confirm the installed core version, PHP 8.3 readiness, Composer 2.7 readiness, Drush access, permission model, and any scaffold customizations that need to survive the upgrade.
- Build the inventory: list contributed modules, themes, custom code, removed or obsolete core extensions, and direct Composer constraints that could block Drupal 11.
- Run readiness analysis: install Upgrade Status on the existing Drupal 10 site, capture the findings, and sort them into environment issues, contributed-project issues, and custom-code deprecations.
- Remediate in the supported order: update contributed projects that can move forward on Drupal 10, handle major-version constraints explicitly, fix custom code, and remove reliance on core extensions that Drupal 11 no longer includes.
- Execute and verify: back up the database, audit and update dependencies with Composer, dry-run the upgrade, run the actual update, complete database updates, rebuild caches where needed, export configuration, test, monitor logs, and run cron.
If that prep has been done properly, the final execution phase should be uneventful. That is the point. With December 9, 2026 on the horizon, the goal is not a dramatic rescue effort. The goal is a controlled rollout with fewer unknowns and fewer avoidable blockers.
If your Drupal 10 site still has unclear module compatibility, aging Composer constraints, or custom code that has never been checked against Drupal 11, the useful work now is not debating whether an upgrade will eventually be necessary. Drupal.org has already settled that. The useful work is turning uncertainty into a documented inventory, a staged remediation list, and a verified path to upgrade. Greg can help by auditing modules, themes, custom code, and hosting constraints; running Upgrade Status; cleaning up Composer debt; and turning a vague future upgrade into a manageable project with clear checkpoints.
Need help with this kind of work?
Scope Your Drupal Upgrade Inventory Get in touch with Greg.