Drupal 11 Adoption Tracker: The Curve, the Cliff, and 260,000 Sites

Two numbers, and they do not sit comfortably together.

The first: 36.0% of Drupal sites that report their version to drupal.org are now running Drupal 11. That is a real achievement — a year ago it was 13.1%.

The second: on 9 December 2026, Drupal 10 reaches end of life. That is 94 days from the day I am writing this, and 43.8% of those same sites are still on it.

I built this page because I kept doing the same arithmetic by hand for client conversations, and because every “Drupal 11 adoption” figure I could find was either a press release, a conference slide, or a number with no date attached. So this is the tracker I wanted to exist: the current figures, the method that produced them, a projection I am willing to be judged on, and what the curve actually means if one of these sites is yours. We update it quarterly. Every chart is free to reuse with attribution and a link.

The numbers (week of 23 August 2026)

• Drupal 11: 168,857 sites — 36.0% of all reporting sites (drupal.org usage statistics)
• Drupal 10: 205,568 sites — 43.8%, still the largest single version (drupal.org)
• Drupal 9: 52,096 — 11.1%. End of life since 1 November 2023 (drupal.org)
• Drupal 8: 42,356 — 9.0%. End of life since 17 November 2021 (drupal.org)
• 94,452 sites — 20.1% — are already running an unsupported version today, before Drupal 10’s deadline arrives
• Drupal 11 grew 2.87× year over year, from 58,814 sites (13.1%) in August 2025
• Drupal 10 peaked at 322,606 sites in February 2025 and has fallen 36.3% since
• The reporting fleet as a whole grew 4.1% year over year, to 468,877 sites — modern Drupal is not shrinking
• On the wider crawlable web, a second source puts Drupal 11 at 19.6% — see the methodology section for why the two disagree (W3Techs, 6 Sep 2026)

Drupal 11 is climbing at half the speed of its predecessors

Raw adoption numbers flatter every release, because the ecosystem keeps growing. The only fair comparison is to line each version up against the clock that matters — months since its own release — and see where it stood at the same age.

Do that, and the picture changes. Two years after launch, Drupal 9 was on 63.0% of reporting sites. Drupal 10 was on 60.1%. Drupal 11 is on 33.1%.

That is not a rounding difference or a slow quarter. At the same point in its life, Drupal 11 has captured a little over half the share each of its two predecessors had. The gap has been widening, not closing, since about month nine.

I want to be careful here, because this is the number most likely to be quoted out of context: this is not evidence that Drupal 11 is a bad release. Nothing in the data says that. What it measures is urgency, and urgency is a function of deadlines, not quality.

Why the curve is flatter, and why that was predictable

Look at what was happening in the background of each of those curves.

Drupal 9 launched in June 2020 into a panic. Drupal 8 was heading for end of life in November 2021, and Drupal 8 sites had no choice — there was a hard, dated, unavoidable cliff seventeen months out. The curve reflects people running.

Drupal 10 launched in December 2022 into the same pressure. Drupal 9 went end of life eleven months later, in November 2023. You can see it in the data: Drupal 10’s steepest climb, from 14.7% to 45.4%, lands almost exactly across that deadline. Again — people running.

Drupal 11 launched in August 2024 into nothing at all. Drupal 10 was fully supported, actively receiving minor releases, and would stay that way for more than two years. For a site owner on a healthy, patched Drupal 10 install, upgrading in 2025 bought exactly one thing: the satisfaction of being current. No security exposure closed, no deadline met, no auditor satisfied. It was a cost with no visible return.

So they did the rational thing and waited. The flat curve is not apathy or disappointment — it is a fleet of sensible people correctly reading the incentive structure. There was no forcing function, so the force never came.

There are secondary reasons, and they are real but smaller. Drupal 11 raised the PHP floor to 8.3, which strands sites on older hosting until someone schedules a platform upgrade. Contributed modules needed a release cycle to catch up, and any site with a long tail of contrib waits for its slowest dependency. But neither of those explains a 27-point gap. The deadline explains the gap.

Which is the whole reason this page has an expiry date on it. The forcing function arrives on 9 December 2026, and everything about this curve should change.

A prediction I’m willing to be wrong about: the crossover lands in late October

Over the last 26 weeks, Drupal 11 has gained an average of 0.52 percentage points per week of share, and Drupal 10 has shed 0.36 points per week. They are 7.8 points apart. Extend both lines and they cross in the week of 27 October 2026 — the first week Drupal 11 becomes the most-used version of Drupal on the reporting web.

That is a linear projection off a short window, which is the weakest kind of forecast, and I would not bet a client’s budget on the exact week. Adoption curves bend; a December scramble could pull it earlier, and a contrib bottleneck could push it later. But it is a specific, dated, checkable claim, and it will be right or wrong by the next refresh of this page. I would rather publish it and be corrected than publish a hedge that cannot be graded.

9 December 2026: the date that makes this page urgent

The core release schedule is unusually blunt about it. Drupal 10.6.0 is the last minor release of Drupal 10. Drupal 12 ships the week of 7 December 2026, alongside Drupal 11.5.0, and Drupal 10 reaches end of life on 9 December 2026 — the same week. No new releases of Drupal 10 will be made after that date (drupal.org core release schedule, last updated 27 August 2026).

Run the current trends forward to that date and you get an ugly arithmetic. Drupal 10 lands at roughly 39.0% — about 183,000 sites — still on it the day it dies. Add the Drupal 8 and 9 sites already stranded, and 55.6% of the reporting Drupal web, on the order of 260,000 sites, is running unsupported code on 10 December.

The unsupported share does not creep up. It nearly triples overnight, from 20.1% to 55.6%, because a version with two hundred thousand installs crosses a line on a Wednesday.

I have deliberately not smoothed that projection to make it look better. If Drupal 11 adoption accelerates the way Drupal 10’s did across the Drupal 9 deadline, the real figure will be kinder than 55.6% — and I will say so in the December refresh. But the shape of the problem does not depend on the precision of the estimate.

What “end of life” actually costs you

Nothing, until something. This is the part that makes end-of-life dates so easy to ignore: on 10 December, every one of those sites will render exactly as it did on the 8th. Editors will log in. Forms will submit. Nothing breaks.

What stops is the maintenance underneath. No more security advisories from the Drupal security team, and no more patches when a vulnerability lands in core. The contributed modules you depend on start drifting as maintainers move their attention to Drupal 12. The PHP versions your stack expects age out beneath you, and managed hosts begin dropping support tier by tier. Every one of those is invisible on the day it happens and expensive on the day it matters.

The historical lesson is Drupalgeddon in 2014, when a critical core vulnerability went from disclosure to mass automated exploitation in a matter of hours. The uncomfortable difference for an unsupported site is not that attackers move faster now. It is that back then, a patch existed.

For public sector and enterprise sites there is a second cost that arrives sooner and hurts more predictably: “we run an unsupported CMS” is a failing answer on a security questionnaire, an insurance renewal, and an increasing share of procurement checklists. A meaningful number of the migration conversations we get pulled into were not started by a security team at all. They were started by an auditor with a checkbox.

The fleet that is already stranded

Before December gets the headlines, it is worth sitting with the number that is already true: 94,452 sites are reporting in on Drupal 8 or Drupal 9 right now. Drupal 8 has been unsupported since November 2021. Drupal 9 since November 2023.

These are not neglected hobby sites — they are sites whose owners did the hard thing. Many of them survived the Drupal 7 to 8 rebuild, which was the most expensive migration in Drupal’s history. And then they stopped, which misses the entire point of what they bought. The whole argument for that painful rebuild was that it was the last one: from 8 onward, staying current became a maintenance task instead of a project. An unpatched Drupal 9 site in 2026 is carrying the same category of risk as the Drupal 7 sites its owner probably feels a little superior to, having paid full price for the escape route and then not used it.

If that fleet behaves the same way after December, the Drupal 10 sites that miss the deadline will not miss it by weeks. They will miss it by years.

Methodology, and why you will see two different Drupal 11 numbers

If you go looking, you will find Drupal 11’s share quoted as 36% and as 19.6%, and both citations will be legitimate. The difference is not error. It is that no single source can see the whole Drupal web, and the two that come closest have opposite blind spots.

Lens 1 — drupal.org usage statistics. Sites running the Update Status module report their core version to drupal.org once a week. This is the primary source for everything above. Its strength is that these are hard counts, not estimates: 468,877 sites in the week of 23 August 2026, with weekly history going back years, which is what makes the aligned-by-release-date comparison possible at all. Its weakness is selection. It only sees sites that report, and a site that reports is a site somebody is still maintaining — exactly the population most likely to have upgraded. The public dataset also does not cover Drupal 7 at all, so the version with the largest abandoned fleet is simply absent.

Lens 2 — W3Techs. Crawls the public web and fingerprints the CMS and version of every site it can identify. Its strength is precisely drupal.org’s weakness: it sees neglected sites, including the 29.6% of the crawled Drupal web still running Drupal 7 — sites that stopped phoning home years ago. Its weakness is that it is a weighted sample of the crawlable, public-facing web, not a census. Intranets, low-traffic sites and anything behind a login are underrepresented.

So drupal.org reads high on Drupal 11 because it is looking at the maintained half of the web, and W3Techs reads low because it is also counting the graveyard. The real figure sits between 19.6% and 36.0%, and I am not going to invent a blended number with a false decimal point to split the difference. What matters is that both sources agree on direction and on ranking: Drupal 11 is rising fast, Drupal 10 is falling, and a very large amount of the Drupal web is running code nobody patches.

For the projection, I fit a linear trend to the last 26 weeks of each version’s share and extended it to 9 December 2026. Twenty-six weeks is long enough to survive the weekly noise in the reporting data — which is considerable, since the total fluctuates by tens of thousands week to week — and short enough to reflect current behaviour rather than 2025’s. If you would model it differently, the underlying dataset is public and I would genuinely like to see your version.

The part nobody puts in a headline: this upgrade is not the hard one

Everything above is a warning, so it is only fair to say the other half plainly, because it changes what the right response is.

Drupal 10 to Drupal 11 is not Drupal 7 to Drupal 8. It is not a rebuild, not a re-platform, and not a project that needs a business case. The 7-to-8 transition was a ground-up architectural change with no in-place upgrade path, and it deserved every bit of the dread it attracted. That era ended with Drupal 7. Since Drupal 8, the release model has been deliberately built so that major upgrades are boring: run the deprecation checker, update the code that trips it, make sure your contributed modules have compatible releases, get onto PHP 8.3, and go.

For a well-maintained Drupal 10 site with mainstream contrib, this is measured in days, not quarters. The sites that will struggle are the ones carrying heavy custom code written against deprecated APIs, or depending on a module whose maintainer has gone quiet — and the single most useful thing you can do this month is find out which of those two descriptions fits you, because the answer determines whether December is an afternoon or a problem.

That is also the uncomfortable implication of the flat adoption curve. When the upgrade is genuinely this manageable, a site that is still on an unsupported version two years from now is not there because the work was too hard.

What to do, depending on where you actually are

Already on Drupal 11 (36.0% of you). Nothing to do except keep doing it. Stay on the current minor release — note that security support for 11.3.x ends when 11.5.0 ships in December, so being on 11 is not the same as being covered. Drupal 12 will be a hop, not a migration.

On Drupal 10 with current contrib and light custom code. This is a scheduled sprint, not a project. Run Upgrade Status, confirm your modules have Drupal 11 releases, check your PHP version, and book it before December rather than after. You are the reason the December projection might come in kinder than 55.6%.

On Drupal 10 with heavy custom code or an aging contrib tail. Start the audit now, this month, even if the work happens later. The deadline is not the problem; discovering an abandoned dependency in week one of December is the problem. What you need before you can plan anything is an honest inventory of what breaks.

On Drupal 9 or Drupal 8. You are already unsupported and have been for years. The good news is that the path from 9 to 11 runs through the same modern upgrade machinery, so this is more recoverable than it feels. The bad news is that every month you wait, you are further from the version everyone else is testing against.

On Drupal 7. Different conversation, genuinely — you are looking at a re-platform, not an upgrade, and the numbers and the four realistic exits are laid out in our Drupal 7 census. If you have decided to move, the 52-step migration checklist is the what, and the 90-day migration calendar is the when.

What we’re watching for the next update

Four things, all of which will be either right or wrong by December, and all of which will be marked as such on this page:

• Does the crossover land in the week of 27 October? The point at which Drupal 11 passes Drupal 10 as the most-used version.
• Does the curve bend? Drupal 10’s adoption accelerated sharply across the Drupal 9 deadline. If the same panic effect appears, Drupal 11’s line should visibly steepen through October and November.
• How big is the stranded fleet on 10 December? Our projection is 55.6%, around 260,000 sites. I would be delighted to be too pessimistic.
• Does the Drupal 8 and 9 population move at all? It has barely shifted in a year. If a hard deadline for Drupal 10 does not dislodge them either, that tells us something durable about how much of the web simply never upgrades.

Reuse this data

Every chart and every figure on this page is free to reuse with attribution and a link back here. We refresh the tracker quarterly — the next update lands in December 2026, immediately after the Drupal 10 end-of-life date, which is the single most interesting data point this page will ever record. A link stays accurate longer than a screenshot.

Corrections are welcome and so are better datasets. The methodology section says exactly what we used and where each source is weak; if you have a private crawl, a hosting-fleet census, or a view of the population these two lenses both miss, I would like to see it.

Related reading: the Drupal 7 census tracks the other end of the same story, and Drupal vs WordPress performance across 2.9 million sites covers what the version you run actually does to your Core Web Vitals.

Gspikes is a Drupal development and SEO agency; Drupal upgrades and migrations that don’t cost you rankings are our flagship service. That’s both the disclosure and the reason we keep these numbers current.