Drupal 10 End of Life: A Decision Calendar for Q4 Freezes

What Changes When Drupal 10 Reaches End of Life?

Drupal 10 stops receiving releases on December 9, 2026. End of life means the branch closes: no bug fixes, no minor releases, no security patches for new flaws in core. The site keeps running. What ends is the supply of fixes.

Drupal 12.0 and 11.5 ship the week of December 7, 2026. The first Drupal 12 beta was tagged on September 30, two weeks late, without moving those dates. Drupal 12 removes every upgrade path below Drupal 11.3, so a Drupal 10 site must land on Drupal 11.3 or higher first.

We are not aware of a paid extended-support program for Drupal 10 as of October 2026. Plan as though none will exist.

What Else Expires in December 2026?

PHP 8.2 loses security support on December 31, 2026, three weeks after Drupal 10 does. Drupal 11 requires PHP 8.3 or later, so a site on 8.1 or 8.2 has two deadlines. Hosting is the long pole, and it runs on a calendar you do not control. Hosts retire PHP versions on their own schedule, so the request goes in before any code work, not alongside it.

Which PHP Version Should You Ask Your Host For?

Ask for PHP 8.4. It is the only version that runs both your Drupal 10.6 site and your Drupal 11.4 target, and it is patched to the end of 2028. PHP 8.3 spans both but expires December 31, 2027. PHP 8.5 cannot be staged early: Drupal 10.6 does not run on it.

Sources: drupal.org PHP requirements; php.net supported versions.

How Long Does a Drupal 10 to 11 Upgrade Take?

Two to four months for a typical enterprise site. The variable that moves the number most is deprecation debt: skipped minor releases and contributed modules that have drifted from their maintained branches.

A small, well-maintained site is a different exercise. Where custom code is light, every module already has a Drupal 11 release, and the host can provision PHP quickly, roughly two weeks of audit plus a month of upgrade work is realistic. That is the short end of the published range, not a contradiction of it: two to four months is end-to-end, including partner selection, testing, and a cutover scheduled around a freeze.

Four things decide where you land: the volume of custom code including the theme, whether every contributed module has a Drupal 11 release, how fast your host can move to PHP 8.3 or later, and how many integrations need testing.

What Are Your Options If You Miss the Freeze?

A change freeze is a period when an organization blocks production deployments to protect a revenue- or mission-critical event. If yours starts before the upgrade finishes, three options are defensible.

Responses to a missed upgrade window.
 

Can You Deploy Inside a Change Freeze?

Often yes, if the window is negotiated rather than assumed. A freeze is a business risk control, not a technical lock, and most owners will consider a short window for a change that reduces risk rather than adding it. What makes the request credible: a window measured in hours, written approval from the freeze owner, a rehearsed rollback with a decision deadline inside it, and a tested restore.

The strongest version of that request is one where development and staging are already on Drupal 11, and only production remains. At that point you are asking for a release, not a project, and the window shrinks to the cutover itself.

What Compensating Controls Does Running Past End of Life Require?

Compensating controls reduce exposure created by a gap you cannot close yet. They do not make an unsupported platform supported, and they do not remove the risk. They buy a defined period at a reduced, documented level of exposure. The baseline:

• An emergency change path agreed before the freeze starts: who authorizes a hotfix, how fast, and what severity triggers it. Drupal 10 core fixes stop, so this is the control that decides whether you can act at all.
• Firewall rules deployable within hours by someone on call. When there is no fix to apply, this is the only move left.
• Unused modules uninstalled and removed, not merely disabled.
• Admin access behind single sign-on, two-factor authentication, or an IP allowlist.
• Anonymous sign-up and form submission off where the site does not need them.
• A module inventory with versions, so you can tell in minutes whether an advisory applies.
• A tested restore with the time measured, plus logging that would show exploitation attempts.
• A named person reviewing advisories on schedule: contrib ships Wednesdays, core the third Wednesday.

This costs money: on-call capacity, firewall upkeep, monitoring, and a second change window in 2027. If it approaches the cost of finishing on time, finish on time. Carried for long, it needs proactive support rather than patching.

Will Contributed Modules Still Get Security Fixes After December 9?

Advisories continue, but they stop reliably applying to you. Coverage for contributed projects is opt-in and tied to each project's supported branches, not to Drupal 10, so fixes keep shipping. What changes is that maintainers move those branches onto Drupal 11 and 12, so a growing share of releases will not declare Drupal 10 compatibility and will not install. We call this coverage fading rather than ending on one date. The Drupal 7 precedent is sharper: after end of life, the security team stopped issuing advisories for its core and its contrib modules and themes.

When an advisory lands, the question is not whether you can deploy the fix today, but whether a fixed release still supports Drupal 10.

When Is Running Past End of Life the Wrong Call?

It is off the table if any of these is true:

• You take payments or hold sensitive data. Compliance obligations, contracts, or cyber insurance may require supported software.

• Anonymous users can register or submit forms at scale. A larger surface gets probed faster.

• You run many sites on one codebase. One unpatched flaw reaches all of them.

• Nobody watches security advisories today. Then the gap is unmanaged, not accepted.

If one applies and no option fits, that is an escalation, not a scheduling problem. You need capacity, not a later date.

Which Sectors Run Into Change Freezes?

Freezes are not only a December event. The binding date varies by what the organization protects.

• Nonprofits: late October to December 31, around Giving Tuesday and year-end giving (readiness checklist).

• Higher education: term start, registration, and admissions, so August, September, and January.

• Media and publishing: elections and major scheduled events.

• Government and intergovernmental: budget cycles, assemblies, and reporting deadlines.

Find your freeze date first, then count backward.

Where We Land: The Risk Is the First Advisory You Cannot Apply

Our view: end-of-life risk starts with an event, not a date. Nothing visibly changes on December 10. Exposure begins with the first advisory affecting code you run that has no Drupal 10 fix, and that could be December or March.

Teams are already making this call, choosing to run Drupal 10.6 into January rather than deploy inside a freeze. That is a defensible position when you choose and document it, and a problem only when it happens by default.

Advisories arrive in batches. On October 7, 2026, the Drupal Security Team published 26 advisories across 25 contributed projects, led by a highly critical Block AJAX flaw. Two had no fix and were marked unsupported, so the advice was to uninstall them. After December 9, Drupal 10 core sits in that position, with one difference: you cannot uninstall core.

So answer three questions in writing: who sees it first, how fast you can tell whether it affects you, and whether a firewall rule can block it while you assess.

Running past end of life is a risk decision, so it does not belong to engineering. It belongs to the executive who owns the freeze, in writing, naming the controls, the monitoring owner, and the upgrade date.

What Should Your Drupal 10 Decision Calendar Look Like?

The calendar runs from a readiness audit now to a finished upgrade by March 31, 2027, assuming a November 1 freeze. Shift it if yours differs. If you are only starting the audit now, cutting the scope is already closing, and the real choice is between a negotiated window and a controlled overrun.

Assumes a November 1, 2026 change freeze.

The second row matters most. Choosing a path is a decision; arriving at December 9 without having chosen is the same outcome with none of the preparation.

Can a Small Site Upgrade In-House?

Yes, for a small Drupal 10 site with current modules and light custom code. Upgrade Status reports module compatibility and deprecated API use, and Drupal Rector automates much of the work. What resists automation: a heavily customized theme, contrib carrying local patches, external integrations, and any module with no Drupal 11 release and no maintainer. More than one of those and the route stalls partway, burning runway.

Where Should You Start?

With a readiness audit, because every option above depends on knowing which one you qualify for. We deliver upgrades and long-term support, so we are paid either way.

A Vardot Drupal audit takes one to two weeks and returns a prioritized, risk-rated picture of what your upgrade involves.

Vardot builds and migrates enterprise Drupal platforms as a Drupal Diamond Certified Partner, with 200+ platforms launched, a 4.9/5 Clutch rating, standing among the top 20 Drupal contributors worldwide, and Gold Sponsorship of the Drupal AI Initiative.

Find out which path is yours before the freeze decides for you.

Book a Drupal readiness audit.