Submitted on: October 22 2026

By Fredric, Principal of Bright Plum

The warning everyone stops reading

Drupal 10 reaches end of life on December 9. When directors hear that, some assume the site will stop working. It won't. End of life means Drupal's core security team stops looking for vulnerabilities in Drupal 10 and stops fixing the ones it hears about.

Some sites lost that protection months ago. Drupal 10.4 stopped getting security fixes in December 2025, and 10.5 in June 2026. Only 10.6 is covered until December. If your site runs 10.4 or 10.5, your deadline already passed.

How does a site fall that far behind? Usually, nobody looked. Drupal's status report flags all kinds of problems in the same red: a misconfiguration, a missing write permission, an out-of-date version. You see red every time you log in, so you stop seeing it. The security update emails pile up the same way. You make your edit, the site still works, and you move on. How bad could it be?

The real risk is trust

Teams worry about stolen data. Most college sites don't hold much of it, and newsletter sign-ups usually run through a third-party embed. The bigger risk is someone changing your content.

Attackers don't hunt by hand anymore. An AI tool can scan the web for sites running a vulnerable version of Drupal. If it finds yours, the attacker can put whatever they want on a page that carries your university's name. The worst case harms your visitors. Even something merely offensive tells a prospective student that the university doesn't control its own website. If you can't protect a web page, why would they trust you with their application?

When something goes wrong, IT gets involved. Legal steps in only if there's a compliance problem. IT then sends your vendor a stack of requests: SOC 2 documentation, compliance paperwork, an audit of every process. Most of those answers come from the hosting platform, whether that's Pantheon, Acquia or another host. The vendor answers for the code updates and who has access.

Don't wait for Drupal 12

Drupal 12 ships the same week Drupal 10 dies. Clients ask us whether they should skip 11 and wait. Our answer is no.

The waiting habit comes from Drupal 7. Moving from 7 to 8 meant a full re-architecture, and it hurt. Drupal 8 felt like a bridge to Drupal 9, so plenty of teams sat on 7 and planned to skip a painful step.

That re-architecture is done. Its whole purpose was to keep major upgrades from hurting like that again. Drupal 9, 10, 11 and 12 each pick up security changes and add or remove features from core. None of them changes how your content is stored. Waiting buys you nothing except exposure.

Why one upgrade takes a week and another takes three months

Testing decides how long an upgrade takes.

We recommend every client invest in automated testing. Visual regression tests catch a page that looks wrong. Functional tests catch a feature that broke. Together they document how your site works and how it should work, for us and for your team. If those tests already run against your current site, the upgrade comes with a quality check built in. Fewer bugs surface late, so the timeline stays short.

Sign-off is the other thing that stretches an upgrade. We set a schedule up front, with a content freeze and a cutover date, so your stakeholders can block time to test. They check their pages, confirm their content is there, and make sure they can still edit. When nobody schedules that time, the date slips. Clients who've spent part of their retainer building automated tests need far less of it.

When we inherit a Drupal 10 site, we check two things first. What versions are core and the modules on? And how many contributed modules are installed, are they turned on, and what do they do? Then we walk through the site with you to learn which pages matter and what you do every day, and we map that to what's installed. Sometimes a site leans on a large contributed module for one small feature. Every security fix for that module becomes yours to wait on. Moving that feature into a small custom module, built around how you work, takes it off the list.

What to do this week

You can do the first two without a developer.

Open your status report and write down what it says. Note your Drupal version and your module versions. Search each version number and see what came after it. If a newer release carries a critical security fix, drupal.org will say so, and your site is exposed until you apply it.

You see red every time you log in, so you stop seeing it.

Then write down what your site has to do. List the four or five pages your team updates most and the tasks that would stop your team cold if they broke. Check your analytics against that list. The pages visitors use most belong on it.

Once you have both, a partner can tell you whether you're at low, medium or high risk. That's what our Website Risk Sprint does.

What to ask your current vendor

Ask two questions. How do you keep our site secure and accessible before something goes wrong? And when someone on my team or yours leaves, where does that knowledge go? The answers tell you how resilient your team and your vendor are. If the answer to the second is a person's name, you're one vacation away from starting over.

If you can't finish by December 9

Set a date you can hit for the Drupal 11 upgrade, then protect the site until you get there. Limit editing access to the people who need it. Email your host and ask what protection it can put in front of your site, such as Cloudflare or a web application firewall, the layer that filters traffic before it reaches your pages. That buys you time until the upgrade lands.

What to tell your VP

Frame the upgrade around trust. Attacks don't need a person behind them anymore. They're automated, and they move fast. Security releases are the best defense you have against that speed, and only if you apply them. It's the Red Queen from Alice in Wonderland: you have to keep running just to stay in place.

This work fits inside the maintenance budget from our first article. The $45,000 a year we described covers keeping Drupal core current, including a major upgrade like Drupal 10 to 11.

In one sentence: "We need to keep investing $45,000 a year in our primary site so it represents the university properly and doesn't get hacked."

The part you can do yourself

You don't need a developer to find out where you stand. Write down your version numbers, look up where they sit against the latest security releases, and list the pages and tasks that always have to work. Keep that list. When the next update comes, or your vendor sends a recommendation, you'll have something to measure it against.

---

Release dates: Drupal core release schedule.