Drupal 10 ends on 9 December 2026: upgrade to Drupal 11, wait for Drupal 12, or replatform

Drupal 10 reaches end of life on 9 December 2026. The date is fixed. Drupal’s core team set it in June 2025 and deliberately detached it from the Drupal 12 release, so it holds regardless of when the next major version arrives.

A second deadline has already passed. Security support for the Drupal 10.5 branch ended in June 2026, and 10.4 and everything before it stopped earlier. Only 10.6 carries security coverage through to December. A site sitting on 10.5 today is a site running without security coverage today, while the deadline in the plan is still months away.

That gap is the reason this piece opens here rather than on the December headline. Checking which minor version a site runs takes a minute and settles whether the decision below is a planning exercise or an active exposure.

For teams already on 10.6, December is a planning window, and a wider one than the Drupal 7 deadline allowed. Three paths lead out of it: upgrade to Drupal 11, wait for Drupal 12, or use the window to ask whether Drupal is still the right platform. Each is right under different conditions, and the conditions are checkable.

What end of life actually removes

On 10 December 2026, sites still running Drupal 10 will serve pages exactly as they did the day before. Editors will log in. Cron will run. Nothing breaks on the date, which is the main reason the date gets deferred.

What stops is maintenance. Drupal publishes no further releases for the version. Contributed module maintainers stop shipping releases compatible with it. The security team stops issuing advisories that cover it. A vulnerability found in January 2027 in a module the site depends on gets patched for Drupal 11 and 12, and stays open on Drupal 10.

The exposure accumulates rather than arriving. Each month after the date adds unpatched surface, and the cost of moving rises with it, because the eventual migration starts from a codebase further behind than the one available today.

For organisations with formal audit obligations, the position is more concrete. An unsupported content platform is a finding an auditor records and a procurement process penalises. The regulatory framework varies by sector; the finding does not.

Which Drupal versions are still supported

Three branches carry security coverage today: 11.4 and 11.3 on Drupal 11, and 10.6 on Drupal 10. Everything else has passed its end-of-life date.

Version	Released	Security support ends
Drupal 7	January 2011	5 January 2025 — ended
Drupal 8	November 2015	17 November 2021 — ended
Drupal 9	June 2020	1 November 2023 — ended
Drupal 10	14 December 2022	9 December 2026
Drupal 11	2 August 2024	Until Drupal 13 is released. No date published
Drupal 12	Scheduled week of 7 December 2026	Not yet set

Last verified against drupal.org on 24 August 2026.

Drupal 11’s end of life has no calendar date because it is defined by a later release rather than by a date. Drupal’s support policy states that “each major version is supported for a minimum of 4 years, until the release of two further major versions”, with the qualifier that “major versions are only supported while their key dependencies’ versions are supported”. Two further majors after Drupal 11 means Drupal 13, for which drupal.org has published nothing. The four-year minimum, counted from 2 August 2024, puts the earliest possible date in August 2028. Any figure more precise than that is an estimate rather than a published commitment.

That dependency qualifier is what sets the version floors. Drupal 11 requires PHP 8.3, Composer 2.7.0 or newer, and Symfony 7, PHPUnit 10 and jQuery 4, with a database floor of MySQL 8.0, MariaDB 10.6, PostgreSQL 16 or SQLite 3.45. When a key dependency reaches its own end of life, the Drupal major built on it follows.

The major version is only half the answer. Security coverage attaches to specific minor branches, and Drupal 10 is now down to its last one, so a site can be on a supported major version and an unsupported minor one.

Drupal 10 branch	Security support
10.3 and earlier	Ended
10.4	Ended
10.5	Ended June 2026
10.6	Through 9 December 2026

A site on 10.5 or below is running without security coverage now, months ahead of the December deadline. The version sits under Reports → Status report in the admin, and checking it settles whether the rest of this piece is a planning exercise or an active exposure.

The same trap exists on Drupal 11, and it catches teams who assume the newer major version settles the question.

Drupal 11 branch	Security support
11.2 and earlier	Ended week of 29 June 2026, when 11.4.0 released
11.3	Through the week of 7 December 2026, when 12.0.0 and 11.5.0 release
11.4	Current

A site that upgraded to Drupal 11 in 2025 and has not taken minor releases since can be sitting on 11.2 today, which is unsupported for the same reason 10.5 is. Moving to Drupal 11 is a major-version decision; staying supported on it is a minor-release habit, and the two are separate commitments.

The three paths, and why Drupal 12 complicates them

Drupal 12 is scheduled for the week of 7 December 2026. Drupal 10’s support ends on 9 December 2026. The two land in the same week, which changes what “upgrade in place” means this year.

Path	Supported until	What it asks for
Drupal 11	Until Drupal 13 is released. No date published; August 2028 is the policy floor.	PHP 8.3, MySQL 8.0, Symfony 7, Composer 2.7+. Module compatibility work. Sites must be on 10.3.0 or higher first.
Drupal 12	Longer than Drupal 11. Date not yet set.	Ships the week of 7 December 2026. No runway before the deadline, and contributed-module coverage will be thin at release.
Replatform	Determined by the target platform	Discovery, migration, retraining.

Drupal 11 released on 2 August 2024. By December it will have more than two years of contributed-module support behind it, and that maturity is the main argument in its favour. The upgrade is also materially smaller than the Drupal 7 to Drupal 10 step was, because modules written for Drupal 10 generally need compatibility updates rather than rewrites.

A team that moves to Drupal 11 this autumn will be one major version behind from December onward. That position is more comfortable than it first sounds. Drupal deferred its disruptive deprecations from 12.0.0 to 13.0.0, so Drupal 11 keeps its APIs through the whole of Drupal 12’s life.

Waiting for Drupal 12 buys a longer support horizon and costs the December runway. A major version released in the same week as the deadline gives a team no time to test against it, and the contributed modules a site depends on will not all have Drupal 12 releases on day one. For most teams that makes Drupal 12 a 2027 conversation rather than a route out of this deadline.

The practical shape of the decision, then, is Drupal 11 or replatform, with Drupal 12 open only to teams whose December is genuinely flexible.

When upgrading in place is the right call

Upgrading is the lower-risk path, and for a large share of Drupal 10 sites it is the correct one. The conditions are specific enough to check in an afternoon:

• The module set is mostly contributed and actively maintained, with Drupal 11 releases already published.
• The team has current Drupal skills and a deployment path that works.
• The content model fits Drupal’s entity and field system without custom bridging.
• Multisite or granular per-field permissions are load-bearing, and the site uses them as they were designed to be used.
• The editorial workflow is understood, and editors work with it rather than around it.

Where most of that holds, the upgrade is a scheduled maintenance project with a known shape. It does not need a discovery phase, and treating it as a replatforming decision spends the window on a question that is already answered.

Drupal’s permission model deserves specific mention here. Role-based access control with per-content-type and per-field granularity, combined with configurable publishing workflows, maps closely to how universities, agencies and large institutions structure editorial teams. Where a site depends on that, the upgrade path protects an investment that already works.

Conditions that justify replatform discovery

Discovery is a different commitment from a decision. The conditions below justify looking; none of them settles the answer.

• Headless delivery was retrofitted, and the front end is constrained by the theme layer.
• Custom modules exist to work around the content model rather than to extend it.
• The upgrade estimate approaches the cost of a rebuild, because the custom surface is large enough that compatibility work touches most of it.
• Content has to reach native apps, AI retrieval, or channels the current architecture serves awkwardly.
• Editors avoid the CMS, and the workarounds are documented well enough to count as a system of their own.

Each of these describes requirements that have moved past what the platform was built for. Drupal has not stopped doing what it does well; the site’s requirements have travelled. That distinction matters, because a team that replatforms while blaming the platform tends to reproduce the same mismatch on the next one.

The evidence to collect before deciding

The decision is answerable with six pieces of evidence. Collecting them is a week of work at most, and it is the same week whichever path a team ends up taking.

1. The current minor version. Whether the site is on 10.6, or on a branch that already lost security coverage. This determines whether the timeline is a plan or an incident.
2. A module inventory, split into contributed and custom, with Drupal 11 readiness recorded for each. Drupal’s Upgrade Status module reports this directly.
3. Deprecated API usage in custom code. drupal-rector automates a large share of the fixes and, more usefully at this stage, quantifies the work.
4. PHP and database versions, checked against Drupal 11’s floor of PHP 8.3 and MySQL 8.0.
5. An integration inventory. Everything that reads from or writes to the CMS, including the integrations nobody has touched in two years.
6. Content model complexity. Entity types, fields, and how many of them are genuinely in use. Sites frequently carry a model far larger than the content that populates it.

Items 2 and 3 produce a number. That number, set against the cost of a migration the team has scoped, is what turns this from a preference into a decision.

Where Payload fits

If the evidence points past Drupal, the next question is what to move to. Payload is the platform WAYF works in most often.

It handles content that has to reach more than one destination: a website, an app, a partner feed, a search or AI system drawing on the same material. Editors get an interface shaped around how the organisation publishes. And because the content model sits in the same repository as the rest of the build, changing it goes through the same review as any other change.

The heaviest scope in a Drupal migration sits in two places: a multisite running dozens of departmental sites on shared infrastructure, and permission models with many roles and per-field rules. Both get rebuilt on the new platform, and both are worth pricing before anyone commits. WAYF quotes them explicitly, and says when the upgrade is the cheaper route.

The guide to migrating from Drupal to Payload covers what the move involves in practice. It is written for teams who have already made that case.

If the decision itself is still open, /migrate/drupal is where to tell us what you are running. A free consultation and a scoped, fixed quote come before any commitment, so putting a number against the replatform costs a conversation. Where the evidence says the in-place upgrade is the cheaper route, that is what we will tell you.

The date is the one thing that will not move

Drupal 10’s end-of-life date has been fixed since June 2025, and it does not move if Drupal 12 slips. December is the last release window Drupal 10 gets. After it, no further releases of Drupal 10 will be made.

FAQ

1. When does Drupal 10 reach end of life?

   9 December 2026. Drupal's core team set the date in June 2025 and deliberately separated it from the Drupal 12 release, so it holds regardless of when Drupal 12 arrives.

2. When does Drupal 11 reach end of life?

   Until Drupal 13 is released. Drupal's policy supports each major version for a minimum of four years and until two further major versions ship, which means Drupal 13 for a site on Drupal 11. Drupal has published no Drupal 13 date, and the four-year minimum counted from Drupal 11's release on 2 August 2024 puts the earliest possible date in August 2028.

3. Which Drupal versions are still supported today?

   Three branches: 11.4 and 11.3 on Drupal 11, and 10.6 on Drupal 10. Drupal 11.2 and earlier, Drupal 10.5 and every earlier 10.x branch, all lost security coverage in the week of 29 June 2026 or before. Drupal 7, 8, and 9 are past end of life.

4. Is my site unsupported right now?

   If it runs any Drupal 10 branch below 10.6, yes. Check the version under Reports → Status report in the admin. This takes a minute and determines whether December is a planning deadline or a live exposure.

5. Is Drupal 11 fully supported, whichever minor version I run?

   No. Drupal 11.2 and earlier lost security support in the week of 29 June 2026, when 11.4.0 was released. Supported branches today are 11.4 and 11.3, and 11.3 loses coverage in the week of 7 December 2026 when Drupal 12.0.0 and 11.5.0 release. A site that moved to Drupal 11 and then stopped taking minor releases can be unsupported on a current major version.

6. How long does upgrading from Drupal 10 to Drupal 11 take?

   It depends almost entirely on contributed modules rather than core. Sites on 10.2 or earlier must reach 10.3 first. The work is auditing each module for a Drupal 11-compatible release and replacing those without one.

---

Sources

• Disruptive deprecations scheduled for removal in Drupal 13.0.0
• Drupal 11.0 will require PHP 8.3 and MySQL 8.0
• Drupal core release schedule
• Policy: define explicit Drupal 10 end-of-life date (#3524111)
• Open proposal, not adopted policy: EoL for majors six months after the second subsequent major (#3508715) — quoted here only for its statement of the current support policy
• Sites must update to Drupal 10.3.0 or higher before updating to Drupal 11.x
• Drupal 8 is now end-of-life (PSA-2021-11-30)
• Releases for Drupal core