Drupal 9 launched on June 3, 2020 as a deliberate design choice: not a major architectural change from Drupal 8, but a cleanup release that removed deprecated code and refreshed dependencies. We covered what that actually meant in What Drupal 9 Actually Changed and the strategic decision frame in The Drupal 7 vs Drupal 8 vs Wait-for-Drupal 9 Decision.
This post is the tactical readiness checklist for institutional Drupal sites preparing the actual upgrade. Written for Drupal 8 site owners who need to upgrade to Drupal 9 within the 18-month window after launch, and Drupal 7 site owners who need to plan a longer migration.
Checklist for Drupal 8 Site Owners
For institutions on Drupal 8, the upgrade to Drupal 9 was structurally a routine in-place upgrade. The readiness work was the part that determined how routine it actually was.
1. Audit Site Goals and Editorial Workflow
Before touching the codebase, review the site's purpose, content strategy, and editorial workflow with the people who use it. Major version upgrades are good windows for institutional review. Content that should be archived, sections that should be retired, workflow patterns that should be reconsidered all surface during this audit.
For institutional sites, this audit typically pulls in marketing, communications, IT, and the section owners who publish day-to-day. The audit is not the upgrade work; it is the input that shapes the upgrade scope.
2. Inventory Contributed Modules
Run drush pm-list or use the admin interface to inventory contributed modules. For each module, check the project page on Drupal.org for Drupal 9 compatibility status. Categorize the modules:
- Compatible modules with Drupal 9 releases
- Modules flagged Drupal 9-compatible (single codebase working on D8 and D9)
- Modules without Drupal 9 status, with active maintenance (likely to be ready by upgrade time)
- Modules without Drupal 9 status, with stalled maintenance (need replacement, fork, or removal)
The fourth category is where institutional upgrade timelines slip. Identify these early so the resolution work can happen in parallel with other readiness tasks.
3. Update to the Latest Drupal 8 Minor Version
Drupal 9 expects the source site to be on Drupal 8.9 (the LTS version). Sites running older minor versions need to update first. The minor version updates are routine but should be done in non-production environments with regression testing.
4. Run Upgrade Status
The Upgrade Status contributed module scans the site for deprecated code, deprecated module usage, and Drupal 9 compatibility issues across core, contributed modules, and custom code. The output is the work plan for cleanup.
For institutional sites with custom modules, custom themes, or installation profiles, Upgrade Status output typically identifies a meaningful list of cleanup items. The fixes are typically straightforward (replace deprecated function calls with their current equivalents) but the count adds up.
5. Remediate Deprecated Code
Use Drupal-Rector for automated cleanup of common deprecated patterns. For more complex deprecations, manual code review and update. The work is not exotic but it is detail-oriented.
For institutional sites with multiple custom modules, this phase typically takes one to four weeks of focused developer time depending on the size of the custom codebase.
6. Validate in Non-Production
Run the actual upgrade in a non-production environment that matches production configuration. Test editorial workflows, integration points, performance under representative load, and the specific functionality the institution's users depend on.
For institutional sites under audit, document the validation activities. The validation evidence becomes part of the change management record for the upgrade.
7. Schedule Production Cutover
Coordinate the production upgrade window with stakeholders. For sites with significant traffic patterns (enrollment cycles, election cycles, fiscal year-end), schedule outside the high-traffic windows. Document the rollback plan in case the upgrade encounters unexpected issues.
The production upgrade itself is typically a brief maintenance window (under an hour for most institutional sites). The validation that follows the upgrade is the longer work.
Checklist for Drupal 7 Site Owners
For institutions on Drupal 7, the path to Drupal 9 was different. Drupal 7 to Drupal 9 was a re-platform, not an upgrade. The readiness work reflected that.
The recommended path: Drupal 7 to Drupal 8, then Drupal 8 to Drupal 9. Two migrations, distributable across two project cycles. Direct Drupal 7 to Drupal 9 was viable for simple sites but the work was equivalent to D7 to D8 plus D8 to D9 combined.
The readiness work for D7 to D8 (which then becomes the starting point for D8 to D9):
- Site audit and content strategy review
- Inventory custom modules and themes; plan their D8 reconstruction
- Run Migrate API in non-production with current D7 content; validate the migration outcome
- Rebuild custom modules and themes for D8
- Validate the D8 site against the original requirements and editorial workflow
- Schedule the production cutover with documented rollback
This was a project, typically three to nine months of focused work for institutional sites. The Drupal 7 to Drupal 9 path was not faster than D7 to D8 to D9; it just consolidated the project.
What Made Drupal 9 Readiness Different from Earlier Drupal Upgrades
Compared to Drupal 7 to Drupal 8 (which had been a re-platform), Drupal 8 to Drupal 9 was structurally simpler. The readiness work was real but bounded. The pattern Drupal 9 established (clean in-place upgrade from previous version's last minor release) has held for Drupal 10 and Drupal 11.
For institutions on the current version, staying current with minor releases means major version upgrades become scheduled maintenance work. For managed Drupal hosting for government clients, this is the operational pattern: minor version currency is part of routine operations, major version upgrades are planned events with predictable scope.
We covered the actual Drupal 7 EOL trajectory in Drupal 7 End of Life: Lessons From the Long Goodbye and the Drupal 10 upgrade tactical guide in Drupal 10 Upgrade Checklist.
Frequently Asked Questions
How long does Drupal 8 to Drupal 9 readiness work typically take?
For a moderately complex institutional site (50 to 200 pages of custom content, 10 to 20 contributed modules, custom theme), one to four weeks of focused readiness work plus the actual upgrade window. Sites with larger custom code bases or more complex contributed module dependencies can take longer.
What is the role of Upgrade Status in the readiness process?
Upgrade Status is the diagnostic tool that surfaces what needs cleanup before the upgrade. Run it early in the readiness process, treat its output as the work plan, re-run it as cleanup completes to validate progress.
How does the institution document Drupal upgrade work for compliance?
Change management records covering the upgrade plan, validation evidence from non-production testing, rollback procedure documentation, and post-cutover validation. For sites under FedRAMP, HECVAT, or HIPAA review, the upgrade is a system change that triggers documented change management.
What is the readiness pattern for Drupal 10 and Drupal 11?
Same structural pattern. Stay current with the previous version's minor releases, run Upgrade Status, remediate flagged deprecations, validate in non-production, schedule production cutover. The Drupal 9 readiness checklist is a template that has held for subsequent major versions.