Staying on Drupal or moving off: three paths compared

Your Drupal site still works. Then a supplier says its version no longer receives security support, attaches a quote and calls the work an upgrade. Another supplier proposes a rebuild. A third recommends extended support instead.

Those quotes may differ because they describe three different jobs. The question is which job the site needs.

Start by separating editorial content from application behaviour. Pages, articles and menus are one kind of migration. Approval workflows, member accounts, commerce and integrations are another. An afternoon’s inventory can narrow the options, but a list of content types alone does not settle the decision.

Unsupported is a date, not an event

Drupal 7 reached end of life on 5 January 2025 after several extensions. The site did not stop working that morning. What stopped was the Drupal Security Team’s support behind it.

Security advisories for Drupal 7 core and contributed modules stopped coming from the Drupal Security Team. New vulnerabilities remain open unless a commercial provider supplies a patch. The code did not suddenly become less secure; its support arrangement ended.

Drupal also depends on PHP. PHP 8.1 stopped receiving security fixes on 31 December 2025 and PHP 8.2 stops on 31 December 2026. A host may remove an unsupported branch, and old Drupal code may fail on the replacement. The runtime needs its own plan.

Exit 1 — pay someone to keep patching it

The Drupal Association lists two certified extended-support vendors at the time of writing: HeroDevs and Tag1 Consulting. They supply patches for Drupal 7 core and covered contributed modules after the project stopped issuing them.

What it buys is continued security coverage from a commercial provider and a support arrangement you can document for an auditor, insurer or board.

It does not add features, improve speed or resolve the PHP lifecycle. It also does not reduce the eventual migration work by itself. Its value is the time it creates.

Neither vendor publishes a price list, so I will not invent a range. Get the quote and renewal terms in writing, including the second-year price.

Write the purpose beside the price: twelve months to complete a rebuild, retire an integration or replace the site for a business reason. Review that purpose at renewal rather than allowing temporary support to become the default by accident.

Exit 2 — rebuild on current Drupal

Drupal 7 to Drupal 11 is not an in-place update. Drupal provides migration tooling, but it does not carry the running site across unchanged.

Content can move through Drupal’s Migrate API. The theme must be recreated for the current rendering system. Custom modules need to be rewritten or replaced, and each contributed module needs a supported equivalent. Establishing those equivalents is research that belongs before the quote.

The result is a new site containing migrated content and rebuilt behaviour. A useful quote separates discovery, migration, theme work, module replacement, custom code and testing. The word upgrade alone does not describe that scope.

For a rebuild in late 2026, Drupal 10 reaches end of life on 9 December 2026, the week Drupal 12 is scheduled for release. Build on Drupal 11, which requires PHP 8.3 or newer. PHP 8.3 receives security fixes through 31 December 2027.

Exit 3 — move the editorial parts off

A traditional CMS gives editors somewhere to work and assembles public responses at request time. If every visitor receives the same pages, a static public build can remove some runtime work. It is less suitable when Drupal also provides application behaviour.

Editorial content is usually transferable as structured data, although media references, embeds, rich text and old fields need testing. Every exit still needs a URL inventory; I wrote separately about building that map before the new site exists.

Webforms with routing and approval steps, per-user data, member areas, commerce and undocumented integrations are application features. Moving away from Drupal means replacing each one or deciding that it can be retired.

A first-pass inventory

I start with these questions:

1. Which content types and fields are actually in use? Include revisions, taxonomies, media, embeds and multilingual variants.
2. Which modules and custom code provide behaviour? Record supported replacements and unresolved gaps.
3. Which workflows and permissions matter? Include approval, translation review, scheduled publishing and restricted views.
4. Which systems connect to it? Payment, CRM, ERP, fulfilment, SSO, search, feeds and form routing all count.
5. Who logs in? Separate staff editors from customers, members, partners and service accounts.
6. Which data needs special handling? Personal, payment and regulated data change both the migration and testing plan.

If the answers are mostly pages, media and publishing, a smaller platform may be cheaper. If the site depends on workflows, permissions, public accounts or integrations, compare a Drupal 11 rebuild with recreating those features elsewhere. The inventory narrows the choice; it does not make it.

The same site, three exits. What each one actually buys.

Exit	What it buys	What it does not do
Paid extended support	Security patches for Drupal 7 core and covered contributed modules from a certified vendor	Nothing about PHP versions, features or speed — and it does not make the eventual move cheaper
Rebuild on current Drupal	A supported platform, imported content and rebuilt application behaviour	It does not carry the theme or custom modules across. Both are written again
Move the editorial parts off	A smaller system to run, with the CMS runtime out of public delivery	It does not move workflow, member areas or commerce for free. Those are rebuilt too

What I would do this year

Run the inventory first. A preliminary pass can fit into an afternoon and show whether quotes describe comparable work. Custom code and integrations need deeper discovery before responsible pricing.

For an application, quote the rebuild against Drupal 11 and name module gaps. For an editorial site, start with the URL inventory because that work survives every exit.

Buy extended support when the chosen work takes longer than you are prepared to run without Drupal 7 security coverage. Put the intended end date and renewal terms beside the price.

When to ignore all of this

If you are on Drupal 11, none of this is your problem — keep it patched and carry on. If you are on Drupal 10, your job this year is the move to 11, which genuinely is an upgrade in the ordinary sense, and the December date is your deadline rather than a reason to panic.

For memberships, commerce, team workflows or multilingual review, moving off Drupal may mean rebuilding the features that justify it. Compare that work before changing platforms.

If the site will be replaced for business reasons within a year, avoid a full Drupal rebuild. Fund only the support and risk controls needed to bridge the interval safely, then put the remaining budget into the replacement.

Sources

1. Drupal core release schedule — Drupal.org — Drupal 7 end of life on 5 January 2025, Drupal 10 end of life on 9 December 2026 and Drupal 12 scheduled for the week of 7 December 2026. Checked 20 August 2026.
2. Drupal 7 extended support partners — Drupal.org — The certified vendors offering paid Drupal 7 security support after end of life. Checked 20 August 2026.
3. PHP requirements — Drupal.org — The PHP versions each Drupal major version supports. Checked 20 August 2026.
4. Supported versions — PHP.net — PHP 8.1 security support ended 31 December 2025; PHP 8.2 ends 31 December 2026 and PHP 8.3 ends 31 December 2027. Checked 20 August 2026.

Not sure which of the three is yours?

Send the URL and whatever inventory you have of modules, integrations, workflows and user accounts. We'll identify the likely path and say so plainly if staying on Drupal is the better answer.

Get in touchHow a migration goes