A regional hospital group leaves Drupal 7 without a content freeze

The situation

A regional hospital group ran five public sites on one Drupal 7 multisite: the group site, three hospitals and a rehabilitation clinic. Around 35 editors published daily. Visiting hours, ward closures, vacancies and press releases went out the same afternoon they were decided, and the group's own security policy did not allow an unsupported CMS on a public host after Drupal 7 reached end of life on 5 January 2025.

The previous agency had quoted a rebuild with a six-week content freeze. A hospital cannot stop posting closures for six weeks, so the project stalled until the deadline was four months away.

What we found in the assessment

We ran Upgrade Status and a module inventory on a copy of production. The install had 148 contributed modules enabled, 61 of them with no Drupal 11 release. Most were dead weight: three image handling modules, two WYSIWYG editors, and Panels plus Panelizer for layouts that only two pages still used.

Content lived in 22 content types, 9 of which had fewer than 20 nodes. The real complexity sat in the Field Collection data behind doctor profiles and the department directory, plus roughly 3,000 PDF attachments linked from body text with absolute URLs. The Zen-based theme had not been touched since 2017 and nobody on their side could edit it.

The decisions

We agreed three things before writing code.

• No freeze. Editors would keep working in Drupal 7 until cutover day, and the migration would be re-run incrementally until then.
• Consolidate. The 22 content types became 9. Field Collections became Paragraphs. The two Panels pages moved to Layout Builder on a single landing page type.
• A new theme, not a port. The old theme failed the accessibility requirements the group is now held to, so we built a fresh theme on Olivero's structure.

Dropped outright: Panels, Panelizer, Field Collection, Media Gallery, Nodequeue and around 40 modules that added nothing. Media Gallery became core Media. Nodequeue became a small sortable view.

How the move ran

The migration was built on the Migrate API with migrate_plus, one migration group per site and a shared base configuration so the group site could carry a slightly different field set. We ran the full migration 14 times over nine weeks. Each run was diffed against the source on node counts, file counts and redirect coverage, and incremental update runs picked up anything edited since the previous pass.

The PDFs were the tedious part. A process plugin rewrote absolute file URLs to managed Media entities, and every old path went into the Redirect module. Before cutover we crawled the Drupal 7 sitemap and the top 2,000 URLs from their analytics against the staging host. 37 did not resolve and were fixed by hand.

Editors had two training sessions per hospital on a staging copy with their own content. CKEditor 5 raised the most questions, mainly because the old habit of switching to source view no longer applied.

Cutover ran on a Tuesday morning. The final incremental migration took 40 minutes, DNS switched at Cloudflare, and the Drupal 7 host stayed up read-only for four weeks as a fallback. Nobody needed it.

After launch

The group now runs in its own cloud account, right-sized and managed by us, with Redis and Varnish in front of PHP 8.3, and a support retainer covers core and contributed updates. Against their previous hosting plus the old agency's maintenance fee, the monthly cost fell by roughly two fifths.

The first core security release after launch was applied within a day. On the Drupal 7 site that had not happened in three years. Core updates are now an afternoon's work rather than a project, and the editors report that the department directory, once a Field Collection maze, is the part they like most.