Drupal 11 has been available for a while, but adoption is lagging in ways that should get any agency's attention right now. With Drupal 10 reaching end of life on December 9, 2026, the math on how many sites are still running unsupported code is uncomfortable, and the window to fix it is shorter than it looks.
What the numbers show
The adoption tracker published by Gspikes puts Drupal 11 at 36% of reporting Drupal sites as of early September 2026. That sounds like progress until you compare it to context: Drupal 10 reached a comparable share faster at the same point in its lifecycle. Drupal 11 is climbing at roughly half that pace.
The December 9 EOL date for Drupal 10 is the hard number that matters. When that date passes, a large portion of the active Drupal install base will be running software that receives no security fixes. The tracker estimates that share could nearly triple in the weeks after EOL, because a meaningful chunk of the remaining Drupal 10 sites are not on an active upgrade track.
A few contributing factors the data points to:
- Contributed module lag. Many sites are waiting on a handful of critical modules to ship Drupal 11-compatible releases. That waiting has become a habit that extends timelines further than it should.
- Hosting and PHP version requirements. Drupal 11 requires PHP 8.3 minimum. Sites on older shared hosting plans or with locked PHP environments are blocked until they address infrastructure first.
- Prioritization debt. Upgrade projects compete with feature work and new builds. Agencies and in-house teams that treated Drupal 11 compatibility as a "later" item are now staring down a three-month runway.
- The perception that EOL doesn't matter immediately. It does. Drupal security advisories stop covering Drupal 10 on December 9. Any vulnerability disclosed after that date goes unpatched on those sites, indefinitely.
The scale of the problem is not abstract. There are roughly 260,000 sites in the reporting population. If two-thirds of them are still on Drupal 10 when EOL hits, that is a very large surface area of exposed production code.
Our take
We have been tracking this across our own client portfolio since earlier this year, and the pattern the data describes matches what we see. The sites that haven't upgraded fall into a few predictable buckets, and the right response is different for each one.
The "we're waiting on one module" bucket. This is the most common story we hear. A site is otherwise ready, but a critical contributed module hasn't released a stable Drupal 11 version. Our advice: stop waiting passively. Check the module's issue queue. If there is an active beta or release candidate, test it on a staging copy now. If the module appears unmaintained, you have a real decision to make, either find an alternative, write the compatibility patch yourself, or scope the removal of that module from the project. Waiting until November to make that call leaves no margin.
The "infrastructure is the blocker" bucket. PHP version requirements are real but solvable. If a client site is on a host that won't run PHP 8.3, that is not a reason to stay on Drupal 10, it is a reason to change hosts or upgrade the server environment. We would rather have that infrastructure conversation now than explain to a client in January why their site hasn't received a security patch in six weeks.
The "we didn't plan for this" bucket. Some sites are simply not on anyone's active roadmap for an upgrade. Clients who bought a site, launched it, and moved on sometimes don't have a budget line for platform maintenance. This is the hardest conversation, and it's one we'd rather have in September than in December when the EOL clock has already expired. A Drupal 10 to 11 upgrade for a well-maintained site is typically a 20-40 hour engagement depending on contributed module count and custom code. That's a manageable scope when planned in advance. It's a rush job when the security advisory lands and there's no patch available.
What we would not do: treat the EOL date as a soft deadline. The Drupal security team is clear that support ends on December 9. There is no grace period, no extended support tier for Drupal 10 the way some platforms offer it.
One honest trade-off worth naming: Drupal 11 is not a radical departure from Drupal 10. The upgrade path is the most straightforward major version jump Drupal has had in years. The friction is real but it is not architectural, it is mostly module compatibility and environment configuration. That makes the case for acting now rather than treating this as a heavy lift that needs months of scoping.
What to do this month
- Audit your Drupal 10 sites now. List every site, its PHP version, its contributed module count, and the Drupal 11 compatibility status of its top 10 modules. That audit takes a few hours and tells you exactly where the blockers are.
- Check module issue queues, not just release pages. A module with an alpha or beta for Drupal 11 is often testable today. Don't let "no stable release" be a reason to delay if the beta is solid.
- Prioritize infrastructure changes. PHP 8.3 is the floor. If a hosting environment can't meet it, resolve that before touching Drupal itself.
- Talk to clients now. Clients who don't track Drupal release schedules will not know December 9 is coming. Tell them. A short email or a line in the next project status update is enough. Framing it as a security deadline rather than a platform upgrade tends to move budget conversations faster.
- Schedule upgrade work before October. Development queues fill up in Q4. If you want the work done properly before EOL, the engagement needs to start in September or early October at the latest.
Originally referenced: Drupal 11 Adoption Tracker: The Curve, the Cliff, and 260,000 Sites on Gspikes.
If you have Drupal 10 sites in your portfolio and aren't sure where they stand on the upgrade path, we're happy to do a quick assessment and give you an honest timeline. Get in touch before the Q4 crunch makes scheduling tight.
