Drupal 10 end of life: what the date means for your site
Your Drupal 10 site must be running on Drupal 11 before Drupal 10 reaches end of life on December 9, 2026, and Drupal 11 requires PHP 8.3 or later. Drupal 11 is the current major version. Drupal 12 is scheduled for the week of December 7, 2026, and it requires PHP 8.5 or later, so a site that lands on Drupal 11 in late 2026 will face another major upgrade roughly three years after the last one. Drupal 10 itself requires PHP 8.1 or later, which means many sites already run a PHP version that the next core release will not accept. After end of life, the core project no longer publishes security fixes for Drupal 10, so the site would keep serving traffic while the gap in its patch coverage grows. The practical question for the owner is not whether to upgrade but how much work the upgrade will take, and when that work must start. Ask your team to list every component the site depends on, then compare each one against the Drupal 11 release it needs. The upgrade is harder than a core version bump because several layers must move together. Core is only one of them. Contributed modules must have Drupal 11 releases, custom modules must pass deprecated API checks, themes and front-end build tooling must be tested against the new core, the PHP runtime must be upgraded on every web node, and the hosting stack, including the web server, database and any caches, must support the new PHP version. A single contributed module that has no Drupal 11 release can hold back the whole site. Do not rely on the summary dates alone. Confirm the exact end-of-life terms, including the cutoff date and what support remains after it, in the Drupal core release schedule on Drupal.org before you commit to a timeline or sign a contract. Record the version of each dependency you find, because the answer to whether the site is ready depends on those exact versions rather than on the major release number. Finally, plan for risk on the calendar. Core security releases come out on Wednesdays, and an upgrade project that runs close to the deadline has less room to absorb a security patch, a failed module update or a hosting change. Decide early who signs off on the cutover, which environment must be kept in step with production during the project, and what the fallback is if a blocking module has no Drupal 11 release on the planned date.
Which parts of the stack the upgrade touches
Upgrading from Drupal 10 touches more than the core codebase. Each layer below has a different owner, a different way of failing and a different inventory to take before work starts. Build the list from the running site rather than from memory, because the components that break are often the ones nobody documented.
Drupal core
Drupal core moves from the 10.x line to Drupal 11, the current major version, so this is a major upgrade rather than a routine point release. Deprecated APIs that core removed or replaced in the 10.x line must be found in custom code and contributed projects before the switch. The team usually responsible is platform or web engineering. Before starting, record the exact core version in production, any core patches applied to the codebase and the core modules enabled on the site. Confirm the target release against the Drupal core release schedule.
PHP runtime
Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later, so a site on an older PHP version needs a runtime change alongside the core upgrade. Infrastructure or hosting teams usually own the PHP runtime. Check the PHP version in every environment, including development, staging, cron and queue workers, because these often drift apart. Record the PHP extensions the site loads, since each one must be available for the target version. Confirm the requirement on the Drupal.org PHP requirements page.
Composer-managed dependencies
Sites built with Composer pull core, contributed projects and libraries through composer.json and composer.lock, so the upgrade changes the lock file as well as the code. Version constraints that pin an older core or module can stop the resolver from finding a compatible set of packages. Packages installed by hand outside Composer will not move with the rest of the stack. The development team that manages the repository and build pipeline usually owns this layer. Inventory every version constraint, pinned package and patch declaration before the first dependency update.
Contributed modules
Each contributed module needs a release that supports Drupal 11 before the site can move, and some modules have no stable release for the target version. Product owners usually decide what to do with a module that has no path forward, while developers do the technical work. Check each project page on Drupal.org for compatible releases, open issues and recent maintainer activity. Where a module has no path forward, decide whether to replace it, adopt a maintained fork or remove the feature. Inventory every enabled project with its current version, its candidate replacement and its security advisory status.
Custom modules and themes
Custom modules call Drupal APIs directly, so they carry the deprecated calls and hook changes that the upgrade surfaces. Themes depend on Twig templates, libraries and theme-specific code that must be tested against the new core. The in-house development team or the agency that built the site usually owns this code. Run deprecation checks across the custom codebase, list each module's dependencies and hooks, and identify which themes override core templates. Plan page-level regression testing for each theme, because visual problems are rarely caught by unit tests.
Web server and database
Drupal runs on Apache, Nginx or another web server, with MariaDB, MySQL, PostgreSQL or SQLite as its database. The upgrade can require a new PHP handler configuration on the web server and a database engine version that the system requirements list as supported for Drupal 11. Infrastructure or hosting teams usually own these services. Inventory the web server version and how it passes requests to PHP, the database engine and version, the backup and restore process and any database-level customizations. Confirm supported versions on the Drupal.org system requirements page before ordering new infrastructure.
Which upgrade path fits your Drupal 10 site
This table compares the four main routes off Drupal 10: an in-place Composer upgrade, a fresh Drupal 11 build with migrated content, a move to a Drupal CMS starting point, and upgrading now versus planning around Drupal 12. Read each row against your own code debt, contributed module list and editorial team to see which trade-off you can accept.
| Path | When it fits | Operational cost to expect |
|---|---|---|
| In-place Composer upgrade to Drupal 11 | Custom code is modest, contributed modules all have Drupal 11 releases, and the content model should stay as it is | Code debt carries forward, custom modules need deprecation fixes, and the team keeps the same editorial interface |
| Fresh Drupal 11 build with content migrated | The content model, theme or workflows have aged, or the site has accumulated code debt worth retiring | Rebuild effort for theme and modules, migration mapping and testing, and editorial retraining on any changed screens |
| Move to a Drupal CMS starting point | Marketing teams want recipes, site templates and the Drupal Canvas page builder and can accept its defaults | Review of what the template changes, custom features still needing development, and training on the new page building tools |
| Upgrade to Drupal 11 now, or plan for Drupal 12 | Drupal 10 end of life on December 9, 2026 is the deadline; Drupal 12 is scheduled for the week of December 7, 2026 | Going straight to Drupal 12 may need PHP 8.5, so a second upgrade cycle is likely if you move only to Drupal 11 first |
Drupal 11 upgrade sequence and the check that closes each step
The sequence moves a Drupal 10 site to Drupal 11 in controlled stages, and each stage ends with a recorded check so the cutover rests on evidence rather than assumption. Drupal 10 reaches end of life on December 9, 2026, so the order below is designed to finish well before then.
Inventory the site and its contributed modules
Record the current Drupal core version, every contributed module and theme, all custom modules, third-party integrations such as SSO, search and email, and the PHP and database versions in use. Build the list from the Composer lock file and the site's extensions page, then check each contributed project's Drupal 11 support on its Drupal.org project page, since some projects lag behind core. Mark each item as compatible, needs a newer release, or needs replacement. The step closes when the site owner signs off the inventory and every item has a status.
Confirm hosting meets PHP 8.3 or later
Drupal 11 requires PHP 8.3 or later, while Drupal 10 accepts PHP 8.1 or later, so many Drupal 10 hosts will need a PHP upgrade before the core upgrade can run. Confirm the web server, PHP-FPM pool and command-line PHP versions, and check that the PHP extensions the site uses are available for the target version. Then upgrade PHP in a staging environment first, not in production. The step closes when the staging site runs on PHP 8.3 or later, the homepage and administration pages load without errors, and the status report shows no PHP-related warnings.
Run deprecated API and module compatibility checks
Run the deprecation analysis tooling against the custom modules and themes to list deprecated Drupal APIs that must change before or after the core upgrade. Review the Drupal 11 compatibility results for each contributed module from the inventory. Record the list of blockers, the owner of each blocker and the planned fix or replacement. The step closes when the blocker list has an owner for every item and the team agrees which contributed modules must be updated, replaced or removed before the Composer update.
Update core and dependencies through Composer
Update Drupal core and the contributed projects through Composer in a branch of the codebase, pinning each dependency to a version the compatibility review approved. Keep the lock file under version control so every environment installs the same versions. Run the database updates and clear caches in staging. The step closes when Composer resolves without conflicts, the site's status report shows no unresolved requirements, and the database updates complete without errors in staging.
Resolve custom code and theme issues
Fix the custom modules and themes against the deprecations and API changes found earlier, and update any Twig templates, libraries or build steps that depend on removed or changed components. Developers work through the blocker list in order, with a code review for each change. Where a theme cannot be carried forward, the team agrees whether to rebuild it or adjust it. The step closes when the blocker list is empty, the code review is complete, and the site renders its key templates without errors in staging.
Export and review configuration
Export the staging configuration with Drush or the Configuration Management interface and compare it with the production export. Review the diff with the site owner and developers to confirm that every change is intended, and that configuration changed by the upgrade, such as updated module settings, is understood. Remove any unintended changes before deployment. The step closes when the configuration diff has been approved in writing and the export imports cleanly into a fresh environment.
Run the automated and manual test suite
Run the project's automated tests, including unit, kernel and functional tests where they exist, and extend coverage for the custom code changed during the upgrade. Pair the automated results with manual testing of critical workflows such as content editing, publishing, user login, forms, search and any SSO or integration path. Log the defects, fix them and rerun the affected tests. The step closes when the full automated suite passes on the upgraded codebase and the agreed manual test cases have been signed off by the business owner.
Rehearse the production cutover
Rehearse the production deployment at least once on a copy of production data, following a written runbook that covers the maintenance window, database backup, code deployment, database updates, configuration import, cache rebuild and rollback steps. Time each step and note issues for the runbook. Confirm that a tested backup restores successfully. The step closes when a full rehearsal completes with the agreed rollback path verified, and the go-live decision is approved by the site owner and the security or compliance lead.
How the upgrade differs by hosting model
On one server, the upgrade is a single sequence. The PHP runtime, the web server configuration, the code base and the database all change on the same host, and nothing else in the stack keeps serving while you work. Most of the risk sits in the order of those steps.
Rehearse these areas on a copy of the server:
- PHP version. Drupal 11 requires PHP 8.3 or later, so the PHP-FPM pool or module that serves the site must be upgraded and tested before the Drupal code goes live. Confirm that the PHP extensions your contributed modules use are available for the new version.
- Shared files. The public and private file directories sit on the same disk as the code. Copy them with the database snapshot to the staging host, then verify permissions and the paths in settings.php.
- Cache clears. Clear the render, dynamic page and discovery caches after the code deploy and before users return. Restart PHP as well, so old code does not stay loaded in memory.
- Configuration import order. Run the database update step first, then import configuration, then clear caches again. Teams that reverse these steps often see errors on the first page load.
- Where time is lost. Contributed modules that block the update, and backup or disk space windows that were never measured on the real volume.
Confirm that a full restore from the pre-upgrade backup has been tested on a copy of this server, because that restore is the rollback path on a single node.
Behind a load balancer, the upgrade is no longer a single host change. Nodes that run different PHP versions or Drupal code at the same time can return inconsistent responses, and a half-finished rollout can break sessions and forms. The rehearsal must prove that the rolling order, the node drain process and the shared storage behave as designed.
Rehearse these areas on a staging pool with the same node count and load balancer settings:
- PHP rollout across nodes. Decide whether nodes will be drained, upgraded and returned one at a time, or switched in a single window. Confirm that load balancer health checks remove a node cleanly while its PHP version changes.
- Shared files. Every node must read and write the same public and private file storage. Write a file from one node and read it from another before cutover, and check how the storage handles concurrent writes.
- Cache clears. Each node has its own PHP opcode cache, so a clear on one node does not clear the others. Script the clear across all nodes, and clear any shared cache such as Redis if you use one.
- Configuration import order. Run database updates once, from a single designated node, and not from every node in parallel. Import configuration from that node, then bring the remaining nodes into rotation.
- Where time is lost. Mixed-version sessions, shared mounts that behave differently under load, and load balancer rules that keep sending traffic to a node in the middle of its upgrade.
Confirm who owns the rolling procedure and that it has been run from start to finish on the staging pool before the production window is booked.
In a container platform, the PHP version and the Drupal code are built into an image. The upgrade becomes an image build, a one-off migration job and a controlled rollout. Most of the lost time appears in the image pipeline and in the update job, so those need rehearsal as much as the application does.
Rehearse these areas in a non-production cluster:
- Image build. Build the Drupal 11 image on PHP 8.3 or later from a pinned base image. Run the build through the same pipeline used for production so that the result is reproducible.
- Update job. Run database updates and configuration import as a single job before new pods receive traffic, and do not run them in each pod's startup process.
- Shared files. Persistent volumes for public files must support the access mode your replicas require. Confirm this with the storage class before the rollout is scheduled.
- Cache clears. Restarting pods clears PHP caches, but external caches such as Redis or Varnish keep their state across rollouts. Clear them explicitly inside the update job.
- Air-gapped networks. Where the cluster has no route to the internet, package sources and Composer mirrors must hold the Drupal packages and their dependencies before the upgrade window. Container registries and base images need the same preparation.
- Where time is lost. Rebuilding images after a dependency fails to resolve, and rollouts that report success while the update job has failed.
Confirm which team owns the image pipeline and who approves the output of the migration job before the rollout begins.
What drives Drupal 11 upgrade cost and effort
This table lists the factors that most change the size of a Drupal 10 to Drupal 11 upgrade, with how each one is reduced and what to request in a written scope. Read each row as a question to answer about your own site before asking for a quote. The main takeaway is that module count and custom code usually matter more than the core upgrade itself.
| Driver | Why it changes effort | How to reduce it | Ask for in the written scope |
|---|---|---|---|
| Contributed modules | Each contributed project must have a Drupal 11 compatible release, and some may lack one or be unmaintained. | Run a module audit, remove unused modules, and replace abandoned projects with maintained alternatives. | A list of every contributed project with its Drupal 11 status and the planned action for each. |
| Custom code and deprecated API use | Custom modules and themes that call deprecated or removed APIs need code changes and testing. | Run deprecation scans on custom code, fix findings in the current Drupal 10 release first, and keep custom modules small. | The scan method, the count of findings by severity, and who fixes them and when. |
| Themes and Twig templates | Each theme and template override must be checked against updated markup, libraries and Twig behavior. | Consolidate themes, remove unused templates, and move overrides into a single maintained base theme. | The number of themes and template overrides in scope and a visual regression plan for key pages. |
| External integrations | APIs, SSO providers, payment or CRM connectors and search services each need retesting against the upgraded site. | Inventory every integration, document its contract, and add automated contract tests where possible. | A list of integrations, their owners, and the test evidence expected at acceptance. |
| Environments and release gates | Each environment (development, staging, production) and approval gate adds deployment and retest cycles. | Keep environments consistent, script deployments, and agree gate criteria in advance. | The environments in scope, the deployment steps, and the sign-off roles for each gate. |
| Content and configuration volume | Large content sets and many configuration objects increase update, migration and verification time. | Prune stale content, export configuration cleanly, and test updates on a recent copy of production data. | Content and configuration counts, the data copy process, and how data privacy is handled in non-production copies. |
| Compliance evidence requirements | Regulated sites often need change records, test results and a documented rollback path for each release. | Automate test reports, keep change tickets linked to commits, and prepare the rollback plan before cutover. | The evidence list, the format and retention period required by your assessor, and the deliverables that DeployOpen would provide. |
How to confirm the Drupal 11 upgrade works and fails safely
The upgrade is only finished when the team can show, with recorded evidence, that the Drupal 11 site behaves like the Drupal 10 site for the people who use it and that a bad cutover can be reversed. Plan the checks before the upgrade branch is built, so the same suite runs on the staging copy, the candidate release and the production-like environment. Treat every check as a go or no-go input, not as a report to read after launch.
Start with automated tests on the custom modules. Upgrading core and the PHP runtime often breaks code that depends on deprecated API calls, changed service signatures or altered hook behavior, so the custom code needs unit and kernel tests that run on PHP 8.3 against Drupal 11 and fail loudly on deprecations. Confirm which test framework the project already uses and whether its custom modules have coverage at all. Where they do not, the smoke tests below carry more of the weight, and that gap should be recorded as a risk.
Smoke tests should follow the paths that earn revenue or protect the organization: publishing and unpublishing content, moving items through the Content Moderation workflow, media uploads, search, forms that write to integrations, and the front-end pages that depend on Views and custom Twig templates. Compare configuration exports from the Drupal 10 production site and the Drupal 11 candidate, so unexpected changes to fields, views, roles or module settings are visible before cutover. Review every difference and record whether it was intended.
Check performance and caching on the candidate using the same hosting layer planned for production, including page cache behavior, cache tag invalidation after content edits, and the response times of the heaviest views. Verify login and role checks with a test account for each role, confirming that permissions match the documented matrix and that any single sign-on or local administrator account still works. Confirm with the team who owns each contributed module that its Drupal 11 release is stable, not only the development branch.
The rollback plan must restore the database and files taken immediately before the change, and the team should rehearse that restore on a copy before the window. Record the backup identifiers, checksums and the exact steps and owners, then decide in advance the point at which rollback is chosen over a fix. Sign-off should capture test results, configuration diff decisions, performance readings, role checks, the rehearsal outcome and named approvers. Blockers include failing custom module tests, unreviewed configuration changes, a failed restore rehearsal, or an unsupported contributed module without an agreed workaround.
Security controls to keep during the move
A Drupal 10 to Drupal 11 move creates a period where the old site stays live while the new one is built, tested and cut over. The controls below keep the existing site patched, limit change during the freeze, and make sure the new environment does not inherit weak settings, exposed secrets or misassigned administrator roles.
Keep Drupal 10 patched until cutover
Drupal 10 reaches end of life on December 9, 2026, so the live site has to keep receiving security releases until the switch to Drupal 11 is complete. Security releases ship on the third Wednesday of the month, and the Drupal Security Team publishes advisories with CVE identifiers and risk scores. Assign one person to read each advisory, test the patch on a copy of the current site, and record the date each fix reached production.
Limit code changes during the freeze
Once the migration target is fixed, decide who may merge or deploy changes to the Drupal 10 site and to the Drupal 11 build. Route every change through a named approver and keep a written list of exceptions. Without this control, a hotfix on one branch can silently miss the new codebase, and the team may cut over a site that differs from what was tested.
Protect settings.php and file permissions
The settings.php file holds the database connection, the hash salt and trusted host patterns, so it needs the tightest permissions on the server. Confirm that the Drupal 11 environment sets a trusted host pattern, that the web server cannot write to the codebase, and that the public files directory is the only writable path. Check these settings on the staging host and again after cutover, since new servers often start with looser defaults.
Keep secrets out of the repository
Database passwords, API keys, the hash salt and identity provider client secrets should be supplied by the environment or a secrets manager, not committed in settings.php or exported configuration. Review the repository history as well as the current branch, because a secret removed in a later commit remains recoverable. Ask the team which secrets the Drupal 11 site needs and who can rotate each one before the cutover date is fixed.
Review contributed modules and dependencies
Each contributed module carries its own maintainers, release history and advisory exposure. Before the move, list every contributed module and check whether it has a Drupal 11 compatible release, who maintains it, and whether it has open security advisories. Pay attention to PHP and Composer dependencies, since Drupal 11 requires PHP 8.3 or later and a library update can break a module that was previously stable.
Confirm admin accounts and role mappings
Migrated or recreated sites often carry over accounts and roles with different permissions than intended. Compare the user list, the administrator role and each custom role between the Drupal 10 source and the Drupal 11 target. If single sign-on maps identity provider groups to Drupal roles, test that mapping with a non-administrator account, and confirm that local break-glass administrator accounts still exist and are protected by strong authentication.
Keeping Drupal 11 supported and planning for Drupal 12
After cutover to Drupal 11, the upgrade is not finished. The site needs a fixed operating rhythm so that bugfix and security releases are applied on a known schedule, and so that the next major version is planned before it arrives. According to the Drupal core release schedule, bugfix releases are published on the first Wednesday of each month and security releases on the third Wednesday. Ask your partner or internal team to write these two dates into the change calendar, along with a named owner who reviews each release notice within a set window and decides whether it is applied on the next scheduled deployment or handled as an emergency. Updates should run through Composer rather than by replacing files by hand. Keep the core and contributed module versions pinned in composer.json and composer.lock, commit both to version control, and apply updates in a non-production environment first. Run the database updates, configuration import and automated tests before promoting the same build to production. Review the lock file diff on each release so that every change to a module version has a recorded reason, which is the main input for the decision log described in the next section.
Contributed module compatibility needs its own monitoring. A module that worked on Drupal 11 at cutover can fall behind after a core release or a PHP change, and some projects are slow to publish compatible releases. Each month, check the maintenance status and the release notes for every contributed project in the lock file, and check the Drupal Security Team advisories for any project you run. Record the outcome of each review: the version applied, the version deferred, the reason, and the person who approved it. This decision log is the document an auditor or a new team member will ask for first, so keep it in the same repository as the code. Drupal 12 is scheduled for the week of December 7, 2026, and requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. Start planning now by inventorying the PHP version running on each environment, the PHP extensions in use, the database and web server versions, and every contributed module with its declared Drupal and PHP compatibility. Flag any module that depends on a project with no release for the next major version, and any custom code that uses APIs marked deprecated in Drupal 11. Confirm the current schedule with the Drupal core release policy before you set a budget or a deadline, because release dates can change.
Questions teams ask before the Drupal 11 upgrade
How much does the Drupal 11 upgrade cost?
The cost depends on the scope you define, so no reliable figure can be given without an inventory of your site. Drupal has no license fee, so the spend is labor, testing, and any module or theme work, plus hosting changes if your PHP version must move. The main cost drivers are the number of contributed modules that need a Drupal 11 compatible release, the volume of custom code that uses deprecated APIs, the number of themes and integrations, the number of test environments, and the size of the content and configuration to verify. Ask for a written quote that lists each module, custom code area, integration, and test cycle as its own line, and mark which items are one-time (the upgrade itself) and which recur (ongoing security and module maintenance).
How long does a Drupal 10 to Drupal 11 upgrade take?
Duration is set by the amount of work and the availability of your team, not by the version pair alone. A small site with few contributed modules and no custom code is far quicker to move than a large site with dozens of custom modules and several integrations. Work the schedule backward from the dates that matter: Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Plan the sequence so that the upgrade, testing, and cutover fit before end of life, and leave room for contributed modules that lag behind a new major version. Confirm the current dates on the Drupal core release schedule before you commit.
What does our internal team need to provide during the upgrade?
Your team owns the decisions that only your organization can make, and an upgrade stalls quickly without them. Name a product owner who can approve content and feature behavior changes, and a technical contact who can grant access to the codebase, staging and production environments, and the hosting account. Your editors and business owners must test their own workflows and sign off on the results, because automated checks cannot confirm that a form, approval path, or report still behaves as expected. Identify who will own the site after launch, including security release reviews and module updates, so that responsibility does not return to an unprepared team.
Can our own team upgrade to Drupal 11 without a partner?
Yes, if your team has hands-on experience with Drupal core, Composer, contributed module management, and the deprecation tooling that Drupal provides. An in-house team usually handles a small, well-documented site with few custom components. A partner adds the most value when the site has many custom modules, several integrations such as single sign-on or external APIs, or a tight deadline. Whichever route you choose, agree on a written list of deliverables, including the list of modules updated, the custom code changed, the test results, and the rollback plan. That list is the simplest way to compare an internal estimate with an external quote.
What happens if our site stays on Drupal 10 after end of life?
After Drupal 10 reaches end of life on December 9, 2026, the Drupal Security Team no longer provides security releases for that version, so new vulnerabilities in core will not be fixed for your site. Security releases are issued on the third Wednesday of the month, and a site that misses them accumulates exposure over time. Drupal 7 has an extended support program with listed providers for sites that cannot migrate yet, but do not assume an equivalent program exists for Drupal 10. Confirm with the Drupal Association and any provider you are considering what extended coverage, if any, is available and for how long, before you plan a delay.
Does Drupal 11 have a license fee?
No. Drupal and the contributed files on Drupal.org that are derivative works of Drupal are licensed under the GNU General Public License, version 2 or later (GPL-2.0-or-later), and there is no paid edition of Drupal itself. Your costs are therefore the labor to build, upgrade, and maintain the site, the hosting, the PHP and database platform, and any commercial services you buy, such as support or security testing. Check the license of any third-party module, theme, or distribution you add, because some commercial products carry their own terms even when the core is open source. Confirm each license during the module inventory.
How does Drupal 12 change the Drupal 11 upgrade plan?
Drupal 12 is scheduled for the week of December 7, 2026, in the same week that Drupal 10 reaches end of life, so an upgrade planned for Drupal 11 now should also be checked against the next major version. The PHP requirements also rise: Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later. Choose a PHP version and hosting baseline that can move forward, and avoid deprecated APIs in custom code so that the next upgrade is smaller. Before you start, confirm that your critical contributed modules have a release plan for Drupal 12, because a module that stops at Drupal 11 will become a blocker.
How DeployOpen scopes, upgrades and hands over Drupal sites
Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so sites on it need a planned move to Drupal 11 before then. DeployOpen starts with a written scope that inventories the site, its contributed modules and its PHP and database platform, then upgrades, tests and documents it inside your own infrastructure.
How we scope
- The written scope lists the Drupal version, contributed modules, custom code and themes that the upgrade covers.
- Discovery checks the target PHP version, since Drupal 11 requires PHP 8.3 or later per Drupal.org.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any upgrade work starts.
How we build
- Work runs in a staging copy of your site, so the production site stays unchanged until cutover is approved.
- Deprecated API usage in custom modules and themes is identified and fixed against Drupal 11 before testing begins.
- Each contributed module is checked for Drupal 11 compatibility, and any gaps are agreed as replacements or custom fixes.
How we hand over
- Handover includes an upgrade record of changed code, updated dependencies and the tests that were run on staging.
- Configuration is exported and documented so your team can review changes through its normal deployment process.
- Your team receives runbooks for rollback, the cutover sequence and the post-upgrade checks on the live site.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover monitoring of Drupal security release windows and updates to contributed modules.
- Ask any partner which Drupal 12 planning, PHP upgrade and module monitoring steps are included in their written scope.
