Part 2 of a series. Start with Part 1 if you haven’t already read it.
The first thing I do with any major Drupal upgrade is run Upgrade Status and read every line of the output. Not to fix things yet — just to understand the full scope of what’s in front of me. You can’t prioritize work you don’t know about, and upgrade reports have a way of surfacing problems you’ve been successfully ignoring for months.
For this project, I ran Upgrade Status across all four subsites: aircooled, careersinspanish, figueroa, and svloba. The reports were broadly consistent — they’re sharing a codebase, after all — but some subsites had theme-specific issues that others didn’t, and the pattern of what was flagged helped me understand where to focus first.
The headline findings fell into a few buckets:
Things that were fine: Most of the contrib modules I was running either already had Drupal 11 support or were in the process of getting it. Commerce, Webform, Pathauto, Redis, Views Bulk Operations — these all had D11-compatible releases available. The path forward was just updating version constraints in composer.json and letting Composer sort it out.
Things that needed investigation: A handful of older modules were less certain. imagefield_slideshow, slick, and drupal/blog all warranted a visit to their drupal.org project pages to check issue queues and release timelines before I could commit to a direction.
The theme: The single largest finding wasn’t a module at all. It was the base theme. All four of my custom subthemes extended drupal/bootstrap, which is the Bootstrap 3-based theme. It has not been updated for Drupal 11 and won’t be — the project has been superseded by drupal/bootstrap5, which is a separate package built on Bootstrap 5. This wasn’t a warning I could mark and move on from. It was a prerequisite for the entire upgrade.
I’ll cover the theme migration in depth in posts 3 and 4. For now, the important thing is that identifying it early meant I could plan around it rather than discover it mid-upgrade.
Phase 2: Infrastructure
Once I had the full picture from Phase 1, the next step was infrastructure — specifically getting the underlying PHP and database versions to where Drupal 11 needs them.
PHP was already handled. My local DDEV environment and my Platform.sh hosting were both running PHP 8.3, which exceeds Drupal 11’s minimum of 8.3. One composer.json constraint update (>=8.1 to >=8.3) and that was done.
MariaDB was a different story.
Drupal 11 requires MariaDB 10.6 or higher. My Platform.sh environment was running MariaDB 10.4. Platform.sh does not automatically migrate your data when you bump a major database version — you have to dump the database before the upgrade and restore it after. This is not a default Drupal upgrade task; it’s specific to how Platform.sh handles service version changes, and it’s easy to overlook.
There’s an additional wrinkle in this project’s architecture: all four subsites share a single database (hinchodb). They’re not running four separate databases — each subsite’s tables are prefixed with the site name (aircooled_, careersinspanish_, etc.), and they all live in one MariaDB database. This is less common than the “one database per site” model, and it has implications for how you do backups: you only need one dump, but that dump contains everything, so you need to be careful with it.
The sequence for the database upgrade:
- Dump the single shared database from Platform.sh before changing anything
- Download file mounts (uploaded files, private files) as a separate backup
- Update the MariaDB version in
.platform/services.yaml - Update the version in
.ddev/config.platformsh.yamlto match — this file is auto-generated by the Platform.sh DDEV integration and overrides.ddev/config.yaml, so both need to be in sync or DDEV will refuse to start with a version mismatch error - Deploy the service change to Platform.sh
- Re-import the database dump into the upgraded MariaDB instance
The actual deploy triggers Platform.sh to provision a new MariaDB 10.6 instance. Your data doesn’t automatically carry over — that’s what the dump and re-import is for.
Once the database was upgraded and the import confirmed successful, the infrastructure phase was complete. Both the local environment and production were running compatible versions of PHP and MariaDB. Everything from this point forward was about the application layer.
Expert Mode: Phase 1 and Phase 2 Commands
Phase 1 — Assessment
Install and run Upgrade Status:
ddev composer require drupal/upgrade_status --dev for site in aircooled careersinspanish figueroa svloba; do ddev drush --uri=$site en upgrade_status -y done
Then visit /admin/reports/upgrade-status on each subsite. Read the full output. Note everything flagged, especially anything in the “Must fix” category.
Check installed module versions:
ddev drush --uri=aircooled pm:list --format=table
Review contrib modules for D11 compat: For any module flagged as uncertain, visit https://www.drupal.org/project/{module_name} and look at: - Whether there’s a stable D11-compatible release - The issue queue for any open D11 compatibility issues - The project’s maintenance status
Phase 2 — Infrastructure
Update PHP constraint in composer.json:
"php": ">=8.3"
Verify PHP version in each environment:
# Local (DDEV) ddev php --version # Platform.sh platform ssh -- php --version
Back up the database before touching MariaDB (Platform.sh):
# Dump the single shared database platform db:dump --gzip --file=backups/hinchodb-pre-d11.sql.gz # Download file mounts platform mount:download --mount web/files --target backups/files platform mount:download --mount private --target backups/private
Update MariaDB version in .platform/services.yaml:
# Before db: type: mariadb:10.4 disk: 2048 # After db: type: mariadb:10.6 disk: 2048
Update .ddev/config.platformsh.yaml to match:
# This file is auto-generated — edit carefully database: type: mariadb version: "10.6"
Deploy the service change:
git add .platform/services.yaml .ddev/config.platformsh.yaml git commit -m "upgrade mariadb from 10.4 to 10.6 for drupal 11" git push platform master
Re-import the database after the service upgrade:
# On Platform.sh gunzip -c backups/hinchodb-pre-d11.sql.gz | platform db:sql # Verify all subsites are still intact for site in aircooled careersinspanish figueroa svloba; do platform drush --uri=$site status done
Restart DDEV after config change:
ddev restart # Verify DDEV is happy with the new MariaDB version ddev describe
With infrastructure done, you’re ready for the biggest phase of the upgrade: getting every module and theme compatible with Drupal 11 before you touch core. That’s where we’re headed next.
Read the next post - Fresh Modules, Tweak Free Themes