How to Run Drupal Upgrade Status: Find What Blocks Your Move to Drupal 11

Drupal Upgrade Status is the module that shows, project by project, what stops a Drupal 10 site from moving to Drupal 11. Run it before you change a single Composer constraint. With Drupal 10 reaching end of life on December 9, 2026, the scan is the first hands-on step in any upgrade plan.

This piece walks through the scan itself. It covers where to run it, how to install it, how to start it from the browser or Drush, and how to read what comes back. Then it covers the blockers that take the longest, and what to hand a board or client when the scan is done. The full upgrade, Composer steps included, is in our Drupal 10 to 11 upgrade guide.

The short version: install the stable 4.x release on a copy of the site, run a full scan, and sort every finding into fix now, fix with help, or done. Contributed modules without a Drupal 11 release and an old PHP version usually take the longest. Aim for Drupal 11.4, not 11.3, because 11.3 loses security support the same week Drupal 10 does.

Before you run Drupal Upgrade Status: the right copy and release

Run the scan on a local or development copy of the site. It should have the same code as production and a recent copy of the database. Upgrade Status pulls in development tools you do not want on a live server.

Check your Drupal 10 minor version first. Drupal’s guide on how to upgrade from Drupal 10 to Drupal 11 requires Drupal 10.3.0 or later. A site on 10.2 or older has a smaller upgrade to do first. The scan will flag this too.

Then pick the release. As of October 2026, the Upgrade Status project page lists two:

• 4.3.10, released June 8, 2026. Stable, covered by the security policy, and works with Drupal 9, 10 and 11. Use this one on a Drupal 10 site.
• 5.0.0-alpha3, released July 2, 2026. Works with Drupal 10.4, 11 and 12. It is an alpha, so leave it for later.

The project page also says checks run on your current site against the next major version. A Drupal 10 site gets checked for Drupal 11. It cannot tell you about Drupal 12 yet.

Step 1: Install Drupal Upgrade Status with Composer

The project page gives four Composer commands. They remove Drush, add Drupal’s development packages and the module, then put Drush back.

composer remove drush/drush
composer require --dev drupal/core-dev:[version] --update-with-all-dependencies
composer require drupal/upgrade_status
composer require drush/drush

Replace [version] with the constraint that matches your installed Drupal core. The core-dev package matters. Without it, test code in contributed modules can show up as false errors.

Enable the module on the Extend page, or with Drush:

drush en upgrade_status

If your team commits composer.json and composer.lock, keep these changes on a branch. The scan branch does not need to reach production.

Step 2: Run the Drupal Upgrade Status scan

In the browser, go to Reports, then Upgrade Status. The page lists every project on the site. Select the projects you want, start the scan, and wait. Large custom modules take longer. Results are stored, so you can come back to them.

From the command line, the Drush command is upgrade_status:analyze, or us-a for short:

drush upgrade_status:analyze --all
drush us-a --all --ignore-contrib --format=checkstyle

The project page lists these options:

• --all scans every project.
• --ignore-uninstalled, --ignore-contrib and --ignore-custom narrow the scan.
• --format outputs plain text, checkstyle or codeclimate, which most CI tools can read.
• --phpstan-memory-limit raises memory for the code analysis on big codebases.

Gábor Hojtsy, the module’s maintainer, wrote that the 4.2.0 release gave the Drush command correct exit codes for success and failure. That means a CI job can fail when new problems appear. It is a cheap way to keep custom code from sliding back while the upgrade is in progress.

How to read a Drupal Upgrade Status report

The report has two parts. The top checks the environment: your Drupal version and whether the server meets Drupal 11’s requirements. Below that, it sorts every project into groups by what you should do next.

The group names below come from Hojtsy’s 2020 write-up of the report design. Check them against the version you install. The triage color is our shorthand for a planning sheet.

Inside each project, open the detail view. It lists each problem, splits errors from warnings, and notes which ones Rector is likely to fix.

Contributed modules: the blocker you do not control

A contributed module that Drupal Upgrade Status puts in "Collaborate with maintainers" is the slowest item on most lists. You cannot fix it with a Composer command, and the timing is not yours.

Start with the module’s issue queue on drupal.org. Look for an issue titled "Automated Drupal 11 compatibility fixes." These come from Project Update Bot, which posts patches built with Upgrade Status and Drupal Rector. Issues for Drupal 11 carry the tag ProjectUpdateBotD11. A patch there is often most of the work, already done.

If there is no patch and no recent activity, you have four choices: wait, patch it yourself, replace it, or drop the feature. Our upgrade guide covers those options. With under eight weeks to December 9, "wait" needs a date attached.

Also check for the six modules Drupal 11 removed from core: Actions UI, Activity Tracker, Book, Forum, Statistics and Tour. If the site uses one, install its contributed version on Drupal 10 before you upgrade.

Custom code: clear the easy part with Drupal Rector

Deprecated API calls in custom modules and themes are the most common finding. Most are mechanical. Drupal Rector rewrites many of them for you.

composer require --dev palantirnet/drupal-rector
cp vendor/palantirnet/drupal-rector/rector.php .
vendor/bin/rector process web/modules/custom --dry-run

Read the dry run first. Then run it without --dry-run, review the diff like any other code change, and run Drupal Upgrade Status again. Projects should move from "Fix with rector" toward "Relax" or "Fix manually."

What is left after Rector is your real custom-code estimate. Count it per module. That number is more useful to a project manager than the raw total from the first scan.

Environment and Webform: check these early

The environment checks catch problems that no code change will fix. They depend on your host, so start those conversations first.

Drupal 11 needs PHP 8.3 or later, according to Drupal’s PHP requirements page. PHP 8.4 works on every Drupal 11 minor. PHP 8.5 works from Drupal 11.3 on. Drupal 12 requires PHP 8.5, so ask your host when it will offer 8.5.

For databases, the database requirements page lists these minimums for Drupal 11:

• MySQL 8.0
• MariaDB 10.6
• PostgreSQL 16, with the pg_trgm extension enabled
• SQLite 3.45

Webform needs its own check. The Webform project page lists 6.2.x for Drupal 10.2 and up only, with security support until Drupal 10’s end of life. The 6.3.x branch works on Drupal 10.3 and 11. Move to 6.3.1 or later while still on Drupal 10, test every form, then upgrade core.

Pick the target: Drupal 11.4, with 11.3 as the floor

Know where you are landing before you plan the work. The Drupal core project page lists 11.4.8 (September 26) and 11.3.18 (September 28). It says 11.3.x has security coverage until December 2026, when 11.5.0 is released.

Drupal 11.3.0 is also the floor for Drupal 12. The 12.0.0-beta1 release notes say the update system "will refuse to update from Drupal 11.2 or earlier." They recommend 11.4, or 11.5 once it ships. We covered the background in our post on Drupal 12’s release slip, and the new features that need 11.3 or later in our DrupalCon Rotterdam recap.

So the target for a Drupal 10 site is the latest 11.4 release. Rescan with Drupal Upgrade Status after each fix until the project list is mostly green.

What to hand a board or client after the scan

A raw Drupal Upgrade Status export is for developers. A board or client needs one page. Build it from the scan:

1. Environment: pass or fail on Drupal version, PHP and database, with the host’s dates for any fix.
2. Counts by group: how many projects are green, yellow and red.
3. The red list: each blocked contributed module, the decision (wait, patch, replace, drop) and an owner.
4. Custom code: the remaining findings after Rector, per module.
5. Target and dates: Drupal 11.4, a test window, and a go-live date before December 9.

Keep the language plain. "Three add-ons need replacing" lands better than a list of machine names. Our one-page board brief on the Drupal 10 deadline has wording you can reuse for the board itself.

Frequently Asked Questions