Staying on Drupal or moving off: three paths compared
Quotes for an unsupported Drupal site can differ sharply because extended support, a Drupal rebuild and a move to another platform are different jobs.
7 minute read
lordtime
Your Drupal 7 site still takes form submissions and the editors can still publish. Then the quotes arrive: one for support, one for an “upgrade” and one for a replacement. The prices are far apart because the suppliers are pricing different work.
Before comparing totals, ask each supplier what happens to the custom modules, user accounts, forms and old URLs. A page count will not answer those questions. A short inventory will show which quote has left work out.
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’s Migrate API moves content; it does not move the working site. A Drupal 7 theme needs rebuilding for Drupal 11. Each custom module needs its own decision, and some contributed modules have no supported successor.
I would ask for a module list with a decision beside each entry: supported equivalent, rewrite, or retirement. The quote should also name content migration, theme work and testing separately. If it says only upgrade, there is no way to tell which of those jobs is included.
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
If Drupal mainly holds articles and images, the public pages need not be assembled by Drupal on every request. Editors can work in a CMS while a static build serves visitors. That can remove a public runtime, though it still leaves editorial software to maintain.
Export a sample first. Check its images, embeds, rich text and older fields in the proposed new system. Keep the old URLs in scope too; the redirect map belongs before the build.
A membership area or a form that routes work for approval is a different matter. Write down who uses it and what it does before proposing to leave Drupal. The replacement either needs that behaviour or a deliberate decision to retire it.
A first-pass inventory
I start with these questions:
- Which content types and fields are actually in use? Include revisions, taxonomies, media, embeds and multilingual variants.
- Which modules and custom code provide behaviour? Record supported replacements and unresolved gaps.
- Which workflows and permissions matter? Include approval, translation review, scheduled publishing and restricted views.
- Which systems connect to it? Payment, CRM, ERP, fulfilment, SSO, search, feeds and form routing all count.
- Who logs in? Separate staff editors from customers, members, partners and service accounts.
- 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.
| 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 |
Put the quotes beside the inventory
Mark each workflow and integration as included, excluded or still unknown in each quote. If the site is mostly publishing, ask whether the proposed rebuild includes redirects for old URLs. If it is an application, ask which Drupal 11 modules replace the current behaviour. Do not accept an empty cell as an assumption that the work is covered.
If support is the bridge while that work happens, write its end date next to the project date. Check the renewal terms now, while there is still time to choose another route.
When to ignore all of this
Already on Drupal 11? Keep it patched; this three-way choice is for Drupal 7. Drupal 10 has a different task: plan the move to 11 before its 9 December 2026 end of life.
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
- 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.
- Drupal 7 extended support partners — Drupal.org — The certified vendors offering paid Drupal 7 security support after end of life. Checked 20 August 2026.
- PHP requirements — Drupal.org — The PHP versions each Drupal major version supports. Checked 20 August 2026.
- 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.