Drupal 7 End-of-Life: What It Means for Your Website Security

Drupal 7 reached its official end-of-life on January 5, 2025. That date wasn't a soft deadline. The Drupal Security Team stopped issuing core patches the moment the clock ticked over, and 16 months later, every Drupal 7 site still in production is running unsupported software — by every meaningful definition of the word.

If you operate one of those sites, the question is no longer "should I migrate?" The question is "what is my exposure, today, and what do I do about it?"

This guide walks through what the Drupal 7 EOL actually changes for your security posture, the compliance fallout most teams underestimate, and a decision framework you can use this week to plan your next move.

The deadline that already passed

Drupal 7 launched in January 2011. It powered hundreds of thousands of sites at its peak — universities, government portals, media companies, e-commerce stores. The original EOL was set for November 2021, then extended twice in response to community demand. The final extension landed on January 5, 2025, and there will be no further extensions. The Drupal Association has been explicit: Drupal 7 will not receive any further security or compatibility updates from the project.

That means three concrete things stopped happening on that date:

1. Core security advisories — no more Drupal core CVE patches.
2. Contributed module patches — most maintained D7 modules either archived their D7 branches or stopped backporting fixes.
3. PHP and database compatibility updates — D7 will not be patched to work with newer PHP versions, and the userland fixes that kept it running on PHP 8.x are no longer guaranteed to ship.

Sites that took no action haven't suddenly broken. They keep serving requests. That is exactly what makes the situation dangerous: nothing visible changes, but the gap between your code and known attack patterns widens every week.

What "no security support" actually looks like in 2026

Sixteen months in, several patterns have emerged across Drupal 7 sites that delayed migrating.

Public CVEs without patches. Vulnerabilities discovered in D7 core or in popular contributed modules are now disclosed through normal channels — researchers find them, write them up, and post them publicly. Before EOL, that disclosure came with a fix. After EOL, it comes with a target on your back. The Drupal Association documented this risk before EOL, and it has played out as predicted: known D7 issues exist in the public record with no first-party remediation path.

Module ecosystem rot. A typical D7 site uses 40–80 contributed modules. Each one was an independent project with an independent maintainer, and most of those maintainers moved on years ago. Modules that were already barely maintained at EOL are now effectively abandoned. Even when a vulnerability is discovered, there is often nobody empowered to push a patch.

PHP and stack drift. D7 was never designed for PHP 8.x. Hosting providers that still run D7 are doing it on a tightrope of community patches and forks. As servers, browsers, and TLS standards advance, the surface area for incompatibility grows.

Bots know. Automated vulnerability scanners maintain databases of unpatched software. A Drupal 7 site fingerprint is a flag in those databases. The exploitation attempts your access logs see today are not random — they are targeted at known-vulnerable signatures.

The compliance trap most teams miss

The security risk is the obvious problem. The compliance risk is the one that ends careers.

Most major regulatory frameworks treat unsupported software as a finding:

• PCI DSS 4.0 requires that all system components be supported by the vendor and receive timely security patches. A merchant running Drupal 7 in cardholder data environments has a documentable control gap on every audit.
• HIPAA Security Rule §164.308(a)(5)(ii)(B) requires "procedures for guarding against, detecting, and reporting malicious software" — auditors increasingly read that as requiring software with an active patch pipeline.
• SOC 2 Common Criteria 7.1 and 8.1 require monitoring for new vulnerabilities and timely patching. A Drupal 7 deployment fails that on its face.
• GDPR Article 32 requires "appropriate technical and organisational measures" for data security. Regulators have cited unpatched software as a contributing factor in fines.

The Drupal Association noted in April 2025 that organizations subject to HIPAA, PCI-DSS, and FedRAMP would struggle to maintain compliance on Drupal 7. By 2026, that has stopped being a forecast. Auditors are flagging it. Customers running vendor-risk reviews are flagging it. The Drupal 7 instance you used to defend in audits with "we run Drupal" is now indefensible without an active migration plan on the table.

The cyber insurance side is moving faster. Underwriters have been narrowing coverage for unsupported software since 2023, and Drupal 7 sites without an Extended Security Support (ESS) contract are increasingly excluded from breach payouts. Read your renewal carefully — the exclusion is often buried in a definition of "supported software" that changed quietly.

Your three real options (and what they cost you)

Strip away the noise and the choices reduce to three.

Option 1: Migrate to Drupal 10 or Drupal 11

The path the Drupal project recommends and the path most actively maintained migration tooling supports. Drupal 10 is mature; Drupal 11 (released August 2024) is now stable and well-supported. The Migrate API has been a core part of Drupal since version 8 and handles the structural conversion of nodes, users, taxonomies, and media reasonably well. The work is in three places:

1. Module replacement. Roughly 30–50% of D7 contrib modules have direct D10/11 equivalents. The rest require finding alternatives or rewriting custom modules.
2. Theme rebuild. D7 themes do not port. Twig replaced PHPTemplate in D8, and your front-end is essentially a new build.
3. Content reshape. Field structures, content types, and URL aliases need review. The migration is a chance to rationalize, not just translate.

For most sites, expect 8–16 weeks of focused work for a planned migration with a competent team. Emergency migrations done under breach pressure cost two to three times more and produce worse outcomes.

Option 2: Buy Extended Security Support (ESS)

Several vendors — HeroDevs being the most visible — offer commercial security patches for Drupal 7 beyond EOL. This is a legitimate stopgap. It buys you time, satisfies most compliance auditors, and is dramatically cheaper than a panic migration.

It is not a long-term answer. ESS is explicitly a bridge: you pay an annual fee while you plan and execute migration. Sites that treat ESS as a permanent solution accumulate technical debt every year, watch their module ecosystem decay further, and end up migrating eventually with more pain than if they had started in 2024.

If you choose this option, treat the ESS contract as a 12–18 month migration window, not a renewal-in-perpetuity strategy.

Option 3: Replatform entirely

For sites where Drupal was the wrong fit anyway — small marketing sites, content-light landing pages, simple e-commerce — moving to WordPress, a static site generator, or a headless CMS may be cheaper than a Drupal-to-Drupal migration. The trade is that you lose Drupal's structured content model and permissions system, which is precisely what most surviving D7 sites use it for.

Replatforming is not a security shortcut — you still need to migrate content, redirects, and integrations. Decide it on fit, not on EOL panic.

A 30-minute risk assessment you can do today

Before you talk to a vendor, get your own answers to these:

1. What's your exposed surface? Is the site public, behind SSO, or restricted by IP? Public sites carry the highest scanner-driven risk.
2. What data lives in it? PII, payment data, health data, regulated data, or just marketing copy? Data class determines compliance exposure.
3. What's your last patch date? If your last D7 core update was before January 5, 2025, you are running known-vulnerable code today.
4. How many contributed modules do you have, and how many were last updated more than 24 months ago? Run drush pm-list --status=enabled --type=module and cross-reference dates on drupal.org.
5. Do you have backups you could restore from? Tested, recent, off-site. If the answer is "I think so," fix that this week regardless of EOL.
6. What does your cyber insurance policy say about unsupported software? Search the policy document for the word "supported."
7. What's your audit calendar? When is your next PCI, SOC 2, HIPAA, or vendor security review? That is your real deadline.

If three or more of those answers concern you, your migration timeline is shorter than you think.

Why waiting gets more expensive every month

Three forces compound monthly:

• Talent scarcity. Drupal 7 expertise is a depreciating asset. Every month, fewer engineers will touch a D7 codebase, and the ones who will charge more for it.
• Module abandonment. Each contributed module that loses its maintainer makes your migration harder, because direct equivalents are harder to find and custom rewrites become more likely.
• Pressure-driven mistakes. Migrations executed under breach response or audit-fail pressure produce sites with worse architecture, more technical debt, and more downtime than planned migrations. The premium is not just dollars — it's the quality of what you end up with.

A planned migration started today, on a 12-week schedule, almost always beats an emergency migration started in three months on a 6-week schedule.

Frequently asked questions

What happens to my Drupal 7 site if I do nothing?

It keeps running until it doesn't. The failure mode is rarely "the site goes offline." It's a successful exploit (data leak, defacement, ransomware), a failed compliance audit, or a server-side incompatibility that breaks the site at the worst possible time. The longer you wait, the more likely all three become.

Can I pay someone to keep patching Drupal 7?

Yes — Extended Security Support (ESS) vendors like HeroDevs sell exactly this. It's a valid stopgap for 12–18 months while you plan a migration. It is not a long-term strategy, and most ESS providers structure their pricing to make that clear.

How long does a Drupal 7 to Drupal 10 migration take?

For a typical content site (50–500 pages, 30–60 modules, custom theme), 8–16 weeks of focused work with an experienced team. The variance is driven by custom module count, content model complexity, and integration count, not page count.

Will my Drupal 7 modules work in Drupal 10?

No — not directly. Drupal 8 introduced fundamental architectural changes (Symfony, Twig, configuration management) that broke module compatibility. Many popular D7 modules have D10 equivalents, but they are reimplementations, not ports. Your custom modules will need to be rewritten.

Is Drupal 11 production-ready, or should I migrate to Drupal 10?

Drupal 11 (released August 2024) is production-ready and is the recommended target for new migrations as of 2026. Drupal 10 will be supported until December 2026, so a D10 migration is not wrong — but if you're starting today, going straight to D11 saves you a follow-on upgrade in a year.

Should I switch to WordPress instead of migrating to Drupal 11?

Only if Drupal was a poor fit for your site to begin with. WordPress and Drupal solve different problems. If your site relies on Drupal's structured content, granular permissions, or multi-site architecture, replatforming to WordPress is a step backward. If it's a marketing site that never used those features, WordPress may be cheaper to operate long-term.

Get a free migration assessment

Every Drupal 7 site is different, and the right migration path depends on your modules, your content model, your compliance environment, and your timeline. We've helped organizations move D7 sites to Drupal 10 and 11 and can give you a concrete scope, timeline, and risk assessment in 30 minutes — at no cost.

Schedule a free Drupal migration consultation →