Drupal 7 EOL escape routes: a ranked field guide for 2027

It's a Tuesday in late February when the CTO of a Belgian university writes us a one-line email. "The board is freezing all new procurement on 1 January 2027. We need a Drupal 7 exit signed before then. Send a field guide." Attached: a CSV with 62,143 nodes across 14 sites, four languages, eleven faculties, and a quietly enormous research repository.

We spent three weeks costing eleven escape routes. This is the field guide we sent back, condensed. The ranking is not academic. It is which exits can be signed, started, and substantially delivered before the freeze closes the procurement window in seven months.

The freeze, in plain terms

European universities operate on multi-year procurement cycles governed by EU Directive 2014/24 and its national transpositions. A "freeze" usually means three things at once. No new vendor contracts above the open-tender threshold, currently €221,000 for public services. No scope extensions on existing frameworks. And no payments out of the next year's budget allocation until the freeze lifts.

Translated for a CMS migration, this means: any vendor you have not already signed before 1 January 2027 cannot start work after that date. Any multi-vendor stitch becomes a series of negotiations you may not be allowed to finish. A platform that needs new procurement in year two of a three-year migration becomes a hostage situation.

That changes the ranking. The "best" CMS in the abstract is irrelevant. The question is: which exit can a procurement officer actually defend on 1 December 2026 with a single signature?

The four routes we ruled out in week one

We dispatched four routes quickly, not because they are bad in general, but because they were wrong for this specific brief.

WordPress with Advanced Custom Fields. A common suggestion from anyone who has not modelled a real university content graph. The Drupal 7 install has 84 content types with deep entity references between research outputs, courses, staff, faculties, and external partners. Rebuilding that in WordPress means either flattening the model (a content disaster) or installing enough plugins to recreate Drupal poorly. We have shipped plenty of WordPress sites and we still ruled this out in two days.

A hand-rolled Symfony rebuild. Tempting on paper. The university has two senior PHP engineers and a tradition of in-house tooling. But a 62,000-page rebuild on a custom framework is a three-year project with a one-year deadline, and the procurement freeze removes the option to add an outside team in year two. Ruled out as a single-track strategy. (It reappears, in the headless variant, further down.)

Sitecore and Adobe Experience Manager. Enterprise CMS licensing for a 14-site institution comes in around €400,000 per year before implementation costs, and the procurement process for either platform alone usually takes nine to twelve months in a Belgian public-sector context. The freeze closes before the contract closes. Ruled out on timing, not merit.

ClassicPress. A WordPress fork. We mention it only because someone in the kickoff meeting raised it. It is not a Drupal 7 successor in any meaningful sense and the migration story is identical to WordPress's, plus a smaller community. Out.

The middle tier: technically viable, politically difficult

Three routes survived the first pass but lost the ranking. They are listed here because they will resurface in any serious Drupal 7 conversation, and because we want the record to show why we declined them.

TYPO3. A genuinely good European CMS with strong adoption at German and Austrian universities. The content model maps reasonably well to Drupal 7's entity system. The problem is talent. The Flemish-speaking TYPO3 contractor pool in Belgium is small, and the university's internal team has zero TYPO3 experience. A platform switch that introduces a new framework, a new templating system, and a new vendor dependency in the year before a procurement freeze is the textbook way to ship late.

Plone. Python, mature, popular in academic settings, with a content model that survives the migration without flattening. We came close to ranking Plone in the top three. It lost on the same talent argument as TYPO3, sharpened by the fact that the university's existing PHP team would become passengers on a Python rebuild. The freeze means you cannot hire your way out of that gap in 2027.

Drupal 10 as a bridge. Skip Drupal 11, take the long-term-support release, and plan a Drupal 12 jump in 2028. This is fine technical advice in isolation. The political problem is that you are signing a contract in 2026 for a platform that will need a second major upgrade before the freeze lifts. Universities have long memories about migrations that arrive in pairs. If your own Drupal 7 exit involves "we'll do D10 now and D11 later," cost the second migration in the same budget line as the first. Two procurements is a different conversation than one.

The top four, ranked

These are the routes we ranked seriously, in increasing order of how well they survive the freeze.

4. Drupal 11 greenfield rebuild

Modern Drupal, single platform, single vendor. The content migration path from D7 to D11 is supported but not painless. The realistic timeline for 62,000 nodes across four languages is 14 to 18 months with a competent team. That fits inside the procurement window if the contract is signed by August 2026, with no slippage. Our risk model put the probability of zero slippage at around 35 percent.

The reason this did not win: a greenfield rebuild on a deadline turns every content-model decision into a fight, and the university has 11 faculties with 11 different opinions about content modelling. The freeze removes the option to bring in a second team to absorb the overrun.

3. HeroDevs Never-Ending Support, as a buy-time play

The Drupal Association named HeroDevs as the official Drupal 7 Extended Support partner. Their Never-Ending Support keeps a D7 site patched against security issues for as long as you pay, which functionally means indefinitely. Costed at this scale, the licensing is roughly €60,000 per year, not nothing, but small compared to a rebuild.

We did not rank HeroDevs as a destination. We ranked it as a five-year option. Buy three years of NES now, sign the contract before the freeze, and use the breathing room to run a slower, calmer migration that finishes after the freeze lifts in 2029. The risk is that "calmer" becomes "indefinitely deferred" and you wake up in 2031 still on Drupal 7. We have seen this happen at two clients on Drupal 6.

2. Headless Drupal 11 with an Astro frontend

Keep Drupal as the content backend, serve the public site through a static or near-static frontend. For a university where 90 percent of the traffic is read-only research pages, course catalogues, and faculty profiles, this is architecturally correct. Editorial workflows stay in Drupal, where the editors already know the interface. The frontend becomes a build artefact that can be deployed to any static host.

The migration timeline is similar to the greenfield rebuild, but the decoupling buys you something specific: the frontend can be replaced later without touching the content. If procurement gets weird in 2030 and you need to swap from Astro to something else, the content does not move. The backend is the asset; the frontend is the consumable.

This ranked second because it still requires a Drupal 11 migration on the critical path. The headless tier is added complexity, and complexity costs hours that the freeze does not give back.

1. Backdrop CMS

The route we ranked first will surprise people who have not looked at Backdrop CMS recently. It is a Drupal 7 fork maintained by a small, disciplined community since 2015. The upgrade path from D7 to Backdrop is documented, the module ecosystem covers the long tail of D7 contrib, and the content model survives the migration nearly intact.

The procurement argument is the clincher. A Backdrop migration is small enough to fit inside a single contract with a single vendor, short enough to substantially complete before the freeze, and conservative enough that the university's existing PHP team can maintain it without retraining. It buys five to seven years of runway with one signature.

The catch is that Backdrop is not Drupal 11. The community is smaller. The roadmap is more cautious. You are betting on a fork that has so far kept up, and may continue to keep up, but does not have the institutional weight of mainline Drupal. For a university whose primary requirement is "a stable site that does not need a procurement officer's attention until 2031," that bet is the right one.

What we would do differently

Three things, in retrospect.

First: cost the procurement work as a line item. We spent maybe 15 percent of the kickoff phase on procurement mechanics and 85 percent on technical evaluation. The ratio should have been closer to 40/60. Public-sector universities live and die by tender windows, and a tender that misses its window by a week is no tender at all.

Second: stop pretending HeroDevs is a non-answer. The reflex among migration consultancies is to treat extended support as a stalling tactic. It is not. It is a financial instrument that converts a deadline into a schedule. For institutions under freeze constraints, that conversion is worth quoting honestly even when it ends with "we still recommend you migrate."

Third: the headless argument needs a separate champion. Backend-frontend decoupling is the kind of decision that loses to "we have always done it this way" in any committee. If we were running this engagement again, we would write a separate seven-page brief on the headless option, costed in isolation, and present it to the IT director rather than the steering committee. That is not a technical change. It is a meeting change.

One command, today

When we built the Backdrop migration plan for that Belgian university, the thing we ran into was that 47 of their 142 contrib modules had no Backdrop port and no Drupal 11 equivalent. We ended up solving it with a two-week triage workshop with the faculty leads, sorting each module into rewrite, drop, or live-without buckets, which is the kind of legacy migration work that fills most of our Februarys.

If you maintain a Drupal 7 site of any size, run this on your server before the next steering meeting:

drush pm-list --type=module --status=enabled --no-core | wc -l

The number is the lower bound of your migration's complexity. Every enabled contrib module is a module you have to find a successor for, port, or drop. We have seen sites where that number was 11, and we have seen sites where it was 340. The 340 site costed seven times more than the 11 site to migrate, and ran half the traffic. That number is your first honest data point. Get it before you cost anything else.