Drupal 8 reached end of life on November 2, 2021. The Drupal Security Team stopped issuing advisories for Drupal 8 core after that date. For institutions on Drupal 8, this set a deadline: upgrade to Drupal 9 by EOL or accept running an unpatched version.
The migration was structurally an in-place upgrade rather than a re-platform. We covered what Drupal 9 actually changed in What Drupal 9 Actually Changed and the strategic decision in The Drupal 7 vs Drupal 8 vs Wait-for-Drupal 9 Decision. This post is the tactical playbook for the actual D8 to D9 migration as institutions executed it.
Why Drupal 8 to 9 Was Different from Drupal 7 to 9
Drupal 7 to Drupal 9 was a re-platform: different module API, different theming layer, different dependency management. The work was substantial.
Drupal 8 to Drupal 9 was a deliberate cleanup release. The Drupal team designed D9 to be Drupal 8 with the deprecated code removed and underlying dependencies refreshed. Module APIs stayed the same. Themes stayed compatible. Editorial workflow stayed the same. Custom code that did not depend on deprecated functions worked unchanged.
For institutions on Drupal 8 with reasonable custom code hygiene, the upgrade was the lightest major-version transition Drupal had ever offered. The institutions that fell behind on Drupal 8 minor releases or accumulated technical debt found the upgrade harder; the institutions that stayed current found it routine.
The Four-Step Migration Process
The actual upgrade process for Drupal 8 to Drupal 9:
Step 1: Validate Hosting Environment Compatibility
Drupal 9 had specific platform requirements: PHP 7.3 or later (recommended PHP 7.4), MySQL 5.7.8 or higher, MariaDB 10.3.7+, or PostgreSQL 10+, Composer 1.9.1 or later, and Drush 10 if Drush was used.
For institutions running compatible hosting environments, this step was a confirmation. For institutions on older PHP or older database versions, hosting infrastructure had to be updated first. We saw this most often as a coordinated change to PHP runtime alongside the Drupal upgrade.
Step 2: Update to the Latest Drupal 8 Minor Version
Drupal 8.9 was the LTS minor release that Drupal 9 was designed to migrate from. Sites running older Drupal 8 minor versions had to update first. The minor version updates were routine but had to happen in the right order: 8.x to 8.9 first, then 8.9 to 9.0.
For institutions that had stayed current with minor releases, this was already done. For institutions that had fallen behind, the work was a series of incremental updates with regression testing at each step.
Step 3: Update Themes and Custom Code for Drupal 8.9 Compatibility
The Drupal Twig template engine had updated from Twig 1 to Twig 2 in the Drupal 9 transition. Themes using deprecated Twig 1 patterns needed update. Custom modules using deprecated functions needed cleanup.
The Upgrade Status contributed module surfaced what needed change. Drupal-Rector automated mechanical conversions where possible. Manual code review handled the rest.
For institutional sites with custom themes or several custom modules, this step was typically the longest. For sites mostly using contributed modules and a slightly-customized standard theme, the work was usually lighter.
Step 4: Run the Drupal 9 Upgrade
With the previous steps complete, the actual upgrade was a Composer command sequence: update Drupal core to 9.0, run database updates via Drush, validate site behavior. For institutions with mature deployment automation, this was a scripted maintenance window typically under an hour.
Post-upgrade validation: editorial workflow, integrations with campus systems, content rendering, performance under representative load. Documented evidence of the validation became part of the change management record.
What Made D8 to D9 Migration Hard
For most institutions, the migration was not hard. The institutions where it was harder typically had one or more of:
Drupal 8 minor version drift. Sites running 8.5 or earlier had to update through several minor versions before reaching 8.9. Each minor version update could surface unexpected issues with custom code or contributed modules.
Custom code accumulation. Institutions that had been adding custom modules over years had more deprecated code to clean up. The Upgrade Status report could surface dozens or hundreds of items in heavy customization scenarios.
Contributed modules without active maintenance. A small number of contributed modules in any institutional installation typically had stalled maintenance. These required forking, vendoring internally, or replacement. Identifying these early was the discipline that prevented late-stage surprises.
Custom themes built on deprecated Twig patterns. Themes with substantial Twig customization needed pattern updates. Themes using mostly templates inherited from the parent theme with light customization were easier.
For managed Drupal hosting for government clients, we typically completed D8 to D9 migrations within four to eight weeks of focused work for moderately complex sites. The same template applies to current Drupal version transitions.
What This Pattern Established
Drupal 9 deliberately set the template for future major-version upgrades. Drupal 9 to 10 (December 2022) followed the same pattern: cleanup release, dependency refresh, smooth in-place upgrade for sites that stayed current. Drupal 10 to 11 (mid-2024) followed it again.
Institutions that captured the D8 to D9 upgrade pattern operationally were positioned to handle subsequent upgrades as routine work rather than as quarterly projects. The institutions that handled D8 to D9 as a special project typically had to repeat the pattern for D9 to D10.
We covered the broader Drupal version-transition operational pattern in Drupal 9 Readiness Checklist and the Drupal 10 specifics in Drupal 10 Upgrade Checklist.
Frequently Asked Questions
How long did Drupal 8 to Drupal 9 migration take for an institutional site?
For a moderately complex site, four to eight weeks of focused work. For sites mostly using current Drupal 8 minor releases with reasonable custom code hygiene, less. For sites with significant minor-version lag or substantial custom modules, longer.
Was Drupal 8 EOL on November 2, 2021 a hard deadline?
Effectively yes for compliance-sensitive workloads. After EOL, the Drupal Security Team stopped issuing advisories for D8 core. Sites running unpatched D8 produced compliance findings and active risk. Some institutions extended runway through delayed upgrade work but typically did so with explicit risk acknowledgment.
What is the relationship between Drupal 8 to 9 migration and the underlying hosting environment?
The hosting environment had to support Drupal 9's platform requirements (PHP, database versions, Composer). For institutions running on managed hosting, the host typically handled this. For institutions self-managing on AWS or Azure, the hosting environment changes coordinated with the application upgrade.
Does the same upgrade pattern apply to Drupal 9 to 10 and Drupal 10 to 11?
Yes. The structural pattern (compatible hosting, latest minor version of source, deprecated code cleanup, in-place upgrade) is the template Drupal established with D9 and continued with subsequent versions. The tools (Upgrade Status, Drupal-Rector) work for each transition.