Drupal maintenance services exist on a wide spectrum. At one end: a large agency with a support retainer that bundles maintenance alongside development, design, and strategy. At the other: a specialist who does nothing but keep Drupal sites secure and up to date. Plenty of arrangements sit between those two poles, and not all of them are what they appear to be from the outside.
If you're looking for someone to handle your Drupal security updates and ongoing maintenance, here is what's actually worth evaluating — and a few questions that will quickly reveal whether a given provider is the right fit.
Do they cover contrib modules, not just core?
Drupal core — the main Drupal software — is the part most people think of when they talk about Drupal updates. But a Drupal site is also made up of contrib modules — the add-ons and extra features built on top of Drupal itself. These might include contact form tools, media libraries, SEO utilities, e-commerce components, or editorial workflow tools.
Each contrib module has its own security advisories — official announcements that a vulnerability has been found and a fix is available. A maintenance service that only tracks core updates is covering a fraction of your actual exposure.
Ask directly: do they track and apply security updates for contrib modules, not just core? How? Do they audit the full module list when they take on a site, or do they only act on advisories they happen to receive?
Do they test before deploying?
A security update that breaks your site is a different kind of problem from an unpatched vulnerability, but it's still a problem. Applying updates to a staging or development copy of your site before pushing them live is standard good practice. Not everyone does it.
Ask: what is their testing process before an update goes to the live site? Do they have a staging environment they use? What happens if an update causes a conflict with another component of the site?
The answer should be specific. "We test carefully" is not an answer.
How quickly do they act after an advisory is published?
When a security advisory — an official notification that a vulnerability has been found and a patch is available — is published, automated scanning tools start probing the internet for unpatched sites within hours. The window between publication and active exploitation is not generous, particularly for high-severity vulnerabilities.
A maintenance service that batches security updates into a monthly review is not operating at the appropriate pace. Updates for significant vulnerabilities should be tested and deployed within days, not weeks.
Ask: what is their typical turnaround from advisory publication to update deployment? Is that different for critical versus moderate severity?
How do they report to you?
You should know what has been done to your site, when, and why. This doesn't need to be a lengthy document — a clear summary of what was updated and what advisory prompted it is sufficient. But something should be communicated.
Maintenance services that work invisibly and report nothing leave you unable to tell whether anything has actually been done. That's a problem both practically and for your own governance responsibilities around the site.
Ask: what does their reporting look like? How often do you hear from them? What does a typical update notification include?
Is there lock-in?
Some maintenance arrangements — particularly agency retainers — include elements that make it difficult to move away. This might be hosting arrangements, access credentials kept by the provider, proprietary tooling, or contractual obligations.
A good maintenance provider should make it straightforward for you to leave if you want to. Your site and its access credentials are yours. You should always have full access to everything, and changing provider should be a practical decision rather than a contractual one.
Ask: what do you own and control directly? What happens if you want to move to a different provider? Is there a minimum contract term?
Do they understand your site's specific setup?
A site with 40 contrib modules, custom functionality, and third-party integrations requires different maintenance attention than a simple content site. The person maintaining your site should be able to tell you which modules you're running, whether any are unsupported, and whether anything looks like it needs attention beyond routine updates.
This is harder to evaluate upfront, but a useful proxy is whether they offer an initial site audit. If they want to take on your site without first understanding what's on it, that's a sign they may be taking a less systematic approach.
Questions worth asking any provider before you commit:
- Do you cover contrib module updates as well as core?
- Do you test updates on a staging environment before deploying live?
- How quickly do you typically deploy after a security advisory is published?
- What does your reporting to us look like?
- Is there a contract or minimum term?
- Will we retain full access to our site and hosting at all times?
- Do you carry out an initial audit when you take on a new site?
A note on where Nodely fits
We're not an agency. We don't offer design, strategy, or ongoing development. What we do is focused: track security advisories for Drupal core and for the contrib modules on your site, test updates before deployment, apply them within days of release, and report clearly on what was done.
No retainer. No minimum contract. No lock-in. You own everything; we just do the maintenance.
If that sounds like what you need, get in touch for a free security check. We'll tell you where your site currently stands before you make any decision.