Planning your Drupal 10 to Drupal 12 upgrade before end of life
A team still running Drupal 10 in late 2026 has to pass through Drupal 11 before it reaches Drupal 12, and the plan for that route must be agreed before Drupal 10 reaches end of life on December 9, 2026. The core release schedule places Drupal 12.0.0 and 11.5.0 in the week of December 7, 2026, and it also ends security support for 10.6.x and 11.3.x at that point. A site that waits for Drupal 12 to appear has already missed the window, because the stop on Drupal 11 is where most of the work sits. Drupal 10.6.0 is the last minor release of Drupal 10, so the first decision is which Drupal 11 minor line the site will land on and how quickly it will follow the releases after that.
Planning starts with the Drupal 11 stop because each step has different gating requirements. Drupal 11 requires PHP 8.3 or later, while Drupal 12 requires PHP 8.5 or later, so the server and container images need a PHP plan that covers both moves. Contributed modules are the other gate: each one needs a release that supports the target core line, and the team should confirm that status on each project page before estimating work. Deprecated API use in custom modules and themes is checked with Upgrade Status and fixed with Drupal Rector, and the output of those checks is the best input for a budget. Ask any partner for a written scope that lists the modules, themes and integrations covered, the environments involved and the test evidence expected at each stop.
What changes between Drupal 10, 11 and 12
This table compares Drupal 10, 11 and 12 across the requirements and release events that gate an upgrade, with the impact of each change and the action to take. Read each row as a checkpoint: confirm the requirement in your environment, then sequence the work so the site stops on Drupal 11 before Drupal 12 arrives. The main takeaway is that PHP, contributed modules and deprecated code, not the core upgrade itself, usually set the pace.
| Change | Impact on your site | Action to plan |
|---|---|---|
| PHP minimum | Drupal 10 needs PHP 8.1 or later, Drupal 11 needs 8.3 or later, and Drupal 12 needs 8.5 or later | Confirm the PHP version on every web node and CLI host, and plan the server upgrade before the code upgrade |
| Drupal 10 end of life | Drupal 10 reaches end of life on December 9, 2026 | Set a go-live target on Drupal 11 well before this date and confirm the support window with your own risk team |
| December 2026 release week | Drupal 12.0.0 and 11.5.0 are scheduled for the week of December 7, 2026, ending security support for 11.3.x and 10.6.x | Watch the core release schedule and plan a staging test against the release candidates as they appear |
| Bugfix and security cadence | Bugfix releases land on the first Wednesday of each month and security releases on the third Wednesday | Build a fixed patch calendar and a staging rehearsal that fits these release days |
| Contributed module compatibility | Some modules lag core. For example, samlauth 8.x-3.14 supports Drupal 10.3 and later and Drupal 11, so check each module's stated core range | Inventory every contributed module and confirm a release that supports Drupal 11 and, when available, Drupal 12 |
| Deprecated API use | Code that worked on Drupal 10 may use APIs deprecated in 11 or 12 | Run Upgrade Status on custom modules and themes, then plan the fixes with Drupal Rector and manual review |
| Removed core modules and themes | Modules and themes that left core need a contributed replacement or a redesign | List every core module and theme in use and confirm the replacement path before the build starts |
Why Drupal 10 cannot jump straight to Drupal 12
Drupal 12 is a major version, and Drupal core upgrades move one major version at a time. A Drupal 10 site therefore has to pass through Drupal 11 before it can reach Drupal 12. Each major version brings deprecated APIs removed and new requirements, so the intermediate step is where custom code, themes and contributed modules are fixed against a version that still resembles the one they were built for. Skipping that step means fixing two sets of changes at once, with fewer reference points when something breaks.
- Sequencing: Drupal 11 is the stop that lets you separate code changes from the PHP and database changes that Drupal 12 introduces.
- PHP gate: Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, so the server stack moves in two steps.
- Module readiness: Contributed modules must have a release for Drupal 11 before you can run the site on it, and that is the first check to make.
- Release timing: Drupal 12.0.0 and 11.5.0 are scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026.
- Rollback points: A completed Drupal 11 stage gives you a tested, supported state to return to if the Drupal 12 step fails.
Confirm with your own module inventory whether every contributed dependency has a Drupal 11 release, and record the blockers before you commit to a date.
Waiting is a valid choice for a team that wants to delay the Drupal 11 move until the code line is more settled. The Drupal core schedule ships bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so a later Drupal 11 minor release carries more fixes and more stable contributed module support. The cost is that the window to plan shrinks, and the work still has to land before Drupal 10 support ends.
- Downtime: Waiting does not reduce downtime on its own, since the cutover still happens once per major step.
- Testing load: You test one target version later, but the test cycle compresses toward the end of support.
- Risk of delay: Security support for Drupal 10 ends on December 9, 2026, so any slip past that date leaves the site on unsupported code.
- Minor release watch: Drupal 11.5.0 is scheduled for the week of December 7, 2026, and security support for 11.3.x ends at the same time, so the target minor line changes during the window.
- Decision point: Set a date by which you will start the Drupal 11 build regardless of minor release status.
Check the core release schedule against your planned cutover dates, and ask your partner how the Drupal 11 target will be pinned if a new minor release lands mid-project.
Some teams plan a single project that covers both the Drupal 11 and Drupal 12 moves, with one code freeze and one release calendar. This reduces the number of separate project cycles and can share testing setup, but it puts two major version changes into one change window. Work that would otherwise be reviewed in two passes is reviewed together, which increases the size of each test cycle and the chance that a failure has more than one cause.
- Downtime: A combined project can schedule one production cutover, but the window covers two major changes, so it runs longer if issues arise.
- Testing load: Regression testing covers both versions at once, which raises the number of test cases and the environment work.
- Risk concentration: Failures on Drupal 12 readiness can hold back the Drupal 11 release that was otherwise ready.
- Scope control: Keep the two stages as separately gated milestones inside one project, with the Drupal 11 release as a fixed exit point.
- Cost driver: Effort depends on custom code volume, theme rebuilds and the count of contributed modules needing changes.
Ask for a written milestone plan that shows the Drupal 11 release as its own gate, and confirm how the partner will handle a Drupal 12 blocker that appears after that gate passes.
How to prepare the Drupal 10 site before touching code
Before any code changes, the site needs a recoverable baseline, a complete list of what it runs, a server that meets the next PHP requirements, and a place to test changes safely. These four items run in parallel, and each one shortens the stop on Drupal 11 that comes next. Skipping any of them tends to push problems into the cutover week.
Verified backup and restore
Take a full database dump and a complete copy of the files directory, including private files, translations and any configuration exports. A backup only counts once someone has restored it into a scratch environment and logged in as an editor and an administrator. Restore it before you rely on it. Record how long the restore took, because that number feeds directly into your rollback plan for the cutover.
Inventory of code and projects
List every custom module, custom theme, and contributed project with its installed version, its source and whether it has been patched locally. Use composer show and the site's extension list to produce the baseline, and note any project that has no release for Drupal 11. Unpatched and unmaintained projects are the usual source of blocked upgrades, so flag them now rather than during the upgrade.
Server check against PHP targets
Confirm the web servers run PHP 8.3 at minimum for Drupal 11, and plan for PHP 8.5 because Drupal 12 requires it. Check the PHP extensions, memory limits and upload sizes that the site uses today, and check the database engine and version against the current minimums for MariaDB, MySQL, PostgreSQL or SQLite. Confirm the exact database minimums on the official system requirements page, since they change between releases.
Production-like test environment
Build a staging copy that matches production in web server, PHP version, database engine, cron method, and the external services the site calls, such as identity providers and search. Load it with a recent copy of the database and files, scrubbed of personal data where required. Run every change in this environment first, and keep it in sync with production through the upgrade window so that test results mean something on cutover day.
The upgrade sequence with checks and rollback points
The sequence moves a Drupal 10 site through PHP and database upgrades, Drupal 11 and then Drupal 12, with a verification check and a rollback point at every stage so each move can be reversed before the next one starts.
Freeze scope and take a verified backup
The team freezes code and content changes for the upgrade branch, then takes a full database and file backup and restores it to a separate environment to confirm it works. DeployOpen or your internal team records the current Drupal, PHP and contributed module versions in the upgrade plan. The step is done when a restore of the backup boots the site and the version inventory is signed off by the site owner. This backup is the first rollback point.
Run readiness checks with Upgrade Status and Drupal Rector
Install Upgrade Status on a copy of the site and scan custom modules, custom themes and contributed projects for Drupal 11 and Drupal 12 deprecations. Run Drupal Rector to apply automated fixes to custom code, then review the diff manually for anything it cannot change. Each contributed project is marked as compatible, has a release in progress, or has no path forward. The check closes when every custom finding is either fixed or assigned, and every contributed module without a compatible release has a documented decision: replace, fork or remove.
Upgrade PHP and the database on staging
On a staging copy, move the web tier to PHP 8.3 or later, which Drupal 11 requires, and confirm the database engine and version against the Drupal system requirements for the target. Drupal 12 requires PHP 8.5 or later, so the plan should note that the PHP path may need a second step. The check is a green status report with the site still running on Drupal 10 and the same content and configuration. Keep the previous PHP runtime and server image available so the change can be reverted in the same environment.
Move to Drupal 11 through Composer
Update drupal/core-recommended and contributed projects together in a Composer branch so version constraints resolve in one pass, and commit the regenerated lock file. Run database updates, export configuration, and fix any contributed module conflicts reported by Composer before moving on. The step is done when composer install reproduces the lock file on a clean build and the site reports Drupal 11 with no unresolved module errors. Tag this commit as the Drupal 11 candidate so it can be redeployed or reverted.
Test functional, integration and security paths
Run the agreed test set against the Drupal 11 candidate: content editing workflows, forms, search, authentication, cron and queue jobs, integrations with external systems, and theme rendering across the key page templates. Compare configuration exports against the Drupal 10 baseline to catch unintended changes. Review security advisories for the installed contributed versions. The step closes with a signed test report listing defects, their severity and their status. Any blocking defect returns the work to the previous stage rather than patching production.
Release Drupal 11 with a tested rollback
Schedule the production change with the site owner, confirm a fresh backup immediately before the change, and deploy the tagged Drupal 11 build. Run database updates and clear caches, then verify logins, critical transactions and scheduled jobs. Keep the Drupal 10 build and its database snapshot for an agreed window. The step is complete when monitoring shows normal error rates and the owner accepts the release. If acceptance fails, the team restores the snapshot and redeploys the Drupal 10 build.
Move to Drupal 12 after its release
Once Drupal 12.0.0 is released, repeat the readiness checks, PHP 8.5 move, Composer resolution and testing against the Drupal 12 target. The Drupal core release schedule places Drupal 12.0.0 and 11.5.0 in the week of December 7, 2026, so confirm the final release date on that schedule before committing a window. Check that every contributed module used in production has a Drupal 12 compatible release before the change is scheduled. The step is done when the same test set passes and the rollback point from the Drupal 11 release is still available.
How to test and roll back a Drupal upgrade safely
Treat the Drupal 10 to Drupal 12 move as a change that must be proven on a production-like copy before any production window opens, and that must be reversible from a snapshot taken immediately before the change. Regression testing should cover the content workflows that editors use every day: creating and revising nodes, moving content through editorial states, scheduled publishing, media uploads, and the menus and URL aliases that public pages depend on. Build a written test script for each workflow and record who ran it, against which build, and the result. Sign-in deserves its own pass. If the site uses the contributed SAML Authentication module or the OpenID Connect module, test first sign-in, returning sign-in, role mapping, and sign-out against your identity provider's test tenant, because an assertion or token change that passes in a unit test can still lock staff out.
Cron and queues need the same attention because they fail quietly. Confirm that cron runs on schedule after the upgrade, that queue workers drain, and that scheduled tasks such as content moderation, email and search indexing produce the expected results over at least one full cycle. Performance testing belongs on the same copy: replay a realistic set of anonymous and authenticated page loads, check cache hit rates, and compare response times with the pre-upgrade baseline. Confirm with your hosting team which PHP 8.5 build and database versions your environment will run, since the PHP requirement for Drupal 12 is set by the Drupal.org PHP requirements page and must match the production stack.
The rollback plan must restore a known state, not just a previous code folder. Before the window, take a full database dump and a snapshot of the web root, and store the exact composer.lock used for the tested build alongside them. Keep the lock file reproducible by installing with composer install from that file, never composer update, during rollback so that contributed module versions match what was tested. Restoring the database and code together is the only pair that is consistent, so rehearse that restore on the copy and time it. Schedule change windows with the release cadence in mind: bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, according to the Drupal core release schedule, so avoid planning a major change in the same week as a security release that would force a second code change during the window.
What makes a Drupal 10 to 12 upgrade take longer
This table lists the drivers that most often stretch a Drupal 10 to 12 upgrade and the effect each one has on the work. Read each row as a question to answer about your own site before agreeing on a timeline or quote, because the answers decide where the effort sits. The main takeaway is that the path through Drupal 11 is fixed, so most of the extra time comes from custom code, contributed modules and the systems around the site.
| Driver | Effect on the upgrade | Question to ask |
|---|---|---|
| Custom modules and themes | Each custom module and theme must be tested and refactored against Drupal 11 and then Drupal 12 APIs, so effort grows with code volume. | How many custom modules and themes exist, and do they have automated tests? |
| Deprecated API use | Deprecated calls found by Upgrade Status must be fixed in two steps, and some changes need manual work that automated tools cannot make. | How many deprecated calls does an audit report, and how many need manual changes? |
| Contributed modules without a Drupal 11 or 12 release | A module with no compatible release may need replacing, forking or removal, which can change site behavior and content models. | Which contributed projects have a release for Drupal 11 and for Drupal 12, and who maintains them? |
| Removed core modules and themes | Features from modules that left core, such as Book or Olivero, must be moved to contributed versions or rebuilt before the stop on Drupal 11. | Which core modules, themes or features does the site rely on that are no longer in core? |
| Identity provider integrations | SAML, OpenID Connect and other login integrations must be checked against each Drupal and PHP version, and login is hard to roll back once users depend on it. | Which identity provider modules are in use, and which versions do they support? |
| Data volume and content model | Large databases, many revisions or complex field structures lengthen update runs, staging copies and verification. | How large is the database, and how many entities and revisions must update cleanly? |
| Multisite layout | Each site in a multisite estate needs its own update, testing and sign-off, and shared modules must work across all sites. | How many sites share one codebase, and do they share modules or configuration? |
| Regulatory change control | Regulated environments often require approved change records, test evidence and rollback plans for each stage, which adds review cycles. | What approvals, test evidence and rollback records does your change process require for each release? |
| Hosting and PHP requirements | Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so server upgrades may need to happen in step with code changes. | Which PHP and database versions run in each environment, and who controls their upgrade schedule? |
What buyers ask before hiring help with a Drupal upgrade
What drives the cost of a Drupal 10 to Drupal 12 upgrade plan?
The cost is driven mainly by how much custom code, how many contributed modules and how many integrations the site carries, plus how much of the work is audit and planning versus building. Your own team pays for staff time spent on content owners, business sign-off and testing. A partner is paid for the assessment, the plan, the code changes and the verification work agreed in writing. Most of this is one-time, but hosting, module maintenance and security updates recur after the upgrade. Ask any quote to split audit, remediation, testing and post-launch support, and to list which contributed modules and custom components are in scope. Most engagements are fixed-scope, so the written scope is what the price follows from.
How long does a Drupal 10 to Drupal 12 upgrade plan take to produce?
The planning phase takes less time than the upgrade itself, and its length depends on how much code and how many contributed modules need review. The main factors are the number of custom modules and themes, the number of contributed projects with no release for the next major version, and the number of integrations that must be retested. Drupal 12.0.0 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, so the calendar is fixed even though the effort is not. Confirm the duration with the vendor against your own module inventory rather than against a generic figure.
What does our internal team need to provide for the upgrade?
Your team needs to provide access and decisions, not only code. Typical inputs are a current copy of the codebase and Composer files, access to staging and production-like environments, a list of integrations and their owners, the hosting and database versions in use, and named people who can approve content and design changes. Someone must also own the business acceptance tests for the critical workflows. Ask the vendor to list these inputs in the written scope so that delays can be traced to a specific dependency. Confirm change-control steps for your environment before the work starts, since these often set the calendar.
Can our in-house team run the Drupal 10 to Drupal 12 upgrade without a partner?
An in-house team can do the work if it has Drupal developers who have run major upgrades, a test environment that mirrors production, and time that does not compete with other releases. The usual risks are underestimating contributed module work, leaving deprecated code in custom modules, and missing the PHP and database requirements that gate each version. Drupal 12 requires PHP 8.5 or later, and Drupal 11 requires PHP 8.3 or later, so server work has to be sequenced with the code work. A useful test is whether your team can produce a written audit of custom code and modules within a few weeks. If it cannot, a partner can supply the audit and plan while your team keeps ownership of the site.
Can a Drupal 10 site skip Drupal 11 and go straight to Drupal 12?
No, a Drupal 10 site should not be planned to skip Drupal 11. Drupal 12 is a major version that follows Drupal 11, and the core release schedule places the move from Drupal 10 to Drupal 11 as the required intermediate step before Drupal 12 arrives. The plan should therefore treat Drupal 11 as a stop on the way, with its own module checks, testing and release. Drupal 10.6.0 is the last minor release of Drupal 10, and Drupal 10 reaches end of life on December 9, 2026. Confirm the exact stop sequence and the release you will target with your vendor before estimating effort.
What happens if a contributed module has no release for the target version?
The plan has to name a fallback for each affected module before the upgrade is scheduled. Common options are waiting for a maintainer release, adopting a maintained fork, replacing the module with a supported alternative, or rebuilding the feature as custom code that your team owns. Each option has a different effort and maintenance profile, and the choice should be recorded as a decision with an owner. Check the project page on Drupal.org for compatibility before deciding. Contributed modules are licensed under GPL-2.0-or-later, which allows forking, but any fork you maintain becomes part of your ongoing support obligations.
Is there a supported option if the site cannot upgrade in time?
Drupal core releases and security advisories are the baseline for support, and the Drupal Security Team publishes advisories with CVE identifiers and risk scores. If the site cannot finish the move before Drupal 10 reaches end of life, the plan should document the exposure window and the interim controls, such as patch routines and access restrictions. For Drupal 7 the Drupal Association lists certified extended support vendors, which shows that extended support is a recognized route for sites that cannot migrate yet. Confirm with any Drupal 10 extended support provider what it covers, its term and its exit terms, since no such provider is named for Drupal 10 in the sources used for this page.
How DeployOpen scopes and delivers a Drupal upgrade
DeployOpen plans and delivers Drupal 10 to Drupal 12 upgrade work inside your own infrastructure, from a written scope agreed before work starts. The plan covers the required stop on Drupal 11, contributed module readiness and the documents your team needs to run the upgrade with confidence.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- The written scope lists every custom module, theme and contributed project that the Drupal 11 and 12 path touches
- Scope confirms your PHP and database versions, hosting targets and the change window your team can accept
How we build
- We run Upgrade Status against your codebase and record which contributed projects lack a compatible release
- We sequence the Drupal 11 stop with dependency updates, deprecated API fixes and test runs on a staging copy
- We confirm each upgrade step in a staging environment that mirrors your production hosting before any cutover
How we hand over
- You receive a written readiness report listing blockers, owners and the order of remaining upgrade steps
- You receive a documented Composer and lock file workflow so the upgrade can be repeated by your own team
- Runbooks cover rollback, test evidence and the decisions your team must confirm before the Drupal 12 release
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial plan is delivered
- A retainer can follow the Drupal core release schedule, including security releases your team must apply
- Ask any provider whether support covers contributed module replacements and PHP upgrades on your servers
