On December 9, 2026, Drupal 10 reaches end of life. After that date it receives no further releases, including security releases. If your site runs Drupal 10, this is the season to plan the move to Drupal 11, and the good news is that on a well-maintained site it is one of the calmer upgrades the platform has ever offered. This article explains what end of life means in practice, what the upgrade involves, and how we sequence it so that nothing about it feels like an emergency.
What end of life actually means
Drupal publishes its support calendar years in advance. Each major version is supported until shortly after the next one ships, and Drupal 10's date was set long ago to coincide with the release of Drupal 12 in the week of December 7. The site does not stop working on December 10. Nothing breaks. What changes is that from that point, newly discovered vulnerabilities in Drupal 10 core will not receive fixes, and contributed modules will gradually drop their Drupal 10 compatibility as maintainers focus on current versions.
For a business, that translates into a simple statement: after December 9, a Drupal 10 site is running on software nobody is maintaining. That is a position to leave before it starts, not after.
Why this upgrade is easier than the ones you may remember
People who lived through the move from Drupal 7 remember a rebuild. That model ended with Drupal 8. Since then, every major version has been a continuation of the previous one: Drupal 11 is Drupal 10 with the deprecated code removed and a few underlying libraries updated. Content, configuration, users and files carry over unchanged. Custom code that avoided deprecated functions works as it did.
The Drupal community also built tooling for exactly this transition. An upgrade status report lists every module and theme on the site, tells you whether a compatible version exists, and flags the specific lines of custom code that need attention. Automated tools rewrite most of those lines. What used to be discovery work is now a report you can read in ten minutes.
How we sequence it
The upgrade itself is a few hours. The planning around it is what makes it uneventful, and it follows a fixed order.
- Get current on Drupal 10 first. Sites on the latest Drupal 10 minor release with current modules have the shortest path. Any pending updates go in ahead of the major upgrade, so the two are never entangled.
- Run the readiness report. Every module either has a Drupal 11 release, needs a patch that already exists, or has a successor. We resolve each one before touching core. A module with no path forward is a small decision, not a blocker, and we bring those to you with a recommendation.
- Update custom code. The automated rewrite handles most of it. We review the remainder by hand and run the site's tests.
- Check the platform layer. Drupal 11 raised its minimum PHP and database versions. On infrastructure we manage, current versions are already in place, so this step is a confirmation. Elsewhere it may be the piece that takes the longest to arrange, which is why it comes early in the plan.
- Rehearse on staging. The full upgrade runs on a staging environment with a fresh copy of production data. We check the pages people use most, the forms, the integrations and the editorial screens. Any surprise appears here, where it costs nothing.
- Release like any other release. The production upgrade goes out through the same deployment process as a routine update, with a tested backup taken moments before and a rollback path we have already used. Editors usually notice nothing beyond a slightly different version number on the status page.
What comes along for free
Drupal 11 is not only a support renewal. Its recent minor releases carry the largest performance improvement in the platform's history, with the same hardware serving noticeably more requests. The administrative interface has continued to improve. And moving to Drupal 11 now places the site on the version that will receive the smoothest path to Drupal 12 when that becomes the sensible next step, a year or more from now.
Upgrades also tend to be a good moment for small housekeeping: retiring a module nobody uses, tightening a permission, cleaning up an old text format. We keep that list separate from the upgrade itself so that each change stays reviewable, but we do bring the list.
Timing
September and October are the comfortable months. Leaving the upgrade for late November means competing with year-end campaigns, content freezes and holidays for the same calendar, and it leaves no room for a module maintainer who is slower than expected. Our recommendation is straightforward: run the readiness report now, resolve any module questions in the coming weeks, and schedule the upgrade for a quiet day before the middle of November.
For sites we already maintain, this planning is under way and you will hear from us with a proposed date. If you run Drupal 10 elsewhere and would like a second pair of eyes on the readiness report, or a fixed-price quote for the upgrade, get in touch. There is plenty of time, and we would like to keep it that way.