Drupal 10 to 11 Migration Checklist: Modules and Compatibility

What You Will Know After Reading This

• The exact Drupal 11 server baseline: PHP 8.3 (PHP 8.4 supported from 11.1), MySQL 8.0 or MariaDB 10.6, Composer 2.7.7+, Symfony 7 and jQuery 4, and why your site must reach Drupal 10.3 first.
• How to handle the six core modules removed in Drupal 11 (Actions UI, Activity Tracker, Book, Forum, Statistics, Tour) without losing their configuration.
• How to run the Upgrade Status module and Drupal Rector to find and auto-fix deprecated API calls in custom modules and themes.
• How to test drupal module compatibility for contributed projects, including core_version_requirement declarations and Composer conflicts.
• A 5-stage deployment sequence that moves the upgrade through CI/CD with a tested rollback path, before Drupal 10 reaches end of life on December 9, 2026.

Table of Contents

• The Core Enterprise Reality: Why a Drupal 10 to 11 Migration Breaks Custom Logic
• Drupal 11 Upgrade Readiness Matrix: Requirements and Enterprise Risk
• The Drupal 11 Upgrade Pipeline at a Glance
• The Ekfrazo 5-Stage Drupal Migration Checklist
• Where Drupal Upgrades Fail: Hidden Deprecations and Composer Conflicts
• In-House Upgrade vs. Engaging a Specialized Drupal Agency
• How Ekfrazo Delivers Secure, Governed Drupal Architecture
• Frequently Asked Questions

The Core Enterprise Reality: Why a Drupal 10 to 11 Migration Breaks Custom Logic

Short answer: Drupal 11 removes every API deprecated during the Drupal 10 cycle. Custom code still calling those APIs throws fatal errors after the core update, which surfaces as white screens and failing API endpoints.

A drupal 10 to 11 migration is not a version bump. Drupal follows a strict deprecation policy: an API is marked deprecated in a minor release (10.1, 10.2, 10.3) and deleted in the next major release. On Drupal 10, a deprecated call logs a notice and keeps working. On Drupal 11, the same call becomes Call to undefined method or Class not found, and PHP halts the request.

That is where the white screen of death (WSOD) comes from. One custom module calling a removed service in a hook_entity_presave() takes down every node save. One custom REST resource extending a changed base class returns HTTP 500 to your mobile app, your search indexer and your CRM sync at the same moment.

The platform underneath also moves. Drupal 11 runs on Symfony 7, PHP 8.3 and jQuery 4. Event subscribers, routing classes and front-end behaviours written against Symfony 6 or jQuery 3 patterns can fail even when they never touch a deprecated Drupal API.

The deadline is fixed. Drupal 10 reaches end of life on December 9, 2026, the same week Drupal 12.0.0 ships. After that date, Drupal 10 sites receive no security releases, which turns a planned upgrade into a compliance exposure for any regulated enterprise.

Planning an Enterprise CMS Upgrade? Stop guessing your module compatibility — Request a Drupal migration assessment to audit your custom codebase with Ekfrazo’s senior architects.

Drupal 11 Upgrade Readiness Matrix: Requirements and Enterprise Risk

Short answer: A Drupal 11 upgrade needs PHP 8.3, MySQL 8.0 or MariaDB 10.6, Composer 2.7.7+, Drupal 10.3 or later as the starting point, and contributed replacements for six removed core modules.

Scenario: pushing the upgrade without an Upgrade Status scan

Consider an enterprise site with 140 contributed modules, 22 custom modules and a custom theme. The team skips the Upgrade Status scan and runs composer require drupal/core-recommended:^11 directly on a release branch.

1. Composer stops first. Eleven contributed modules have no ^11 release, so the update fails. Developers spend two to three days finding forks, patches or replacements one module at a time, without a prioritised list.
2. Runtime failures follow. Once Composer resolves, the staging site throws a WSOD on node save. Removed APIs in custom code surface one fatal error at a time, because PHP stops at the first one.
3. Missing modules block update.php. The site still has Book and Tracker enabled. Neither was added from contrib before the update, so the database update cannot finish.
4. The release window slips. A two-week upgrade turns into six weeks of reactive debugging, with the content freeze extended and editors locked out.

The Upgrade Status module would have produced the complete list of incompatible contributed projects, deprecated API calls and removed-module dependencies on day one, while the site was still running Drupal 10. The figures above are an illustrative model, not a benchmark; your own Upgrade Status report gives the real count.

The Drupal 11 Upgrade Pipeline at a Glance

Short answer: The upgrade runs in six gated stages. Infrastructure changes first, code remediation loops until Upgrade Status reports no blockers, and only then does Composer move core to Drupal 11.

[Server Env Update (PHP 8.3)]
          |
          v
[Upgrade Status Module Scan] <------------+
          |                               |  re-scan until
          v                               |  no blockers remain
[Drupal Rector Auto-Fixes] ---------------+
          |
          v  (only when the scan is clean)
[Composer Update (drupal/core-recommended:^11)]
          |
          v
[Database Update & Config Export]
          |
          v
[CI/CD Production Deployment]

The Rector-to-scan loop is where most of the effort sits; Composer and the database update are short once it closes.

The Ekfrazo 5-Stage Drupal Migration Checklist

Short answer: Upgrade the server stack first, scan with Upgrade Status, auto-fix deprecations with Drupal Rector, run the Composer and database updates, then deploy through CI/CD with cache rebuilds and post-launch QA.

Use this drupal migration checklist in order. Each phase produces an artefact (a server image, a scan report, a diff, a lock file, a release) that the next phase depends on.

Phase 1: Server Infrastructure & Database Engine Updates

Drupal 10.3+ already runs on PHP 8.3, so upgrade the runtime while still on Drupal 10. This separates infrastructure risk from application risk.

• Update core to the latest Drupal 10.x minor (10.3.0 is the minimum starting point for Drupal 11).
• Rebuild container or server images on PHP 8.3 with the zlib extension; confirm OPcache and APCu settings carry over.
• Upgrade the database engine to MySQL 8.0+ or MariaDB 10.6+ (PostgreSQL 16+ or SQLite 3.45+ where used). Run this as its own change window with a verified backup.
• Update Composer to 2.7.7+ (composer self-update) on developer machines and CI runners.
• Plan Drush 13 for deployment scripts.
• Run the full regression suite on Drupal 10 + PHP 8.3 before touching core.

Phase 2: Upgrade Status Module Scan and Deprecation Auditing

The Upgrade Status module reads your codebase and reports every deprecated API call, incompatible contributed project and environment gap against Drupal 11.

composer require --dev drupal/upgrade_status
drush en upgrade_status -y
drush upgrade_status:analyze --all

• Export the report and classify every project: compatible, update available, patch available, needs replacement, or remove.
• List removed core modules still enabled (Actions UI, Activity Tracker, Book, Forum, Statistics, Tour).
• Uninstall contributed and custom modules the business no longer uses; every module removed is one less compatibility problem.
• Assign each custom-code finding an owner and an estimate.

Phase 3: Automated Code Remediation with Drupal Rector

Drupal Rector rewrites deprecated PHP calls in custom modules and themes into their replacements. It handles the mechanical bulk of remediation; developers review the diff and handle what it cannot.

composer require --dev palantirnet/drupal-rector
vendor/bin/rector process --dry-run   # review the proposed diff
vendor/bin/rector process             # apply it

• Point rector.php at web/modules/custom and web/themes/custom only; never at contrib or core.
• Commit Rector changes as a separate, reviewable pull request.
• Fix the remaining findings by hand: Symfony 7 signature changes, jQuery 4 front-end behaviours, Twig template changes.
• Update every custom .info.yml to core_version_requirement: ^10.3 || ^11, so the same code runs on both versions during the transition.
• Re-run Upgrade Status until custom code reports zero Drupal 11 blockers.

Phase 4: Composer Execution and Database Updates (update.php)

Only start this phase when Upgrade Status is clean. If a removed core module is still needed, add its contrib version before updating core, and do not uninstall it: uninstalling destroys its configuration.

composer require drupal/book drupal/forum   # example: removed modules still in use
composer require 'drupal/core-recommended:^11' 'drupal/core-composer-scaffold:^11' \
  'drupal/core-project-message:^11' --no-update
composer update --with-all-dependencies
drush updatedb -y
drush config:export -y

• Use --no-update first to catch conflicts before anything changes on disk.
• For a contrib module that works but has not declared ^11, use the Composer Lenient plugin or a documented patch, with a ticket to remove the workaround.
• Run drush updatedb (or update.php) and read every update hook message.
• Export configuration and commit composer.json, composer.lock and the config sync directory together.

Phase 5: CI/CD Deployment, Cache Rebuilds, and Post-Launch QA

Promote the upgrade through the same pipeline as any release: build once, deploy the identical artefact to staging and production.

• Pipeline steps: composer install --no-dev, drush updatedb -y, drush config:import -y, drush cache:rebuild.
• Take a database snapshot immediately before production deployment; document the rollback trigger and the restore time.
• Run automated smoke tests on critical paths: login, content save, search, forms, every API endpoint consumed by other systems.
• Watch PHP error logs and watchdog for deprecation and fatal errors for the first 72 hours.
• Re-run Upgrade Status on Drupal 11 to start tracking Drupal 12 deprecations.

Where Drupal Upgrades Fail: Hidden Deprecations and Composer Conflicts

Short answer: Most failed Drupal 11 upgrades trace to four causes: abandoned contributed modules blocking Composer, removed core modules still enabled, deprecated calls in custom code, and themes built on outdated Twig and jQuery patterns.

1. Composer dependency conflicts from abandoned contributed modules

A single contributed module pinned to ^10 blocks the entire drupal/core-recommended:^11 resolution. Composer reports the conflict, but in a large dependency tree the message often names a transitive package rather than the module at fault. Sites with 100+ contrib projects often carry several modules whose maintainers have not released a Drupal 11 version.

Fix: Use the Upgrade Status report to list them up front, then decide per module: update, patch, replace, adopt into your custom codebase, or remove.

2. Removed core modules causing fatal errors on load

If Activity Tracker, Book, Forum, Statistics, Tour or Actions UI are enabled when core 11 lands, Drupal finds a module in the database with no code on disk. update.php blocks, and Drush may skip that warning and leave the site in a broken state.

Fix: composer require the contributed version (for example drupal/tracker) before the core update, and keep the module enabled so its configuration survives.

3. Deprecated API calls hidden in rarely executed code paths

Static analysis catches most deprecated calls, but code built with dynamic service names, magic methods or string-based callbacks can slip past it. These fail only when an editor triggers a rare workflow: a quarterly report export, a bulk content action, a migration rollback.

Fix: Pair Upgrade Status and Drupal Rector with automated functional tests on business-critical workflows, and run PHPUnit with deprecation reporting turned on in CI.

4. Custom themes breaking on Twig and jQuery changes

Custom themes that override core templates, rely on removed Twig filters or use jQuery methods removed in jQuery 4 (such as jQuery.trim or jQuery.isArray) break visually or silently stop running behaviours. Upgrade Status scans Twig templates, but JavaScript needs a separate review.

Fix: Audit *.html.twig overrides against current core templates, replace removed jQuery utilities with native JavaScript, and run visual regression tests on key templates.

3 Questions IT Directors Must Ask Their Dev Team Before a Drupal 11 Cutover

1. “Show me the latest Upgrade Status report. How many blockers remain, and who owns each one?” A team that cannot produce this report has not scoped the upgrade.
2. “Which contributed modules are we patching or running under Composer Lenient, and what is the exit plan for each?” Every workaround is technical debt that resurfaces at the Drupal 12 upgrade.
3. “What is our rollback trigger, and how long does a full database and code restore take?” If the answer is not a tested number of minutes, production is not ready.

In-House Upgrade vs. Engaging a Specialized Drupal Agency

Short answer: Handle the Drupal 11 upgrade in-house when the site uses mostly standard contributed modules and you have Drupal expertise on staff. Engage a partner for headless builds, custom entities and integration-heavy platforms.

A useful rule: if the Upgrade Status report shows more custom-code blockers than your team can clear in two sprints, bring in specialist capacity before the content freeze, not after.

How Ekfrazo Delivers Secure, Governed Drupal Architecture

Short answer: Ekfrazo runs Drupal 11 upgrades as governed engineering programmes: a scoped code audit, automated remediation, and releases through ISO/IEC-aligned CI/CD pipelines, tied to the customer, employee and operational systems the CMS serves.

A Drupal platform rarely stands alone. It publishes the customer experience (CX), feeds intranets and portals that shape the employee experience (EX), and exchanges data with the CRM, ERP and analytics systems that run operations (OX). An upgrade that breaks one integration breaks all three. Ekfrazo plans the drupal 10 to 11 migration around those dependencies, not around core alone.

• Assessment first. Senior architects run Upgrade Status and dependency analysis on your codebase and return a prioritised blocker list with effort estimates, before any code changes.
• Automated, reviewable remediation. Drupal Rector handles mechanical fixes; engineers resolve Symfony 7, Twig and jQuery 4 changes, with every change in a reviewable pull request.
• Governed delivery. Upgrades move through Cloud integration and CI/CD pipeline engineering with change approval, automated testing, database snapshots and documented rollback, aligned to ISO/IEC governance practice.
• Integration assurance. Contract tests verify every API endpoint that external systems consume, so CRM syncs, SSO and search indexing keep working after cutover.
• A path past Drupal 11. The same audit flags deprecations headed for removal in Drupal 12, so this upgrade lowers the cost of the next one.

Learn more about our Enterprise Drupal development services.

Drupal 10 reaches end of life on December 9, 2026.

Get a clear, costed view of your Drupal 11 upgrade: incompatible modules, deprecated custom code, removed core dependencies and a cutover plan your change board can approve.

Request a Drupal migration assessment →

Frequently Asked Questions

Short answer: These answers cover the questions CTOs and platform owners ask most often when scoping a Drupal 11 upgrade: requirements, timelines, tooling, removed modules and contributed module compatibility.