Drupal 7 Extended Support Separates Patch Coverage From Service Ownership

Public transition plans from the University of Oxford and UC Berkeley show that Drupal 7 extended support covers only part of the work required to operate a site and complete its migration. Oxford separates supplied updates from implementation and customised-platform maintenance, while Berkeley leaves content review and migration cleanup with campus website teams. The documents distinguish commercial security coverage from full service ownership.

The responsibilities fall into three layers. Patch coverage applies to Drupal core and specified contributed projects. Service operation includes custom code, integrations, deployment, testing, hosting, runtimes, and monitoring. Exit work includes content review, approvals, migration cleanup, parallel hosting, and project funding.

Community security support for Drupal 7 ended on 5 January 2025, and the version no longer receives community security or compatibility updates. The Drupal Association currently identifies HeroDevs and Tag1 Consulting as certified vendors in its Extended Security Support Provider Program. Certification identifies sources of continued coverage, but the agreement with each customer determines which software and services are included.

Oxford updated its transition plan on 31 March 2026 and extended support for the Drupal 7-based Oxford Mosaic platform until April 2027 while more complex websites move to Oxford Fresco. HeroDevs supplies covered updates for Drupal 7 core and contributed modules, while Oxford’s CMS and Web Platform Team implements the updates and maintains customised modules and integrations. The university has also upgraded Drupal 7, PHP, and SimpleSAML, completed a third-party security assessment of HeroDevs, and coordinated hosting and database work with Acquia. Extended support is therefore one relationship within the service rather than a transfer of the whole platform to a supplier.

UC Berkeley Web Platform Services says Open Berkeley sites hosted on Pantheon have Drupal 7 Extended Support until at least January 2027. Every site must nevertheless be rebuilt or programmatically migrated to Berkeley Web Builder. Campus website teams must review content, remove unpublished pages, update layouts, and complete cleanup caused by technical and design differences between the platforms. Berkeley IT funds the hosting expense for an additional transition site for three months, after which the additional in-progress site begins incurring hosting and maintenance charges.

The University of Cambridge’s legacy-platform guide, dated 3 September 2025, describes its Drupal 7 service as live while sites move to the replacement platform. The page records a first-quarter 2026 migration target but does not confirm whether that target was met. It assigns service responsibility across university teams and documents separate production, test, and development environments, deployment processes, hosting, incident response, and monitoring. New Relic says in an end-of-life notice that support for Drupal 7-specific monitoring in its PHP agent will end on 15 October 2026. The notice shows that an operational dependency can follow a timeline separate from the Drupal patch arrangement.

A recent r/drupal discussion attributed continued Drupal 7 use to migration cost, custom modules, themes, configuration rebuilding, and the limited visible return from replacing a working site. Those accounts provide community context but do not establish what any extended-support agreement covers.

Together, the records show why describing a Drupal 7 site as supported is incomplete unless the remaining responsibilities are named. Oxford distributes work among a commercial provider, its platform team, information-security staff, and hosting provider. Berkeley adds content and transition duties for campus teams, while Cambridge shows the wider operational service that must continue around the application. A credible extended-support plan must document what the provider covers, assign every responsibility outside that coverage, and connect both to a funded migration endpoint.