Why upgrade to Drupal 11 now

Two reasons. The first is that Drupal 10 stays supported for a while yet — but the contrib ecosystem moves to Drupal 11 first. By 2027, the most actively maintained modules will require Drupal 11. Sites that stay on 10 will increasingly carry patched-locally contrib code, which is the long road back to the kind of technical debt the migration is supposed to fix.

The second is that Drupal 11 is genuinely the smallest jump in recent memory. Most contrib modules support both 10 and 11 from the same release. The deprecated-code surface is small. PHP 8.3 was already where you wanted to be. The hard part is showing up — the actual work is straightforward.

The teams that get into trouble on Drupal 11 are the teams who delayed long enough to also need a PHP upgrade, a Symfony jump, and contrib catch-up at the same time. Don't stack the work.

What's actually new in Drupal 11

The headline changes that matter on real builds:

  • Symfony 7 — the framework layer that Drupal sits on top of. Modern, faster, and the source of most of the deprecated APIs you'll need to fix.
  • Single Directory Components are first-class — SDC is now the recommended way to build themes. The pattern that already worked in Drupal 10.3 is the baseline in Drupal 11.
  • Recipes — opinionated installable bundles of config + modules. Think "starter kits that don't lock you in." Genuinely useful for repeatable site setups.
  • Project Browser — an in-admin module browser, so editors and site builders can install modules without touching Composer. A real ergonomic upgrade.
  • Workspaces stabilised — content staging across environments is now production-grade. Worth investigating if your editorial workflow has ever wanted "preview the whole site at a future date."
  • Performance baseline raised — out-of-the-box request times are measurably faster on Drupal 11 vs Drupal 10 on the same hardware.

What got removed

Less than Drupal 10 removed — but enough to plan around:

  • jQuery UI — already optional in Drupal 10, now fully out of core. If you still depend on it, install the jquery_ui contrib module before the upgrade.
  • Various Symfony 6 helpers — anything that called Symfony 6-specific deprecated APIs in your custom code needs porting.
  • PHP 8.1 and 8.2 support — Drupal 11 requires PHP 8.3 minimum.
  • Some long-deprecated Drupal hooks — usually the ones that have had a deprecation notice on them since Drupal 9. If you're seeing deprecation warnings in your logs today, those are the ones that turn into hard errors in 11.

The dependency floor — PHP 8.3, Symfony 7, MariaDB 10.6

Before you touch core, validate every layer:

  • PHP 8.3 — non-negotiable. PHP 8.2 reaches end-of-security in December 2026, so you'd want to be on 8.3 anyway.
  • Composer 2.7+ — earlier versions choke on some Drupal 11 dependency resolutions.
  • MariaDB 10.6 / MySQL 8.0 / PostgreSQL 16 — the new database floor.
  • Node 20+ — only matters if you have a front-end build, but if you do, this is now the baseline.

The single most common Drupal 11 migration failure we see is "we upgraded core but the production server is still on PHP 8.1." Validate hosting first.

Step 1 — Run Upgrade Status on Drupal 10

The same module that drove the Drupal 9 → 10 migration drives 10 → 11. Install it on your Drupal 10 site and let it scan:

composer require drupal/upgrade_status --dev
drush en upgrade_status
# visit /admin/reports/upgrade-status

You'll get a list of contrib modules that aren't Drupal 11 ready yet, custom modules using deprecated APIs, and themes that need work. Every red row turns into a ticket — same discipline as the Drupal 10 upgrade.

Step 2 — Fix the deprecated code

Drupal Rector covers most of the routine deprecation patterns automatically:

composer require palantirnet/drupal-rector --dev
vendor/bin/rector process web/modules/custom
vendor/bin/phpstan analyse web/modules/custom

The deprecations specific to Drupal 11 that need human eyes:

  • Symfony 7 service container changes — some service definitions need updating
  • Removed Twig filters and functions — replace with the Drupal 11 equivalents
  • EntityViewBuilder API tightening — explicit type hints required where they used to be loose
  • Form API state changes in some edge cases

Step 3 — Bring contrib current

Get every contributed module on its latest release first. Many modules have a single release that supports both Drupal 10.3+ and Drupal 11 — those upgrade with one Composer command. The modules that don't yet support 11 are the ones you need to plan for: either there's a working dev branch, or you'll need to patch locally, or you replace the module.

Watch out for the long-tail contrib modules in your tree. The 90% of contrib that maintainers keep current is fine; the 10% that hasn't seen a release in 18 months is where the surprises hide.

Step 4 — Run the core update

Once Upgrade Status is green or close to it:

composer require 'drupal/core-recommended:^11' 'drupal/core-composer-scaffold:^11' 'drupal/core-project-message:^11' --update-with-all-dependencies
drush updb
drush cr

If Composer can't resolve dependencies cleanly, that's almost always a contrib module that hasn't published a Drupal 11 release. Check upgrade status, file the issue upstream, and decide whether to patch or replace.

Step 5 — Real-load testing

Same discipline as every other major upgrade:

  • Visual regression — BackstopJS or Percy on a representative URL set
  • Functional — Behat / PHPUnit on critical user journeys
  • Performance baseline — capture LCP / INP / CLS / TTFB before and after
  • Load test — k6 or JMeter at production peak load

The performance baseline is interesting on Drupal 11 — you'll often see TTFB improve out of the box. Capture it as a public-facing win.

Step 6 — Production deploy

The Drupal 11 production deploy checklist is the same as Drupal 10's. The one thing worth adding: verify PHP 8.3 on the production server before you push the build. We've seen at least one team push the new build, see white-screens-of-death, and find out the prod hosts were still on PHP 8.1 — a one-line fix that costs an hour of downtime when you discover it in production.

Production deploy checklist

  • Verify PHP 8.3+, MariaDB 10.6+ / MySQL 8.0+ on production hosts
  • Take a verified database backup (and test the restore in staging)
  • Put the site into maintenance mode
  • Deploy the new build, run drush updb -y, drush cim -y, drush cr
  • Smoke test the critical paths
  • Take the site out of maintenance mode
  • Monitor error rate, response time, and PHP errors for 24 hours minimum

Key takeaways

  • Drupal 11 is the smallest major version jump in recent memory — on a current Drupal 10 estate.
  • The hard part is the dependency floor: PHP 8.3, Symfony 7, MariaDB 10.6+. Validate hosting before you start.
  • Drupal Rector + PHPStan handles most deprecated-code remediation automatically.
  • Single Directory Components, Recipes, and Project Browser are the genuinely useful new features.
  • Real-load testing catches the bugs that bite in production. Don't skip it.
  • Performance baseline is often noticeably better on Drupal 11 — capture the win.

If you'd rather hand the Drupal 11 upgrade to a specialist team, that's exactly the kind of thing we do every week. Get in touch — we'll come back with a clear scope and a realistic timeline within 48 hours.