The websites that reach us after years without maintenance don’t each have their own story. They have the same one, with small variations in the dates. They work, the homepage looks fine and nobody in the organisation feels there is a problem. Until there is one, and by then there are usually several at once.
We have written that story as the website itself would tell it. No entry corresponds to a specific client, but we have seen every one of them more than once.
Dear diary
June 2023. I went live today. Everyone says I look great. I run on Drupal 10, released six months ago, and around thirty modules. At the wrap-up meeting someone said we would talk about maintenance later.
September 2023. A new version of one of my modules is out. It fixes a security flaw. Nobody noticed, so neither did I.
March 2024. The contact form hasn’t sent anything for three weeks. A customer found out when they phoned to ask whether anyone read the messages.
November 2024. I’m getting a lot of spam. Someone suggests adding a captcha. To install it, three other modules have to be updated first, and to update those, Drupal has to be updated. It gets put off until after Christmas.
January 2026. The hosting company has sent an email: the PHP version I run on lost support on 31 December and they are going to upgrade the server. It went to someone who no longer works here.
February 2026. They’ve upgraded my server. The news page shows a blank error. The homepage still looks lovely.
May 2026. Marketing wants a new page for a campaign. The supplier’s answer: first the website has to be brought up to date. The quote for bringing it up to date is a good deal higher than the one for the page.
October 2026. I’ve read that on 9 December I stop receiving security updates. I don’t think anyone else has read it.
Wednesday, 9 December 2026. Today is the first day of my life without security updates. From the outside, I look the same as ever.
What you can’t see from the homepage
The last entry is the one that repeats most often and alarms people least, because nothing visible happens. To understand why it matters, you need to know how Drupal works on the inside.
A Drupal website is made up of a core and dozens of modules maintained by the community. Drupal has a security team that reviews the flaws that are discovered and publishes updates on a fixed schedule: module updates on any Wednesday, core updates on one Wednesday a month, from 6 pm Spanish time.
Each of those updates comes with a public advisory explaining what is wrong and in which versions. That is the right thing to do, because it lets everyone protect themselves. It also means that, from that moment on, anyone who wants to exploit the flaw knows where to look. The best-known case dates from 2014: Drupal’s security team published a critical core update and, hours later, automated attacks were already scanning for unpatched sites. Its official recommendation was to treat any site not updated within seven hours of the announcement as compromised.
A website without maintenance is not a website that doesn’t change. It is a website that stands still while everything around it moves: the modules, the core, the server’s PHP version, browsers, email providers. Every advisory nobody applies is a door left open, and the list of open doors is public.
December 2026, a month full of dates
On 9 December 2026 Drupal 10 reaches end of life. There will be no more releases, not even security ones. Drupal 12 is due out that same month, and on 31 December PHP 8.2 stops receiving security updates. PHP 8.1 stopped receiving them on 31 December 2025. A website on Drupal 10 running PHP 8.2 loses support on both fronts almost at the same time.
The way out is Drupal 11, which in turn requires PHP 8.3 or higher. Moving from one major version to the next is not a matter of pressing a button, and each site’s custom code is what takes the most work:
- functions that Drupal 10 marked as deprecated and that Drupal 11 no longer includes;
- community modules that have to be checked one by one, because not all of them have a Drupal 11 version, or they have one with changes;
- templates and JavaScript that depended on pieces that have changed;
- a server that has to be upgraded in parallel.
We went through something similar with Drupal 7, which lost support on 5 January 2025 after several years of extensions. Organisations that reached the date without a plan had to choose between migrating in a hurry or carrying on without updates. With Drupal 10, the date was set well in advance and doesn’t depend on when Drupal 12 comes out.
How we do it
The first step is knowing what state the website is in. Our technical audit reviews, among other areas, the platform and its support cycle, pending updates and known vulnerabilities, applied patches and the quality of the custom code. The result is a list of findings ranked by severity and effort, in business language for you and with the technical detail for the team.
With that diagnosis, the migration to Drupal 11 follows a written, verified process: automated refactoring of the custom code, static analysis at the level of the target version, a compatibility check for every module and validation of the migrated project in a real environment before touching production. If your team keeps publishing or developing while we migrate, the process merges those changes with what has already been migrated.
Maintenance, afterwards, relies on a register of validated versions. Every update is tested on a copy of the website before it is applied, and once it’s done you get a summary of what changed, why and with what result. We explain it in more detail in AI with our own method: how we build and maintain Drupal.
The same diary, with maintenance
Wednesday. An update for one of my modules came out. They tested it on a copy of me and applied it. I didn’t notice.
October 2026. They’ve moved me to Drupal 11 and PHP 8.4. For a few days I lived in a test environment. After that, nobody noticed a thing.
Wednesday, 9 December 2026. Just another Wednesday.
It’s a very boring diary, and that is exactly what you pay for. Maintaining a website means making its diary boring.
Maintaining a website means making its diary boring.
Four questions before 9 December
They apply to any Drupal website, whoever maintains it.
01 Version. Do you know which version of Drupal and PHP your website runs on? It’s in the admin panel, under Reports > Status report.
02 Owner. Who applies your website’s security updates today, and when did they last do it?
03 Custom code. How much bespoke development does your website have? It’s what weighs most in a version migration.
04 Plan. Is there a date for moving to Drupal 11? If not, on 9 December your website will start writing the first diary.
If any answer is left hanging, it can be sorted out calmly until 9 December. After that, in a hurry.
Sources
- Drupal.org, Drupal core release schedule: Drupal 10 end of life on 9 December 2026, planned release of Drupal 12 and Drupal 7 end of life on 5 January 2025.
- Drupal Security Team, Security release numbers and release timing: release schedule for security updates (modules, every Wednesday; core, usually the third Wednesday of each month, from 12:00 New York time).
- Drupal Security Team, PSA-2014-003: advisory following the critical flaw SA-CORE-2014-005; recommends treating sites not updated within seven hours of the announcement as compromised.
- Drupal.org, Drupal 10 will be supported until the release of Drupal 12 in mid-late 2026: the end-of-support date for Drupal 10 is set for December 2026, whenever Drupal 12 comes out.
- Drupal.org, PHP requirements: PHP versions compatible with Drupal 10 and Drupal 11.
- PHP, Supported versions and Unsupported branches: end of security support for PHP 8.1 (31 December 2025) and PHP 8.2 (31 December 2026).