Drupal 7 extended support: what it covers and what it does not

Drupal 7 reached end of life on 5 January 2025. Since then, the only security fixes come from commercial extended support vendors, and what they sell is narrower than the name suggests. Extended support keeps a known site patched against known classes of issue for a defined period. It does not make the site current, and it does not stop the ground moving underneath it.

What extended support covers

The vendors in the Drupal Association's extended security support partner programme, and the independent providers alongside them, offer roughly the same core scope.

Core security patches. When a vulnerability is found in Drupal 7 core, or a fix in Drupal 10 or 11 turns out to apply to the 7 codebase as well, the vendor writes and tests a patch and distributes it to subscribers. This is the heart of the service. Before end of life these fixes were public and free. Now they are private and paid for.

Contrib module review. A list of commonly used contrib modules, typically the most installed few hundred, is monitored. When a security issue affects one of them, the vendor either patches it or tells you to remove it. Modules outside the list are your problem.

PHP compatibility. The final Drupal 7 core releases added compatibility with PHP 8, but plenty of contrib and custom code still assumes PHP 7.4. Vendors maintain compatibility patches for the modules on their list so that a site can move to a PHP version the host still supports.

Monitoring and advisories. A feed telling you what has been patched, what to apply and by when. Some vendors add uptime and file-integrity monitoring. Some leave that to your host.

What you get, in practice, is a private patch feed and a promise that someone is looking. Applying the patches, testing them and deploying them is usually a separate line, either your team's hours or a retainer.

What it does not cover

The gaps are where the real cost sits.

New features. Nobody is adding anything to Drupal 7. Layout Builder, modern media handling, JSON:API for a headless front end, decent editorial workflows: none of it is coming. Every feature request from now on is custom code on a frozen platform.

Contrib modules nobody maintains. The Drupal 7 sites we see run somewhere between eighty and 150 contrib modules. The vendor's list covers the popular ones. The module your agency picked in 2014 for a carousel, with a few hundred installs and a maintainer who left Drupal in 2019, is not on any list. If it has a hole, it stays open.

Custom code. Your theme, your custom modules and your Features exports are yours. Extended support vendors do not audit them.

PHP 7 hosting going away. This ends more Drupal 7 sites than any exploit. PHP 7.4 lost security support in November 2022. PHP 8.1 lost it on 31 December 2025, and PHP 8.2 loses it on 31 December 2026. Hosts drop versions after those dates, and a Drupal 7 site whose contrib and custom code will not run on PHP 8.2 or 8.3 has nowhere to go. Extended support can patch core for PHP 8.3. It cannot rewrite your custom modules.

Compliance. If a customer, regulator or cyber-insurer asks whether the site runs on a supported platform, the honest answer is that it runs on a platform whose project ended support in January 2025, with a third party patching it. Some auditors accept that. Some do not.

Third-party integrations. Payment gateways, CRM connectors and SSO providers retire their old API versions on their own schedules. The Drupal 7 module that talks to them stops working, and no security patch fixes that.

How the monthly cost works

Vendors do not publish a single price, and we will not invent one, but the mechanism is consistent across the market.

• A base subscription for the patch feed, priced per site or per organisation, sometimes tiered by the size of the contrib list you want covered.
• A hosting component, because most vendors want the site on infrastructure they control, or at least on a PHP version they support. This often means a hosting move before extended support even begins. If that is your situation, read what you are paying for in a Drupal hosting bill first.
• Hours for applying patches, testing them against your custom code and deploying. Budget for one patch cycle a month plus the occasional urgent one.
• A minimum term, usually twelve months, because vendors are recovering the fixed cost of maintaining their patch sets.

The important arithmetic is not the monthly figure. It is the monthly figure multiplied by the number of months you expect to stay, plus the migration you will still have to do at the end. Extended support does not replace the migration. It moves it, and each month of delay is a month of fees on top of the same migration cost.

When to stop paying and migrate

Extended support is a bridge, and a bridge has a far side. Three signals tell you it is time to cross.

The PHP wall is in sight. If your host has announced a date for dropping the PHP version you run on, and your contrib and custom code cannot be made to run on the next one within the extended support scope, the migration deadline is that date, whatever the contract says.

You have a real feature need. A redesign, a new language, a headless front end, an integration the business needs. Building it on Drupal 7 doubles the work, because it will have to be rebuilt after the migration anyway.

The fees are approaching the migration cost. Take a site that has been on extended support for eighteen months as a worked example. The subscription, hosting premium and patch hours over that period may already add up to a meaningful share of what a migration to Drupal 11 would have cost, and the migration is still ahead. Every further month makes the comparison worse.

The right time to migrate is usually earlier than the extended support contract suggests, because the contract term is set by the vendor's economics, not by your site's.

Decision table

| Situation | Recommendation | | --- | --- | | Site is being retired or replaced by another platform within twelve months | Extended support for the remaining months, then decommission | | Site is stable, low traffic, no feature needs, and the host still offers a PHP version the code runs on | Extended support for one term while you plan and budget the migration | | Host has announced a PHP cutoff within the next year | Start the migration now, with extended support only for the overlap | | Business needs a redesign, new features or an integration | Migrate first and build the feature on Drupal 11 | | Site holds personal data or is in scope for a compliance audit | Migrate. Extended support alone is hard to defend to an auditor | | Migration budget is not available this financial year | Extended support with a fixed end date, and the migration written into next year's budget explicitly | | Site has been on extended support for more than a year with no migration scheduled | Stop and price the migration. The bridge is now costing more than the crossing |

Notice that most rows end in a migration. That is not a sales pitch. It is where Drupal 7 goes.

When you do migrate, plan for the URLs before anything else. Our post on keeping every URL through a Drupal 7 to 11 migration explains why the inventory is the first deliverable, not the last.

Where to start

We provide Drupal 7 extended support for sites that need a defined bridge, with a fixed end date agreed up front and a migration plan alongside it. If you are not sure which row of the table you are in, the fixed-price five-day assessment will tell you what your site runs on, what the PHP situation is, and what the migration would involve, so that the decision is made on facts rather than on the contract renewal date.