We covered the strategic decision frame for Drupal 7 site owners in The Drupal 7 vs Drupal 8 vs Wait-for-Drupal 9 Decision. This post is about the tactical work once the decision was made: the actual tools and tactics that made Drupal 7 to Drupal 9 migration work for institutional sites.
The structural reality: Drupal 7 to Drupal 9 was a re-platform regardless of whether the destination version was D8 or D9. Three specific tools made the work tractable.
Tool 1: The Migrate API in Drupal Core
Drupal core ships a Migrate module suite specifically designed for migrating from Drupal 6 and Drupal 7 to current Drupal. The module handles the standard entity types that most institutional sites use: nodes, users, taxonomy terms, files, comments, and the field structures that organize them.
For institutional sites with content largely consisting of standard entities, the Migrate API does most of the heavy lifting. The migration is configured through YAML definitions, and the migration runs on the destination Drupal 9 site, pulling content from the source Drupal 7 database.
Where Migrate API does not cover the migration:
- Custom entity types defined by D7 modules
- Field collections (deprecated in favor of paragraphs in D8)
- Workflow states from contributed workflow modules
- Specific D7 module data structures that have no D8/D9 equivalent
For institutional sites with extensive custom content modeling, supplementary custom migrations were typically required. The Migrate API provided extension points for the custom work.
Tool 2: Upgrade Status
The Upgrade Status contributed module is the diagnostic tool. Run against a Drupal 7 site, it inventories contributed modules and reports their D8/D9 readiness status. Run against a Drupal 8 site (post-migration to D8), it reports deprecated code that needs cleanup before D9 upgrade.
For Drupal 7 sites preparing for migration, Upgrade Status was the work plan. The output told the institution which contributed modules had D9 versions ready, which had D9-compatible alternatives, which required custom work, and which had stalled maintenance and would need replacement.
For institutions with twenty or more contributed modules, this inventory typically surfaced 5 to 15 modules requiring active resolution. The institutions that ran Upgrade Status early captured the work in their planning timeline; the institutions that ran it late discovered surprises.
Tool 3: Drupal Module Upgrader
The Drupal Module Upgrader was a command-line tool that scanned Drupal 7 module source code and flagged code patterns requiring update for D8/D9. Where the conversions were mechanical (function name changes, hook signature changes), it could automate the conversion. Where the conversions required architectural change (D7 procedural code to D8/D9 OOP module structure), it flagged the work and pointed to relevant documentation.
For institutional sites with custom modules, the Drupal Module Upgrader was the starting point for porting the custom code. It did not eliminate the work but it dramatically reduced the effort of identifying what needed to change and where.
The Migration Process That Worked
For institutional Drupal 7 to Drupal 9 migrations, the process that produced durable outcomes:
Phase 1: Discovery. Run Upgrade Status against the Drupal 7 site. Inventory custom modules and themes. Document custom content models. Catalog integrations with campus systems.
Phase 2: Site goals review. Use the migration as an opportunity to review the site's purpose, content strategy, and editorial workflow. Content that should be archived gets archived rather than migrated.
Phase 3: Custom code port. Port custom modules using Drupal Module Upgrader output as the starting point. Rebuild custom themes for Drupal 9's Twig-based theming layer. Validate against the original functionality requirements.
Phase 4: Content migration. Configure Migrate API for the standard entity migration. Build custom migrations for non-standard entities. Run migrations against representative content in non-production. Validate migrated content against the source.
Phase 5: Integration validation. Test integrations with campus systems (SSO, student information systems, learning platforms). Re-establish API connections that depend on D7-specific patterns.
Phase 6: Editorial workflow re-establishment. Reconfigure approval workflows in D9. Train editorial teams on the D9 interface. Validate that the workflow produces the same outcomes as the D7 workflow.
Phase 7: Production cutover. Schedule the cutover with stakeholders. Document the rollback procedure. Run the cutover during a maintenance window. Validate post-cutover.
The total elapsed time for a moderately complex institutional site was typically three to nine months. Larger sites with more complex custom code took longer.
Direct D7-to-D9 vs D7-to-D8-to-D9
The question of whether to migrate directly to Drupal 9 or stage through Drupal 8 came up frequently in 2020 and 2021. The work was effectively equivalent. Migrating to D8 first meant doing the migration work once and then a smooth in-place upgrade later. Migrating directly to D9 consolidated the project. For institutions with the capacity to do the project in one cycle, direct D9 was operationally simpler. For institutions with capacity constraints that benefited from spreading the work, D8-then-D9 was the approach.
We covered the strategic decision frame in The Drupal 7 vs Drupal 8 vs Wait-for-Drupal 9 Decision and the broader Drupal 7 EOL pattern in Drupal 7 End of Life: Lessons From the Long Goodbye.
What This Pattern Set Up
The institutions that completed Drupal 7 to Drupal 9 migration in 2020 to 2022 captured the smooth upgrade path that Drupal 9 onward provided. Drupal 9 to 10 was an in-place upgrade. Drupal 10 to 11 followed the same pattern. The re-platform pain was a one-time investment in exchange for years of routine version upgrades after.
For managed Drupal hosting for government clients still on Drupal 7 today, the same migration pattern applies, with the destination being current Drupal (11 as of 2024) rather than Drupal 9. The tools and tactics carry forward.
Frequently Asked Questions
How long did Drupal 7 to Drupal 9 migration typically take for an institutional site?
For a moderately complex institutional site (50 to 200 pages of custom content, 10 to 20 contributed modules, custom theme), three to nine months. Sites with substantial custom modules or complex content models could take a year or more.
What was the typical cost of Drupal 7 to Drupal 9 migration?
Variable, but for a mid-size institutional site, low to mid five figures for the migration project, with larger or more complex sites running into low six figures. The cost was concentrated in custom code porting and theme rebuild rather than in content migration, which was largely automated by Migrate API.
Did Vendor Extended Support change the migration timeline?
Yes. Drupal 7 EOL was extended twice (eventually to January 2025), and Vendor Extended Support added additional runway. Institutions facing capacity constraints could defer the migration into the VES window. The migration was inevitable; the timing could be managed.
How does this pattern apply to current Drupal version transitions?
The structural pattern (Migrate API, Upgrade Status, deprecated code cleanup) is the same. The destination changes (Drupal 11 as of 2024 instead of Drupal 9). The tactical work has gotten easier as Drupal's release model matured. Institutions still on Drupal 7 today face the same fundamental work but with a longer migration path.