Drupal 9 still turns up in inherited estates, agency handovers, and internal sites that still work well enough. The problem in 2026 is that Drupal 9 is not a normal maintenance branch anymore. Drupal.org ended support on November 1, 2023, and there will be no further Drupal 9 releases. If you own the budget, the delivery risk, or the agency handover, that changes the question from 'when do we get around to this?' to 'how do we reduce risk without creating a bigger mess?'
That is the practical frame I would use with a client: keep the site stable, move to a supportable toolchain, and make upgrade decisions in the right order. Old Drupal 9 notes about Composer and Drush are still useful, but only when they support that larger goal.
Start with the real status of the site
If a site is still on Drupal 9, assume you need an audit before you need a rebuild. Check four things first: the exact Drupal minor version, how Composer is being used, whether Drush is installed per project or globally, and what custom code or patches exist in the codebase. Also list deployment scripts, cron jobs, and any edits to scaffolded files such as .htaccess or robots.txt.
This matters because a Drupal upgrade is usually not just a core update. It is a dependency and operations project. The hard part is rarely the version number itself. It is the hidden coupling between hosting, CI, deployment habits, old modules, and custom code that nobody has reviewed for two years.
What still makes sense from older Drupal 9 setup advice
The Composer-first approach is still the right foundation. Drupal's official project template recommends the drupal/recommended-project layout, which keeps the web root in /web and the vendor directory outside the public document root. That is still the sensible default for new builds and for agency teams that want predictable environments.
composer create-project drupal/recommended-project my-project
cd my-project
composer require drush/drush
vendor/bin/drush status
composer outdated 'drupal/*'Two points matter here. First, those commands are fine for a supported Drupal build; they are not a reason to start a new project on Drupal 9 in 2026. If you are launching something new, start on a supported Drupal release. Second, Drush should live in the project, not in a shared global Composer setup. Current Drush guidance is to install it as a dependency and run it from vendor/bin/drush. That makes local machines, CI jobs, and production automation behave the same way.
If you still run Drupal 9, upgrade in the right order
For most legacy sites, the safest route is to get the codebase to a clean Drupal 9.4 or 9.5 baseline first, then prepare for Drupal 10. Drupal's official upgrade guidance also calls out the blockers teams forget until late in the project: deprecated core extensions, altered scaffold files, and custom code that still depends on removed APIs.
Two examples show up often. The Seven admin theme and the legacy CKEditor 4 module were deprecated in Drupal 9 and removed from Drupal 10. If editors still depend on them, that is not a last-minute technical task. It affects content workflows, training, and acceptance testing. The same applies to scaffolded files. If your team has modified .htaccess or related scaffolding, document those changes before you update code so they can be re-applied deliberately instead of rediscovered in production.
Also plan the upgrade path realistically. The supported path is sequential. You do not skip straight from Drupal 9 to Drupal 11. If the site is business-critical, it is usually better to land on a clean, supportable Drupal 10 baseline first and then decide whether the Drupal 11 step belongs in the same roadmap.
Use compatibility checks before you touch production
On a development copy, run compatibility checks before you book a deployment window. The Upgrade Status module is still the most practical way to review Drupal 10 readiness across contributed and custom code. It is also useful for agency handovers, because it turns a vague 'we think this site is upgradeable' into a list of concrete blockers.
composer require 'drupal/upgrade_status:^4.3'The goal is not to install more tooling for its own sake. The goal is to surface the unknowns early enough that you can budget the work properly. Inherited Drupal estates usually fail on estimation, not on the existence of an upgrade guide.
Treat it as a delivery project, not a one-line fix
If you inherited the site from another agency or a previous internal team, the biggest risks are usually outside core itself: undocumented patches, old deployment assumptions, third-party integrations, and custom modules with little or no current test coverage. That is why Drupal 9 work so often looks larger than it first appears.
The shortest successful path is usually staged delivery: stabilize the current site, remove the known blockers, update the stack in a controlled lower environment, and only then push the supported upgrade through QA and release. That sounds unglamorous, but it is how you avoid turning a maintenance task into an outage.
A practical operating checklist
- Keep a full backup and a restorable lower environment before changing Composer constraints.
- Use project-local Drush and the project's own
composer.lock; do not depend on a shared global CLI toolchain. - Inventory custom modules, applied patches, third-party integrations, and cron jobs before estimating effort.
- Check blockers early, especially deprecated themes, CKEditor 4 usage, and custom code tied to removed APIs.
- After code changes, run tests and verify database updates and logs with Drush rather than assuming the site is healthy because the homepage loads.
That last part is still worth keeping in the runbook:
vendor/bin/drush updatedb -y
vendor/bin/drush watchdog:tailIf you need a practical second opinion on a Drupal 9 site, whether the answer is stabilize it, upgrade it, or plan a replacement, Greg can help turn that work into a scoped delivery plan instead of another vague backlog item.
Need help with this kind of work?
Need a practical plan for a Drupal upgrade or inherited site cleanup? Talk to Greg. Get in touch with Greg.