In early 2020, institutions running Drupal sites faced a strategic decision that would shape their operational posture for the next several years. Drupal 9 was scheduled for release in June 2020. Drupal 7 was approaching the end of community support (originally November 2021, eventually extended). Drupal 8 was reaching its own EOL alongside Drupal 7. The right upgrade path was different for each version's owners, and the consequences of getting it wrong would compound over years.
This post is the upgrade decision as it actually played out, written as a retrospective for institutions who navigated it and as a reference for institutions facing similar version transitions in the future.
The Three Decision Paths
Institutions running Drupal sites in early 2020 had three options.
Path 1: Stay on Drupal 7 with extended support. Continue running the existing site, accept that community support was ending, and rely on Vendor Extended Support providers for security patches after EOL. This path bought time but did not close the migration question; it deferred it.
Path 2: Migrate to Drupal 8, then to Drupal 9. Upgrade Drupal 7 sites to Drupal 8, then ride Drupal 8's continued release cycle until the relatively smooth Drupal 8 to Drupal 9 transition. This path was operationally heaviest in the short term but produced the smoothest long-run trajectory.
Path 3: Skip Drupal 8, wait for Drupal 9 to launch, then migrate directly. Stay on Drupal 7 until mid-to-late 2020, then migrate directly to Drupal 9. This path appeared simpler on paper but was actually equivalent in effort to Path 2; the Drupal 7 to Drupal 9 migration is fundamentally a re-platform whether the destination is D8 or D9.
The right path for any specific institution depended on the existing site's complexity, the institution's capacity for migration work, and the timeline tolerance of the institution's planning horizon.
What Drupal 9 Actually Changed
Drupal 9 was deliberately not a major architectural change from Drupal 8. The differences were:
- Removal of deprecated code that had been flagged through Drupal 8's release cycles
- Updated underlying dependencies (Symfony 4.4, Twig 2.0)
- Cleaner codebase that would support continuous improvement going forward
For institutions on Drupal 8, the upgrade to Drupal 9 was structurally straightforward. Cleanup of deprecated code, validation of contributed modules' D9 compatibility, and the upgrade itself. The 18-month window after Drupal 9 launched gave institutions time to plan.
For institutions on Drupal 7, none of this was relevant. Drupal 7 to Drupal 8 (and from there to Drupal 9) was a re-platform. The new Drupal architecture, the Composer-based dependency management, the Twig theming layer, and the OOP module APIs were all different from D7. The migration tooling helped but did not eliminate the work.
The Right Path Depended On the Institution
The decision pattern that emerged across higher education and government Drupal deployments:
Institutions running Drupal 8 in early 2020: The right path was to maintain Drupal 8 currency (use the latest minor version), clean up deprecated code as flagged by Upgrade Status, and wait for Drupal 9's release to upgrade. The migration was relatively painless.
Institutions running Drupal 7 with significant custom code or themes: The right path was Drupal 7 to Drupal 8 first (using the Migrate API), then Drupal 8 to Drupal 9 later. Yes, this required two migrations, but the work was distributable across two project cycles rather than concentrated in one massive re-platform.
Institutions running simple Drupal 7 sites: Direct migration to Drupal 9 once it launched was viable. Without significant custom code or theme work, the destination version mattered less than the migration discipline.
Institutions facing budget or capacity constraints: Vendor Extended Support for Drupal 7 bought one to two years of additional runway. The migration was inevitable; the timing could be deferred.
What Played Out
The actual five-year arc, looking back from 2026:
- Drupal 7 EOL was extended twice (to November 2023, then to January 2025)
- Drupal 8 reached EOL on schedule in November 2021
- Drupal 9 reached EOL in November 2023 as Drupal 10 launched
- Drupal 10 launched in December 2022, with the smooth in-place D9-to-D10 upgrade pattern Drupal had targeted
- Drupal 11 launched in mid-2024
For institutions that took Path 2 (D7 to D8 to D9 to D10), the trajectory was a series of relatively smooth upgrades. For institutions that stayed on D7 through extended support and then migrated directly to a current Drupal version, the work was concentrated in one heavy project.
We covered the broader Drupal 7 EOL pattern specifically in Drupal 7 End of Life: Lessons From the Long Goodbye and the Drupal 10 upgrade tactical guide in Drupal 10 Upgrade Checklist.
What Future Drupal Version Decisions Should Consider
Institutions facing similar version-transition decisions should evaluate against the same dimensions:
- The complexity of existing custom code and themes (more complex = more migration work)
- The institutional capacity for migration work in the relevant year
- The compliance and audit cycle constraints (institutions under active FedRAMP or HECVAT review have less flexibility to defer)
- The dependency on contributed modules with uncertain compatibility
- The risk tolerance for running on extended-support paths
The institutions that operate Drupal upgrades well treat version transitions as standing operational work, not as one-time projects. We operate this discipline for managed Drupal hosting for government clients as part of the engagement model.
Frequently Asked Questions
Was the right answer in 2020 to skip Drupal 8 and wait for Drupal 9?
For institutions running Drupal 7 with substantial custom code, no. The Drupal 7 to Drupal 9 migration was equivalent in effort to Drupal 7 to Drupal 8. Skipping D8 saved no work; it just postponed it. For institutions with simple D7 sites, direct migration to D9 was viable.
How long should a Drupal upgrade take for an institutional site?
For Drupal 8 to 9 (or 9 to 10, 10 to 11) on a moderately complex site: four to twelve weeks of focused work. For Drupal 7 to current Drupal: three to nine months including planning, custom code porting, theme rebuild, content migration, and validation.
Does Vendor Extended Support cover the same security advisories as the Drupal Security Team?
Approximately. VES providers issue patches for Drupal 7 core and a defined list of contributed modules following the original Drupal Security Team patterns. For most institutional use cases, VES coverage is operationally sufficient. For workloads with strict compliance requirements, the audit cycle should validate that VES coverage satisfies the framework's requirements.
What is the typical cost of a Drupal version migration?
Variable depending on site complexity. For a mid-size institutional site, low to mid five figures for the migration project, plus ongoing operational cost for the new version's hosting and maintenance. Institutions running multiple sites or significant custom code can see migration costs into six figures.