The D10 EOL Architectural Audit: Delete Code or Pay for It Twice

Bottom Line for Stakeholders

Symfony 6 Is the Real Clock

Here's where it gets interesting. Most teams focus on the "Drupal 10 → Drupal 11" label. But the actual forcing function is one layer deeper: Symfony.

Drupal 10 runs on Symfony 6.4. Drupal 11 requires Symfony 7. Symfony 6.4's own LTS support doesn't end until November 2027 — but the Drupal security team stops patching D10 a full year before that. So after December 2026, you're flying without a net on both layers. Drupal isn't patching your application code, and you're stuck on a Symfony version that's marching toward its own EOL with no upgrade path that doesn't go through D11.

This matters beyond developer convenience. If your organization goes through security audits, maintains cyber insurance, or operates under any regulatory compliance framework, running unsupported software isn't a "we'll get to it" item. It's a checkbox that auditors specifically look for. Post-EOL Drupal 10 isn't "old Drupal." It's unsupported infrastructure — the same category as an unpatched Windows Server or an expired SSL certificate.

That's the conversation to have with your CTO. Not "we need to upgrade our CMS." It's "our web infrastructure becomes a compliance liability on December 10, 2026."

 

The "Clean Room" Audit: Your Custom Module Count Should Go Down

Now for the part that separates an upgrade from an architectural win.

Drupal 11 core has absorbed a significant amount of functionality that used to live in contrib modules or, worse, in your custom code. Single Directory Components (SDC) are now stable in core. The new Navigation module ships with D11. If you're running custom admin navigation solutions or contrib SDC shims, those should be deleted — not ported.

Think of it like this: every line of custom code is a liability. It needs maintenance, testing, documentation, and someone who remembers why it exists. If core now handles that responsibility, your job isn't to keep your implementation alive. Your job is to kill it and let core do the work.

This is the "Clean Room" philosophy. Don't port the mess. Audit every custom module, every contrib dependency, every workaround that got shoved in during the D9→D10 rush. Each one gets justified or removed. No exceptions.

Here's the litmus test: if your custom module count doesn't decrease during this migration, the architecture failed.

The goal is a leaner D11 footprint. One that's closer to core, carries less custom baggage, and — critically — makes the eventual D12 move a non-event. Because D12 is coming, and the teams that do the hard audit work now will breeze through it. The teams that blindly port everything forward? They'll be right back here, writing the same budget justification, having the same painful conversations.

The Upgrade Toolchain (and Why You'll Fail the First Dry Run)

Let's get tactical. But first, a mandatory stepping stone that trips people up:

You must be on D10.3.0+ before touching D11. All core update hooks added prior to 10.3.0 have been removed from D11's codebase. If you try to jump from, say, D10.2.x directly to D11, those database updates simply won't exist. D10.3.1 specifically defined all deprecated code targeted for D11 removal — it's your clean baseline.

With that out of the way, here's the toolchain:

Upgrade Status module — Install this on your dev environment and navigate to Administer >> Reports >> Upgrade Status. It scans your contrib and custom code for deprecated API usage and gives you a checklist. It effectively gamifies the process, which — honestly — you'll need, because the list will be longer than you expect.

Drupal Rector (drupal-rector) — This is your automated deprecation fixer. It'll rewrite deprecated code patterns across your custom modules. Where it can't make the call automatically, it leaves // @todo comments in the code for human judgment. Run it, commit the auto-fixes, then work through the @todo list manually.

Project Update Bot — Before you start patching contrib modules yourself, check the module's issue queue on drupal.org. The Project Update Bot runs across all projects and opens issues with D11 compatibility problems. Someone may have already done the work.

**The composer gauntlet:**

# Pre-flight check. This WILL fail the first time. And the second. 
composer update --dry-run

# When it fails, this tells you exactly which dependency is blocking D11.
composer why-not drupal/core 11.0

# For contrib modules that work on D11 but haven't declared compatibility yet:
composer require mglaman/composer-drupal-lenient

# For contrib modules that need a patch to work:
composer require cweagans/composer-patches

Expect multiple failed dry runs. That's not a bug in your process — it is the process. Each failure tells you something specific about your dependency tree. Fix, re-run, repeat.

One more thing: BLT has to go. Acquia's Build Launch Tool is undergoing its own EOL and is not compatible with Drupal 11. If it's in your codebase, it must be fully removed before upgrading. Acquia has a tutorial on docs.acquia.com for the removal process. Don't skip this — it's not optional.

The Silent Breakage Vectors: jQuery 4 and Infrastructure Requirements

The upgrade guides will walk you through the PHP and database requirements. But there's a breakage vector that doesn't get enough attention: jQuery 4.

D11 ships with jQuery 4, up from jQuery 3.x in D10. Removed methods, changed signatures — any custom JavaScript or contrib module relying on jQuery 3.x-specific APIs will break. And it'll break silently. No PHP errors in your logs. No big red warnings. Just broken UI interactions that your QA team may or may not catch before production.

Audit your *.js files. Audit your contrib modules' JS. If you're using jQuery methods that were deprecated in 3.x and removed in 4, this is where they'll bite you.

I have personally run into this with Drupal Odyssey. The theme that I use relied on local copies of Owl Carousel and FancyBox; both of which were for jQuery 3. There wasn't a jQuery 4 version on CDN that I could find either.

Now, the infrastructure checklist. Here's where "just a composer update" falls apart completely:

If your hosting environment doesn't meet these requirements, you're not upgrading Drupal — you're upgrading your entire infrastructure stack first. That's a different project, a different timeline, and a different budget conversation. Which brings us back to the budget urgency.

December 2026 is roughly 9 months away. That sounds comfortable until you factor in enterprise procurement cycles, infrastructure upgrades, QA passes, and the fact that every other Drupal shop is going to be doing this simultaneously. The contrib maintainer bandwidth crunch alone should worry you.

The "Clean Room Migration" isn't about fear. It's about using this forcing function to do what we always say we'll do "next sprint" — delete the dead code, remove the workarounds, question the assumptions baked into modules written three major versions ago.

If your custom module count goes up during this migration, we need to talk.

Mapping out a complex Drupal migration or architecture? Let's chat about how to navigate those waters safely. And if you've already started your D11 audit and found something gnarly lurking in the dependency tree — the Odyssey is better when we travel together. Drop a comment or find me on Slack.