Drupal 10 to Drupal 11: Successfully Navigating the Drupal Upgrade Path

December 17, 2025

We've all done it. You know that your Drupal website needs an upgrade, but you put it off for one reason or another. Next thing you know, the upgrade ticket is six months (or more) old. Guilty as charged.

For me, the deadline was clear: Security support for Drupal 10.5.x ends the week of June 15, 2026. Ignoring that date means ignoring critical security patches which is a huge liability for any site owner. While client work had kept me busy, a brief slowdown provided the perfect opportunity to tackle this necessary upgrade for drupalodyssey.com, making the jump to Drupal 11.

I've done several Drupal upgrades from D10 to D11 for clients already, so I was prepared for the amount of work that needed to be done. This experience, gained while performing dozens of client upgrades, is the basis of the streamlined, risk-mitigating process I'm sharing below.

Turning Unknowns into Known Costs

The very first thing in the upgrade process is identifying exactly what needs to be updated. Attempting this manually is a monumental task that turns development hours into unknown costs.

The Essential Tools

  • Environment Check: Before touching any code, confirm your server is ready. Drupal 11 requires a minimum of PHP 8.3. Confirm your environment meets the new requirements.
  • The Upgrade Status Module: This module is invaluable. It reports on:
    • Which Contributed (Contrib) modules are ready for the new core version.
    • Which Contrib modules are unsupported, obsolete, or need work.
    • Where in your Custom Code you are using deprecated functions that must be updated.

This comprehensive reporting provides the baseline necessary to accurately estimate the time and cost involved, transforming a nebulous task into an actionable plan.

A Critical Oversight

While the tools are great, they don't catch everything. The Upgrade Status module does fall short on client-side code. In my case, I had two or three broken JavaScript libraries because they did not work with jQuery 4, which is included in Drupal 11.

This is a critical reminder that while automated tools are a massive help, manual regression testing on every major feature is non-negotiable after the upgrade.

Mitigating Risk With A Two-Phase Deployment Strategy

From my experience managing client site upgrades, I have found it best to divide the upgrade into two distinct releases. This strategy isolates potential problems and dramatically reduces risk.

Phase 1: Dependency Cleanup and Compliance

The first release is done AFTER updating all of the contrib modules and custom code, but BEFORE updating Drupal core.

The reason for this is to clean your code base by removing any unused, unsupported, or obsolete Contrib modules/themes, and updating all custom code to be compliant with the next Drupal core version. This means you are running a fully D11-compliant codebase while still running on the old, stable Drupal 10 core. If something breaks, you know it's a module bug, not a core bug.

Phase 2: Core Upgrade Execution

Once your code base is clean and compliant, then and only then, should you update Drupal core.

  • The Composer Step: With a clean codebase deployed, Phase 2 is about running the core upgrade command (see the specific upgrade composer command on the Drupal release page) and resolving dependencies.
  • The Database Step: Once the files are updated, you finalize the process with the classic one-two punch:
     drush updb
     drush cr
  • The Configuration Step (Critical): The updb process may introduce new core configuration or require existing configurations to be updated. You must immediately export the new configuration to ensure your codebase reflects the current state of the database.
    • drush cex (or using the UI)
    • Review the exported configuration files for any unintended changes before committing.

By cleaning house first, Phase 2 becomes a pure, simple test of the new Drupal Core APIs, making the overall process much faster with minimal stress.

Future-Proofing Your Business

The Drupal 10.5 EOL date is approaching fast. The clock is ticking, and the consequence of not upgrading is the loss of security patches which is a risk no responsible site owner should take. Upgrading isn't just a technical chore; it's a vital part of risk management and future-proofing your business.

Do you want to spend your time hunting down deprecated JavaScript libraries or Composer conflicts?

If the answer is no, let me handle it. I specialize in streamlined, low-risk Drupal upgrades that get your site safely and quickly on the path to Drupal 11 and beyond. Leverage my proven two-phase strategy to ensure a smooth transition without the headache.
 

Author

Ron Ferguson

0 Comments

Login or Register to post comments.