Most Drupal sites are built with a budget and a launch date. Very few are built with a plan for the three years afterwards, which is when nearly all of the site's actual life happens.
The result is a familiar pattern: a site launches in good shape, receives no attention for eighteen months, and then needs an expensive intervention — because a security release was missed, a module broke after a PHP upgrade, or nobody noticed the contact form stopped delivering email in March.
This page describes what ongoing Drupal support should cover, what actually goes wrong on unattended sites, and how to judge whether you need a support arrangement or simply a better routine.
What Drupal Support Should Actually Cover
"Support" is a vague word, and vagueness is where support arrangements disappoint. It reasonably covers several distinct things:
- Security updates — applying core and contributed security releases promptly.
- Routine updates — keeping minor versions and dependencies current so upgrades stay small.
- Monitoring — knowing the site is up, and that the things that matter still work.
- Backups and recovery — verified, restorable copies.
- Fixing things that break — the reactive part most people mean by "support".
- Helping the people who use it — editors with questions about how to do something.
An arrangement that does not say which of these it includes will disappoint someone. The useful conversation is which of them you need, not which tier you are on.
Why Unmaintained Drupal Sites Fail
Drupal sites rarely fail suddenly. They accumulate small deferrals until something ordinary becomes expensive.
A missed security release is the obvious risk, but the quieter failure is version drift. A site left on an old minor version for two years is no longer one update behind — it is behind on core, on twenty contributed modules, and probably on PHP. Each of those is individually routine. Together, applied at once, they interact, and the "quick update" becomes a project with no clear rollback point.
The second common failure is silent breakage. Forms that stop sending, integrations whose credentials expired, scheduled tasks that stopped running months ago. None of these produce an error page, so nobody reports them. They are found during an unrelated piece of work, or by a customer.
Security Updates Are the Non-Negotiable Part
The Drupal Security Team publishes advisories on a predictable schedule, and critical issues in widely used modules are exploited quickly once public — the advisory is the starting gun for automated scanning.
The practical standard: critical and highly critical advisories applied within a day or two, moderate ones within the normal update cycle. That requires knowing an advisory exists, which means someone subscribed to the announcements and someone able to act on them.
This is also the argument for keeping the module count honest. Every installed module is a potential advisory to respond to, whether or not the site uses it. Uninstalling something genuinely unused is a permanent reduction in maintenance load.
The Update Cadence That Works
Monthly is the cadence that keeps updates boring. Small enough that changes can be reviewed and tested quickly, frequent enough that nothing accumulates.
A workable routine: check for updates, read what changed, apply them on a copy first, run through the site's important paths, then deploy with a fresh backup taken beforehand. For most sites this is an hour or two a month.
Quarterly is workable with more testing per cycle. Annually is not really maintenance — it is a small upgrade project each time, priced and risked accordingly.
Backups, and the Test Nobody Runs
Nearly every site has backups. Considerably fewer have backups anyone has restored.
The gap matters because the failure modes are silent. A backup job that has been writing zero-byte files since a disk filled up looks identical, in a monitoring dashboard, to one that is working. A database dump taken without the right flags may be missing content. A files backup that excludes the wrong directory takes every image with it.
The only way to know is to restore one somewhere safe and look at it. Doing that once a quarter is not a large investment, and it converts an assumption into a fact. A backup nobody has restored is a belief.
Worth being explicit about what is backed up, too: the database holds content and configuration, but uploaded files live on disk. A database-only backup restores a site whose images are all missing.
Monitoring: Knowing Before Your Customers Do
Uptime monitoring is the minimum, and it is the least interesting part — a site that is down announces itself. The valuable monitoring watches the things that fail quietly.
Worth watching: that scheduled tasks ran recently, that outbound email is being accepted, that error rates have not changed shape, that disk space is not quietly filling, and that the site's important user journeys still complete. A synthetic check that submits a test form once an hour catches an entire class of failure that uptime monitoring never sees.
Drupal's own log is worth reading periodically rather than only during an incident. A recurring warning is usually the early form of a problem that will eventually become an outage.
What Breaks Most Often
Across sites, the same small set of things accounts for most incidents:
- Email delivery. A DNS change, an expired credential, or a provider policy change, and forms stop arriving. Usually noticed weeks later.
- Scheduled tasks. Cron stops, and search indexes, scheduled publishing and cleanup all quietly stop with it.
- Disk space. Logs and temporary files accumulate until writes fail, which produces confusing errors far from the cause.
- External integrations. An API version is retired, a token expires, an endpoint moves.
- PHP version changes applied at the hosting layer, which can break contributed code with no warning to the site owner.
What these share is that none of them announce themselves on the site's front page.
Content Editor Support Is Support Too
A meaningful share of support requests are not faults. Someone needs to do something they have not done before, or something behaves in a way they did not expect.
These are worth handling well, because the alternative is expensive: editors work around the system, content ends up in the wrong place, and the site drifts away from the model it was designed around. Ten minutes answering a question is much cheaper than fixing six months of workarounds.
Recurring questions are also a signal. If three people ask the same thing, the interface is unclear, and a small change to a field description or a form layout removes the question permanently.
If your site is already behind on some of this, a maintenance review establishes what needs bringing up to date before any ongoing arrangement starts. Request a quote with your Drupal version.
Support and Hosting Are Different Things
Hosting and support get bundled together, and it is worth keeping them distinct when deciding what you need.
Hosting is where the site runs: the server, PHP, the database, the network. Support is the work of keeping the application healthy: updates, fixes, monitoring the things that matter, and answering questions.
Good hosting does not apply your module updates, and good support does not resize your server. Knowing which one an incident belongs to is often the fastest part of resolving it — and being clear about the boundary in advance prevents the situation where each side reasonably believes the other is handling something.
What a Support Arrangement Should Specify
Before agreeing to anything, these should have written answers:
- Scope — which of the activities above are included, and which are billed separately.
- Response expectations — what counts as urgent, and what happens then.
- Update cadence — how often routine updates are applied, and who tests them.
- Backups — what is backed up, how often, how long it is kept, and how often a restore is tested.
- Access — who has credentials to what, and what happens to that access when the arrangement ends.
- Reporting — what you receive that shows the work happened.
That last one matters more than it sounds. Maintenance done well is invisible; a monthly note saying what was updated and what was checked is how you can tell the difference between a quiet month and a month where nothing happened.
Common Support Mistakes
- Updates applied straight to production with no copy to test on and no backup taken first.
- Backups never restored, so their state is unknown until they are needed.
- Nobody subscribed to security advisories, so the clock starts when someone happens to notice.
- Modules installed and never removed, each adding permanent maintenance surface.
- Credentials held by one person, so everything stops when they are unavailable.
- No record of what changed, so a regression cannot be traced to a change.
Doing It Yourself, or Not
A team with PHP and Composer experience can absolutely maintain a Drupal site. It requires someone to own it, a monthly slot in the calendar, and a place to test changes before they go live.
An arrangement makes sense when there is nobody in-house who can judge whether a security advisory affects you; when the site earns enough that a week of quiet breakage is expensive; when it has to keep working while the people who built it have moved on; or when updates have already been deferred long enough that catching up is its own project.
The honest test is whether last month's updates were applied. If the answer is "probably" or "I'd have to check", the routine does not exist yet.
What a Month of Maintenance Actually Looks Like
"Ongoing support" is abstract until you see the shape of it. On a typical mid-sized Drupal site, a month runs roughly like this.
Early in the month, check what updates are available and read what they change. Most are routine; occasionally one alters behaviour and needs a closer look. Apply them to a copy of production, click through the paths that matter — content editing, the main forms, search, anything that takes payment — then deploy, with a fresh backup taken immediately beforehand.
Separately, and not on the same schedule: watch for security advisories. These arrive when they arrive, and the response is measured in hours rather than weeks for anything critical. This is the part that cannot be batched into a monthly slot.
Once in the month, look at the things that fail quietly. Did scheduled tasks run? Is outbound email still being accepted? Has the error log changed shape? Is disk usage trending anywhere alarming? Each is a two-minute check and each catches a class of failure that produces no visible symptom.
Once a quarter, restore a backup somewhere safe and open it. Confirm the content is there, the files are there, and the site runs. This is the check that converts a belief into a fact, and it is the one most often skipped.
Then write down what was done. Not a report for its own sake — a short record of what was updated, what was checked and anything noticed. It is what makes a quiet month distinguishable from an unattended one, and it is what lets someone reconstruct a timeline when something does eventually go wrong. The engineering habits behind this are covered on the Drupal developer page.
Next Steps
If you want to assess your own position, three checks tell you most of it: when was the last core update applied, when was a backup last restored and looked at, and does anyone receive Drupal security advisories. Sites that fail all three are the ones where support pays for itself the fastest.
If you would rather hand it over: a maintenance review establishes the current state and what needs bringing up to date, and an ongoing support arrangement covers updates, monitoring, verified backups and a defined amount of fix time each month.
Web development has been my work since 2005, and I am the author of Drupal modules and themes published on drupal.org — my profile there lists them.
Request a quote with your Drupal version, roughly how many modules you run and what your current maintenance routine looks like, or get in touch to talk it through. If the site is already behind, say so — catching up is a normal starting point, not an awkward one.