Drupal 10 end of life lands on December 9, 2026 (drupal.org release schedule). After that date, the Drupal Security Team stops releasing security patches for the 10.x branch. The site keeps working; every new vulnerability disclosed after that date is unpatched on your installation by default.
For most Drupal 10 site owners, that single fact is the entire story. The practical question is what to do about it, and there are two reasonable answers: upgrade to Drupal 11 now, or wait briefly for Drupal 12. This post walks through what end of life actually means, who is on the hook for the consequences, and how to build a realistic timeline so December 9 doesn’t arrive with the work undone.
Drupal 10 end of life: what it actually means
End of life is a specific status in the Drupal core release cycle. When a major version reaches it, the Drupal Security Team stops issuing security advisories and stops releasing patches for that branch (endoflife.date Drupal page). Contributed modules generally follow suit, focusing maintenance effort on the still-supported core version.
What this does not mean:
- The site stops working: PHP still executes, pages still render, content editors can still log in. Existing functionality keeps behaving the way it did the day before EOL.
- Third-party modules immediately abandon you: many contributed modules ship simultaneous releases for the current and the EOL major during the wind-down period.
- Custom code breaks: your custom modules and theme don’t know December 9 happened. They keep running.
What it does mean:
- New CVEs disclosed against Drupal 10 core go unpatched on your site by default. The same applies to major contributed modules that have moved their attention to Drupal 11.
- The community’s responsibly-disclosed-then-patched workflow no longer reaches your installation. Your site is outside the supported population.
- Each passing month accumulates more unpatched vulnerabilities. The risk profile compounds rather than appearing as a sudden break.
The technical site doesn’t fall over on December 10. The security posture does, slowly and silently, and the deficit grows from there. Industry coverage of the deadline (The Drop Times) emphasizes the same point: the operational lever is the upgrade plan, not the date itself.
The compliance and risk picture
For organizations subject to compliance frameworks, running an unpatched EOL platform is more than a security concern. It can be a documented control failure.
Frameworks that explicitly cover unsupported or unpatched software:
- SOC 2: expects ongoing vulnerability management with documented remediation timelines. EOL software with no patch path makes those timelines structurally impossible to meet.
- PCI-DSS 4.0: requires patching of critical vulnerabilities on a defined schedule. EOL platforms cannot satisfy this regardless of operator intent.
- HIPAA Security Rule: includes protection-from-malicious-software provisions that auditors increasingly read to cover known unpatched CVEs on internet-facing systems.
- ISO 27001: vulnerability management controls require identifying and remediating technical vulnerabilities within a defined timeframe. Running EOL software shifts those vulnerabilities from “remediable” to “permanent.”
- GDPR Article 32: requires appropriate technical measures to ensure ongoing confidentiality and integrity of personal data. Running EOL software materially undermines the demonstration of those measures.
Beyond formal compliance, several cyber insurance carriers in 2025 and 2026 added exclusions for incidents traceable to EOL software. Read your policy. An unpatched Drupal 10 site after December 9 may not be covered for the incident response you assume is included.
The takeaway: for any organization where the website touches regulated data, customer PII, or B2B SLAs, "we’ll upgrade soon" stops being a defensible plan in late 2026.
Two upgrade paths from Drupal 10
There are two coherent paths forward. Both end on a supported Drupal version; they differ in timing and risk profile.
Path A: Upgrade to Drupal 11 now. Drupal 11 has been generally available since August 1, 2024 and is the current stable major. The upgrade from Drupal 10.3 or later is well-documented and, for most sites running primarily contributed modules, mostly a sequence of Composer commands. We cover the mechanics in Migrating from Drupal 10 to Drupal 11, and the broader feature overview lives in Drupal 11 Explained. This is the recommended path for most sites because it puts you on a supported version now and gives you usable buffer time before the December 9 deadline.
Path B: Wait for Drupal 12. Drupal 12 is planned for release in 2026, with release-window candidates in August 2026 or December 2026 depending on beta readiness (drupal.org release schedule). In theory a site could skip 11 and migrate directly to 12. In practice the path is tight: if Drupal 12 slips into late December, you risk landing on EOL Drupal 10 with no fallback. The supported migration path also goes through Drupal 11 first, so "skipping 11" really means a back-to-back Drupal 10 to 11 to 12 sequence with little time between them.
For most sites, Path A is the safer call. Path B makes sense only when there is a specific Drupal 11 incompatibility (a contributed module without a Drupal 11 release that does have a Drupal 12 commitment), and even then the timing risk is real.
Lessons from Drupal 7 end of life
Drupal 7 reached EOL on January 5, 2025 (drupal.org schedule). The transition offers two useful data points for Drupal 10 site owners thinking about December 9.
First, commercial extended support emerged. Several hosting providers and Drupal agencies became Certified Drupal 7 Extended Support Partners. Pantheon, Acquia, and others continued patching Drupal 7 cores for paying customers after the EOL date. The same model will almost certainly emerge around Drupal 10 holdouts in 2027.
Second, extended support is a bridge, not a destination. Drupal 7 extended support is expensive relative to upgrading. It buys time, not a long-term posture. The organizations that bought a year of Drupal 7 ES in 2025 mostly used that year to plan and execute a migration, not to indefinitely stay on Drupal 7. The economics force the same conclusion every time: the platform you stay on long-term is a supported one.
If your situation makes both Path A and Path B impossible by December 9 (the audit reveals a contrib dependency with no Drupal 11 fork, you cannot get the engineering capacity in time, a holiday-season freeze makes a December cutover unsafe), then extended support exists as a pressure-relief option. Plan to use it for at most one supported-version cycle, not as a permanent home.
Building a realistic upgrade timeline
Working back from December 9, 2026, here is a defensible cadence for the typical mid-sized Drupal 10 site.
Now through mid-2026: audit and dependency check. Install the Upgrade Status module on your Drupal 10.3 or later environment. Run it against your full module list. Identify three categories: modules with Drupal 11 releases ready (no action), modules with Drupal 11 releases in beta (track), and modules without any Drupal 11 work (the blockers). For each blocker, decide: wait for a release, fork the module, swap to an alternative, or drop the feature.
Mid-2026 through August 2026: schedule the upgrade window. Most Drupal upgrades for non-trivial sites take a long working session plus a follow-up week of QA. Block the time. If your stack uses a continuous integration pipeline, build a multidev or staging environment specifically for the upgrade work so production stays available throughout.
Late summer through early fall 2026: execute. Do the upgrade on the dev or multidev environment first. QA against your real content, your real user flows, and your real performance characteristics. Promote through your normal staging path before touching live.
Buffer: October through early December 2026. Keep this margin. Things that slip in the real world include contributed-module bugs surfaced only in production, performance regressions that need tuning, and the occasional theme-level fix once you can see the upgraded site in actual use. A buffer is not optional; it is what makes the deadline survivable.
If the audit in early 2026 reveals a structural blocker, that is the signal to either prioritize the contributed-module resolution work earlier or to plan for extended commercial support as the bridge.
Frequently Asked Questions
What does end of life mean for my Drupal 10 site? Will it stop working?
Your site keeps functioning on December 10, 2026 and after. PHP still executes, pages still render, content editing still works. What stops is the Drupal Security Team’s commitment to publishing patches for newly disclosed vulnerabilities in Drupal 10. Over the months following EOL, the gap between known vulnerabilities and patches available for your site widens. The risk is gradual and silent rather than sudden, but it accumulates.
What happens if I miss the December 9, 2026 deadline?
Nothing dramatic happens on that specific day. The risk is cumulative. The first month after EOL is usually fine in practical terms. Nine or twelve months in, you are running a meaningful unpatched-vulnerability surface that compliance frameworks, cyber insurance carriers, and motivated attackers will all notice. If you miss the deadline, the question becomes how quickly you can either complete the upgrade or get on a commercial extended-support program to bridge the gap.
Can I jump directly from Drupal 10 to Drupal 12 when it releases?
The supported migration path goes through each major version: Drupal 10 to 11, then 11 to 12. In practice you would upgrade to Drupal 11 first and upgrade to Drupal 12 when it ships. The “skip 11 entirely” mental model doesn’t match how the Composer-driven upgrade actually works. If your goal is to land on Drupal 12, plan it as a two-step path with Drupal 11 in the middle.
Is extended commercial support a long-term option?
It is a bridge, not a destination. Drupal 7 extended support taught the community that organizations who buy ES typically use it for one supported-version cycle (twelve to twenty-four months) while completing their migration. The cost structure rewards finishing the upgrade rather than perpetually renewing extended support. If you find yourself signing a second extended-support renewal, the underlying upgrade plan needs attention.
How long does a typical Drupal 10 to 11 upgrade actually take?
For a site running well-maintained contributed modules on Drupal 10.3 or later, the upgrade itself is a long working session: a few hours of Composer commands, database updates, and configuration adjustments, followed by a week of QA. For sites with substantial custom code, the planning and refactoring phase (running Upgrade Status, applying Drupal Rector, manually fixing API changes Rector cannot handle) often takes longer than the upgrade itself. Plan for weeks of preparation and a long day of execution on a non-trivial site.
