Higher education
A university faculty jumps from Drupal 9 to 11 between two semesters
An unpatched Drupal 9 faculty site with a live course catalogue integration reached Drupal 11 in three weeks, in the gap between exams and term.
- Sector
- Higher education
- Scale
- 1 site, 4,200 pages, 12 editors, 380 courses synced nightly
- Migration
- Drupal 9 to Drupal 11
The situation
The faculty site was built on Drupal 8 in 2019, upgraded to Drupal 9 in 2021, and then left alone. Drupal 9 reached end of life in November 2023, so the site had gone more than eighteen months without a security update when the university's IT security office flagged it.
The site matters more than a typical faculty site because it carries the course catalogue. Around 380 course records are pulled nightly from the university's central student information system over a SOAP endpoint, and prospective students use the faculty pages more than the university's own catalogue. The faculty wanted to go straight to Drupal 11 rather than land on Drupal 10 and face its December 2026 end of life within a year. The work had to fit between the end of summer exams and the start of the autumn semester.
What we found in the assessment
Upgrade Status on a production copy listed 34 contributed modules, 6 without a Drupal 11 compatible release, and a custom course sync module of about 4,000 lines that had never been checked for deprecations. The server ran PHP 8.0.
Composer had been used once and then abandoned in favour of copying module folders by hand, so the lock file no longer described what was installed. Configuration had never been exported. The theme was a Bootstrap 3 subtheme with jQuery plugins driving the course filter.
The decisions
We ran both hops as one project: Drupal 9 to 10 on a working branch, then 10 to 11 on the same branch, with a single launch. That avoided a second round of regression testing on the course sync.
The custom sync module was worth keeping. Drupal Rector handled most of the deprecations, and we fixed the rest by hand, mostly the entity query access flag and a few removed jQuery helpers. Of the six incompatible modules, Colorbox became core Media with a small lightbox library, Webform moved to its 6.3 line, a patched Views Data Export was dropped for core's CSV serializer, and three admin helpers were simply removed.
We chose not to redesign. The budget was for the upgrade, so the Bootstrap 3 theme was rebuilt as a Starterkit subtheme with the same layout and the same class names, which meant editors saw no visible change on launch day.
How the move ran
Week one rebuilt the install as a proper Composer project and exported all configuration, so every later step was reproducible from git. Week two was the upgrade itself: 9.5 to 10.4, then 10.4 to 11.1, with PHP moved to 8.3 in between.
The course sync ran against the staging system every night for the whole period. Each morning we compared the 380 course records with the previous night's output and with production, field by field. Week three was regression testing with two faculty editors and a crawl of every course URL printed in the previous year's prospectus, since printed URLs cannot change.
Launch was a Friday evening in late August. Downtime was 25 minutes for the database updates and the configuration import.
After launch
Median server response time fell by roughly a third, mostly from PHP 8.3 and from replacing the jQuery course filter with a Views exposed form using AJAX. The faculty now has a monthly support retainer: minor releases are applied within the month and security releases within 48 hours. The next major upgrade will be a Composer update rather than a rescue.
A similar site?
Send us the URL. Within one working day you get a free initial review of whether a similar move makes sense for your site, and what a five-day assessment would cost.