When this post was first written in late 2022, Drupal 7 was approaching its second extended end-of-life date in November 2023. The Drupal Association had already pushed the original EOL from November 2021, and was about to push it again. Drupal 7 ultimately reached its final EOL on January 5, 2025, more than three years after the originally announced date.
That timeline is operationally interesting. Drupal 7 was the most successful version of Drupal in the platform's history, powering an estimated 400,000+ websites at its peak, including a substantial portion of US government and higher education. The EOL extensions were not a sign that Drupal had stalled. They were a reflection of how slowly large institutional websites actually move, and the practical accommodation the Drupal community made for that reality.
This post is a snapshot of what was true about Drupal 7 in late 2022, with a retrospective note on how the transition actually played out for agencies and institutions that operated D7 sites.
Why Drupal 7 Was So Hard to Leave
Drupal 7 was the last version of Drupal that worked the way Drupal had always worked. It used a procedural module system, ran on traditional PHP, did not require Composer, and could be operated by site builders who were not professional developers. Templates, modules, and themes followed conventions that had been stable for years.
Drupal 8 was a different platform. It introduced Symfony, Composer-based dependency management, and an object-oriented module API. The migration path was not a version upgrade in the traditional sense. It was effectively a re-platform.
For government agencies and large universities running on Drupal 7, the cost of that re-platform was substantial. Custom modules had to be ported. Themes had to be rebuilt. Editorial workflows had to be reconfigured. Procurement cycles had to fund the work. None of this happened quickly in public-sector institutional contexts.
By 2022, an estimated 552,000 of 1,027,000 Drupal sites were still on Drupal 7. The Drupal Association extended the EOL to give those institutions more runway.
What "End of Life" Actually Means
End of life means the Drupal Security Team stops issuing security advisories and patches for the version. The platform itself keeps running. Sites do not break on the EOL date. They become exposed to whatever vulnerabilities are discovered after that point with no central source for remediation.
For a public-facing government or institutional website, this is operationally untenable. A vulnerability scanner finding a CVE on a post-EOL Drupal 7 site will produce an audit finding. Compliance frameworks like NIST 800-53 and FedRAMP do not accept "the platform is end-of-life" as a justification for unpatched vulnerabilities.
The Drupal community recognized this and authorized a Vendor Extended Support program. Approved vendors continued to publish security patches for Drupal 7 core and a list of contributed modules after the official EOL. This was the same pattern Drupal 6 had followed (Long Term Support extended for six years past EOL).
For agencies and institutions that needed more time to migrate, Vendor Extended Support was the operational bridge.
How Institutions Actually Handled the Transition
Three operational patterns emerged across the institutions we worked with on Drupal 7 migrations.
Direct migration to Drupal 9 or 10. Institutions with sufficient development capacity and modern hosting environments migrated directly from D7 to D9, then to D10 as the next minor version. This was the cleanest path technically but required the most up-front investment.
Drupal 7 with Vendor Extended Support, then migration. Institutions facing compliance audit cycles or political constraints that prevented immediate migration paid for Vendor Extended Support and continued operating Drupal 7 for one to three years past the original EOL. The migration happened on a planned schedule rather than under EOL pressure.
Replatform to a different CMS entirely. A subset of institutions, particularly higher education marketing teams, used the EOL as an opportunity to replatform to WordPress or Cascade rather than upgrade Drupal. The cost of re-platforming to a different CMS was sometimes lower than the cost of porting custom Drupal 7 work to Drupal 9, especially when the original Drupal 7 implementation had heavy customization.
For managed Drupal hosting for government, we ran all three patterns simultaneously across different clients during the 2022 to 2025 window. The choice was driven by institutional capacity and risk tolerance, not by a single best-practice recommendation.
What Made the Drupal 7 to Drupal 9 Migration Hard
The technical migration challenges that surfaced repeatedly across institutions:
Custom modules. Institutional Drupal 7 sites typically had between five and fifty custom modules. Each had to be either ported to Drupal 9 (significant development effort) or replaced by a contributed module providing similar functionality. The Drupal community published Migrate API documentation and the Upgrade Status module to help, but custom code was still custom work.
Custom themes. Drupal 9's theming layer (Twig) was different enough from Drupal 7's PHPTemplate engine that themes had to be rebuilt rather than ported. Institutions with brand-customized themes faced visual regression risk on every migration.
Content migration. Drupal 9's core Migrate module handled standard entities (nodes, users, taxonomy, files) reliably. Custom entity types from Drupal 7 required custom migration scripts. Institutions with heavy use of fields, content types, and entity relationships faced migration design work proportional to the complexity of their content model.
Editorial workflow reconfiguration. Drupal 9's workflow system replaced Drupal 7's contributed workbench moderation. Institutions with mature editorial workflows had to reconfigure them in the new model.
The Retrospective Lesson
The Drupal 7 to Drupal 9 transition is a reasonable model for how large institutional CMS migrations actually happen. They take longer than the platform's stated timeline, they require operational discipline at the hosting and security layer to span the transition window, and they often involve a mix of upgrade, replatform, and extended-support strategies across different parts of the institution.
For agencies still operating Drupal sites today, the structural lesson is to plan migration cycles two to three years ahead of platform EOL dates and to budget for vendor extended support as a practical bridge if necessary. We typically build these timelines into managed Drupal hosting engagements as a standing operational commitment rather than a one-time project.
Frequently Asked Questions
When did Drupal 7 actually reach end of life?
Drupal 7 reached its final official end of life on January 5, 2025, after two extensions from the original November 2021 date. Vendor Extended Support continues to provide security patches for institutions that need additional runway.
Can Drupal 7 sites still be operated safely after EOL?
Only with Vendor Extended Support providing security patches, and only with active security monitoring at the production hosting layer. A Drupal 7 site without ongoing patching is operationally unsafe and will not pass most compliance audits.
What was the recommended migration path from Drupal 7?
For most institutions, direct migration to the latest Drupal version (10 or 11 depending on timing) using the core Migrate API and Upgrade Status module. Institutions with substantial custom code or specialized themes often used the migration as an opportunity to evaluate replatforming to a different CMS.
How long does a Drupal 7 to Drupal 10 migration typically take?
For a moderately complex institutional site (50 to 200 pages of custom content, 10 to 20 contributed modules, custom theme), a competent migration team typically completes the work in three to six months including planning, development, content migration, testing, and cutover. Larger sites with extensive custom modules can take a year or more.