Why a Drupal monthly maintenance routine matters
A live Drupal site needs a fixed patching rhythm so that security and bugfix releases reach production on a schedule the team controls, not whenever someone notices an advisory. The routine described on this page is built around the release calendar in the Drupal core release schedule: bugfix releases arrive on the first Wednesday of each month, and security releases arrive on the third Wednesday. Because those dates are published in advance, a team can plan triage, staging tests and production windows around them instead of reacting under pressure. Drupal core and the contributed modules hosted on Drupal.org are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. The cost of staying current is therefore operational rather than a license purchase: staff time, a staging environment that mirrors production, and the people who test and sign off changes. Any live site that runs contributed modules needs this routine, because contributed projects are updated on their own schedules and a core update alone does not keep the codebase current. The routine does not cover major version upgrades, such as the move from Drupal 10 to Drupal 11 or the planned Drupal 12 release, and it does not replace a migration off an unsupported version. Drupal 7 security support ended on January 5, 2025, and those sites need a different plan. Confirm with your own team which Drupal and PHP versions your site runs before you adopt a monthly cycle, because a site on an end-of-life branch cannot be kept safe by routine patching alone.
How the monthly cycle runs, week by week
The sequence turns Drupal's published release windows into a repeatable routine: each month, advisories and releases are reviewed, changes are tested on staging, and production is updated in a planned change window with a written record of what was patched. The result is a site that stays on supported code and an audit trail that shows when and why each change happened.
Monitor advisories and the release calendar
Early in each month, the maintainer checks the Drupal core release schedule and the Drupal Security Team advisories for core and every contributed project on the site. Bugfix releases arrive on the first Wednesday of the month and security releases on the third Wednesday, so the calendar sets when work is planned. The output is a dated list of incoming releases and any advisories that affect installed modules, themes and core, recorded in the maintenance log.
Triage core and contributed updates
The lead engineer reviews each pending update and sorts it by urgency: security fixes first, then bugfixes, then minor version moves. For each item, they check the Drupal.org project page for compatibility notes, confirm the PHP version the release requires, and flag any contributed module that is abandoned or lacks support for the current Drupal version. The output is a triage sheet that names each change, its risk, its owner and whether it goes into this cycle or the next.
Apply updates to a copy of production
Updates are applied to a staging site refreshed from a recent production database and files, using the same codebase and Composer lockfile that production runs. Database updates, configuration changes and any custom code affected by the update are run in that order and logged. The output is a staging build with recorded update output and a clean error log, and any failure is written up before anything moves forward.
Test critical paths on staging
The team runs a fixed checklist on staging: login and any single sign-on flow, content creation and editorial workflow, forms, search, payment or integration endpoints, and the pages with the most traffic. Automated tests and visual checks run where they exist, and results are compared with the previous release. The output is a signed test record that lists each check, the tester, the result and any defect that blocks release.
Schedule the production release in a change window
The release is booked into an agreed change window, usually after the Wednesday release that carries the updates, so the team can respond if a patch causes trouble. The rollback plan is written down: the pre-update backup to restore, the code tag to revert to and the person who decides to roll back. The output is an approved change record that names the window, the approvers and the rollback steps.
Deploy to production and verify
The release is deployed from the same tagged build tested on staging, with a fresh backup taken immediately beforehand. After deployment, the team runs the same critical-path checklist on production, watches the error log and cron output, and confirms the health endpoint responds. The output is a verification record with timestamps, the versions now running and confirmation that no new errors appeared in the first hours.
Report what was patched
The team issues a short maintenance report to the site owner and security contact. It lists every core and contributed update applied, the advisory identifiers and risk levels where published, any updates deferred and why, the staging and production verification results and any incident. The output is a monthly record that the site owner can file for audit, risk review or a future upgrade decision.
Triaging security advisories against bugfix releases
Security advisories do not wait for the monthly bugfix cycle. The Drupal Security Team resolves reported vulnerabilities in Drupal core and contributed projects, publishes advisories with CVE identifiers and risk scores, and ships fixes in security releases on the third Wednesday of the month. Bugfix releases come out on the first Wednesday. Your routine should treat the two as separate inputs: bugfix releases are scheduled hygiene you batch into the monthly cycle, while each advisory needs its own triage record stating the affected project, the affected versions in your codebase, the risk score, and whether your site exposes the vulnerable path. Confirm the current advisory feed and notification options on the Drupal Security Team page before you rely on them.
Decide urgency from exposure, not from the score alone. Start with whether the affected module or core component is installed and enabled, whether the vulnerable code path is reachable by anonymous or low-privilege users, and whether the site runs a configuration the advisory describes. A high risk score on a feature you do not use may wait for the next window, while a moderate advisory on an anonymous-facing form may not. Contributed modules are the harder case. When a project has no stable release that includes the fix, your options are a dev release, a backported patch that your team or a vendor maintains, removing or disabling the module, or a temporary control such as blocking the path at the web server. Record which option you chose, who owns the patch, and when it returns to the normal cycle. If you cannot name an owner for an unreleased fix, treat that as a finding for the next review.
Which maintenance model fits which team
This table compares an in-house routine, a scheduled retainer and a managed hosting arrangement across who triages Drupal updates, who tests them, who approves release and what evidence is kept. Read each row against your own staffing and change controls, because the main takeaway is that the model matters less than whether one named person owns approval and the record of what was patched.
| Responsibility | In-house routine | Scheduled retainer | Managed hosting arrangement |
|---|---|---|---|
| Who runs triage | Your developers review core and contributed release notes after each first-Wednesday bugfix and third-Wednesday security release | Partner reviews advisories and release notes each cycle and proposes a patch list | Host applies platform patches; module-level triage often stays with your team unless the contract says otherwise |
| Who tests on staging | Your QA or developers run regression checks on a staging copy | Partner runs the staging regression pass and reports failures | Often the customer or a separate agency; confirm whether the host tests Drupal modules at all |
| Who approves release | Named product owner or service manager signs off before production | Your named approver signs off on the partner's change list | Usually your change board; confirm the host's emergency patch path and approval window |
| Evidence kept | Your own change tickets, staging results and a patch log you maintain | Partner's written patch report per cycle, held alongside your change records | Host logs for platform changes; Drupal-level evidence may be thin, so request it in writing |
| Best fit | Teams with Drupal developers available each month and an established change process | Teams without spare Drupal capacity that still want a documented monthly cycle | Teams that want infrastructure managed and can accept limited visibility into module changes |
| Main risk | Security releases slip when the one developer who knows the site is unavailable | Scope creep or unclear ownership of failed tests after a patch | Assuming the host covers contributed modules and themes when it does not |
What staging tests must cover before release
A monthly Drupal patch is only safe to release once it has been applied to a copy of production and exercised in the same ways production is used. The six areas below cover what staging has to prove, and each one catches a different class of failure.
Core and contrib update on production data
Apply the core and contributed updates to a copy of the production database and files, not a fresh install with sample content. Mismatches between old and new code often only show up against real nodes, media, taxonomy and user records. Confirm that the staging copy is refreshed from a recent production backup and that personal data is masked before anyone outside the team uses it. Record the exact versions applied so the release notes match what was tested.
Database updates
Run database updates with drush updatedb against the copied data and read the output for failed or skipped update hooks. A hook that fails halfway can leave a site in a partly updated state that is hard to recover from in production. Time the run on a copy of realistic size, since large tables can make some updates slow enough to need a maintenance window. Confirm that a database backup is taken immediately before the production run.
Configuration import
Export configuration from the staging copy after updates, then compare it with the version held in version control. Unexpected diffs often come from a contributed module changing its default settings, which can alter access rules, field display or URL behavior without any code change in your project. Run drush config:status and review every change before importing. Confirm who signs off on configuration changes that were not made by your team.
Custom module regression
Run the automated tests for your custom modules and walk through the business processes they support, such as checkout, form submissions, approval steps and custom entity workflows. Deprecated API calls in your code are a common result of a core or contributed update, and they may not raise visible errors until a specific path runs. Confirm that the regression list is written from your own business processes, not only from the default test suite.
Theme and front-end checks
Load the key page templates, forms, navigation and responsive breakpoints on staging, and check the browser console for JavaScript errors. Updates to core front-end libraries or to the theme's build tooling can break layouts and interactive components without changing any PHP. Include any headless or decoupled front end in the same pass if it consumes Drupal APIs. Confirm the list of templates to check with the people who own the design and accessibility commitments.
Cron and queue behavior
Confirm that cron still runs on schedule after the update, that queue workers drain normally, and that scheduled jobs such as imports, search indexing and cache rebuilds finish without errors. A broken cron run can stop content publishing or email delivery silently for days. Check the cron log and the queue size before and after the update. Confirm the cron method (Drupal's built-in cron or an external scheduler) in your own hosting setup, since this differs between environments.
Releasing safely and reporting what was patched
The production release is where a monthly maintenance cycle either protects the site or puts it at risk, so the sequence matters more than the speed. Take a verified backup of both the database and the files before anything changes, and confirm that the backup restores on a separate environment. Schedule the release inside an agreed maintenance window, announce it to content editors and site owners, and put the site into maintenance mode only for the period the database update and config import actually need. Before the window opens, confirm that the staging build was produced from the same Composer lock file that will go to production, so the release contains exactly what was tested.
The release itself follows a fixed order. Apply the updated packages with Composer, then run drush updb to apply database updates, then drush cim to import configuration, and clear caches with drush cr. Check that drush config:status reports no differences you did not expect, because a config import that changes settings without review is a common source of post-release surprises. Define the rollback path in writing before the window: who decides to roll back, which backup is restored, and how the code is reverted. Ask your partner or internal team to show a rehearsal of that rollback on staging. Note that Drupal sites usually sit on a web server, PHP runtime and database that also need patching. The PHP requirement depends on the Drupal version: according to the Drupal.org PHP requirements page, 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. Check the PHP version against the Drupal version in the same change record, because a Drupal update can require a PHP upgrade first.
The monthly report is the record that proves the cycle happened and tells the next reader what changed. For each release, list the Drupal core version and every contributed module and theme version before and after the update, the security advisories addressed, with their identifiers, and any findings you deferred. Include the PHP, web server and database versions as well, since those are part of the attack surface. Close the report with open items: modules without a stable release for the current Drupal version, patches you carry locally, and anything that failed testing. The report should be written so an auditor or a new administrator can reconstruct the site's state at any point. Confirm with your partner exactly which artifacts they will deliver each month, such as a Composer diff, the drush pm:list output and the test log, and where those artifacts are stored.
Version constraints that can block a monthly update
A monthly bugfix or security release only applies cleanly when the server stack and the contributed code still fit the Drupal version in production. The four constraints below are the ones most likely to turn a routine patch into a project, and each needs a check before the next release window opens.
PHP floor for each major version
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. No supported Drupal version runs on PHP 7. A PHP upgrade is a server change with its own testing, so it cannot ride along with a monthly core update. Check the PHP version on every environment, including the staging copy, and confirm the upgrade window before you schedule a major Drupal move.
Drupal 10 end-of-life date
Drupal 10 reaches end of life on December 9, 2026, according to the core release schedule. After that date, monthly security releases no longer cover the site, so the routine stops being a safe holding pattern. Add the date to your planning calendar now, and start the Drupal 11 readiness review early enough that the upgrade has its own test cycle. Confirm the current schedule with Drupal.org before you commit to a date.
Drupal 7 without core security support
Drupal 7 security support ended on January 5, 2025, so monthly security releases no longer reach core or Drupal 7 modules. Drupal 6 and 7 sites cannot be updated in place to a supported version. They are migrated into a new site and their themes are rebuilt. If you cannot migrate yet, the Drupal Association lists certified extended security support providers, and you should ask any provider exactly which modules and advisories they cover.
Contributed modules without a current release
A contributed module may have no release for the Drupal major version you run, or its maintainer may have stopped responding. A monthly update can then leave a module on an unsupported line or break it when core moves. Build an inventory of every contributed project with its supported core versions and last release date. Any module without a path forward becomes a replacement, patch or removal task with its own estimate, not a routine update.
Questions teams ask before running Drupal maintenance
What does the monthly Drupal maintenance routine cost in effort, and what drives it?
The recurring effort depends mostly on how many contributed modules and custom modules the site runs, how far behind the current release it is, and how much testing the business expects before each release. A site with few contributed dependencies and good automated tests needs far less attention than one with many modules that have their own release cadence. The cost has two parts: a fixed routine each month (triage, staging deploy, smoke tests, release notes) and variable work when a release changes something important. Ask any quote to break these into recurring and one-time components, state how many modules and environments are in scope, and say which party tests and approves each release.
Can an in-house team run the Drupal monthly routine itself?
Yes, if it has someone who can read release notes, reproduce issues on staging, and roll back a deployment. The routine itself is straightforward: review the bugfix and security releases, apply updates to a copy of production, run functional checks, and promote the change. The harder part is staying on schedule. Drupal's bugfix releases come out on the first Wednesday of each month and security releases on the third Wednesday, so a team needs someone available on those days, not only in a planned week. Teams that lack Drupal depth in-house often use a retainer for the routine and keep approval and business testing internally.
How long does a typical monthly maintenance cycle take, and what changes it?
The length of a cycle depends on the scope of testing, the number of environments and how many updates arrive in the same window. A cycle with a clean bugfix release and automated checks can be short, while one that includes a security release touching a contributed module, or a dependency that needs a PHP or database change, takes longer. Timing also matters: a bugfix release on the first Wednesday and a security release on the third Wednesday can fall in the same month, which means two rounds of triage. Ask for the cycle plan in writing, including the testing window, the release day, and what triggers an out-of-cycle change.
What does the routine need from our team?
The routine needs four things before it starts: read and write access to the code repository and hosting platform, a staging environment that mirrors production closely enough to test, a agreed change window, and named approvers who can sign off a release. Without a staging copy, every update becomes a production test. Access should be scoped to the systems the routine touches, and credentials should be stored in your secrets tooling. Confirm with your own team who approves security-driven releases, since those often cannot wait for the next scheduled window.
What happens when a security release lands outside the plan?
A security release is handled as an exception to the monthly plan. Drupal's Security Team publishes advisories with CVE identifiers and risk scores, and its security releases come on the third Wednesday of the month. When a release affects a module you run, the team triages it, applies the patch to staging, runs checks, and schedules production deployment according to the agreed emergency process. Your written scope should state the response expectations for security releases, who can authorize an emergency deployment, and how the work is billed when it falls outside the retainer. Confirm these terms before an incident, not during one.
How do Drupal 7 sites differ in this routine?
A Drupal 7 site cannot follow the monthly routine in the same way because it cannot be updated in place to Drupal 10 or later. Drupal.org documentation says these sites are migrated into a new site with the core Migrate modules or with Drush, and themes must be rebuilt. Drupal 7 security support ended on January 5, 2025, so a site still running it depends on a paid extended support provider, such as HeroDevs or Tag1 Consulting, which the Drupal Association lists as certified vendors. The routine for a Drupal 7 estate is therefore a migration plan first, with any patching handled through an extended support arrangement until the move is complete.
Which Drupal versions will need maintenance planning next?
Drupal 11 is the current major version. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Drupal 12 requires PHP 8.5 or later, and Drupal 11 requires PHP 8.3 or later, so a site on an older PHP version may need a runtime upgrade before core can move. Confirm your current core and PHP versions against these dates in your own environment, then include the upgrade work in the scope so the routine does not hide a major version change.
Security and operational considerations in the cycle
Each monthly cycle moves code and data through more hands and systems than the release itself suggests. The controls below cover the pipeline, the approval step, the restore point, the staging copy and the record of changes, so that a patch can be traced, reversed and explained.
Scope pipeline credentials to one job
The account that pulls updates, pushes to the repository and deploys to staging holds the most leverage in the cycle. Give the pipeline a deploy key or service account per environment, store its secrets in your CI secret store or a vault, and keep production write access out of the job that runs Composer updates. Rotate these credentials on a schedule you can name, and confirm that a revoked key stops a pending deploy. Check whether any Drush or database credential is written into settings.php or the repository.
Separate who builds from who approves
A release should need a named approver who did not write the update branch and who is not the only person able to deploy it. Record the approval in the ticket or merge request, and make production deployment a protected step in the pipeline. Keep the approver list short and current, and confirm who can approve when the usual person is unavailable on a security release date, since those windows fall on a fixed Wednesday.
Prove each backup restores before the change
Take a database and file backup immediately before applying the update, and restore it to a scratch environment at least once per cycle to confirm it is complete and usable. A backup that exists but has never been restored tells you little during a failed drush updatedb run. Note the backup identifier in the release record so that a rollback targets a known point. Backup tooling and schedules are covered on the sibling backup page.
Control access to staging copies with production data
Staging is refreshed from production so that testing reflects real content, but that copy carries personal data from users, submissions and logs. Restrict staging access to the same people who need it for testing, disable outbound email and payment or CRM callbacks, and anonymize user records where the test does not need real addresses. Ask whether the refresh process is documented, who authorizes it, and when the copy is deleted.
Log who applied which update
Keep a dated record for each release that names the Drupal core and contributed module versions before and after, the security advisories addressed, the approver, the deployer and the backup identifier. Use the same record for out-of-cycle security patches. Store it outside the Drupal site so that it survives a rebuild, and make it the source for the monthly report. Confirm where pipeline logs are retained and who can read them.
How DeployOpen approaches Drupal maintenance
DeployOpen starts by agreeing the maintenance routine in writing before any work begins. The written scope names the Drupal core and contributed modules in the estate, the environments involved (production, staging and any build or preview systems), the people who approve each release, and the reporting format the client expects. It also states which items are excluded, such as custom code changes, content work or theme redesigns, so that a monthly update is never mistaken for a feature project. Because the routine follows Drupal's own cycle, the scope should reference the first Wednesday bugfix window and the third Wednesday security window from the Drupal core release schedule, and it should say how urgent out-of-cycle advisories are handled.
Each cycle then runs in the same order. The team triages the month's core and contributed releases and Security Team advisories against the installed versions, then applies the updates to a copy of the production codebase on staging, using a database and files sync that matches production as closely as the client's policies allow. Tests cover login, content editing, forms, search, payment or integration paths and custom code, with Composer lock file changes reviewed before release. Releases run in the client's own cloud accounts or data centers, with a pre-release backup and a rollback plan written down. The client keeps approval rights over every production change.
After each release, DeployOpen delivers a short report listing the core and contributed items patched, the advisories addressed, the tests run, any deferred items with reasons and open risks. Ongoing support, upgrades and continuous testing are available as retainers, and the cycle can be bundled into one. DeployOpen prepares these routines, controls and evidence, but it does not issue audit reports, attestations or certifications. If a client needs independent assurance, the report is an input for their auditor, who should confirm which evidence they require before the routine starts.
How DeployOpen scopes and supports Drupal maintenance
DeployOpen plans and runs Drupal maintenance inside your own infrastructure, from cloud accounts and data centers to air-gapped networks. Engagements are fixed-scope, with the routine agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Inventory the Drupal core version, contributed modules, themes and PHP and database versions in use.
- Agree which monthly bugfix and security windows the routine will cover, and who triages each release.
- Define staging environments, test coverage, rollback steps and the reporting format before the first cycle.
How we build
- Set up a repeatable triage checklist that sorts each release into core, contributed and custom code changes.
- Apply updates on a staging copy of production, then run agreed functional and regression checks.
- Record each change, its security advisory reference where one exists, and the test results before release.
How we hand over
- Deliver a written runbook covering the monthly steps, approval points, rollback and escalation contacts.
- Provide a patch report template that lists what was updated, what was deferred and why.
- Walk your team through one full cycle so they can run the routine without DeployOpen present.
How we support
- Offer ongoing monthly maintenance as a retainer with the scope and response expectations written out.
- Review upcoming Drupal core major version changes so planning starts before deadlines arrive.
- Confirm with your own team and the Drupal.org release notes which items fall under each agreed window.
