Drupal 9: Practical Upgrade Guidance for Legacy Sites

As of June 11, 2026, Drupal 9 has been out of support since November 1, 2023. That does not automatically mean you rebuild tomorrow. It does mean you should stop treating the site as ordinary maintenance. For business owners, operations leads, and agency teams, the practical question is simpler: what is the lowest-risk path to a supportable stack without breaking editor workflows, integrations, or delivery dates?

Most inherited Drupal 9 sites do not fail because the core upgrade steps are hard to find. They fail because nobody audited the real dependencies first: custom modules, patched contrib code, scaffold changes, CI assumptions, or hosting limits that were never revisited. Start there. Then decide whether you are stabilising for a controlled upgrade to Drupal 10 or whether the economics now point to replacement.

Start with an audit, not a hopeful estimate

Before you promise dates or budgets, confirm the exact Drupal core version, PHP version, Composer usage, installed modules, custom code, and deployment path. Drupal's official upgrade guidance still expects Drupal 9.4.x or 9.5.x as the starting point for a Drupal 10 upgrade, so if the site sits below that, you already know there is a cleanup step before the main move.

On a safe lower environment, these checks still earn their keep:

composer show drupal/core | grep versions
composer outdated 'drupal/*'
vendor/bin/drush status
vendor/bin/drush pm:list --status=enabled

If those commands already surface version drift, missing local tooling, or unexplained enabled modules, that is useful information. It means the project needs discovery and risk control before anyone books a release window.

What old Drupal 9 setup advice still holds up

Two older habits are still correct. First, keep the site Composer-managed. Drupal's official project template still recommends drupal/recommended-project, with the public web root in /web and vendor outside the document root. Second, keep Drush in the project, not as a shared global convenience install, and run it via vendor/bin/drush.

What has changed is the version context. In 2026, you should not start anything new on Drupal 9. And if you are working on an old Drupal 9 estate, do not blindly trust old notes that say composer require drush/drush and move on. Current Drush documentation still recommends Composer-managed, project-local Drush, but its current supported branches are aimed at newer Drupal versions. That implies a Drupal 9 codebase may need an older temporary Drush version during the transition. This is one reason old setup notes are not enough on their own.

Upgrade in the order Drupal expects

The safest route is usually sequential. Clean up the Drupal 9 site first, remove blockers, and land on a supportable Drupal 10 baseline. Do not plan a direct jump from Drupal 9 to Drupal 11 or later; Drupal's own upgrade tooling states that skipping multiple major versions is not supported.

There are also a few blockers that regularly surprise teams late in the project. Drupal's upgrade guide calls out altered scaffold files such as .htaccess, which must be reviewed and re-applied deliberately after the core update. It also calls out deprecated core extensions removed in Drupal 10, including the Seven admin theme and the CKEditor 4 module. If editors still depend on those, the work is not just technical. It affects content operations, training, screenshots, acceptance criteria, and stakeholder sign-off.

Use compatibility tooling early, not after the quote is approved

The Upgrade Status module is still one of the most useful ways to turn a vague assumption into a concrete blocker list. Its current stable 4.3 release still supports Drupal 9, 10, and 11, which makes it practical for inherited estates being assessed in 2026.

composer require 'drupal/upgrade_status:^4.3'

If Composer conflicts appear, follow the module's current install notes. You may need Drupal's developer dependencies, and some projects temporarily remove and re-add Drush during installation. The point is not to add ceremony. The point is to learn early whether your risk sits in contributed modules, custom code, or the surrounding toolchain.

Where budget and timelines usually go wrong

Most overruns come from the things nobody scoped: local patches in composer.json, abandoned modules, fragile integrations, and custom code tied to APIs removed in Drupal 10. Agency handovers add another layer: undocumented deployment steps, forgotten cron jobs, or production edits that never made it back to version control.

If the site matters to revenue, lead flow, publishing, case handling, or partner operations, treat the upgrade like a delivery project. That means a restorable lower environment, a tested rollback path, explicit acceptance criteria, and real regression testing. A homepage that loads is not evidence that the site is ready.

A practical operating checklist

Confirm whether the site is on Drupal 9.4.x or 9.5.x before planning the Drupal 10 step.
Inventory custom modules, applied patches, scaffold changes, third-party integrations, cron jobs, and deployment scripts before estimating effort.
Use Composer and project-local Drush so local, CI, and production workflows behave the same way.
Resolve deprecated themes and editor dependencies before the main upgrade, especially Seven and CKEditor 4 usage.
Run post-change checks with Drush and your test suite, not just a visual smoke test.

The runbook commands worth keeping close are still simple:

vendor/bin/drush updatedb -y
vendor/bin/drush cron
vendor/bin/drush watchdog:tail

That combination will often surface problems faster than a superficial browser check, especially on inherited sites where the real risk sits in background tasks, configuration drift, or module update hooks.

If you need a practical second opinion on a Drupal 9 estate, the useful deliverable is usually not a long technical memo. It is a scoped plan: what to stabilise now, what to upgrade next, what can wait, and what should probably be replaced. Greg can help turn that into an execution plan your team can actually run.