Drupal 7 EOL migrations: ranked by editorial weeks lost

You inherit a Drupal 7 site that did €4.2M in pipeline last year. The marketing team is fourteen people. They write campaign pages, regional landing pages, partner profiles, case studies. The CMS works, the editors know it cold, and the head of marketing has told you twice that writers shipping content is the only thing keeping their number alive.

Then Drupal 7 hit end of life on 5 January 2025. The community stopped patching it, your security team flagged the next pen test, and you have eight months to be off the platform.

The cost most boards ask about is engineering hours. The cost that actually breaks marketing is editorial weeks. A fourteen-person team blocked for two weeks loses twenty-eight editor-weeks of campaign output. Multiply that by your content-to-pipeline ratio and you have the bill that the CMO will feel in Q4.

We have shipped eleven migration paths off Drupal 7 since the EOL extension was announced. Below is the cheatsheet, ranked from cheapest to most expensive in editorial weeks at a comparable shop. Engineering hours are noted but not the headline.

Why editor-weeks beats engineering hours

Engineering you can hire. Editorial muscle you cannot. The writers who know your tone, your product, and which legal phrases come back in 48 hours instead of 12 days are the irreplaceable side of any migration.

Every CMS migration adds three taxes to that team:

• Retraining to a new editor (Gutenberg, Sanity Studio, Payload Admin, whatever).
• Workflow disruption (preview, draft, scheduling, approval chains).
• Content reconciliation (broken layouts, fields that lost their meaning, embed shortcodes that no longer render).

We score those three together as editor-weeks lost. It is approximate. It is also the only number a CMO actually feels.

The cheatsheet, ranked

1. Drupal 7 Extended Support. 0 editor-weeks.

You don't migrate. HeroDevs or Tag1 sells extended security support past EOL. Roughly €15k to €45k a year depending on traffic and the security posture you need. Editorial cost is zero because nothing changes for the writers. Engineering cost is one Friday for the contract paperwork plus annual renewal.

Right answer when: you have a hard rebuild on the roadmap twelve to twenty-four months out and need to buy time without disrupting campaign cadence. We have used it twice as a bridge, never as the destination.

Where it bites: PHP 7.4 is also out of support, so the underlying stack still drifts. Pantheon and Acquia phase D7 out regardless of your support contract.

2. Backdrop CMS. 2 to 4 editor-weeks.

Backdrop is the fork of Drupal 7 that the community started in 2013 specifically for sites that did not want to follow the D8 architecture. Same admin UI, same Views, same CCK heritage, modernised PHP support.

Migration is a Drush-driven import that maps cleanly because the data model barely moved. Editors keep their muscle memory: same node form, same revisions tab, same blocks panel. The two to four weeks lost is mostly content audit (drop the cruft you accumulated in twelve years) and a re-shoot of the editorial style guide.

Where it bites: smaller module ecosystem. If your D7 site leaned on Workbench Moderation, Webform, or Commerce, expect the Backdrop equivalents at 80% feature-parity, not 100%.

3. Drupal 11 in-place. 4 to 8 editor-weeks.

The official path. The Migrate API moved into Drupal core in D8 and supports a direct D7 to D11 jump.

Editorial cost lands higher than people expect because the admin UX between D7 and D11 is genuinely different. Claro is the new admin theme. Layout Builder replaced Panels. Paragraphs is the recommended pattern instead of nested fields. Your team will be slower for six to eight weeks while the muscle memory rebuilds.

Engineering cost is steep but bounded: every contrib module on the D7 site needs a D11 equivalent or a replacement. Custom modules are a rewrite, not a port.

4. Drupal 11 with decoupled front end. 6 to 10 editor-weeks.

Same migration as path 3, but the front end becomes Next.js (or Nuxt, or Astro) consuming Drupal via JSON:API. Editors stay in Drupal. Preview gets harder.

The editorial cost is the preview workflow. In the monolith they hit Save and preview and saw the page. In a decoupled setup the preview tab needs a per-page tunnel to a Next dev server or a built-in preview deployment. We have shipped both. Neither is invisible to the editor.

5. WordPress with Gutenberg. 8 to 12 editor-weeks.

A real path, used more than the WordPress evangelists admit and more than the Drupal loyalists like. The data model is rebuilt: nodes become posts, taxonomies become taxonomies (different table, same idea), fields become ACF or block attributes.

Editorial cost is mostly Gutenberg retraining and the rewrite of every reusable layout as a block. The eight to twelve weeks reflects what a fourteen-person team actually loses while the editor changes underneath them.

Where it bites: the migration is one-way. If you change your mind in month fourteen, you go back to the D7 export and start over.

6. Craft CMS. 10 to 14 editor-weeks.

We have used Craft for clients whose content team described their Drupal experience as fighting the form. Craft's entry types and matrix fields map well from Paragraphs-heavy D7 sites. The editor is genuinely pleasant once they get there.

Cost is two things: the content model needs to be redesigned from scratch (you are not porting, you are translating), and Twig templates have to be rewritten from D7's PHPTemplate-into-Twig hybrid.

7. Statamic. 12 to 16 editor-weeks.

Statamic is the flat-file Laravel CMS. Same idea as Craft, but with content stored as YAML and Markdown on disk, which means the whole site goes through git review. Engineers love it. Editors take longer to settle.

The twelve to sixteen weeks reflects the cultural shift to git-aware editing, even when you give them a real admin UI on top.

8. Strapi plus Next.js. 14 to 18 editor-weeks.

You inherit a headless CMS and a brand new front end at the same time. Editors learn Strapi, content modellers redesign the schema, front end engineers rebuild every template as a React component.

Editorial cost is dominated by the preview gap. Strapi has improved here but it is not a Drupal-class preview yet.

9. Sanity plus Next.js. 16 to 22 editor-weeks.

Sanity Studio is the best structured-content editor we ship, and the worst transition for a team used to WYSIWYG. Portable Text replaces the rich-text field. Every block is a structured object.

The pay-off is real: editorial velocity six months in is usually higher than where they were on D7. The pay-back period is the question, not whether it pays back.

10. Payload CMS plus Next.js. 18 to 24 editor-weeks.

Same shape as Sanity but the schema lives in your TypeScript repo and the database is yours (Postgres or MongoDB). Engineers love it for the same reason editors take a while: nothing is automatic, everything is your code.

We picked this twice for clients whose engineering team would own the CMS forever and where editorial velocity could trade against ownership and control.

11. Eleventy or Astro plus Decap CMS. 24 to 36 editor-weeks.

The static path. Content moves to a git repo, editors get a basic UI on top, every publish is a pull request.

Engineering cost is the lowest of any path. Editorial cost is the highest because the editors are now operating inside a developer workflow whether the UI hides it or not. We shipped this once for a client whose marketing team was four engineers who happened to write. For a fourteen-person editor team it is not a serious option.

The pattern that decides the path

Three questions decide it for us.

First: how many of the fourteen editors will still be there in two years? If turnover is high, optimise for the cheapest editor to onboard, which is the Drupal 11 in-place path. If the team is stable, you can pay a higher one-time editorial cost (Sanity, Payload, Craft) for the higher steady-state velocity later.

Second: how important is the existing content model to the business? If marketing has 8,000 nodes across fourteen content types and each one earns SEO traffic, you want a clean import path, which favours Backdrop or D11 in-place. If most of the old content is dead, the migration cost stops mattering and the destination CMS matters more.

Third: is the editor team also the buyer? On B2B sites where marketing picks the CMS, Sanity and Craft win more often than engineering predicts. On sites where IT picks the CMS, Payload and Strapi win more often than marketing predicts.

The five-minute audit is two Drush queries on your prod database. Run them before you spend another day in a migration RFP:

-- node counts per content type, last 24 months
SELECT type, COUNT(*) AS nodes
FROM node
WHERE created > UNIX_TIMESTAMP(NOW() - INTERVAL 24 MONTH)
GROUP BY type
ORDER BY nodes DESC;

-- content types still publishing this year
SELECT type, COUNT(*) AS published
FROM node
WHERE status = 1
  AND created > UNIX_TIMESTAMP(NOW() - INTERVAL 12 MONTH)
GROUP BY type
ORDER BY published DESC;

If the first query lists fourteen content types and the second lists three, the answer to what should we migrate is the three. The other eleven are archive. Decide what to do with archive before you pick a destination, not during the migration.

What we ran for the Dutch publisher

We ran exactly this matrix for a Dutch B2B publisher last autumn. Backdrop was cheapest on engineering and third on editor-weeks, and lost to a Drupal 11 in-place migration because their writers had built a layered Paragraphs habit that translated cleanly to Layout Builder and not to Backdrop's panels. The legacy migration work that follows that kind of audit is most of what we ship at ABN now.

Run the two queries against your prod database before lunch. Picking the path is the easy half.