What Drupal upgrades and support involve
Drupal has no paid edition, so there is no license renewal to manage. What recurs is operational work: applying core and contributed updates, keeping PHP on a supported version, and planning major upgrades before a version leaves support. The Drupal core release schedule sets a predictable rhythm. Bugfix releases come out on the first Wednesday of each month, security releases on the third Wednesday, and new major versions typically arrive about every three years. Someone on your side needs to own that calendar and decide who applies each release and how quickly.
Four kinds of trigger drive most of the work. A Security Team advisory names a vulnerability in core or a contributed project and often needs a patch within days, not weeks. A bugfix release is routine but still needs regression testing. PHP end of support forces a runtime change, and Drupal 10 requires PHP 8.1 or later while Drupal 11 requires PHP 8.3 or later. A core end of life date, such as Drupal 10 reaching end of life on December 9, 2026, starts a planned migration. A contributed module that stops working on a new core version can block the whole upgrade, so check module compatibility early in every planning cycle.
For many teams, the practical split is this. A small team with an existing Drupal developer often keeps routine patch releases in-house, since these are usually contained updates with a test pass. Major upgrades, out-of-hours security response and a planned retainer are often where a partner adds the most value, because they need concentrated effort and a defined response expectation. Ask any provider to write down the response times, the systems covered and who approves changes before work starts.
DeployOpen runs this work in infrastructure you control, including your cloud accounts, data centers or air-gapped networks, so patching and upgrade evidence stays in your environment. DeployOpen prepares systems, controls and records for your compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies.
What the work includes
A Drupal support engagement covers the routine release work that keeps a site patched, plus the larger projects that move it to a supported major version. Scope, deliverables and response expectations are agreed in writing before work starts.
Release monitoring and triage
Core bugfix releases arrive on the first Wednesday of each month, and security releases arrive on the third Wednesday. We track both windows, read each advisory against your installed core and contributed projects, and classify what applies to your site. Ask which advisories your team will review and how quickly triage starts after a release, and define both in the written scope.
Composer-managed updates in staging
Updates are made through Composer so that every change is recorded in version-controlled dependency files. Each update is applied to a staging copy of production first, with configuration and database state matching live. Check that your hosting setup can reproduce the staging environment, because a staging copy that differs from production makes test results unreliable.
Contributed module compatibility checks
Before each release is applied, contributed modules are checked against the new core version and the PHP version your site runs. Some modules lag behind core releases, and an update that breaks a module can stall a security fix. Ask for a list of modules that are unmaintained or lack a release for the target version, so you can decide whether to replace, patch or remove them.
Major version upgrade projects
Major versions arrive roughly every three years, and each one requires a separate project with its own scope. The work covers PHP version requirements, deprecated API changes in custom code, theme and module readiness and content or configuration review. Confirm the target version and PHP version at the start, since both shape the effort and the test plan.
Regression testing and rollback checks
After each update, critical user journeys such as sign-in, content editing, forms and key pages are tested on staging. Backups are restored to a separate environment to confirm they work before a production change is made. Ask which test cases are standard, which are yours to supply, and how a failed update is reversed, including the time it takes to restore the database and files.
Retainer scope and fixed-scope projects
Recurring monitoring, patching and reporting are usually sold as a retainer, while major upgrades and one-off fixes are usually fixed-scope projects with agreed deliverables. Ask how the retainer boundary is drawn, which work falls outside it and how additional requests are priced. Scope, deliverables and response expectations are agreed in writing before work starts, and any response commitments should be defined there rather than assumed.
Reporting on applied changes
Each engagement ends a release cycle with a record of what was applied, what was deferred and why, and what was tested. This record is the evidence your auditors or internal risk team will ask for when they review patch management. Ask for the report format, the frequency and whether it includes advisory references so each change can be traced back to its source.
What drives cost and effort
This table lists the drivers that change upgrade and support effort, why each one matters and how to reduce it, and the PHP versions shown are the published Drupal requirements, not estimates of effort.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Contributed modules without a release for the target core | Each one needs a replacement, a patch or a fork before the upgrade can finish, and this work is often the least predictable item. | Count them from the Composer lock file and check each project page for compatibility with the target core. |
| Custom modules and hooks tied to core APIs | Deprecated or removed APIs break custom code, and each hook must be read and tested against the new core. | Run deprecation checks early, keep custom code small and test the behavior that matters to users. |
| Custom theme complexity | Twig templates, libraries and preprocess functions change with core, and heavily overridden themes need more review. | Keep overrides minimal and remove unused templates and libraries before the upgrade starts. |
| Number of environments and deployment automation | Each environment needs its own update and verification, and manual deployments add steps that must be repeated. | Automate builds with Composer and configuration export and import so every environment receives the same change. |
| Integrations such as SAML or OpenID Connect | Sign-in flows, role mapping and account creation must be retested after core and module updates. | Keep a written test script for each sign-in path and confirm module versions support the target core. |
| PHP version gap to the target core | Drupal 10 needs PHP 8.1 or later, Drupal 11 needs PHP 8.3 and Drupal 12 needs PHP 8.5, so older runtimes need upgrading first. | Check the PHP version in every environment and confirm hosting and extensions support the target runtime. |
| Still on Drupal 7 | Drupal 7 security support ended on January 5, 2025, and Drupal 7 sites cannot be updated in place to modern core. | Plan a migration with the core Migrate modules or Drush, and confirm whether an extended support provider is needed meanwhile. |
| Compliance evidence requirements | Assessors may ask for records of patch dates, test results and change approvals, which add work to each release window. | Agree the evidence list in writing before the upgrade and confirm with your auditor which records they expect. |
How a support engagement or upgrade runs
The sequence moves a Drupal site from an unknown baseline to a supported, documented state, with a known path for every security release and major version.
Audit the current baseline
We inventory Drupal core, the PHP version, the database, every contributed module and theme, and the custom code, then record which versions are installed and which have open security advisories. The output is a written baseline report that lists gaps, risks and the decisions you need to make before any work is scheduled.
Agree the cadence and scope
We agree in writing whether the work is a fixed-scope upgrade or an ongoing retainer, which release windows it covers, who approves changes, and how urgent security fixes are escalated. The output is a signed scope with named responsibilities and a calendar that matches the Drupal release schedule. Phase lengths depend on the audit findings and this written scope.
Set up staging under version control
We build a staging environment that mirrors production, manage dependencies with Composer, and track configuration export in version control so every change is reviewable. The output is a staging site that deploys from the same repository as production and a documented process for exporting and importing configuration.
Test and patch each release window
On each monthly bugfix release and each Wednesday security release, we apply updates to staging, run compatibility and regression tests on the critical workflows, and record the results. The output is a patched staging site with a short test report, followed by a production patch that is approved and logged.
Review deprecations and rebuild the test plan
For a major upgrade, we check deprecated API usage in custom code, confirm readiness of each contributed module for the target version, and rebuild the test plan around content types, forms, integrations and permissions. The output is a deprecation and module review with a decision for each item and an updated test plan agreed with your team.
Rehearse and run the production cutover
We run the full upgrade on a copy of production data, rehearse the cutover timing and steps, and then perform the production cutover with a documented rollback procedure ready. The output is a completed cutover with verified critical workflows and a rollback path that was tested in the rehearsal.
Hand over the run book and calendar
We document the architecture, deployment steps, backup and restore procedure, patch process and escalation contacts in a run book, and set up an update calendar aligned to Drupal release windows. The output is a handover session, a run book your team can follow without us, and a calendar of planned review dates.
What to keep in-house and what to outsource
This table shows which Drupal upgrade and support activities usually stay with your team and which a support partner typically takes on, along with the skills each one needs.
| Activity | Usually in-house or outsourced | Skills it needs |
|---|---|---|
| Monitoring Security Team advisories and CVE identifiers | Outsourced when under a retainer, in-house otherwise | Subscribing to Security Team notices, reading risk scores, mapping affected contributed projects to your site |
| Applying routine bugfix and security updates | Outsourced under a retainer, with in-house sign-off on content impact | Composer updates, test runs, staging deployment, rollback planning for the monthly and Wednesday release windows |
| Editorial and content owner decisions | In-house | Knowledge of content types, editorial workflows, business rules and which pages must not change |
| Major version upgrades | Usually outsourced for planning and build, with in-house testing and acceptance | Deprecated API remediation, contributed module readiness checks, PHP version planning, content and configuration validation |
| Contributed module replacement or custom patches | Outsourced for technical work, decided jointly with in-house owners | Module evaluation, custom module development, patch maintenance, Drupal coding standards |
| PHP and web server upgrades | Shared, with the partner often leading the compatibility work | PHP version compatibility, Apache or Nginx configuration, Composer dependency resolution, hosting team coordination |
| Database and backup testing | Shared, with restore tests run by whoever owns the infrastructure | Database administration on MariaDB, MySQL, PostgreSQL or SQLite, restore procedures, documented recovery time |
| On-call coverage for critical advisories | Retainer partner gives coverage when internal staff are unavailable | Out-of-hours response, incident triage, access to production and hosting providers, clear escalation contacts |
What usually goes wrong
Most Drupal upgrade and support problems trace back to a short list of habits. Each card names a failure pattern and the prevention step that stops it.
Security releases treated as optional
Teams often hold back an update because it contains no new features, so a security fix waits for the next planned change. Security releases for Drupal core and contributed projects come out on the third Wednesday of the month, and advisories name the risk. Prevention: assign one named owner who subscribes to Security Team advisories, and set a fixed window to apply them.
Changes made directly on production
Updates applied straight to production, or edits made in the database or file system, leave the live site different from the code in version control. Without a staging copy, a broken module or theme reaches users first, and configuration drifts from what the team deployed. Prevention: test every update on a staging copy, move configuration through export and import, and deploy only from version control.
Contributed module without a target release
A contributed module may have no release compatible with the Drupal core version you need, which blocks the whole upgrade. Module maintainers sometimes stop work, and a project can lag behind a new major version. Prevention: before scoping, list every contributed module, check its release history against the target core version, then decide to replace, fork or drop each one.
Custom code using deprecated APIs
Custom modules and themes that call deprecated APIs keep working on the current version but fail once a later major release removes them. This code often hides in hooks, services and Twig templates that no one has reviewed since the last build. Prevention: run deprecation scans against custom code for each target version and fix the findings in an upgrade branch covered by automated tests.
Unsupported PHP after a host change
A move to a new hosting platform can bring an older PHP version that the current Drupal release does not support. 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. Prevention: pin the PHP version in the hosting contract or container image, check it against the target Drupal release, and record it in every change request.
Drupal 7 with no migration plan
Drupal 7 security support ended on January 5, 2025, and a Drupal 7 site cannot be updated in place to Drupal 10 or later. Sites left without a plan carry known risk, and themes must be rebuilt during migration. Prevention: start a content and module audit now, use an extended security support provider only as a stopgap, and set a cutover date tied to a funded migration plan.
What the client needs to provide
Before a quote or kickoff, the client needs to give us working access and decisions, not just a brief. Start with read and write access to the Git repository that holds the Drupal codebase and its Composer files, including composer.json and composer.lock, plus staging and production access inside your own infrastructure. We also need a current backup of the database and files, and a restore path you have tested. A backup nobody has restored is a risk to plan for, not a control.
Next, provide the inventory the upgrade depends on. List every enabled contributed module with its installed version, the PHP and database versions in use (MariaDB, MySQL, PostgreSQL or SQLite), and the owner of each custom module or theme. Custom code without a named owner usually becomes the longest item in the plan, because someone has to decide whether it still works, is deprecated or should be replaced.
Decisions matter as much as access. Set the acceptable downtime windows for the upgrade and for routine security releases, and name a business owner who approves content and feature impacts. Name a security contact who receives Drupal Security Team advisories and can confirm which sites they apply to. Agree the approval path for production changes now: who signs off, who can halt a release, and how emergency patches are handled outside the normal schedule.
Finally, tell us what evidence your auditor will expect. DeployOpen does not issue compliance certificates or audit reports. We can, however, prepare update records, change logs, test results and patch history that your independent auditor can review. Ask your auditor which of these artifacts they need and in what format, so the evidence is captured during the work rather than reconstructed afterward.
How the work changes by starting point
A Drupal 10 site needs readiness work for Drupal 11 before its end of life, and the scope centers on that move. The sibling page on Drupal 10 end of life covers the upgrade steps in detail, so this tab only summarizes what changes for support.
- Scope: Contributed module compatibility review, deprecated API checks and a PHP upgrade to a version Drupal 11 supports (Drupal 11 requires PHP 8.3 or later).
- Testing: A staging copy of production with automated and manual regression tests before the monthly bugfix window.
- Cadence: Keep applying bugfix and security releases on Drupal 10 until the upgrade is complete.
- Confirm: Your Drupal 10 end of life date in the core release schedule and whether any custom modules depend on removed APIs.
A Drupal 11 site is on the current major version, so the work is routine maintenance on a steady cadence rather than a version change. Most effort goes into keeping pace with the release calendar and contributed modules.
- Scope: Monthly bugfix updates, security updates applied from advisories, and Composer-managed dependency updates.
- Testing: Each update passes through a staging environment with regression checks on forms, workflows and integrations.
- Cadence: Bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, so plan a window for both.
- Confirm: Your team's approval process for out-of-cycle security releases and the rollback procedure for failed updates.
A Drupal 7 site cannot be updated in place to a supported version, because Drupal 7 security support ended on January 5, 2025. If the migration cannot happen yet, an extended security support provider is the stopgap, and the migration remains the long-term path.
- Scope: Enrollment with an extended security support provider, with the migration to modern Drupal planned as a separate project.
- Testing: Confirm that the provider's patches are tested against your modules and theme before deployment.
- Cadence: Follow the provider's delivery schedule for patches, which may not match the core monthly release calendar.
- Confirm: The providers listed in the Drupal Association program, their terms, and the migration date your organization can commit to.
A site built on Drupal CMS is a distribution on Drupal core, so it inherits core security releases while its recipes and site templates add components you must also maintain. Support scope depends on which recipes and optional AI tools you installed.
- Scope: Core updates plus updates to the Drupal CMS distribution and the recipes or site templates your team adopted.
- Testing: Test the Drupal Canvas visual page builder and any optional AI tools separately from core features, since they change more frequently.
- Cadence: Track the current major release, Drupal CMS 2.0, and plan distribution upgrades alongside core updates.
- Confirm: Which recipes are in use, whether AI features are enabled, and whether your organization accepts their data handling terms.
A site on Kubernetes or in an air-gapped network cannot pull updates directly from the internet, so advisory patches must be moved in through an internal mirror. The timing of each update depends on your transfer process as much as on the release calendar.
- Scope: Mirror creation for Drupal core, contributed modules and Composer packages, plus container image rebuilds for each release.
- Testing: Verify package checksums and run regression tests in a non-production cluster before promotion.
- Cadence: Security advisories may arrive faster than your transfer and approval cycle, so define who decides on emergency transfers.
- Confirm: Your mirror tooling, how often transfers are permitted, and whether your cluster and database configuration match the supported system requirements.
Questions buyers ask before hiring help
Does Drupal have a license fee for upgrades?
No. Drupal and the contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. What you pay for is the work around the code: planning the upgrade, testing it against your custom code and contributed modules, deploying it, and keeping the site supported over time. Hosting, PHP upgrades and any commercial add-ons or extended support you choose are separate costs to confirm in your own environment.
How often does Drupal release security and bugfix updates?
Bugfix releases arrive on the first Wednesday of each month, and security releases arrive on the third Wednesday. Build a standing review for both dates so a security release does not sit until the next planned maintenance window. Follow Drupal Security Team advisories, which include CVE identifiers and risk scores, and decide in advance how quickly each one reaches each environment. Check these dates against your own change approval calendar before you commit to a schedule.
How often does Drupal ship a new major version?
The core release schedule says new major versions typically arrive every three years. Drupal 11 is the current major version, and Drupal 12 is scheduled for the week of December 7, 2026. Drupal 10 reaches end of life on December 9, 2026, so sites still on it need a plan before that date. Major upgrades cost more effort than routine updates because they involve deprecated code, new PHP requirements and contributed module readiness. Confirm the PHP version each release needs against your hosting before you set a date.
What changes the price of a Drupal support retainer?
The scope agreed in writing is the starting point. It defines which environments are covered, which services are included and how much review and response time you need. Contributed modules add work because each one has its own release history and compatibility with your Drupal version. Custom code adds testing and review work, since Drupal.org does not maintain it for you. Every additional environment adds testing and deployment steps. Ask the quote to list each driver separately and to state what is included each month and what is billed as project work.
Can an in-house team handle Drupal updates without a partner?
Yes, a capable in-house team can handle routine updates alone if it runs a staging process and monitors advisories. Routine work means applying bugfix and security releases, updating Composer-managed dependencies and running automated tests on a copy of production before each change. The harder cases are major version upgrades, contributed modules that lag behind a new core release and custom code that relies on deprecated APIs. Decide in advance who reviews advisories, who approves a release and who responds when a patch breaks a feature.
How does a support retainer differ from a one-off upgrade project?
A one-off upgrade project has a fixed scope, deliverables and end date, agreed in writing before work starts. A retainer covers ongoing work under an agreed scope, such as monitoring advisories, applying bugfix and security releases, keeping contributed modules compatible and responding to incidents. Either model needs the same inputs: access to your environments, a tested backup and named owners who approve changes. A common path is a project to reach a supported version, followed by a retainer to stay on it.
How DeployOpen delivers Drupal support
DeployOpen scopes, builds, tests, documents and hands over Drupal upgrades and support inside the infrastructure you control, with ongoing support available as a retainer. Each step is written down so your team can run the site after the engagement ends.
How we scope
- Inventory the Drupal core version, PHP version, database, web server and every contributed and custom module in use.
- Map each module to its compatibility status with the target Drupal version and flag any that need replacement or custom work.
- Agree the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.
How we build
- Run upgrades in a staging environment built from a copy of production, using Composer to manage core and contributed versions.
- Address deprecated API usage in custom code and test contributed module updates against the target release before cutover.
- Align the patching process with the Drupal core release schedule, including first-Wednesday bugfix and third-Wednesday security windows.
How we hand over
- Document the upgrade path, dependency versions, deployment steps and rollback procedure in a format your team can follow.
- Walk your team through the monthly and security release process, including how to check advisories and apply updates.
- Confirm with your team which environments, accounts and access levels they will own after handover.
How we support
- Scope a support retainer that covers the update cadence, module monitoring and response activity your site needs.
- Review contributed module maintenance and PHP version support ahead of each Drupal major release cycle.
- Ask for a written statement of what the retainer covers, how requests are prioritized and how updates are tested.
