The Drupal 10 upgrade is not a feature-driven decision. The features matter, but they are not why institutions upgrade. Institutions upgrade because the cost of staying on Drupal 9, 8, or 7 compounds: security exposure increases, contrib ecosystem support shrinks, technical debt accumulates, and audit findings become unavoidable. This post is the institutional cost-of-inaction case for upgrading to Drupal 10.
We covered the prerelease context in Brace Yourself for the Drupal 10 Release, the upgrade matrix from any source version in Upgrade to Drupal 10 From Any Version, and the four-months-in lessons in Upgrade to Drupal 10: Lessons From Early Adoption. This post focuses on what happens to institutions that defer.
What Happens If the Upgrade Is Deferred
For institutional Drupal sites that did not upgrade by the supported window, the costs compound across several dimensions.
Security Exposure
Drupal 9 reached end-of-life on November 1, 2023. After that date, the Drupal Security Team stopped issuing security advisories for Drupal 9 core. Critical vulnerabilities discovered in shared code (which Drupal 9 and Drupal 10 substantially share) were patched in Drupal 10 only. Drupal 9 sites became vulnerable in real time.
For institutional sites under audit (FedRAMP Continuous Monitoring, NIST 800-53 control evaluation, internal IT audit), running an end-of-life CMS is an audit finding. The remediation is the upgrade. The audit finding does not go away by deferring further.
For Drupal 7, the situation is even sharper: end-of-life arrived January 5, 2025 after multiple extensions. Sites still on Drupal 7 today are running unsupported code. The Drupal 7 Extended Support program (commercial, vendor-provided) is a stopgap, not a permanent answer.
Contrib Ecosystem Erosion
Drupal contrib modules are maintained by the community. As Drupal 10 became the supported version, contrib maintainers focused effort on Drupal 10 compatibility. Drupal 9 versions of contrib modules stopped receiving updates. Bug fixes that landed in Drupal 10 versions did not back-port to Drupal 9.
For institutional Drupal sites that depend on niche contrib (specialized field types, integration modules with specific external services, legacy form builders), staying on Drupal 9 means depending on increasingly stale contrib code. The institutional consequence: bugs that the broader Drupal community has fixed remain in production for the deferring institution.
Hosting Platform Drift
Drupal 9 supports PHP 7.4 and PHP 8.0; Drupal 10 requires PHP 8.1 minimum. Hosting platforms have moved to PHP 8.1 and beyond. Institutional Drupal sites pinned to PHP 7.4 increasingly run on hosting that is itself end-of-life or unsupported. The hosting platform drift becomes the next audit finding.
Technical Debt Accumulation
Each Drupal major version that the institution skips increases the eventual upgrade cost. A Drupal 9 to Drupal 10 upgrade is routine. A Drupal 8 to Drupal 10 upgrade is two coordinated upgrades. A Drupal 7 to Drupal 10 upgrade is a rebuild. The longer the institution defers, the larger the eventual upgrade project.
Staff Knowledge Erosion
Drupal developers and Drupal-fluent operations staff move forward with the community. Staff with deep Drupal 7 expertise are increasingly rare; the developer market has moved to Drupal 9 and 10. Institutional Drupal that pins to old versions also pins itself to a shrinking pool of available expertise.
What the Institutional Upgrade Case Looks Like
For institutional decision-makers (CIOs, communications directors, IT directors), the Drupal 10 upgrade case is a risk-management case with a finite upgrade cost on one side and compounding costs on the other.
Upgrade cost. For sites on current Drupal 9 with maintained contrib: hours to days of effort. For sites on Drupal 8: weeks of effort. For sites on Drupal 7: months of effort, effectively a rebuild. The cost is finite and bounded.
Cost of inaction. Increasing security exposure, audit findings, contrib ecosystem erosion, hosting drift, technical debt accumulation, staff knowledge erosion. The cost is compounding and unbounded over time.
The decision frame. The question is not "should we upgrade." The question is "when should we upgrade, and what is the structured plan."
For institutions with budget cycles that prevent immediate execution, the right interim posture is documented planning: the upgrade is on the institutional roadmap, the budget is identified, the staff or vendor capacity is reserved, and the timeline is committed. A Drupal 10 upgrade scheduled for the next fiscal year is operationally different from a Drupal 10 upgrade that has not been planned.
What Institutions Get When They Upgrade
The features matter when the upgrade is happening. Drupal 10 brings:
Modern editorial experience. CKEditor 5 with a polished authoring surface, Claro administrative theme, Olivero front-end theme with WCAG 2.1 AA conformance out of the box. Institutional content authors notice the difference.
Security improvements. Drupal 10's reduced attack surface (removed deprecated code, modern dependencies) is a meaningful security posture improvement over Drupal 9 and especially over Drupal 7.
Performance improvements. PHP 8.1 alone produces measurable performance gains. Drupal 10's caching architecture refinements compound the PHP improvement.
Contrib ecosystem currency. Modules are actively maintained. Bug fixes land. New capability is available.
Forward path to Drupal 11. The Drupal 10 to Drupal 11 upgrade (Drupal 11 shipped in 2024) is operationally similar to the Drupal 9 to Drupal 10 upgrade. Institutions on Drupal 10 have the easier path forward; institutions still on older versions have the harder catchup.
For managed Drupal hosting engagements supporting government and higher-education Drupal workloads, the upgrade is a planned operational engagement. For institutions operating internally, the same planning discipline applies.
Frequently Asked Questions
Our institution is on Drupal 7 and the site has not been actively developed in years. Should we upgrade or replatform?
The Drupal 7 to Drupal 10 path is a rebuild. The same effort can also be used to migrate to a different platform. The decision depends on whether the institution has Drupal-specific reasons to stay on Drupal (multi-site infrastructure, custom contrib investments, staff expertise, content workflow). For institutions without those reasons, replatforming is sometimes the right answer; for institutions with those reasons, Drupal 10 is the right target.
Drupal 9 EOL was November 2023. Are sites still on Drupal 9 actually compromised?
"Compromised" is the wrong question; "exposed to known vulnerabilities" is the right one. Drupal 9 sites past EOL run code that is no longer receiving security patches. Whether a specific site has been exploited depends on the attack surface and whether attackers have targeted it. Audit and compliance frameworks treat unsupported software as a finding regardless of whether exploitation has occurred.
What is the typical institutional upgrade timeline?
For institutions on current Drupal 9: 3 to 6 months from decision to production, including planning, contrib audit, custom code review, theme remediation, staging validation, and production cutover. For Drupal 8: add 2 to 3 months for the Drupal 9 hop. For Drupal 7: 9 to 18 months for the rebuild.
Should institutions skip Drupal 10 and go directly to Drupal 11?
For Drupal 9 sites, the supported path is Drupal 9 to 10 to 11, executed as two separate upgrades. For Drupal 7 sites being rebuilt, building on the current Drupal version (11 at time of writing) is a valid option since the work is a rebuild regardless of target version.