What Enterprise Drupal Maintenance Covers, and What It Does Not

Drupal maintenance is sold as a monthly line item and understood as “keeping the site up”. That description hides the part that matters, which is that Drupal has a published, predictable release discipline, and a site either keeps pace with it or gradually becomes impossible to update at all.

Here is what the work is, what it is not, and how to tell whether the contract you have covers the thing that will eventually hurt.

The security cycle, which is the non-negotiable part

The Drupal security team publishes advisories on a regular schedule, for core and for contributed modules. Advisories carry a severity, and a critical one in a module you use is not something that waits for the next convenient window.

A maintenance arrangement worth paying for therefore has to include somebody actually watching the advisories for your module list, a defined response time by severity, and an environment where a patch can be tested before it goes near production. If any of those three is missing, what is being bought is monitoring, not maintenance.

The reason this matters more on Drupal than on a smaller platform is the module list. A serious Drupal site runs dozens of contributed modules, each with its own maintainer and its own pace. The site’s exposure is the union of all of them.

What routine maintenance actually contains

• Applying core and module updates, tested, in a defined window, with a rollback path.
• Dependency management. On a modern Drupal site this is Composer, and it is where most update pain lives: a module that will not move because another one pins an older library.
• Watching what is abandoned. Contributed modules get abandoned. Finding out during a security advisory is the expensive way; a quarterly review of maintenance status is the cheap way.
• Backups that have been restored. A backup nobody has restored is a hope. Restoring one into staging, on a schedule, is the only version of this that counts.
• Uptime and error monitoring, with somebody named who receives the alert.
• Performance drift. Sites get slower through content growth and accumulated modules rather than through any single change.

What is not maintenance, however it is described

The recurring argument in these contracts is scope, and it is avoidable by naming the boundary in advance.

New features are not maintenance. A new content type, a new integration, a redesigned landing page: these are projects, however small, and folding them into a monthly retainer means either the retainer grows or the maintenance quietly stops happening.

Content work is not maintenance. Adding pages, uploading documents, editing copy. Some agencies include a few hours; the point is that it should be stated rather than assumed.

A major version upgrade is not maintenance. This is the big one and it deserves its own section.

Major version upgrades, honestly

Drupal’s modern releases are far kinder than the old rebuild-every-time reputation suggests, but a major version jump is still a project with a shape of its own:

1. An audit of every contributed module for compatibility with the target version. Some are ready, some have a patch, some are abandoned and need replacing, and the replacements rarely map one to one.
2. Custom code brought up to date with deprecated APIs removed. Tooling finds most of this automatically, which makes it predictable work rather than exploratory work.
3. The theme, which is usually the largest single piece if it is old.
4. A content migration only if the data model changes. Often it does not, and this is where the fear in these projects usually comes from.
5. Regression testing of the flows that matter, in a staging environment that matches production.

The cost is driven almost entirely by the module list and the custom code, not by the size of the content. A site with forty contributed modules and heavy custom work is a different project from one with twelve and a clean theme, even if they look the same to a visitor.

The important scheduling fact: each Drupal major version has an end-of-life date, published in advance. After it, security advisories stop. Planning the upgrade against that date, rather than against a budget cycle, is the difference between a project and an emergency.

The questions to ask a maintenance provider

1. Who watches the security advisories, and what is your response time for a critical one?
2. Do we have a staging environment, and is it a real copy of production?
3. When was our last backup restored, rather than taken?
4. Which of our modules are unmaintained today?
5. What is our current version’s end-of-life date, and what is the plan for it?
6. What, exactly, is excluded from the retainer?

The fourth and fifth questions are the ones that produce silence, and silence there is the most useful answer in the list.

Why we take this seriously

We run enterprise Drupal in production, including the academic platform for NSUT and work for Mahindra Insurance Brokers. Both are the kind of site where an unpatched module is not an inconvenience, and both are the reason the list above is written the way it is rather than as a feature comparison.

The state a site gets into when maintenance lapses

Neglect on Drupal has a recognisable progression, and knowing where a site sits on it tells you what the recovery costs.

1. A few updates behind. Routine. A single window fixes it.
2. A module cannot update because a dependency conflicts. Now every subsequent update is blocked behind one decision nobody has made.
3. Custom code depends on a patched module. Somebody applied a patch directly rather than through the dependency manager, so an update overwrites it and quietly breaks a feature. This is why patches belong in the project’s Composer configuration, where they are reapplied deliberately.
4. The version is out of support. No more advisories, which does not mean no more vulnerabilities, and the upgrade is now larger than it would have been at any earlier point.
5. Nobody knows how to deploy it. The person who set it up has gone, there is no staging environment and no documented process, so any change is a risk. At this point the maintenance conversation is really a recovery project.

Steps one and two are cheap. Step five is where a practice of skipping the monthly cost has become a five-figure decision, and it is reached in about three years of nothing happening.

What a first month should look like

Taking over an unfamiliar Drupal site is its own piece of work, and a provider who starts applying updates on day one has skipped it. A sound first month is an inventory of core and module versions with maintenance status, a check of what is customised and how, a staging environment created and proved, a backup taken and restored, the end-of-life date established and written down, and only then the first update window.

Ask for that inventory as a deliverable. It is the document that tells you what you actually own, and it is useful even if you never sign the retainer.

If your Drupal site is on a version whose end-of-life date you do not know, that is the thing to find out this week. Our Drupal work covers maintenance and the upgrades, and if you are considering moving off the platform entirely there is a separate honest answer for that in migration. Ask us for a module audit and we will tell you where you actually stand.