Drupal 10 to Drupal 11 Upgrade Checklist (with Upgrade Status + Rector)

Most "Drupal 11 upgrade" articles are narrative guides — useful background, but you can't run a checkbox down the side of a story. This is the other thing: a Drupal 11 upgrade checklist you can paste into a ticket, assign, and tick off. Four phases, clear gates between them, and the decision logic for the one part that actually trips teams up — contributed modules.

If you haven't decided whether and when to upgrade yet, start with the Drupal 10 end-of-life decision framework — Drupal 10 reaches EOL in December 2026, so the window is real. This post assumes the decision is made and you need the execution plan.

A healthy Drupal 10 site upgrades to Drupal 11 in days to a few weeks. The work below is what makes it days instead of an emergency.

Before you start: what kind of upgrade this is

Drupal 10 → 11 is an upgrade, not a migration. Composer pulls new package versions, the database update runs, and your site keeps its content, configuration, and structure. Nothing is rebuilt from scratch.

That is the opposite of a Drupal 7 jump. If you're still on Drupal 7, this checklist does not apply to you — see Drupal 7 End-of-Life: What It Means for Your Website Security and the five signs your site is overdue for migration instead. Your path is a full replatform to Drupal 11, scoped in months.

Two tools carry most of the load in the checklist below:

Upgrade Status — a contributed module that scans your environment, contrib modules, and custom code, then reports exactly what is and isn't Drupal 11 ready.
Drupal Rector — a command-line tool that automatically rewrites deprecated API calls in your custom code. It fixes a large share of custom-code warnings without you touching the files.

Install both early. They turn "we'll find out during the upgrade" into a written task list.

Phase 1 — Pre-flight audit (do this first, change nothing)

This phase is read-only. You're producing a scope, not editing code.

[ ] Confirm your Drupal 10 minor version. Run drush status. Drupal 11 can only be upgraded to from Drupal 10.3 or later. If you're on 10.0–10.2, a minor update to the current 10.x release is step zero.
[ ] Check your PHP version. Run php -v. Drupal 11 requires PHP 8.3+. If your hosting is locked to 8.1 or 8.2, the hosting upgrade is the first ticket — and sometimes the only invoice in the whole project.
[ ] Check your database engine. Drupal 11 requires MySQL 8.0+, MariaDB 10.6+, or PostgreSQL 16+. Verify with your host before scoping anything else.
[ ] Confirm Composer and Drush versions. You'll want Composer 2 and Drush 13 for Drupal 11.
[ ] Install Upgrade Status (composer require --dev drupal/upgrade_status) and run the report. Read the three buckets it produces: environment, contrib, and custom code.
[ ] Inventory contributed modules. List every contrib module and its current version. Upgrade Status tells you which already have a Drupal 11–compatible release and which don't.
[ ] Measure your custom code. find . -path "*/modules/custom/*" -name "*.php" | xargs wc -l gives you the size of the surface Rector has to cover.
[ ] Check your test coverage. If you have no smoke tests for your content types and top-trafficked pages, note it now — you'll write a few before Phase 3.
[ ] Check the 2027 audit calendar. PCI, SOC 2, and vendor security reviews scheduled for Q1 2027 set your real deadline, not December 2026.

Gate: Phase 1 is done when you have a written list of every "needs review" item from Upgrade Status, each with an owner and a time estimate. If three or more items are still "I don't know," stay in Phase 1.

Phase 2 — Dependency prep (the part that actually takes time)

This is where the calendar time goes. The upgrade command in Phase 3 is fast; getting your dependencies ready for it is not.

Get to the latest Drupal 10 first

[ ] Update to the current Drupal 10.x release and run drush updatedb and drush cr.
[ ] Confirm the site is stable on the latest 10.x before going further. Never debug a minor update and a major upgrade at the same time.

Triage every contrib module

For each contributed module, Upgrade Status puts it in one of three states. Your decision tree:

Has a stable Drupal 11 release → update it. No further thought needed.
Has a D11 release in a dev or release-candidate branch → test it on a staging copy. If it works, plan to ship with it; if not, treat it as state 3.
No Drupal 11 release at all → this is a decision, not a task. Your options, cheapest first:
- Find an open D11 compatibility patch in the module's issue queue and apply it via composer-patches.
- Replace the module with a maintained equivalent that already supports D11.
- Port it yourself (run Rector against it like custom code).
- Drop the feature if it's no longer used.

A typical 30-module site finds one to three modules in state 3. Each one is a small project. Finding them now, in Phase 2, is the entire point of doing a checklist instead of winging it.

Handle removed and relocated core modules

Drupal 11 removed several modules from core and relocated others. Check whether your site uses any of them:

Removed entirely: Aggregator, RDF, HAL, Quick Edit, and others. If you use one, you need a contrib replacement or you remove the feature.
Moved to contrib: Book, Forum, Tour, and others. These still work — you just composer require them as separate packages so they keep functioning.
CKEditor 4 was already removed back in Drupal 10. If you somehow skipped that migration, it lands on you here.

Fix custom code with Drupal Rector

[ ] Install Rector and run it against your custom modules and theme in dry-run mode first to see the proposed changes.
[ ] Apply the automated fixes, then review the diff. Rector handles the mechanical deprecations; it does not invent business logic.
[ ] Re-run Upgrade Status. The custom-code warning count should drop sharply. Whatever remains is your manual fix list — work it down to zero.

Gate: Phase 2 is done when Upgrade Status reports a clean custom-code scan, every contrib module has a D11 path, and you've confirmed the environment meets requirements. Do not enter Phase 3 with open items.

Phase 3 — The upgrade

With Phase 2 clean, the upgrade itself is short. Do it on a staging environment first, every time.

[ ] Take a full backup. Database and files. drush sql-dump plus a file snapshot. Confirm you can restore it — an untested backup is not a backup.
[ ] Branch your code. A dedicated upgrade/drupal-11 branch keeps the change reviewable and revertable.
[ ] Update composer.json to require Drupal 11 core and the D11-compatible versions of every contrib module and dependency (Drush 13, etc.).
[ ] Run composer update and resolve any version conflicts it surfaces. This is where leftover Phase 2 gaps show up — if something conflicts, go back, don't force it.
[ ] Run the database update: drush updatedb.
[ ] Rebuild caches: drush cr.
[ ] Export configuration (drush config:export) and review the diff so no unexpected config change ships silently.

Gate: Phase 3 is done when the staging site loads, the database update completed without errors, and the status report (/admin/reports/status) is green.

Phase 4 — Post-upgrade verification

The upgrade ran. Now prove it worked before it touches production.

[ ] Run your smoke tests against every content type and your highest-traffic templates.
[ ] Click through admin workflows — content editing, media, the page-building tools your editors use daily.
[ ] Check the log at /admin/reports/dblog for new errors and warnings.
[ ] Verify forms, search, and any third-party integrations still function.
[ ] Test performance — caching behavior and page load on key pages, compared against your pre-upgrade baseline.
[ ] Confirm the rollback path is still valid right up to the production deploy. Know exactly how you revert if production behaves differently from staging.
[ ] Deploy to production during a low-traffic window, then re-run the smoke tests against the live site.
[ ] Monitor the log for 48 hours after the production deploy.

Gate: the project is done when production has run clean for two days and you've removed the --dev upgrade tooling you no longer need.

Where the time actually goes

If you're scoping this, here's the honest distribution for a healthy Drupal 10 site:

Phase 1 (audit): half a day to a day.
Phase 2 (dependency prep): the bulk of the project — anywhere from a few days to a couple of weeks, driven almost entirely by how many contrib modules land in "state 3" and how much custom code Rector can't auto-fix.
Phase 3 (the upgrade): a few hours on a clean codebase.
Phase 4 (verification): one to three days, including the production deploy and monitoring.

The headline number — "2 to 6 weeks" — is real, but it's almost all Phase 2. A site with current, well-maintained contrib and modest custom code lands at the short end. A site with abandoned modules and three years of un-Rectored custom code lands at the long end. The checklist doesn't change the work; it just tells you which site you have before you commit a date.

Frequently asked questions

What version of Drupal 10 do I need before upgrading to Drupal 11?

Drupal 10.3 or later. Drupal 11 cannot be upgraded to from Drupal 10.0, 10.1, or 10.2. If you're on an older minor version, update to the current Drupal 10.x release first, confirm the site is stable, then proceed with the Drupal 11 upgrade.

What does the Upgrade Status module do?

Upgrade Status scans your site and reports Drupal 11 readiness in three areas: your environment (PHP and database versions), your contributed modules (which have D11-compatible releases), and your custom code (which APIs are deprecated). It turns an unknown into a concrete, per-item task list before you change a single line of code.

Does Drupal Rector fix custom code automatically?

Largely, yes. Drupal Rector rewrites deprecated API calls in your custom modules and themes automatically. It handles the mechanical, repetitive deprecations — which is most of them. It cannot rewrite business logic, so a small number of warnings will still need a manual fix. Run it in dry-run mode first, then review every diff before committing.

How long does a Drupal 10 to 11 upgrade take?

For a healthy Drupal 10 site — current minor version, mostly maintained contrib, modest custom code — plan 2 to 6 weeks. Most of that is dependency preparation (Phase 2), not the upgrade command itself. The actual upgrade runs in hours on a clean codebase.

What happens to contrib modules with no Drupal 11 release?

You have four options, cheapest first: apply an existing D11 compatibility patch from the module's issue queue, swap the module for a maintained equivalent, port it yourself with Rector, or drop the feature if it's unused. A typical 30-module site has one to three modules in this state — find them during the audit, not during the upgrade.

Which core modules were removed in Drupal 11?

Several modules were removed from core entirely, including Aggregator, RDF, HAL, and Quick Edit. Others — such as Book, Forum, and Tour — moved to contrib and still work once you require them as separate Composer packages. CKEditor 4 was already removed in Drupal 10.

Do I need to do this before December 2026?

Drupal 10 reaches end-of-life in December 2026, after which it stops receiving security advisories. The upgrade gets more expensive the closer you run to that date — engineering availability tightens and contrib maintainers drop their D10 branches. See the Drupal 10 EOL decision framework for how to time it.

Need a second set of eyes on the scope?

The checklist is the easy part. The judgment calls — which contrib module to patch versus replace, how much custom code Rector will really cover, whether your hosting move is a ticket or a project — are where an outside read pays for itself.

We scope Drupal 11 upgrades in a single 30-minute call: readiness audit, contrib triage, timeline, and a risk register you can take to your team.

Schedule a free Drupal 11 upgrade consultation →