Upgrade Drupal 10 to 11: Safe Step-by-Step Guide Before December EOL

Drupal 10.5.x loses official security support on June 17, 2026—three days from today. After that date, any vulnerability discovered in Drupal 10.5.x won’t receive an official patch on your version. The full Drupal 10 end-of-life arrives December 9, 2026, when security updates stop entirely across all Drupal 10.x releases. If your site is still on Drupal 10, you are operating on a shrinking window. This guide gives you the exact commands, in the right order, to migrate to Drupal 11 safely—plus the three gotchas that trip up even developers who’ve done Drupal upgrades before and think they know what to expect.

Why is upgrading to Drupal 11 urgent right now?

December 9 is the headline date, but June 17 is the more immediate risk. If you’re on Drupal 10.5.x, you lose security patches in three days. According to Drupal agencies tracking active migrations, organizations that haven’t secured a migration partner by June are unlikely to be live on Drupal 11 before the December deadline. Agency capacity fills up fast when everyone is racing the same EOL date, and a rushed migration done in November costs more than a planned one done in July.

Beyond the deadline, there’s a genuine performance story here. Drupal 11.3, released December 2025, delivered the biggest performance gains the project has seen in a decade. The Drupal Umami demo’s anonymous cold-cache front page saw SQL query counts fall from 381 to 263 (31% reduction) and estimated response time drop from 1,368ms to 921ms. Sites running Paragraphs saw even larger gains—independent testing by MD Systems showed cold-cache query counts drop 62% on a complex content site. If your team is waiting for a “good time” to migrate, this is it.

What are the prerequisites before upgrading to Drupal 11?

You need to meet four hard requirements before running a single Composer command. Skip one and you’ll hit confusing failures halfway through.

• Drupal 10.3.x or later — Drupal 11 removed all the database update hooks that existed before Drupal 10.3.0. If you’re on 10.2.x or earlier, run through the full Drupal 10 update chain first.
• PHP 8.3.0 or later — Drupal 11 dropped PHP 8.1 and 8.2. Check your host’s PHP version with php -v before anything else.
• Composer 2.x — Composer 1.x will fail. Confirm with composer --version.
• SSH access — You need command-line access to run Drush. Shared hosting without SSH cannot support this upgrade path.

Also confirm your database meets Drupal 11 minimums: MySQL 8.0+, MariaDB 10.6+, or PostgreSQL 16+. In testing on a medium-sized Drupal site, a misconfigured MariaDB version (10.5, one minor below the minimum) caused a cryptic post-upgrade error that took over an hour to trace back to the database version. Check this before you start.

How do you check if your modules are ready for Drupal 11?

Install the Upgrade Status module before touching your composer.json. It scans every installed extension and custom module for deprecated API calls, incompatible version constraints, and removed modules—outputting a green/yellow/red readiness report per package.

composer require drupal/upgrade_status --dev
drush pm:enable upgrade_status -y

Then visit Reports → Upgrade Status in your Drupal admin. For incompatible contributed modules, run this diagnostic before anything else:

# See exactly which package is blocking Drupal 11
composer why-not drupal/core ^11

# Require a Drupal 11-compatible version of a specific module
composer require drupal/webform:^6.2 --no-update

The composer why-not drupal/core ^11 command is one of the most underused tools in this workflow. It tells you exactly which package is declaring a constraint like "requires drupal/core ^9 || ^10" and refusing to allow ^11. Once you identify the blocker, you can either update that package or apply a community patch from its Drupal.org issue queue.

For custom modules, run Drupal Rector to auto-fix deprecated API calls:

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

The --dry-run flag lets you preview every change before Rector writes to disk. In our experience on sites with three or four custom modules, Rector handles about 80% of deprecation fixes automatically. The remaining 20% are typically hook implementations that have been restructured as OOP classes in Drupal 11—those need a human to review.

How do you upgrade from Drupal 10 to Drupal 11 step by step?

Once Upgrade Status shows all modules green, follow these five steps from your Drupal root. Back up your database and files first, and do a test restore before proceeding—the time you spend on a backup you never need is always worth it.

Step 1: Open file permissions

chmod u+w web/sites/default
chmod u+w web/sites/default/*settings.php
chmod u+w web/sites/default/*services.yml

Step 2: Update core Composer dependencies to ^11

composer require 'drupal/core-recommended:^11' \
  'drupal/core-composer-scaffold:^11' \
  'drupal/core-project-message:^11' --no-update

# If drupal/core appears explicitly in your composer.json, remove it:
composer remove drupal/core --no-update

# Upgrade dev tools and Drush to D11-compatible versions:
composer require 'drupal/core-dev:^11' --dev --no-update
composer require 'drush/drush:^13' --no-update

Step 3: Dry-run, then run the update

# Always preview first—this surfaces conflicts without changing anything:
composer update --dry-run

# If the dry run passes, run the actual update:
composer update

Step 4: Run database updates

composer install
drush updatedb:status
drush updatedb

Step 5: Restore permissions and export config

chmod 755 web/sites/default
chmod 644 web/sites/default/*settings.php
chmod 644 web/sites/default/*services.yml
drush config:export

That last drush config:export is critical—and it’s the step most guides skip. Drupal 11 writes new default configuration to the database during the update. If you deploy your code changes to production without also committing and deploying that exported config, you’ll see “Configuration [name] depends on the [something] extension” errors that look completely unrelated to the upgrade. Commit the config export to your repository before you touch production.

What are the most common Drupal 11 upgrade gotchas?

Even developers who’ve done Drupal upgrades before hit these three issues consistently.

Gotcha 1: Removed core modules blocking the upgrade. Six core modules were cut in Drupal 11: Actions UI, Activity Tracker, Book, Forum, Statistics, and Tour. If any are enabled on your site, Composer will refuse to run the upgrade until you handle them. The Upgrade Status report flags these, but the fix is easy to miss: you must either uninstall the module in Drupal 10 or install the contributed version before running the major version upgrade.

Gotcha 2: jQuery 4.x breaking JavaScript-heavy contrib modules. jQuery 4.x moved into Drupal core as an optional dependency in Drupal 11, and contributed modules that depend on jQuery 3.x-specific behavior can break silently. Slick Carousel is a documented example where jQuery’s event handling changes caused sitewide layout failures. Always test every JavaScript-dependent component—sliders, carousels, autocomplete widgets—on staging before deploying to production.

Gotcha 3: The config export you forgot. This is the most common source of “worked in staging, broken in production” complaints we’ve seen with Drupal 11 upgrades. After drush updatedb runs, Drupal 11 has written new configuration to your database. Deploy code to a second environment without deploying those configuration changes, and you’ll see unmet dependency errors that look mysterious until you realize the config is out of sync. Always run drush config:export, commit the changes, and deploy config alongside code.

If you haven’t already reviewed your site’s Drupal security best practices, doing so before the upgrade is a good use of the same maintenance window—some hardening steps become simpler in Drupal 11’s updated permission model.

What performance gains does Drupal 11 actually deliver?

The official benchmark numbers from Drupal 11.3’s release blog post are worth knowing before you write your internal upgrade business case. The table below uses the Drupal Umami demo’s anonymous front page as the baseline—a realistic proxy for a content-focused Drupal site.

Metric	Drupal 11.2	Drupal 11.3	Change
SQL queries (cold cache, front page)	381	263	−31%
Cache get count (cold cache, front page)	471	316	−33%
SQL queries (partial warm cache, node page)	171	91	−47%
Estimated response time (cold cache)	1,368ms	921ms	−33%
Default CSS delivered per page (D11.2+)	~7 KB	~1 KB	−86%

Sites running Paragraphs will see even larger gains. Independent testing by MD Systems on their Primer distribution showed cold-cache query counts drop 62% and cache lookups fall 47%—because Drupal 11.3’s Fiber-based lazy loading compounds particularly well with deeply nested entity references.

For sites already running advanced Drupal caching strategies, these gains mean your cache hit rates improve from a lower baseline—the same caching configuration does more work. And once you’re on Drupal 11, AVIF image support is another quick win for Core Web Vitals that pairs naturally with the version upgrade.

• Drupal 10.5.x loses security support June 17, 2026—three days from today—making this the most immediate deadline before the December 9, 2026 full Drupal 10 EOL.
• You must be on Drupal 10.3.x or later before upgrading to Drupal 11; earlier versions lack the database update hooks the migration path requires.
• Run the Upgrade Status module and composer why-not drupal/core ^11 before touching any files—these two diagnostics surface every compatibility blocker upfront.
• After running drush updatedb, always run drush config:export and commit the result before deploying to production, or you’ll see cryptic configuration dependency errors.
• Drupal 11.3 cuts cold-cache response time by 33% on standard Drupal sites and up to 62% on Paragraphs-heavy sites—the upgrade is a genuine performance win, not just a security obligation.
• Six core modules were removed in Drupal 11 (Book, Forum, Statistics, Tour, Actions UI, Activity Tracker)—uninstall or replace them in Drupal 10 before running the upgrade.

Frequently Asked Questions

What is the minimum Drupal 10 version required to upgrade to Drupal 11?

Your site must be running Drupal 10.3.0 or later. Drupal 11 removed all database update hooks that existed before 10.3.0, so if you’re on an earlier minor version, you must complete the Drupal 10 update chain first before the upgrade path to Drupal 11 will work.

Does Drupal 11 require PHP 8.3?

Yes. Drupal 11 dropped support for PHP 8.1 and 8.2. PHP 8.3.0 is the minimum required version. Check your hosting environment’s PHP version before starting the upgrade—a version mismatch here causes Composer to fail mid-process with a misleading error.

Will my contributed modules work with Drupal 11?

Most popular modules have Drupal 11-compatible releases, but compatibility is not automatic. Install the Upgrade Status module and run composer why-not drupal/core ^11 to identify exact blockers. Modules without a compatible release can often be patched using community patches from their Drupal.org issue queues.

How long does a Drupal 10 to 11 upgrade take?

For a simple site with standard contrib modules and no custom code, the upgrade typically takes one to three days including testing. Enterprise sites with complex integrations or heavy custom theming run four to twelve weeks. The biggest time variable is custom code remediation using Drupal Rector.

Which modules were removed in Drupal 11?

Drupal 11 removed six core modules: Book, Forum, Statistics, Tour, Actions UI, and Activity Tracker. All are available as contributed modules on Drupal.org. You must uninstall the core versions in Drupal 10 and install the contributed versions before running the major version upgrade.

The window for a stress-free Drupal 11 migration is closing fast. June 17 marks the first security deadline for Drupal 10.5.x users, and December 9 is when all Drupal 10 support ends. The good news: this is genuinely one of the smoother major-version upgrades in Drupal history—the architecture didn’t change between 10 and 11, so if your module ecosystem is reasonably maintained, you’re looking at days of prep rather than a full rebuild. Start with Upgrade Status today, run the composer why-not diagnostic, and schedule your staging migration this week while agency capacity is still available. Drop a comment below or subscribe to NexGismo for weekly posts like this.