How to Upgrade from Drupal 10 to Drupal 11: A Practical Checklist
The Drupal 10 to Drupal 11 upgrade is the most straightforward major version jump in Drupal's history — but it still requires a structured approach. This checklist covers every step from pre-flight checks to production deployment, including how to handle the common blockers: modules with no D11 release and deprecated API warnings in custom code.
Why upgrade now, not later
Drupal 10 reaches end of life on December 9, 2026 — the same week Drupal 12 is released. After that date, there will be no security patches for Drupal 10 core and no official support for contrib modules that only declare D10 compatibility.
The upgrade gets harder the longer you wait. Contrib modules move on; the gap between your locked versions and current releases widens; and the Drupal community's attention shifts to Drupal 12 planning. Starting the Drupal 11 upgrade now — three months before EOL — gives you time to handle blockers without pressure.
composer.json and receive a fixed-price Drupal 11 upgrade scope within 24 hours.What actually changes in Drupal 11
Drupal 11 is an incremental evolution of Drupal 10, not a rebuild. The content model, configuration system, Twig templates, and Composer-based workflow are all the same. The changes are focused on removing deprecated code and modernising the PHP baseline.
The biggest practical impact is removed deprecated APIs. Anything your custom modules or themes were calling that Drupal 10 had marked deprecated will throw a fatal error in Drupal 11. The Upgrade Status module identifies every one of these before you touch core.
The Drupal 11 upgrade checklist
Work through these phases in order. Do not upgrade Drupal core until all custom and contrib code passes the Upgrade Status scan — you will get fatal errors that are much harder to debug after the core version bump.
Before you start
Non-negotiable. Drush: drush sql:dump > backup.sql. Files: tar -czf files-backup.tar.gz web/sites/default/files
Drupal 11 requires PHP 8.3 with the zlib extension. php -v on your host. Many shared hosts still default to 8.1 or 8.2.
composer require drupal/upgrade_status, enable it, and run the scan. It flags every deprecated API call in custom code and lists module compatibility.
Visit drupal.org/project/<module_name> and confirm an 11.x-compatible release exists. If it doesn't, you need a plan before proceeding.
Update contrib modules
composer update "drupal/*" --with-dependencies. Do this before touching core — it clears the most deprecation warnings.
Options: find a fork, patch it yourself, or replace it with a D11-compatible equivalent. Do not skip this step.
If you don't have automated tests, at minimum click through the site's critical paths after each update batch.
Fix deprecated code in custom modules and themes
Drupal Rector can automate most of this: composer require palantirnet/drupal-rector --dev, then vendor/bin/rector process web/modules/custom.
Drupal 11 moves hooks to OOP event subscribers in some cases. Upgrade Status identifies which ones.
Common ones: \Drupal::entityManager() → \Drupal::entityTypeManager(), entity_get_bundles() → \Drupal::service('entity_type.bundle.info').
Upgrade Drupal core
Change "drupal/core-recommended": "^10" to "^11" (and core-dev, core-composer-scaffold if present).
composer update drupal/core drupal/core-recommended drupal/core-composer-scaffold --with-dependencies
drush updb -y — applies any D11 schema updates.
drush cr. If you get class-not-found errors, drush cache:rebuild-registry or composer dump-autoload.
Verify and deploy
drush cex, review the diff, drush cim. Drupal 11 may have changed some schema definitions.
Should return zero errors after a clean upgrade. Any remaining warnings are informational.
All content types, views, forms, user roles, integrations. Do not deploy to production until staging is clean.
drush sset system.maintenance_mode 1, deploy, drush updb, drush cim, drush cr, drush sset system.maintenance_mode 0.
Common blockers and how to handle them
- Check the module's issue queue for a D11 patch — often one exists even if not yet released
- Pin the module version and apply the patch via composer patches
- Find a replacement module (e.g. Media module replaces several legacy file modules)
- Fork the module and maintain your own compatibility patch until the maintainer catches up
- Most major hosts (Acquia, Pantheon, Platform.sh) already support PHP 8.3
- For self-hosted: upgrade via your OS package manager — PHP 8.3 packages are available for Ubuntu 22.04+, Debian 12+
- If stuck on a legacy server, a migration to a new host is often the faster path
- Run Drupal Rector — it automates a significant portion of the mechanical changes
- Prioritize custom modules over contrib — contrib issues resolve when you update the module
- Warnings in code that is never executed at runtime can be deferred; errors cannot
DIY vs. hiring out the upgrade
The DIY path is viable if: you have a Drupal developer on staff, all your contrib modules already have D11 releases, and your custom code volume is small. For most sites, the checklist above is a 1–3 day project for an experienced Drupal developer.
Hiring out makes sense if: you have significant custom module code, one or more contrib modules with no D11 release, a large content database requiring careful migration testing, or no Drupal developer available internally before the December deadline.
Related reading
What Drupal 10 EOL means for your site, your upgrade options, and how to get a free fixed-price Drupal 11 scope within 24 hours.
Rather have someone else handle the Drupal 11 upgrade?
Paste your composer.jsonand I'll send you a free upgrade evaluation with a fixed-price scope within 24 hours. No sales call required.