Skip to main content

Drupal 11 Change-Record Impact Map for 10.4.x Teams

· 4 min read
Victor Jimenez
Victor Jimenez
Software Engineer & AI Agent Builder

If your team is still on Drupal 10.4.x, treat Drupal 11 migration as active incident prevention, not roadmap hygiene: Drupal.org now flags 10.4.x security support as ended, and current supported lines are newer. The fastest safe path is to clear the high-impact change records first, then move to supported 10.5/10.6 and 11.x targets in one controlled sequence.

The Problem​

Teams on 10.4.x usually underestimate three traps:

TrapWhy it breaks lateReal impact
Removed core modules/themes in 11.0Code/config still references modules that moved out of coreComposer/update failures or missing functionality after deploy
Config Actions model shiftTeams keep procedural assumptions while actions are pluginizedRecipe/config automation drifts or fails under newer workflows
Platform baseline jumpPHP/composer/test stack upgrades bundled with core majorCI starts failing before code deploy is attempted

For Drupal CMS teams, another timing issue matters: the CMS release stream now shows 2.0.0 current and marks the 1.x line unsupported, so upgrade planning must align core and CMS constraints together.

The Solution​

Build an impact map from official change records and release notes, then execute in this order.

Impact map (10.4.x -> supported 10.x -> 11.x)​

AreaChange record / release noteRisk for 10.4.x teamsConcrete migration move
Core support windowDrupal releases page marks 10.4.x security support endedStaying on 10.4.x leaves no security runwayMove first to latest supported 10.x branch, then 11.x
Removed extensions in 11.011.0.0 release notes + deprecated/obsolete modules docsConfig still depends on core modules removed in 11.0Install contrib replacements before major upgrade
Config Actions architectureChange record: configuration actions are now pluginsCustom automation written around old assumptionsRefactor to plugin-based config actions and re-test recipes
OOP hooksChange record: object-oriented hook implementationsMixed procedural/OOP hook style causes maintenance driftStandardize new hook code to OOP style, keep legacy only where needed
Entity ID assumptionsChange record: content entities may use UUID as entity ID(int)$entity->id() and numeric route assumptions failAudit integrations and update typed ID assumptions
Access-aware label formatterChange record: entity reference label formatter restricts linksTests/UI code assume <a> always existsUpdate assertions for link-or-text output by access context
Platform prerequisites11.0.0 release notes (PHP 8.3, Symfony 7, PHPUnit 10, Composer updates)Upgrade blockers happen in CI/container images firstUpgrade runtime/tooling baseline before core major step

Code-level examples from upstream sources​

EntityPermissionsRouteProviderWithCheck is explicitly deprecated in core 11.x:

/**
 * @deprecated in drupal:11.1.0 and is removed from drupal:12.0.0.
 * Use EntityPermissionsRouteProvider instead.
 */
class EntityPermissionsRouteProviderWithCheck extends EntityPermissionsRouteProvider {}

Statistics removal in Drupal 11 also requires cleaning old .htaccess exceptions:

# Allow access to Statistics module's custom front controller.
RewriteCond %{REQUEST_URI} !/core/modules/statistics/statistics\.php$

Related posts:

What I Learned​

  • The largest Drupal 11 risk for 10.4.x teams is usually sequence, not code volume.
  • Config actions and hook modernization should be treated as upgrade enablers, not optional cleanup.
  • Drupal CMS version cadence can invalidate a technically successful core upgrade if CMS branch support is ignored.
  • Access-aware rendering changes create noisy false negatives unless test assertions are updated early.

References​