Drupal 10 to 11 Upgrade: Commands, Failures, Timeline
A Drupal 10 to 11 upgrade is mostly work done on Drupal 10. Get the site to Drupal 10.3 or later on PHP 8.3, run Upgrade Status and composer why-not, release every fix to the live site, then switch core with Composer. For a mid-size site, that takes 11 to 24 working days.
Drupal 10 reaches end of life on December 9, 2026, the same week Drupal 12 ships, according to Drupal's core release schedule. No Drupal 10 releases follow that date, security fixes included, and Drupal 12 won't update from Drupal 11.2 or earlier, so the Drupal 11 upgrade comes first.
This walkthrough is for the dev lead or architect who owns a Drupal 10 site with 40 to 60 contributed modules: what we run, in what order, where it breaks, and how long it takes.
Key Takeaways
- Drupal 10 support ends December 9, 2026. Drupal 12 won't update from 11.2 or earlier, so target Drupal 11.4 or later.
- A Drupal 11 upgrade for a site with 40 to 60 contrib modules takes 11 to 24 working days, usually three to six weeks on the calendar.
- The core switch takes minutes. The weeks go into preparing on Drupal 10, then fixing and testing.
- Upgrade tools don't scan JavaScript, so scripts calling functions removed in jQuery 4 can break menus and sliders after every check passes.
How Do You Upgrade a Drupal 10 Site to Drupal 11?
You upgrade a Drupal 10 site to Drupal 11 in three phases:
- Prepare on Drupal 10. Update modules, fix custom code, and upgrade hosting, releasing each fix to the live site.
- Switch core. Require Drupal 11 with Composer and run database updates, first on a full-size copy of the site.
- Fix and test. Resolve what breaks and pass a done checklist before launch.
Preparation is most of the work. The switch itself takes minutes.
What Does the Drupal 12 Beta Change About Your Drupal 11 Target?
The Drupal 12 beta makes Drupal 11.4 or later the release to aim for. The Drupal 12.0.0-beta1 release notes, published September 30, 2026, say Drupal 12 refuses to update from Drupal 11.2 or earlier, and they recommend at least 11.4, or 11.5 once it's available.
Drupal 11.3 is a short-lived landing spot. The core release schedule ends its security support in the week of December 7, 2026, when Drupal 12.0.0 and 11.5.0 ship.
Two more Drupal 12 changes are worth planning for now:
- Drupal 12 requires PHP 8.5, up from Drupal 11's PHP 8.3. If your host needs lead time, ask about both versions in one request.
- Nine core modules and three core themes move to contributed projects, including Search, Toolbar, Claro, and Olivero.
Neither change blocks a Drupal 11 upgrade, but both decide whether Drupal 12 is a short step or a second project. Our breakdown of Drupal 12 requirements for Drupal 10 sites covers the platform changes in detail.
What Should You Check Before Starting a Drupal 11 Upgrade?
Start with a health check of the current site, so anything that breaks later can be traced to the upgrade rather than to existing problems. We run these checks in this order:
- Back up the site and mark the current version as a known-good restore point.
- Confirm the site is on the latest Drupal 10 release. Drupal 10.3 is the minimum, and 10.6, the final Drupal 10 minor release, is current.
- Confirm hosting meets Drupal 11's platform requirements: PHP 8.3 or later, and MySQL 8.0, MariaDB 10.6, or PostgreSQL 16.
- Confirm the site is clean: no pending database updates, and configuration in code matches the live site.
- Run Upgrade Status, a contributed module that lists every module and piece of custom code not ready for Drupal 11.
- Run composer why-not drupal/core ^11 to see which packages block the upgrade.
The Upgrade Status and composer why-not reports are where the timeline estimate starts.
Which Tools Do You Need for a Drupal 11 Upgrade?
Four tools do most of the work in a Drupal 11 upgrade, and four more support them:
Tool | What it does | How we use it |
Upgrade Status | Reports Drupal 11 readiness for every module and theme | drush upgrade_status:analyze --all |
Drupal Rector | Rewrites outdated code in custom modules automatically | Handles routine changes; developers handle the rest |
PHPStan | Catches outdated or broken code before it reaches a browser | Level 2 on custom code, kept running after launch |
Composer | Manages Drupal's code packages | Lists the modules blocking the upgrade |
Composer Lenient (mglaman/composer-drupal-lenient) | Installs a module that hasn't declared Drupal 11 support yet | Lets a community fix be applied to that module |
Composer Patches (cweagans/composer-patches) | Applies community fixes to modules as patches | Set to stop the build if a patch fails to apply |
Drush | Drupal's command-line tool | Database updates, configuration, and status checks |
drupal/core-dev | Drupal's development tools | Required for accurate Upgrade Status scans |
None of these tools scan the site's own JavaScript, so we add a separate scan for functions removed in jQuery 4.
What Pre-Flight Checks Aren't in the Official Upgrade Docs?
Three checks we run aren't in the official upgrade documentation:
- Do as much as possible on Drupal 10 first. Most fixes also work on Drupal 10, so we release them to the live site in small steps, which keeps upgrade day small and predictable.
- Ask the hosting provider what production actually runs. Development machines are often newer than the live server, and a database upgrade is a hosting request with its own lead time.
- Make sure patches can't fail silently. By default, a patch that stops applying only raises a warning, and an old bug quietly returns. We switch that to a hard stop.
What Commands Run the Actual Drupal 11 Upgrade?
The upgrade itself is a short Composer and Drush sequence. On a recent project, once preparation was done, it ran like this:
composer require 'drupal/core-recommended:^11.4' \
'drupal/core-composer-scaffold:^11.4' \
'drupal/core-project-message:^11.4' --no-update
composer require 'drush/drush:^13' --no-update
composer config allow-plugins.symfony/runtime true
composer update --dry-run
composer update
drush updatedb -y
drush cache: rebuild
drush config:export -y The --no-update flags change the project's requirements without installing anything, and the dry run previews what Composer will change. The whole sequence took a few minutes.
Where Does a Drupal 11 Upgrade Usually Fail?
When a Drupal 11 upgrade fails, it usually fails in one of three places. Each should surface in rehearsal, never on the live site.
When Composer installs the new code. A module without a Drupal 11 version blocks the upgrade, and Composer prints a message that begins "Your requirements could not be resolved to an installable set of packages." It's safe, because nothing has changed yet.
When the database updates. A module that fell several versions behind, or a removed feature still switched on, stops the update with an error. The site is restored from the backup taken minutes earlier.
The first time someone opens the site. Custom code that worked on Drupal 10 can stop pages from loading, and visitors see "The website encountered an unexpected error." The log shows the real cause, usually a small code incompatibility.
A rehearsal on a full-size copy of the site is how you find all three before launch.
What Breaks That the Drupal Upgrade Tools Don't Catch?
Three breakages surprised us on Drupal 11 upgrades, and none of them showed up in a readiness report.
Why Do Sliders and Menus Stop Working After a Drupal 11 Upgrade?
Interactive features can break while every page looks right. Drupal 11 ships jQuery 4, which removed old functions such as $.trim and $.isFunction that older custom and third-party scripts still call. Sliders, lightboxes, and menus stop responding, and no upgrade tool scans JavaScript to warn you. Compatibility shims work as a stopgap; the real fix is updating the script.
Can a Module That Works on Drupal 11.0 Break on a Later 11.x Release?
Yes. Core tightens its code rules across Drupal 11 minor releases, so a module that works on 11.0 can break on the latest 11.x. The Superfish menu module stopped the database update on Drupal 11.4.0 until a fix landed in the Superfish issue queue: the module was missing a return type that 11.4 now required. Rehearse on the exact 11.x release you plan to ship.
Why Do Scheduled Jobs Fail After Moving to Drush 13?
Drush 13, the command-line version used with Drupal 11, expects custom commands to use autowiring, and its documentation on custom commands marks the old drush.services.yml registration as deprecated. On our upgrades, commands still registered that way didn't load, and scheduled jobs that call them failed with a "command not defined" error. That failure often happens where nobody is looking.
What Do You Do With a Contrib Module That Has No Drupal 11 Release?
A contrib module with no Drupal 11 release gets the same three questions every time, in this order:
- Is it still needed? Often it isn't, and removing it is the fastest fix.
- Has someone already fixed it? The Drupal community often has a fix waiting for the maintainer to publish. We apply it with Composer Lenient and Composer Patches.
- No fix yet? Make it compatible yourself, which is usually a small change, or replace it with a maintained alternative.
Each route has a cost: a lost feature, a patch on your maintenance list, or behavior editors have to relearn. When the change is small, we make the module compatible ourselves, because it's faster than a replacement and keeps the site behaving as editors expect.
How Long Does a Drupal 10 to 11 Upgrade Take?
A Drupal 10 to 11 upgrade for a mid-size site takes 11 to 24 working days, usually three to six weeks on the calendar. That's our estimate for a site with 40 to 60 contrib modules, a handful of custom modules, a custom theme, a recent Drupal 10 release, and AI-assisted engineering:
Phase | Range (working days) | What's in it |
|---|---|---|
Preparation | 5 to 10 days | Compatibility review, module updates, custom code fixes, replacing removed features, hosting upgrades |
The upgrade | 1 to 2 days | Switching to Drupal 11 and updating the database, first on a test copy |
Fixing and testing | 5 to 12 days | Resolving issues, visual and functional testing, integrations, stakeholder review |
Total | 11 to 24 days | Usually 3 to 6 weeks on the calendar |
Engineering rarely sets the calendar for a Drupal 11 upgrade; stakeholder review and the launch window usually do. Three things move the number: a critical module with no Drupal 11 version, the amount of custom code, and how quickly the host can upgrade the server. A well-kept site can finish in about two weeks. A neglected one can take more than eight.
As of early October 2026, about ten weeks remain before Drupal 10's end of life, so a three-to-six-week upgrade fits if preparation starts this month. Count back from your own change freeze, not from December 9, as we explain in why Q4 2026 is an expensive window for Drupal work.
A Drupal 11 Upgrade Is a Drupal 10 Project
Our view is that a Drupal 11 upgrade is mostly a Drupal 10 project. The most common mistake we see is starting the upgrade before every module and custom fix is ready, and live, on Drupal 10.
Releasing those fixes in small steps turns the switch into a formality: by upgrade day, only a core version change and a database update are left. We also target silent failures on purpose, because a failed patch, a removed jQuery function, or a missing Drush command passes the obvious checks.
AI changes the preparation phase, not the testing phase. Our engineers use Claude and AI agents to read compatibility reports and draft code fixes, and they review every change. That shortens preparation; review, testing, and sign-off still take the time they take. It's the same working model behind How we bring AI into Drupal managed services.
Is Your Drupal 10 Site Ready to Set an Upgrade Date?
Check these six statements before you commit to a Drupal 11 date:
- Your site runs Drupal 10.3 or later, ideally 10.6.
- Your hosting provider has confirmed that production, not just development, runs PHP 8.3 or later and a supported database.
- composer why-not drupal/core ^11 lists only modules you can remove, patch, or fix.
- Your patch tooling stops the build when a patch fails to apply.
- Someone has checked your custom and third-party JavaScript for functions removed in jQuery 4.
- Custom Drush commands used by scheduled jobs no longer rely on drush.services.yml.
How to read your answers:
- Yes to all six: your site is near the well-kept end, around two weeks of work. Book the rehearsal.
- No to statement 2 or 3: the hosting request or the blocking module sets your start date. Raise it now.
- No to statement 1, or to several of statements 4 through 6: plan for eight weeks or more, and start preparing on Drupal 10 now.
What Should You Check Before Calling a Drupal 11 Upgrade Done?
A Drupal 11 upgrade is done when every check below passes. We run them in this order:
- The code installs cleanly, with no failed patches.
- The site reports Drupal 11, with no pending database updates.
- Configuration in code matches the site.
- Drupal's status report shows no errors.
- The error log stays clean while we browse the main pages.
- Scheduled tasks run.
- Key pages show no browser errors, logged in and logged out.
- Editors can create, edit, and publish content, including images and media.
- Forms submit, and emails arrive; logins, search, and integrations work.
- Automated tests pass, and PHPStan reports no new issues in custom code.
- Pages look the same as before, checked with screenshot comparison.
- Speed is the same as before, or better.
- Upgrade-only tools are removed, and security settings are restored.
If any item fails, the upgrade isn't done, even when the site looks right.
What Is the Rollback Plan if a Drupal 11 Cutover Fails?
The rollback plan for a Drupal 11 upgrade is restore, not undo. Database changes made during an upgrade can't be reversed, so the plan puts back the previous code and a fresh backup.
- Before: editors pause publishing, the site goes into maintenance mode, and we take a fresh backup and confirm it restores.
- During: we release Drupal 11 and run the checks within an agreed time limit, typically 30 minutes.
- If anything fails: we put back the previous version and the backup, and the site is exactly as it was.
- Where the hosting allows: we build the Drupal 11 site alongside the live one and switch traffic over, so rolling back means switching back.
We haven't needed the rollback on our Drupal 11 cutovers so far, because rehearsal surfaced the failures first. We still prepare it every time.
How Much Downtime Does a Drupal 11 Cutover Need?
A Drupal 11 cutover needs minutes for the switch itself, and we plan a 30- to 60-minute maintenance window that includes the checks, timed first in a full-size rehearsal. These are typical figures, not guarantees.
The side-by-side approach cuts visitor downtime to almost nothing, but editors pause publishing longer, and it needs hosting that can run both sites.
What Should You Do After the Drupal 11 Upgrade?
After a Drupal 11 upgrade, keep PHPStan and the other checks running, which turns the Drupal 12 upgrade into routine maintenance rather than a project. It's also a chance to remove unused modules, outdated custom code, and old workarounds, which makes the site cheaper to maintain.
Where Should You Start?
Start with two reports: Upgrade Status and composer why-not drupal/core ^11. Together they show what blocks your Drupal 11 upgrade and roughly how long it will take.
For an engineer's second read on those reports before you set a date, a Drupal site audit can map your blockers and give you a realistic range.