Drupal 10 loses security support on December 9, 2026. That date is real, and it is close. If your site still runs Drupal 10, the work to move it is now, not in January.
This is not a scare post. It is a checklist. Security support ending means no more security patches, and a site that stops getting patches becomes a risk you carry quietly until something goes wrong. The upgrade path to Drupal 11 is well worn by now, and the work is mostly inventory and testing, not reinvention.
What we cover
- What actually ends on December 9
- What breaks if you stay put
- The upgrade path to Drupal 11
- What to check first
- What Q4 timing costs you
What actually ends on December 9
December 9, 2026 is the day Drupal 10 stops receiving security coverage. No more security releases for core, and community support for Drupal 10 modules winds down with it. Drupal 10.6.0 is the last minor release of the 10 line, and Drupal 12 ships the same week support ends.
Your site will not stop working on December 10. That is the trap. A site that keeps running looks fine while the risk quietly grows. Every vulnerability found in Drupal 10 after that date stays open on your site, and the longer you wait, the more of them stack up.
What breaks if you stay put
The first thing that breaks is your security posture. An unpatched CMS is the easiest target on the internet, and automated scanners do not care how small your site is. They probe everything.
The second thing that breaks is your module stack. Contributed module maintainers move to Drupal 11 and 12. New releases stop supporting Drupal 10, and the fixes and features you want land on versions you cannot install.
The third is compliance. Accessibility and security obligations do not pause because your CMS is old. If your site has to meet WCAG or an ADA requirement, running an unsupported platform makes that harder to defend, not easier.
The upgrade path to Drupal 11
The move from Drupal 10 to 11 is an upgrade, not a rebuild. The architecture is the same, the content model is the same, and most well maintained modules have Drupal 11 releases already. The work is methodical:
- Inventory your modules and note which ones have a Drupal 11 release
- Audit custom code for deprecated APIs that Drupal 11 removed
- Run the upgrade in a staging copy first, never on production
- Test content, configuration, and the editor experience, not just the homepage
- Plan a launch window and a rollback step before you start
Most of the pain lives in the inventory step. Sites with a small, well kept module list move fast. Sites with years of accumulated modules and custom code take longer, and the time is spent deciding what to keep, not fighting the upgrade itself.
What to check first
Before you scope anything, answer four questions:
- What version are you actually on? Check the real number, not the one in the project plan.
- Which contributed modules have no Drupal 11 release? Those are your blockers.
- What custom code touches APIs that Drupal 11 removed? That is your real development work.
- Does your hosting meet Drupal 11 requirements? PHP and database versions matter here.
Those four answers tell you whether this is a week of work or a quarter of work. Guessing without them is how upgrade projects blow up.
What Q4 timing costs you
Here is the part nobody likes. Migrating in the last quarter of 2026 is the most expensive time to do it. Demand spikes, calendars fill up, and rush work costs rush rates. Vardot has a good piece on why Q4 is the priciest window to migrate, and it is worth a read before you set your timeline: Q4 2026: the most expensive time to migrate Drupal.
The cheapest upgrade is the one you start before the deadline rush. If you are reading this in November, you still have room to do it properly. If you are reading it in December, start the inventory today and stop debating.
Final thoughts
Drupal 10 had a good run. The end of support is not a failure of the platform, it is the normal lifecycle doing its job. Your job is to move before the risk outweighs the effort, and that point arrives on December 9.
The short version: security support ends December 9, 2026. Inventory your modules, audit your custom code, upgrade in staging, and do it before the Q4 rush makes it expensive.
