Why PHP and database versions decide when a Drupal upgrade can start
The PHP runtime and database engine decide when a Drupal code upgrade can start, so the server stack has to be sequenced with the code, not treated as a separate maintenance task. A Drupal team on an older PHP or database host cannot move to Drupal 11 or Drupal 12 until the runtime underneath meets the minimum for the target release. Plan the server upgrade and the code upgrade as one schedule with shared checkpoints.
The supported path runs through each major version in turn. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, according to the Drupal PHP requirements page. No supported Drupal version runs on PHP 7, so a site still on PHP 7 must change its runtime before any current Drupal release is possible. The usual sequence is to reach Drupal 10 on a supported PHP version, move to Drupal 11, then move to Drupal 12. Drupal 10 reaches end of life on December 9, 2026, which sets the deadline for the first step on sites that have not yet moved.
Confirm three things before the first code change: the PHP version on every web node, including workers and command-line hosts that run Drush and cron, the database engine and version, and whether any contributed module or hosting control panel pins an older runtime. Ask your hosting provider or platform team to confirm the PHP and database versions they can deliver on the same date as the code branch. A server that is ready only for the current release leaves the next major upgrade to start again from the infrastructure.
What changes in PHP and database requirements
This table sets the PHP and database minimums for Drupal 11 and Drupal 12 side by side, with the impact on a typical current server and the action to take. Read each row against your existing versions: any cell where your server falls below the minimum is a blocker to fix before the code upgrade starts. Drupal 12 raises the bar on PHP and PostgreSQL, so servers that clear Drupal 11 may still need work.
| Component | Drupal 11 minimum | Drupal 12 minimum | Impact and action needed |
|---|---|---|---|
| PHP | PHP 8.3 or later | PHP 8.5 or later | Drupal 12 needs PHP 8.5. Confirm your current PHP version, then plan the PHP upgrade before the Drupal 12 code work. |
| MariaDB | MariaDB 10.6 or later | MariaDB 10.11 or later | Check your MariaDB version. Servers below 10.11 need an upgrade before Drupal 12 can run on them. |
| MySQL | MySQL 8.0 or later | MySQL 8.0 or later | No change in minimum. Confirm the version is supported and patched on your platform. |
| PostgreSQL | PostgreSQL 16 or later | PostgreSQL 18 or later | Drupal 12 needs PostgreSQL 18. Plan a major upgrade and confirm the pg_trgm extension is installed. |
| SQLite | SQLite 3.45 or later | SQLite 3.45 or later | No change in minimum. Typically relevant only to small or test sites. |
| PostgreSQL extension | pg_trgm required | pg_trgm required | Confirm with your DBA that pg_trgm is available and can be created in the Drupal database. |
| Web server | Apache, Nginx or other supported servers | Apache, Nginx or other supported servers | No change in support. Confirm your web server configuration works with the target PHP version. |
What to inventory and back up before touching the server stack
Server upgrades for Drupal 11 and 12 change the runtime under the code, so the rollback point and the facts about the current environment must exist first. The four to six items below are the work a team should complete before anyone edits a PHP version or database engine.
Full file and database backups
Take a complete backup of the Drupal codebase, the sites/default/files directory and a database dump, and confirm that the backup restores on a separate machine. A backup that has never been restored is not a rollback plan. Record the Drupal core version, the Composer lock file commit and the exact PHP and database versions in the same change record so the restore point is unambiguous.
PHP extension and module inventory
List every PHP extension the site loads and every contributed module that depends on one, such as GD, intl, mbstring or a database driver. Drupal 12 requires PHP 8.5 or later, so an extension missing from the new PHP build can block the upgrade even when the code is ready. Ask the hosting provider or platform team to confirm which extensions their PHP packages include.
Current database version audit
Record the exact database engine and version the site uses today, including MariaDB, MySQL or PostgreSQL, and any SQLite use outside development. Compare it against the minimums for Drupal 11 and Drupal 12, and confirm whether PostgreSQL has the pg_trgm extension available. Note which upgrades are minor and which cross a major version, because major database upgrades need their own rollback plan.
Staging that matches production
Build a staging environment with the same PHP minor version, database engine and version, web server and extensions as production before changing either one. Deploy a recent production database copy and files to it, and run the update path there first. Staging that uses a different PHP or database version proves nothing about production, so confirm the match in writing before any test is accepted.
Hosting capacity confirmation
Confirm that the target servers have the CPU, memory, disk and connection limits needed to run the new PHP and database versions alongside the current stack during cutover. Ask the platform owner for the current peak load, the connection limit and the maintenance window that the business accepts. Capacity for a parallel environment and a rollback window usually matters more than the steady-state size.
How PostgreSQL major upgrades fit a Drupal 12 plan
Drupal 12 requires PostgreSQL 18 or later, so any site that runs on PostgreSQL 14, 15, 16 or 17 needs a database major upgrade on the same plan as the code upgrade. Per the PostgreSQL versioning policy, supported versions are 18 through 14, and PostgreSQL 14 reaches end of life on November 12, 2026, which falls before Drupal 12 is scheduled for the week of December 7, 2026. Confirm the exact PostgreSQL version on every environment, including staging and the replicas, because a site can pass its Drupal 12 code review and still fail at the database layer if one tier lags behind.
PostgreSQL documents three major upgrade methods: dump and restore with pg_dumpall, pg_upgrade, and logical replication. Dump and restore is the simplest to reason about but usually means the longest write outage, since the database is unavailable while data is exported and reloaded. pg_upgrade rewrites the cluster in place and is faster on large databases, but it still requires a stop. Logical replication works across major versions and can shorten the cutover to several seconds of downtime, at the cost of more setup, replication monitoring and a sequence check before switching the application. Ask your team which downtime window the content editors and the Drupal cron schedule can tolerate, then pick the method that fits that window.
PostgreSQL 18 pg_upgrade keeps planner statistics across the upgrade, so the database does not start cold with missing statistics, and it adds parallel jobs and a --swap option that can shorten the window. Minor releases are different: they never change the storage format, so applying one only means replacing the executables and restarting. Schedule minor updates as routine maintenance and reserve the major upgrade for a rehearsed change window. Run the full Drupal test suite and a restored copy of production data against the target version before the cutover, and keep a tested backup or point-in-time recovery path ready in case the rollback is needed.
How to sequence server upgrades with the Drupal code upgrade
The sequence rehearses the PHP and database changes in a staging copy, upgrades the Drupal code against them, and promotes both together only after each check passes. A rollback point before each change keeps every step reversible.
Take a rollback point and snapshot production
Before any change, the owner of the platform takes a full database backup, a copy of the code tree with its Composer lock file, and a snapshot of the web server and PHP configuration. Someone other than the person who took the backup restores it to a scratch host and confirms that the site loads and that row counts and recent content match production. The step is done when the restore test passes and the backup set is labeled with the Git commit and date it represents.
Build a staging copy with the target stack
The infrastructure team clones production into a staging environment that matches its topology, including the web server, PHP-FPM pool, and database engine. They then install the target PHP version (8.3 for Drupal 11, 8.5 for Drupal 12) and the target database version from the supported list, keeping the production database engine in place until the test is complete. The step closes when Drupal's status report shows the new PHP and database versions with no errors, and the site runs on the copied data.
Upgrade the database engine in staging
On the staging database, the team applies the database change using the method the engine documents, such as a logical dump and restore or an in-place major upgrade with its own tooling. For PostgreSQL, the pg_trgm extension must be present on the target server, and the team confirms it with a query before Drupal connects. The step is complete when the database reports the target version, all Drupal tables are readable, and a second backup taken from the upgraded instance restores cleanly.
Run the Drupal code upgrade against the new stack
With the staging server and database in their target versions, the developer applies the code changes, including core, contributed modules, and custom code fixes identified in the readiness audit. Updates run through Composer, the lock file is committed, and database updates are executed with Drush so schema changes are recorded. The step is complete when
drush updatedbfinishes without errors and the codebase installs from the lock file on a clean checkout.Verify with status report and Upgrade Status
The QA lead runs the Drupal status report and Upgrade Status on the staged site, and records any remaining deprecation warnings in custom code. Automated tests, smoke tests of login, content editing, search, and forms, and checks of integrations such as SSO and payment callbacks run against the staging environment. The step closes when the status report shows no errors, the remaining Upgrade Status items are either fixed or accepted in writing, and the test results are attached to the change record.
Rehearse the rollback before promotion
The team tests the rollback path on staging by restoring the pre-change backup to a separate host and confirming that the old PHP, database, and code tag bring the site back. The operations lead confirms who can authorize a rollback and how long the change window is in the approved plan. The step is done when the rollback has been run once on a copy and its result is documented.
Promote the server and code changes together
During the approved change window, the team takes a fresh backup of production, then moves the database and PHP changes and the code release to production in a single controlled sequence. The site is put in maintenance mode while database updates run, and the team checks the status report, logs, and critical user journeys before lifting it. The step closes when production passes the same checks used in staging and the rollback point is retained until the owners sign off.
Confirm stability and retire the old stack
After promotion, the operations team watches error logs, database performance, and PHP-FPM health for a period agreed with the client, and confirms that scheduled cron and queue jobs run on the new versions. Old PHP and database packages are removed only after the sign-off, and the change record is updated with final versions. The step is complete when the owners accept the production state in writing and the rollback point is archived according to the client's retention policy.
Choosing a database and PHP path for your estate
Staying on MariaDB or MySQL is the smallest change when your team already runs these engines well. Drupal 11 requires MariaDB 10.6 or later or MySQL 8.0 or later, and Drupal 12 requires MariaDB 10.11 or later or MySQL 8.0 or later. If you run MariaDB, the Drupal 12 gate is the one that moves, so a version step may be needed before the Drupal 12 code upgrade. Confirm the exact database version your hosting platform provides, not only the version your team installed in a lab.
- Version floor: Check the MariaDB or MySQL build in each environment, including staging and the backup restore target.
- Character set and collation: Confirm the utf8mb4 settings your existing tables use before you change the server.
- Drupal settings: The database driver and connection values in
settings.phpusually stay the same when the server is only patched. - Sequencing: Upgrade the database server in a lower environment first, then run the Drupal code upgrade against it.
- Rollback: Keep a tested dump taken before the server change.
Ask your hosting provider which MariaDB or MySQL versions they offer and when they schedule server upgrades, since these may not match your code upgrade window.
Moving to PostgreSQL is a larger project because it changes the database engine, not only its version. Drupal 11 requires PostgreSQL 16 or later and Drupal 12 requires PostgreSQL 18 or later, and PostgreSQL needs the pg_trgm extension enabled. PostgreSQL is released under the PostgreSQL License, a liberal open source license similar to the BSD or MIT licenses, so there is no license fee for the server. Its high availability and automatic failover need external tools, because PostgreSQL does not detect a failed primary and promote a standby on its own.
- Engine change: Plan a data migration with schema and content verification, not a simple dump import.
- Extensions: Confirm that
pg_trgmcan be installed in your managed or self-hosted cluster. - Version support: PostgreSQL 16 is listed as supported until November 9, 2028, and PostgreSQL 18 until November 14, 2030, per the PostgreSQL versioning policy.
- Failover: Select and test an external tool for detection and promotion, plus a connection pooler such as PgBouncer if needed.
- Backups: Test point-in-time recovery before cutover.
Confirm with your team which PostgreSQL version you will run on the Drupal 12 timeline, because it affects when the engine move should happen.
Containers and managed hosting split responsibility between your team and the provider. The image, the PHP runtime and the database service are often fixed by a platform team or a hosting contract, so the version you need may not be the default. Drupal supports Apache, Nginx and other web servers, and PHP 8.3 or later is required for Drupal 11, PHP 8.5 or later for Drupal 12. Many managed platforms lag behind the newest PHP and database releases, so check this before the upgrade plan is fixed.
- PHP image: Confirm the PHP version in your base image and whether the provider can rebuild it on the required release.
- Database service: Check the engine and version offered by the managed database and whether it includes the
pg_trgmextension for PostgreSQL. - Maintenance windows: Ask when the provider applies its own server patches and whether they can be pinned or deferred.
- Configuration: Keep the database host, port and credentials in environment variables or a secrets store, not in code.
- Pipeline: Build the image in CI so that the PHP version and the Drupal code change together in one tested release.
Ask the provider in writing for the supported PHP and database versions, the upgrade schedule and the process for requesting an earlier version change.
What makes server upgrades take longer
This table lists the factors that stretch server-side work for a Drupal 11 or 12 upgrade, with the direction each one pushes cost or duration and what to request in a quote. Read it before you ask for a fixed-scope proposal, because most of these drivers are visible in your inventory before any work starts.
| Driver | Why it changes effort | What to ask for in a quote |
|---|---|---|
| Number of sites and environments | Each site, multisite domain and environment (dev, staging, production) needs its own PHP and database cutover, testing and rollback path. | Per-environment breakdown of PHP, database and web server changes, and whether multisite sites share one database cluster. |
| Custom PHP extensions | Extensions compiled for an older PHP version must be rebuilt or replaced for PHP 8.3 (Drupal 11) or PHP 8.5 (Drupal 12), and each build needs testing on the target image. | A list of extensions, who builds them, and the test evidence expected before cutover. |
| PostgreSQL migration versus in-place minor updates | Minor releases replace executables and restart the server, which is usually quick. A major version change needs a dump and restore, pg_upgrade, or logical replication, which adds planning, rehearsal and rollback work. | Whether the proposal covers a minor update only or a major move, and the method, rehearsal count and rollback plan for each. |
| Database size and write volume | Larger databases lengthen dumps, restores and replication catch-up. Heavy write traffic makes a cutover window harder to hold. | The database size and growth rate used for planning, and how downtime is measured in the proposal. |
| Replication topology and high availability | Hot standbys, synchronous replication and external failover tooling each need configuration, testing of failover and changes to the upgrade order across nodes. | Which nodes are upgraded first, how replicas are re-synced, and how failover is tested after the upgrade. |
| Connection pooling and proxies | A pooler such as PgBouncer must be checked against the new PostgreSQL version and the Drupal connection settings. | Whether pooler configuration and load tests are in scope. |
| Contributed modules pinned to older PHP | Modules that still require an older PHP version block the PHP upgrade until they are updated, replaced or forked, which can pull code work into the infrastructure schedule. | A module-by-module compatibility list and the owner of any fork or replacement. |
| Authentication method changes | Moving to SCRAM or certificate, LDAP or OAuth-based login changes client configuration in Drupal, proxies and admin tooling. | Which client tools and connection strings change, and who tests them. |
Questions teams ask before upgrading PHP and the database
What PHP and database versions does Drupal 11 require?
Drupal 11 requires PHP 8.3 or later. On the database side, it requires MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later, or SQLite 3.45 or later. These minimums come from the Drupal.org PHP and database requirements pages, so confirm them against the release you plan to install before you lock versions. Drupal runs on Apache, Nginx and other web servers, so the web server choice is yours, provided it can run the required PHP version. If your current stack sits below these minimums, the infrastructure work comes before the code upgrade, not after.
What does Drupal 12 change for PHP and the database?
Drupal 12 requires PHP 8.5 or later, and it raises the database minimums to MariaDB 10.11 or later and PostgreSQL 18 or later. MySQL 8.0 and SQLite 3.45 remain at the same minimums. Drupal 12 is scheduled for the week of December 7, 2026, according to the Drupal core release schedule. Because PHP and database versions move on separate tracks, a site on Drupal 11 may need to upgrade PHP and PostgreSQL before it can run Drupal 12 at all. Check both the PHP and database requirements early in your readiness plan.
Can we upgrade PHP and the database before the Drupal code?
In most cases, yes, and it is often the safer sequence. Upgrading PHP and the database first lets you test the current Drupal version on a newer runtime, which isolates infrastructure faults from application faults. Check that your current Drupal version supports the new PHP version before you switch. For PostgreSQL, upgrade the server in a planned window using pg_upgrade, a dump and restore, or logical replication. Logical replication can shorten downtime to several seconds, according to the PostgreSQL upgrading documentation. Confirm each step in a staging copy that matches production data volume.
What drives the cost and duration of a PHP and database upgrade?
The main drivers are how many environments you run, how far below the minimums your stack sits, and how many services depend on the database. Costs split into planning and inventory, staging rebuilds, testing across the application and contributed modules, the production change window, and post-change monitoring. Costs are mostly one-time, while patch support for PHP and PostgreSQL recurs. PostgreSQL supports each major version for 5 years after release, so the support calendar shapes how often you repeat this work. Ask any quote to list each environment, each database cluster and the rollback test separately.
What must our team provide before an upgrade engagement starts?
You need to provide access and information the work depends on. Typical items include an inventory of hosts, PHP versions, database versions and extensions; read access to current configuration; a staging environment that can be rebuilt; a copy of recent production data for testing; and a named owner for change approval. For PostgreSQL, the team should also provide the list of extensions in use, including pg_trgm, which Drupal requires. Confirm which backup and restore tooling your environment already uses, because rollback planning depends on it. DeployOpen works inside your own infrastructure, so access to your cloud accounts or data center systems must be agreed in writing.
Can our internal team do this upgrade without a partner?
Yes, a capable internal team can do this work, and many do. The deciding factors are whether you have people who have run the PHP runtime, the database engine and the Drupal deployment pipeline in production, and whether they can take time away from current work. The hardest part is usually not the commands but the testing: confirming that contributed modules, cron jobs, search indexes and integrations behave the same on the new versions. Decide early whether you need outside help for the test plan, the rollback rehearsal or the change window, and ask any partner to state which of these parts they will cover.
How does rollback work if the PHP or database upgrade fails?
Rollback depends on the component. For PHP, rollback usually means switching the web tier back to the previous runtime, which only works if the old package remains installed and the application still runs on it. For PostgreSQL, a minor release replaces executables and restarts, and it never changes the storage format, so rollback is a binary swap. A major upgrade is harder: pg_upgrade changes the data directory, so you must keep a verified backup or a standby on the old version. Continuous archiving and point-in-time recovery give you a restore path to a chosen moment. Rehearse the rollback in staging before the change window, and record the time it takes.
How DeployOpen scopes and delivers Drupal server upgrades
DeployOpen treats the PHP and database versions as part of the upgrade plan, not a separate task. We scope the server changes in writing alongside the Drupal code work, then build and verify them in infrastructure you control, so the runtime and the code move through each stage together.
How we scope
- Written scope lists the current PHP and database versions, the target Drupal version and each server component to change.
- Scope records the web server, container or VM layout and every environment that must match production.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We stand up target PHP and database versions in non-production environments that mirror your production configuration.
- We check PostgreSQL extensions such as pg_trgm and confirm the Drupal database settings before any code upgrade runs.
- We sequence the server change and the code upgrade so each environment has one moving part at a time.
How we hand over
- Handover includes a runbook for the PHP and database change, with rollback steps and a verified backup before each cutover.
- We document the version matrix, configuration files and extension list so your team can reproduce the build.
- Your team receives test evidence from each environment, covering the Drupal status checks and database connectivity results.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover tracking of PHP and database support windows and planning for the next server change.
- Confirm with DeployOpen during scoping which support terms, response expectations and reporting your organization needs.
