Drupal 7 went end of life January 5, 2025.

Here is what that looks like on real sites.

Security advisories still get published. Patches do not.
The Drupal security team still documents vulnerabilities in D7 contrib modules. Fixes ship for D10 and D11. D7 gets nothing. The CVE exists. Your site is listed. The fix is not coming.

Hosts are dropping PHP 7.4 support.
D7 runs on PHP 7.4. Most hosts have either deprecated it or moved it to a paid legacy tier. Sites start throwing errors not because of any attack because the server underneath changed.

Contrib modules are going abandoned mid-project.
Maintainers are moving on. A module that worked fine in January stops getting releases. One server update breaks it. Now you are either patching it yourself or ripping it out.

The handoff problem.
If you are a developer maintaining D7 sites for clients - what does that conversation look like? "Your site is technically running but I cannot promise what happens next month" is not a great position to be in.

Anyone still handling D7 client sites? How are you managing it?

Been doing Drupal migrations for about 10 years and seeing the same thing play out right now that happens every EOL cycle.

Teams think they have until December 9. They don't. Enterprise change freezes typically start mid-November. Some nonprofits freeze earlier because of year-end giving. A proper D10 → D11 migration takes 2-4 months.

So if you're starting now, you're already in rush territory. Starting in October means going into December with things half done.

The other thing nobody talks about — most good Drupal agencies are already booked into Q4. You're not just racing the calendar. You're racing everyone else who also waited.

If you want to check where your site actually stands, run this:

drush pm:list --status=enabled

Check every contrib module against drupal.org/security. That list will tell you exactly how much work is ahead. Happy to look at anyone's output if they want a second opinion.

maybe it's just the projects landing on my desk but the last few months have been different.

had two clients come in asking about moving off WordPress. not because anything dramatic happened one had a plugin conflict that took down their checkout for six hours, the other just got tired of updating things every week and something always breaking anyway.

neither of them came in saying "we want Drupal." they came in saying "we're done with this."

the checkout one was a 720 page site. we moved it to Drupal, load time went from just under 6 seconds to under 2. organic traffic was up about 12% in the first quarter after. not sure how much was speed vs the redirect work, probably both honestly.

the other one is still in discovery. some integrations that are going to be annoying regardless of platform.

wondering if this is a wider pattern or just a weird few months on my end. feels like something shifted in how clients think about their CMS but maybe i'm reading too much into it.

been doing this for a few years now and kept running into the same problem. quote a timeline, client agrees, then week three happens and suddenly we're explaining why it's taking longer.

took me embarrassingly long to figure out the pattern.

it's always the integrations. not the modules, not the theme, not even the content migration. it's always some connection to a third party system that nobody documented because the person who built it left two or three years ago.

last one was a CRM integration that was still firing on every form submission. CRM itself had been discontinued. nobody on the client side knew it was there. showed up in the server logs as a timeout error that everyone had just... learned to ignore.

started doing a proper integration audit before we write any estimates now. just mapping everything that talks to everything else. takes a few days but it's saved us from at least three nasty surprises this year.

curious if others have a good process for this. especially for sites that have changed hands a few times and have basically no documentation. feels like every D7 site we touch has at least one of these buried in it somewhere.

Working on a client site right now and it's giving me flashbacks.

42 contrib modules installed. Asked the client which ones they actually use. They could name maybe 8.

The rest? "They were there when we took over the site." Which was 2019. Which means whoever installed them is long gone.

Ran Upgrade Status and it's the usual chaos. Some have D11 equivalents, some don't, a couple are just... abandoned. Last commit 2021.

The one that got me was a custom integration with a CRM that no longer exists. Still enabled. Still trying to ping something every time a form submits. Nobody knew it was there.

D7's been EOL since January anyway so this is all moving eventually but in the meantime I'm building a module inventory spreadsheet from scratch because apparently that's the job now.

Anyone have a good process for this kind of archaeology? Getting tired of reverse engineering everything from database logs.

We've audited a lot of Drupal 7 sites this year.

Same things keep showing up.

Modules nobody uses but nobody removed either. They just sit there. Unmaintained. Invisible until they're not.

Integrations the original developer built in 2016 and never wrote down. Current team has no idea what connects to what. We've had to reverse-engineer CRM connections from database logs because there was no other record they existed.

Custom themes nobody wants to touch. PHPTemplate, built when the site launched, last modified when someone added a banner in 2020. The institutional knowledge of how it works left with whoever built it.

PageSpeed scores under 40 on mobile. Not because the hosting is bad. Because nobody has looked at performance since the site went live.

And no process for security advisories. Drupal published 30 in July 2026 alone. Most of these teams knew about zero of them.

The one thing the better-maintained sites have in common: someone actually runs Upgrade Status and does something with what it finds. That's it. Not complicated.

Curious what others are seeing out there. Same patterns or different?

had a client last month whose site went from like 2s to 9s load time over the past couple years. support kept telling them enable caching and it'll be fine. it wasn't.

spent a day actually digging instead of just throwing cache at it and found the real problems -

images were like 5mb+ per page, nobody ever compressed them. 23 modules installed that literally weren't being used anywhere on the site. hosting was still running an old php version, not really set up right for D11. and no cdn, so every single asset was hitting the origin server directly

fixed all of it over about a week, didn't even touch caching config in the end. once the actual bloat was gone the default caching handled everything fine

not the first time i've seen this either, feels like half the "why is my site slow" posts jump straight to caching or hosting when its actually just years of stuff nobody cleaned up

what do you guys usually check first when someone says their drupal site is slow

Been coming across a surprising number of Drupal 7 sites still live this year, even with EOL long behind us.

Curious what's actually holding people back is it cost of migration, custom modules with no clean upgrade path, or just "it still works, why touch it"?

Also curious if anyone's done a D7 → D10/11 migration recently - what ended up being the most painful part?