Why a Drupal 11 site needs a Drupal 12 plan before December 2026
If you run a Drupal 11 site, you need a dated plan for Drupal 12 now, because the new major version is scheduled for the week of December 7, 2026, and the decision that matters most is whether your PHP, hosting and contributed modules can move with it. Drupal 12 is a new major version, and the supported path is to move from Drupal 11 to Drupal 12 rather than to skip ahead from older releases. The core question for your planning is simple: what must be true on your servers, in your code and in your contributed modules before that week arrives?
Start with the hard gate. According to the Drupal.org PHP requirements page, Drupal 12 requires PHP 8.5 or later, while Drupal 11 requires PHP 8.3 or later. A site that is current on Drupal 11 may still run an older PHP minor version, so confirm your runtime today and find out who owns the server change, how long your change control takes, and whether your hosting provider offers PHP 8.5 on your platform. Also check your database against the Drupal.org system requirements page, since the server upgrade and the code upgrade should be sequenced together rather than treated as separate projects.
Drupal 10 end of life is the other date to track. According to the Drupal core release schedule, Drupal 10 reaches end of life on December 9, 2026, so any Drupal 10 estate will need its own path, and Drupal 11 sites should treat that date as a signal that the ecosystem is shifting. Drupal core and contributed projects are licensed under GPL-2.0-or-later, according to the Drupal.org licensing page, and there is no paid edition of Drupal itself, so the cost of this upgrade is the engineering, testing and hosting work you or a partner carry out, not a license fee. Ask any partner to quote that work against a written scope, and confirm your release timing against the Drupal core release schedule.
What changes between Drupal 11 and Drupal 12
This table lists each change that affects a Drupal 11 site moving to Drupal 12, with the impact and the action to take. Where the researched facts do not give a detail, the cell says what to confirm. Use it as a checklist to scope the upgrade before the code work starts.
| Change | Impact | Action needed |
|---|---|---|
| PHP minimum rises to 8.5 | Drupal 12 requires PHP 8.5 or later, up from PHP 8.3 for Drupal 11. Servers, container images and CLI tooling all need a matching runtime. | Plan the PHP upgrade for every web and worker host, then confirm the PHP 8.5 requirement on the Drupal.org PHP requirements page. |
| Deprecated APIs removed in Drupal 12 | Code that uses APIs deprecated in Drupal 11 may stop working. Custom modules and themes carry most of this risk. | Run Upgrade Status on custom code, apply Drupal Rector fixes, then review remaining manual changes. Confirm the exact removed APIs in the Drupal 12 release notes. |
| Contributed modules need a Drupal 12 release | A contributed module without a Drupal 12 compatible release blocks the upgrade or forces a replacement or fork. | Check every contributed project in Upgrade Status and on its Drupal.org project page. Record any project with no compatible release and decide on a replacement. |
| Core modules and themes removed | Modules or themes removed from core stop being available in the codebase. Sites that depend on them need a contributed version or a replacement. | Inventory enabled core modules and themes. Confirm the removal list for Drupal 12 in the release notes before choosing contributed alternatives. |
| Core minimum database versions | Database minimums can change with a major release. Older MariaDB, MySQL or PostgreSQL versions may stop being supported. | Confirm the Drupal 12 database minimums on the Drupal.org system requirements page and schedule any database upgrade ahead of the code change. |
| Web server and runtime extensions | PHP extension and web server changes can break builds or cron jobs even when the application code is correct. | Compare the PHP extension list for the new runtime with the current one and test the full build and deploy pipeline on a staging host. |
| Drupal 11 minor release support | Drupal 11 minor releases continue during its support window, so the upgrade should start while security releases still arrive. | Track the release schedule and plan the Drupal 12 target around the scheduled release week, noting that Drupal 10 reaches end of life on December 9, 2026. |
Which upgrade path fits your site
A site already on Drupal 11 with little custom code has the shortest path. Most of the work is confirming that contributed modules and the hosting stack are ready, then moving to Drupal 12 in a planned window. Start with a readiness scan on a copy of production, not on the live site.
- Check PHP first: Drupal 12 requires PHP 8.5 or later, so the runtime must move before the code upgrade. Confirm that the PHP 8.3 requirement for Drupal 11 is already met.
- Run Upgrade Status: Use Upgrade Status against the current codebase to list deprecated API use and contributed projects without a Drupal 12 compatible release.
- Apply Drupal Rector: Let Drupal Rector fix the mechanical deprecations it handles, then review every change in version control.
- Upgrade in staging: Move core and contributed packages in a staging copy, run the test suite and smoke tests, and record the resulting lock file.
- Schedule around releases: Plan the production change against the Drupal 12 release week and the Drupal 11 minor release schedule, allowing for security release dates.
Before booking a date, check every contributed module against Drupal 12 compatibility, because a clean custom codebase does not help if one essential module has no release yet. Confirm the release dates on the core release schedule before you commit to a window.
A Drupal 11 site with large custom modules, themes or patched contributed code needs a bounded audit before any upgrade date is set. The effort sits in custom code that scanners can flag but cannot fully rewrite, so the plan should separate automated fixes from manual engineering work. Treat the audit as the first deliverable, not a preliminary step.
- Inventory custom code: List every custom module, theme and local patch, with its owner and the business features it supports.
- Triage deprecations by risk: Separate mechanical changes from those touching services, plugins, forms or render logic, which need developer judgment.
- Replace removed or unmaintained components: Check whether any dependency has been removed from core or lacks a maintained contributed alternative.
- Refactor in reviewable batches: Merge changes in small batches, each covered by automated tests for the feature area it touches.
- Assess test coverage: Without tests on custom features, the upgrade depends on manual regression checks, which business owners should scope and sign off.
Ask your internal team or partner for a written inventory of custom code and an effort breakdown that separates automated and manual changes. Agree the Drupal 12 date only after that breakdown is complete, since patched contributed code often holds up the schedule more than core changes do.
A site still on Drupal 10 cannot reasonably move to Drupal 12 in one change set. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so the Drupal 11 step has to be planned first and the Drupal 12 step follows. Treat the two steps as separate releases, each with its own testing and cutover.
- Stop on Drupal 11: Complete Drupal 11 as a full release, with readiness work, testing and cutover, before starting Drupal 12 work.
- Move PHP in steps: Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so plan server upgrades alongside each code step.
- Check contributed modules for both targets: A module that works on Drupal 11 may not yet have a Drupal 12 release, so check both targets in the same audit.
- Cover the gap until cutover: Decide how the site will be supported between now and the Drupal 11 cutover, and confirm what your support arrangements include.
- Time updates to the schedule: Use bugfix and security release timing to decide when each step can safely start and finish.
The sibling topic on planning a Drupal 10 to Drupal 12 upgrade covers the full sequence in more detail. Confirm the end-of-life date and your support arrangements first, because they determine how much time the two steps can share.
How to prepare before you touch the code
These items run in parallel and set the baseline for the Drupal 12 upgrade. Each one protects a rollback path, shows what the code must change to, or removes a surprise from the PHP and contributed module work. Start them together, because the module status list and the test environment often decide the schedule.
Tested full backup
Take a complete backup of the database and the files directory, including private files and the Composer-managed codebase, then restore it to a separate environment. An untested backup does not count as a rollback path. Record how long the restore takes, since that figure feeds the cutover plan. Confirm that the backup covers configuration exports and any file storage outside the web root.
Custom code and theme inventory
List every custom module, custom theme, and patched contributed project, with its owner and whether it is still in use. Unused code is cheaper to delete than to port. This inventory becomes the input for Upgrade Status and Drupal Rector runs, so each custom project should map to a repository and a named reviewer. Note any custom code that depends on modules removed from core.
PHP 8.5 test environment
Build a staging environment that runs PHP 8.5, because Drupal 12 requires it, and match the web server, database and extensions used in production. Drupal 11 requires PHP 8.3 or later, so the current production runtime may need a separate upgrade step. Confirm with your hosting provider whether PHP 8.5 is available on your platform and which extensions are included. Keep this environment separate so test results reflect the target runtime.
Composer-managed codebase
Confirm that the site is built from Composer with a committed lock file, so every dependency version is reproducible. Sites that edit core files directly or install modules by hand cannot show which versions a Drupal 12 upgrade will change. Check that the version constraints for drupal/core-recommended and contributed projects allow the target release. Resolve conflicts in a branch before the upgrade window opens.
Contributed module status list
Build a table of every contributed module and theme with its current release, its maintainer status and whether a Drupal 12 compatible release exists on Drupal.org. Use Upgrade Status to confirm which projects report blocking issues. Projects without a planned release need a decision: replace, fork with an owner, or remove. Ask each vendor or maintainer for a timeline in writing when a commercial module is involved.
How Upgrade Status and Drupal Rector find the work
Upgrade Status is the starting point for finding the work. Install the Upgrade Status module on the current Drupal 11 site, run it against the codebase and it reports deprecated API use in custom modules, custom themes and contributed projects, along with whether each contributed project has a release that declares compatibility with the target version. The output is a list of findings grouped by project, which is the raw input for effort planning. Treat that list as a floor, not a complete inventory: it does not see behavior that breaks at runtime, data that depends on removed features, or integrations with external systems. Confirm the Upgrade Status version and the Drupal 12 target it checks against on the module's Drupal.org project page before you rely on the results, because both change as the target release nears.
Contributed module readiness is where most schedule risk sits. A finding that says a contributed project has no compatible release for the target is a decision, not a code fix. For each one, record whether the maintainer has a development branch, whether a patch exists in the issue queue, whether the module can be replaced, or whether the feature must be rebuilt as custom code. Check the project's release history on Drupal.org for a stable release that supports Drupal 12, and do not assume that a release marked for Drupal 11 will work on Drupal 12 without testing. Ask the team that owns each dependency to name a date by which they will commit to a compatible release, and keep that date in the upgrade plan.
Drupal Rector changes the deprecated code, and people review what it cannot change. Drupal Rector applies rule-based transformations to the deprecated calls that Upgrade Status reports, which usually clears the mechanical share of findings in custom modules and themes. Run it on a branch, read the diff by rule rather than by file, and run the test suite afterward. Rector will not resolve design changes, such as code that depends on a removed core module, a service whose signature changed in a way the rules do not cover, or Twig templates with logic that needs rework. Those remain manual items, and they are where custom code estimates tend to go wrong. Record which rules produced changes so that the same reviewer can check them on every later pass.
The upgrade sequence from audit to production
The sequence moves a Drupal 11 site through an audit, infrastructure and code changes, and tested cutover, with a rollback point at each stage so the team can return to a known good state if a step fails. Each step closes with a check the owner can confirm before the next one begins.
Audit the site with Upgrade Status
Install Upgrade Status on a copy of the production site and run it against the custom modules, custom themes and every contributed project. The output is a list of deprecated API uses, contributed projects without a Drupal 12 compatible release, and core features that have left core. The developer lead and the site owner review the report together and record which items are blockers, which are fixes, and which need a decision on replacement. The step is done when every finding has an owner and a disposition in the upgrade backlog.
Upgrade PHP and the database on staging
Build a staging stack that matches production, then raise PHP to 8.5 and confirm the database version meets the Drupal 12 system requirements, which your team should verify against the current Drupal.org pages before scheduling. Run the existing Drupal 11 code on this stack first, so any failure caused by the runtime is separated from code changes. The platform engineer records the PHP, web server and database versions in the change record. The step is done when the unchanged site loads, passes its smoke tests and logs no new errors on the new runtime.
Apply Drupal Rector to custom code
Run Drupal Rector against custom modules and themes in a version-controlled branch, then review each diff rather than accepting changes in bulk. Rector handles many mechanical deprecations, while signature changes, removed services and logic that depends on removed behavior still need a developer. The lead developer commits the automated changes separately from manual fixes so the history stays readable. The step is done when Upgrade Status reports no remaining findings for custom code, and the reviewed commits are merged into the upgrade branch.
Update contributed modules to compatible releases
Update each contributed project to the release that declares Drupal 12 compatibility, and replace or remove any project that has no such release. Use Composer to resolve constraints in the upgrade branch and keep the lock file committed so the result can be rebuilt exactly. The developer and site owner confirm that each replacement keeps the required behavior, such as SSO or search, before it is accepted. The step is done when the lock file resolves cleanly, every contributed project is on an accepted release, and the decisions are documented.
Update core in a branch with Composer
Change the Drupal core constraint in the upgrade branch with Composer, resolve the dependency graph, and run database updates on a fresh copy of the staging database. Keep the change in its own branch so it can be reverted without touching the contributed or custom work. The developer checks the update output and the configuration status report for drift. The step is done when database updates complete without errors, configuration is in a clean state, and the branch builds from scratch in CI.
Run automated and manual test suites
Run the project's automated tests, including unit, kernel and functional suites for custom code, then execute a scripted manual test plan covering content editing, forms, login, search, integrations and any payment or identity flows. Testers record results against each test case, and failures return to the relevant earlier step rather than being patched in the branch silently. QA and the business owner sign off on the results. The step is done when the agreed test set passes, open defects are triaged, and the sign-off record names who approved the release candidate.
Rehearse the production cutover
Perform a full cutover rehearsal on a staging copy using a fresh production-like backup, timing each action and recording the commands, maintenance window steps and post-deployment checks. The rehearsal exposes missing steps, environment differences and runbook gaps before production is touched. The operations lead updates the runbook with every correction from the rehearsal. The step is done when a complete rehearsal finishes with the runbook signed off and the rollback procedure has been executed at least once in staging.
Define rollback points and restore from tested backup
Before each production change, take a backup of the code, database and files, and confirm it can be restored on a separate environment. Record a rollback point at each stage, from the PHP change through the core update and the cutover, so the team knows exactly which state to return to. The operations lead restores the most recent backup in a test environment to confirm it works. The step is done when a restore has been verified, rollback criteria are written down, and the on-call team knows who can trigger a rollback.
What makes a Drupal 12 upgrade longer
This table lists the factors that most often lengthen a Drupal 11 to Drupal 12 upgrade, the effect each has on effort, and what to ask for in a quote. Read each row as a question to answer about your own estate before comparing proposals, since the same driver can add little effort on one site and a great deal on another.
| Driver | Effect on effort | What to ask for in a quote |
|---|---|---|
| Custom modules and themes | Each custom module and theme needs its own deprecation fixes, testing and code review, so effort grows with the amount of custom code and its age. | A per-module inventory from Upgrade Status output, with custom code split into modules, themes and any custom Composer packages. |
| Contributed modules without a Drupal 12 release | A module with no compatible release can block the upgrade, forcing a replacement, a fork or a wait, and each replacement adds design and testing work. | A list of every contributed project with its Drupal 12 status checked on Drupal.org, and a named fallback for each one that is not ready. |
| Removed core modules and themes | Modules such as Book, Actions UI, Activity Tracker, Ban, Olivero and Claro need either a contributed replacement or a rebuild, and the content or configuration they hold must be moved. | Confirm which removed components are in use, the replacement chosen for each, and the data migration steps included. |
| Identity, CRM and payment integrations | Integrations depend on third-party modules and API clients, so each one needs version checks, configuration review and end-to-end tests against live or sandbox services. | A separate line for each integration, including the vendor sandbox access needed for testing and who owns credentials. |
| Multisite count | Each site repeats the code, configuration and test cycle, though shared codebases reduce repeated work when sites follow the same pattern. | The number of sites, which ones share a codebase, and whether the estimate covers a pilot site before the rest. |
| Data volume and content model | Large content sets, complex entity relationships and custom fields lengthen upgrade rehearsals and database updates, and they increase the time needed to verify results. | Expected row counts for major entities, the staging copy used for rehearsals and how long a full dry run is planned to take. |
| Test coverage | Without automated tests, more effort goes to manual regression checks, and gaps often surface only after launch. | Whether automated tests exist, what they cover, and what manual test scripts the quote includes for business-critical paths. |
| Infrastructure gates (PHP 8.5 and database versions) | Server upgrades must be sequenced with the code upgrade, and older hosting can add a separate project before Drupal work starts. | Confirmation of the PHP and database versions in use today and the upgrade plan for each host, with ownership named. |
When to start relative to Drupal 11 minor releases and security windows
Start the Drupal 12 preparation work on a fixed calendar, because the Drupal core release schedule gives a predictable rhythm to plan around. Bugfix releases ship on the first Wednesday of each month, and security releases ship on the third Wednesday. Treat the third Wednesday as the date that can interrupt any planned work, and treat the first Wednesday as the normal point to pull in non-security core updates. Build a standing change window that sits clear of both dates, and keep a rollback path ready for any release that lands inside your window. Confirm the exact release dates and any out-of-cycle releases on the Drupal core release schedule before you lock your calendar.
Keep Drupal 11 patched until the cutover date, not just until the upgrade branch is ready. Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, so a site still on Drupal 10 will need to pass through Drupal 11 on the way. Apply every security release to the production Drupal 11 codebase on the day it ships or within your agreed window, and carry the same updates into the upgrade branch so that the two codebases do not drift. Ask your Drupal partner or internal team to show how each contributed module update is tested against both branches. Security advisories for core and contributed projects are published by the Drupal Security Team, so subscribe to them and assign an owner who can judge whether a fix affects your installed modules.
Freeze feature work on the site for the duration of the upgrade, and decide in advance what counts as an exception. Every new content type, view, module or configuration change made on Drupal 11 during the upgrade must be replayed onto the Drupal 12 branch, which adds effort and delays cutover. Set a feature freeze date, a code freeze before the final sync, and a short list of allowed fixes such as security patches and blocking defects. Agree these rules with content owners and product stakeholders in writing. Confirm with your team how configuration is exported and deployed so that the frozen state can be reproduced exactly at go-live.
Questions buyers ask before upgrading Drupal 11 to 12
What does a Drupal 11 to 12 upgrade cost and why does the price vary?
The cost depends on how much custom code, how many contributed modules and how many integrations the site carries, not on a license fee, because Drupal itself is free under GPL-2.0-or-later. Cost components are the readiness audit, custom code fixes, contributed module updates or replacements, infrastructure work such as PHP 8.5, testing, and cutover. Some of these are one-time project work, while hosting, security updates and support recur after launch. Ask any provider for a quote built from a written scope that lists each module, custom component and integration, plus who performs each task and what is excluded.
How long does a Drupal 12 upgrade take?
Duration is set by the size of the custom code, the number of contributed modules without a Drupal 12 release, the number of integrations to retest, and how many environments and approval gates the change control process requires. The Drupal core release schedule places Drupal 12 in the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, which fixes the external deadline. Ask for a timeline that separates audit, remediation, testing and cutover, and confirm which steps depend on your own staff or approvals.
What must our team provide before the upgrade starts?
A clear upgrade starts with access and decisions, not code. Your team should supply a current codebase in version control, a staging environment that matches production, database and file backups, a list of integrations with their owners, and the names of people who can approve content, security and release decisions. Engineers also need the PHP and database versions your hosting provides, plus your change control rules and test cases for critical business flows. Missing items usually show up as delays during testing, so confirm them in the written scope.
Can our in-house team perform the Drupal 12 upgrade?
Yes, if your team has Drupal development experience, can run Composer-managed builds, and has time to fix deprecated code and test the site. Upgrade Status reports deprecated API use and contributed module readiness, and Drupal Rector can fix many of those findings automatically, but reviewing the changes and handling custom logic still needs skilled developers. A partner is most useful when staff are limited, the site has many integrations, or the release window is fixed. Compare the internal hours required against a fixed-scope quote, and confirm who owns the result after launch.
Does a Drupal 10 site have to move to Drupal 11 before Drupal 12?
Yes. Drupal does not support a direct jump across two major versions, so a Drupal 10 site should first move to Drupal 11, then to Drupal 12. Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so server and database upgrades need to be sequenced with each code step. Plan the intermediate release as its own project with its own testing, rather than treating it as a short step inside the Drupal 12 work. Your readiness audit should confirm where each site currently sits.
What happens if a key contributed module has no Drupal 12 release?
The site cannot simply run that module on Drupal 12 without a compatible release, so the options are to wait for a release, replace the module with an alternative, move the feature into custom code, or remove it. Each option has different cost and risk, and the decision depends on how central the module is to content, security or integrations. Upgrade Status shows which modules lack compatible releases, so run it early. Ask for a written list of blocking modules, a decision owner for each one, and a fallback plan that protects the production date.
How do we check whether our site is ready for Drupal 12?
Start with a readiness audit that runs Upgrade Status against the custom and contributed code, then reviews hosting requirements, including PHP 8.5 and supported database versions. Drupal Rector can apply automated fixes for many deprecated API uses, and the team should review every change before merging. The audit output should list each finding, its owner, and whether it is automated, manual or blocked. Use the Drupal.org system requirements page to confirm the web server and database options your hosting supports.
How DeployOpen scopes and delivers the upgrade
DeployOpen plans, implements, tests, documents and supports Drupal upgrades inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. For a Drupal 11 to Drupal 12 move, the work starts with a written scope that ties PHP, contributed modules and custom code to a delivery sequence your team can review and approve.
How we scope
- Written scope covering custom modules, themes, contributed modules and the PHP 8.5 server change for Drupal 12
- Upgrade Status results reviewed with your team to list every blocking deprecation and module gap
- Deliverables, timelines and responsibilities agreed in writing before any upgrade work begins
How we build
- Upgrade work done in a non-production copy of your site with your current database and files
- Deprecated API use in custom code fixed with Drupal Rector, then reviewed manually where Rector cannot finish
- Contributed modules updated or replaced, with each change recorded and tested before it reaches staging
How we hand over
- Documented change log covering code changes, dependency versions, server settings and known open items
- Test results for functional paths, including login, content editing and any integrations you run
- Runbook for the Drupal 12 cutover, rollback steps and the updated Composer and deployment workflow
How we support
- Post-launch support available as a retainer, covering monitoring of the upgraded site and issue fixes
- Ongoing updates for contributed modules and core releases handled under the same agreed process
- Support scope, response expectations and fees confirmed in writing as part of the quote
