Drupal isn't set it and forget it
It's easy to think of a website as finished once it launches. Drupal doesn't work that way. A Drupal site is a living stack of software (Drupal core, dozens of contributed modules, the Symfony components underneath, PHP, the database, and the server) and every layer moves on its own schedule:
- Security advisories are published regularly for core and contributed modules. Critical ones need to be applied within days, not whenever someone gets around to it.
- Minor releases of Drupal core ship about twice a year, and each minor release is only supported for a limited time.
- Contributed modules update independently, and some get abandoned by their maintainers entirely.
- PHP versions reach end of life too, and hosts eventually stop offering the old ones.
- Major versions arrive roughly every two years, and each one has a fixed end-of-life date.
What Drupal maintenance actually involves
Here's the work that typically goes into keeping a Drupal site healthy. Most organizations are surprised by how much of it there is.
Security updates
Watching Drupal security advisories and applying patches quickly, especially for critical vulnerabilities that attackers start scanning for within hours of disclosure.
Module and core updates
Keeping core on a supported minor release and modules current, resolving dependency conflicts, and replacing modules that have been abandoned.
PHP and hosting compatibility
Moving to newer PHP versions as old ones reach end of life (Drupal 11 requires PHP 8.3), and making sure the server, database, and caching keep up.
Database and config updates
Running database updates after each release and keeping configuration in sync between local, staging, and production so changes deploy cleanly.
Backups and recovery
Automated backups of the database and files, plus periodic restore tests. A backup nobody has ever restored is a guess.
Monitoring and performance
Uptime checks, error log review, cron health, caching, and page speed, so problems get caught before they reach your visitors or your inbox.
Bug fixes and small changes
A broken form, a layout glitch after an update, a new field or content type, a CKEditor quirk. The steady trickle of fixes every site generates.
Content editor support
Answering "how do I…?" questions, fixing permissions, and making the admin experience easier for the non-technical staff who update the site.
Planning the next upgrade
Scanning for deprecated code and module readiness so each major version upgrade is a small, planned step instead of a scramble.
How often each task comes up
| How often | Typical Drupal maintenance tasks |
|---|---|
| As released | Critical security updates for core and contributed modules |
| Monthly | Module and core updates, database updates, log and error review, backup checks |
| Quarterly | PHP and hosting review, performance and accessibility checks, restore test, deprecation scan |
| Twice a year | Move to the latest Drupal core minor release before the old one loses support |
| Every ~2 years | Major version upgrade (for example Drupal 11 to 12) |
What happens when maintenance slips
- Security exposure. Known, public vulnerabilities stay open on your site. See how Drupal security works.
- Update debt compounds. Ten small updates are easy. One giant leap across years of changes is not.
- Upgrades get expensive. A site kept current moves to the next major version in days. A neglected one can take months.
- Compliance and insurance risk. Unpatched software can fail PCI-DSS, HIPAA, and cyber-insurance requirements.
- Emergencies happen on someone else's schedule. When the site goes down, there's no one who knows it well enough to fix it fast.
Your team is already wearing many hats
In most organizations, the Drupal site belongs to someone whose real job is something else: marketing, communications, IT, or operations. Maintenance gets done between other priorities, which means it often doesn't get done at all.
Modern Drupal also asks more of whoever maintains it. Since Drupal 11, modules are installed and updated through Composer on the command line, not the admin screen. Doing it safely means a staging environment, Drush, and someone who knows what to do when an update conflicts. That's a specialist skill set, and it rarely makes sense to build it in-house for a few hours of work a month.
A Drupal expert on hand gives your team:
- Time back to focus on content, campaigns, and the work only they can do.
- Someone who already knows the site when something breaks, instead of a scramble to find help.
- Predictable upkeep rather than surprise projects and emergency invoices.
- A clear path forward on upgrades, so end-of-life dates never sneak up again.
Want a Drupal expert in your corner?
Tell us what you're running and how it's maintained today. We'll take a look and suggest the right level of support for your site and your team.
Ways to get Drupal support
Every site and team is different, so there's no one-size plan. These are the most common ways we work:
Ongoing maintenance
A monthly plan covering security updates, module and core updates, monitoring, and backups, with a set block of hours for fixes and small changes.
Time and materials
Help when you need it, billed for the actual work. Good for sites with lighter needs, one-off fixes, or teams that want flexibility.
Upgrades and projects
Major version upgrades, migrations, new features, or a redesign, planned and delivered as a defined project.
Start with an audit
A review of your Drupal version, modules, custom code, hosting, and security posture, so you know exactly what your site needs before committing to anything.
Inherited a site you didn't build? That's the norm, not the exception. Most maintenance relationships start with a site someone else built, which is why we begin with an audit.
Tell us what you need
Share your site and a bit about how it's maintained today. We'll check your Drupal version and update status, flag anything urgent, and recommend the right kind of support, whether that's an ongoing plan, time and materials, or a one-time fix. No obligation.
We'll email you back and may follow up if we spot significant issues worth fixing. No spam.
Drupal support and maintenance: frequently asked questions
What does Drupal support and maintenance include?
Applying core and contributed module security releases, routine updates through Composer, keeping PHP and hosting compatible, database updates, backups and restore tests, monitoring logs, uptime and performance, helping content editors, and planning the next major version upgrade.
How often does a Drupal site need maintenance?
Security advisories can land any week, and critical ones should be applied within days. Most sites need routine updates monthly, a broader health check quarterly, and a major version upgrade roughly every two years.
How much does Drupal maintenance cost?
It depends on the size of the site, how many modules and custom integrations it has, and how current it is today. Common models are a monthly plan with a set block of hours, or time and materials billed only for the work done. A quick look at your site is the fastest way to get a real number.
Can our team just handle Drupal updates ourselves?
Some can. Modern Drupal is Composer-first, so updates require command-line access, Composer and Drush comfort, and a staging environment to test in. Teams without that, or without the time, usually find an outside Drupal expert cheaper than the hours lost.
Do you support Drupal sites you didn't build?
Yes. Most maintenance engagements start with a site we didn't build. We begin with an audit of the version, modules, custom code, and hosting so we know exactly what we're taking on.
We're on an end-of-life version. Can you still maintain it?
We can help keep it stable and as secure as possible in the short term, but there's no substitute for getting onto a supported version. We'll help you plan that move. See the upgrade paths for where to start.