Drupal 10 end of life (Dec 9, 2026): your six-month plan
Let’s start with the facts, because the deadline is not negotiable:
| Fact | Value |
|---|---|
| Drupal 10 end of life | December 9, 2026 (when Drupal 12 is released) |
| What ends | Security advisories and bug fixes for core 10.x |
| Upgrade target | Drupal 11 (released August 2024 — mature, stable) |
| Drupal 11 requires | PHP 8.3+, MySQL 8.0+ / MariaDB 10.6+ |
| Upgrade path | From the latest Drupal 10 minor, via Composer — an update, not a rebuild |
| Time needed | From a few days (clean site) to several weeks (heavy custom/contrib) |
Five months out is exactly the right time to start — not because the upgrade is huge (it isn’t, compared to the Drupal 7 era), but because of what happens to everyone else’s calendar in Q4.
What end of life actually means
Your site does not stop working on December 10. What stops is the safety net:
- No more security advisories for core 10.x. Every vulnerability found after EOL stays unpatched — while the advisory for Drupal 11 tells attackers exactly where to look. I explained that mechanism in my security playbook; running an EOL major is its worst-case scenario.
- Contrib follows core. Module maintainers drop 10.x support fast once core does — I do it myself on the 24 modules I maintain. Your dependency tree fossilizes.
- Compliance and insurance exposure. For public-sector, media and finance sites, “unsupported CMS” is an audit finding, not a technicality.
Why “we’ll do it in November” is the expensive option
Every Drupal team in Europe has the same deadline. Agency and freelance capacity in October–December 2026 will be booked and priced accordingly — and rushed migrations are where regressions and SEO accidents happen. The teams that migrate in August pay normal rates and sleep in December.
The six-month plan
July — know your site. Run Upgrade Status, inventory custom modules and contrib, and get an honest effort estimate. One day of audit turns “we think it’s fine” into a task list with numbers.
August — prepare the ground. Upgrade environments to PHP 8.3 (local, CI, staging, production) and current database versions before touching Drupal. Uninstall what you no longer use — every removed module is migration work deleted.
September — fix the code. Drupal Rector automates most deprecation fixes in custom code; triage contrib (compatible release / patch in the issue queue / replace / drop). This is the only phase whose length varies wildly between sites — which is why the July audit matters.
October — upgrade and test. Composer upgrade on a staging copy, drush updb, then real acceptance testing with
the people who use the site daily. Keep production untouched on Drupal 10 meanwhile.
November — ship it. Production cutover with a rollback plan, redirect and metadata checks, Search Console monitoring. My step-by-step technical guide covers the exact commands and the SEO checklist.
December — buffer, not plan. If your schedule ends on December 8, it has no schedule. The buffer month is for the surprise every real project has.
Still on Drupal 7 or 9?
Then this deadline is not your first problem — those versions are already end of life (D7 since January 2025), and the jump is a real migration, not an update. Same conclusion, more urgency: start with an audit, today.
I run these migrations all year, from the one-day audit to the full delivery. Talk to me before the Q4 rush — your future self will thank you in December.