Skip to content
Why your Drupal investment isn't reducing risk or improving performance
Most Drupal sites get fixed the same way. The platform falls behind and pages slow down until a security advisory lands on someone’s desk in IT, and then a budget gets approved for a major upgrade or a rebuild. Eighteen months later the new site launches on the latest version, fully patched and quick, and the risk register goes green.
The trouble is that a project only resets risk on the day it launches. Drupal core and PHP both follow fixed, published schedules, and contributed modules release security fixes every month, so a site that nobody keeps moving starts to fall behind straight away.
By the time anyone signs off the next rebuild, the business has usually been paying for it for a while, in slower releases and in upgrade work that grows every year. Site speed slips in a similar way, as new scripts and features pile onto pages that were fast at launch.
Across the Drupal sites we look after, that drift was already there when we took them on. They were generally a major version behind, with security updates waiting, and we’ve moved them through several major and minor upgrades since.
That’s why our Drupal support and maintenance works from the release calendar. We flag each security advisory that affects the site, and we raise each upcoming end-of-life date with the client well ahead of time, with a plan for the upgrade, so the decision is made before it becomes urgent.
Where the big Drupal upgrade habit comes from
Drupal 7 to Drupal 8 was a rebuild in all but name. Drupal 8 brought a new architecture built on Symfony components, and most Drupal 7 sites needed their content migrated and their custom code rewritten. Organisations that lived through it learned that Drupal upgrades are big, expensive and best put off for as long as possible. Drupal 7 stayed supported for more than nine years after Drupal 8 arrived, which made waiting feasible.
In 2017 Drupal project lead Dries Buytaert set out a different approach, in which new systems arrive in minor releases and old ones are marked deprecated and left in place for a while. His stated aim was that updating from the latest Drupal 8 release to Drupal 9.0.0 “should be as easy as updating between minor versions of Drupal 8”.
It works for sites that keep up. Sites that skip releases lose the benefit, because Drupal’s own documentation states that “a major version cannot be skipped during an upgrade.” A Drupal 9 site that wants to reach Drupal 11 has to go through Drupal 10 first, and each year a site waits adds another step to the journey.
Why Drupal support and maintenance must track four clocks
Every Drupal site depends on four release schedules, which we think of as four clocks. None of them waits for a budget cycle.
Drupal core – Drupal 10 reaches end of life on 9th December 2026, a date the Drupal core team fixed regardless of when Drupal 12 ships so that site owners could plan. Drupal 12 is scheduled for the same week, and after that date there are no new Drupal 10 releases, security fixes included.
PHP – the PHP project supports each version for four years, with two years of active fixes followed by two of security fixes only. Drupal 10 runs on PHP 8.1 or later, and PHP 8.1 reached end of life on 31st December 2025.
A Drupal 10 site still on its launch PHP version has been running on an unsupported language for nine months, and Drupal 11 needs PHP 8.3 as a minimum.
Dependencies – Drupal inherits timelines from the libraries underneath it. Dries Buytaert explained that Drupal 9 had to reach end of life in 2023 because its biggest dependency, Symfony 4, stopped receiving security fixes that November.
Contributed modules – Drupal.org publishes contributed-module security advisories in a monthly window. The two windows in September 2026 produced more than 40 advisories, at least nine of them rated critical, and the list included Webform, one of the most widely installed modules.
The good news is that every one of these dates is published years in advance, so each can be planned as ordinary work. Risk builds when a site only gets attention every four or five years, as part of a project.
Why Drupal performance drops after launch
At platform level, Drupal does well on speed, according to HTTP Archive’s Core Web Vitals data as reported by Search Engine Journal. When a Drupal site is slow, the cause is usually something added after launch.
The wider web shows how fast that happens. The HTTP Archive Web Almanac 2024 puts the median mobile page at 2,311 KB in October 2024, up 6.4% in a single year, with around 558 KB of JavaScript.
Its third-parties chapter found that about 92% of pages load at least one third-party service, and the median page in the top million sites loads 27. Each tag manager, consent banner, chat widget or campaign analytics tool is a small decision on its own, but together they slowly use up the speed that the rebuild paid for.
A rebuild clears most of this out, but the same process then fills the new site, because no one owns a performance budget between projects.
What planned Drupal maintenance looks like
Planned Drupal support and maintenance means every release date that affects the site is tracked, so each update happens because something specific needs it, and well before it becomes urgent.
- Security advisories – check each core and contributed-module advisory against the modules the site uses, flag any that affect it, then apply and test the fix once it’s approved.
- End-of-life dates – track the dates for Drupal core, PHP and key dependencies, and plan each upgrade well before security support ends.
For the business, this turns an unpredictable capital request into a predictable cost. Each upgrade is planned against a published date, so it arrives as scheduled work with a known scope.
Deprecated code still builds up between upgrades, so we’d suggest running the Upgrade Status module whenever an upgrade is planned. It shows what needs to change while there’s still time to spread the work out.
How to tell if your Drupal support contract reduces risk
A digital lead without a technical background can learn more from six questions than from a monthly status report.
- Which Drupal core version are we on, and when does it reach end of life? For Drupal 10, the answer is 9th December 2026.
- Which PHP version runs in production, and when does its security support end?
- How many days pass, on average, between a security advisory and the fix reaching production?
- How many deprecation warnings does our custom code produce today? The Upgrade Status module reports this.
- What were our Core Web Vitals in field data last month, and what changed them?
- Who approves new third-party scripts, and what does each one cost in page speed?
If your agency can’t answer these quickly, it’s worth asking what the contract is paying for.
The question for your next budget review
A rebuild gives you a clean starting point, but the site starts to drift again the week after launch. Planned maintenance deals with each release date as it comes, so the upgrade work stays small and never has to wait for a project.
So if your site launched on the latest Drupal version, how many of those four clocks have moved since, and who on your side noticed?
If a second opinion on where your own site sits would help, get in touch with our development team.
Frequently asked questions
When does Drupal 10 reach end of life?
Drupal 10 reaches end of life on 9th December 2026, the same week Drupal 12 is scheduled for release. After that date the Drupal project makes no new Drupal 10 releases, including security fixes. Drupal 10 sites need to move to Drupal 11, which requires PHP 8.3 or later.
Can you skip a Drupal major version when upgrading?
No. Drupal’s documentation states that a major version cannot be skipped, so a Drupal 9 site must upgrade to Drupal 10 before it can move to Drupal 11. Each year of delay adds an upgrade step and more deprecated code to remove, which is why postponing Drupal upgrades raises their cost.
What should Drupal support and maintenance include?
Drupal support and maintenance should include checking every core and contributed-module security advisory against the site and applying the fixes that affect it, tracking end-of-life dates for Drupal core, PHP and key dependencies, planning each upgrade before security support ends, and monitoring Core Web Vitals from real user data. A contract that only fixes bugs on request leaves the platform drifting towards its next forced upgrade.
Is Drupal slow?
Not at platform level. HTTP Archive data for November 2025 shows a higher share of Drupal sites passing Core Web Vitals than WordPress sites. When a Drupal site is slow, the cause is usually third-party scripts, heavy front-end code or unmanaged modules added after launch.
How often should a Drupal site be updated?
A Drupal site should get a security update whenever an advisory affects one of its modules, and Drupal.org publishes contributed-module advisories in a monthly window. Drupal core and PHP upgrades should be planned against their published end-of-life dates, well before security support ends. Tracking those dates means no upgrade arrives as an emergency.
Sources
Drupal core release schedule, Drupal.org (Drupal 10 EOL 9th December 2026, Drupal 12 release week of 7th December 2026, Drupal 7 EOL 5th January 2025)
Policy: fixed Drupal 10 end-of-life date, issue #3524111, Drupal.org
PHP requirements for Drupal, Drupal.org (Drupal 10 min PHP 8.1, Drupal 11 min PHP 8.3)
Upgrading from Drupal 8 or later, Drupal.org (major versions cannot be skipped)
Contributed project security advisories, Drupal.org (September 2026 windows)
Upgrade Status module, Drupal.org
Making Drupal upgrades easy forever, Dries Buytaert, 8th March 2017
Drupal 10 target release date and Drupal 9 end-of-life, Dries Buytaert (Symfony 4 dependency)
Supported versions and Unsupported branches, PHP.net (four-year support window, PHP 8.1 EOL 31st December 2025)
Core Web Vitals champ: open source versus proprietary platforms, Search Engine Journal, reporting HTTP Archive CWV Technology Report data for November 2025
Web Almanac 2024: Page weight, HTTP Archive
Web Almanac 2024: Third parties, HTTP Archive
