The site goes down at 11:04 PM on a Friday. Not a caching hiccup — fully down, 500 errors across the board. Your client calls you. You call the support vendor. Forty minutes later, you get an automated email.
Thank you for contacting support. Your ticket #00847 has been created. Our team will respond within 24 business hours.
Twenty-four business hours. It's Friday night. That's Monday morning at the earliest.
| The Problem | Most Drupal support plans are reactive ticket queues — they respond to problems you already know about |
| The Risk | Drupal 10 reaches end of life December 9, 2026; PHP 8.1 is already EOL; attackers monitor drupal.org/security the same moment you do |
| What a Real Plan Includes | Proactive monitoring, tiered SLAs by advisory severity, and EOL tracking baked in before the crisis |
| The Standard | If your vendor won't tell you something you don't want to hear, you have a warranty — not a plan |
No escalation path. No on-call engineer. No one who can tell you whether this is a failed update, a compromised module, a PHP memory fault, or something worse. Just a ticket number and a logo on the invoice.
This is not an edge case — it's the industry norm. And the dirty secret is that most clients don't find out their "support plan" is a warranty until that exact moment. They signed a contract, they pay a monthly retainer, and they assumed professional services implied professional readiness. What they actually bought was a help desk with a Drupal logo on it.
A real support plan looks nothing like that. It has three layers that most vendors never quote because they require actual expertise, process discipline, and the willingness to surface problems before the client notices them.
Layer 1: Monitoring That Doesn't Wait for You to Notice
Drupal's release cadence is, genuinely, one of its strengths — and almost nobody treats it that way. Core follows a predictable monthly rhythm: bugfix releases drop on the first Wednesday of each month, security releases on the third Wednesday, starting at 12:00 America/New_York. That's not chaos. That's a calendar. A real support plan has a process ready at noon on the third Wednesday, not one that starts when the calendar notification fires.
The canonical source is drupal.org/security. Every advisory published there; whether it's an SA-CORE for Drupal core or an SA-CONTRIB for a contributed module, lands in a public feed that your team should be watching. Your client's site has contrib modules. Those modules have advisories. Someone should be subscribed to the RSS feed, the Drupal security newsletter (configurable under your Drupal.org profile), and @drupalsecurity on Bluesky or Mastodon.
Here's where severity matters. Advisories are scored on a 25-point scale: Highly Critical (20/25), Critical (15/25), Moderately Critical (13/25), Less Critical (8/25). A "Highly Critical" advisory carries an explicit note that exploits may be developed within hours or days. That is not a "next sprint" item. That is an all-hands, today item.
For clients who genuinely cannot patch same-day — because their change management process requires a two-week approval window, or because their staging environment needs to be spun up fresh — Drupal Steward exists as a WAF-level mitigation layer. It provides protection from known attack vectors for highly critical advisories while a proper patch is being tested. It's not a substitute for patching, but it's a legitimate first line of defense that buys your team time to do the update right. A professional plan should name it explicitly as a response option.
Proactive monitoring also means uptime monitoring — but that's table stakes. The differentiator is someone watching the advisory feed before your client's site becomes collateral damage in a wave of automated exploit attempts.
Layer 2: The Update Tiers Your Vendor Should Be Defining
"We handle updates" is not a service definition. It's a red flag.
A real plan separates update types and attaches actual SLA commitments to each tier:
| Advisory Type | Severity Score | Response SLA |
|---|---|---|
| Highly Critical security | 20/25 | Hours — same business day |
| Critical security | 15/25 | 24–48 hours |
| Moderately Critical security | 13/25 | 3–5 business days |
| Non-security bugfix | — | Scheduled monthly window |
| Functional / feature updates | — | Quarterly review cadence |
Collapsing these into a single bucket means a Highly Critical advisory with working exploits in the wild gets queued behind a minor bugfix from two weeks ago. That's not a prioritization strategy — it's the absence of one.
One more thing most contracts get wrong: SLAs should be measured to UAT-ready, not to production deploy. A patch that lands in production without staging validation is often worse than no patch at all — you've traded one emergency for a different one. A staging or UAT environment isn't optional infrastructure; it's a requirement for any update workflow worth paying for. If your vendor's contract doesn't mention a staging environment, ask why.
Layer 3: Architectural Governance and the EOL Calendar
This is the layer nobody quotes because it requires expertise, not just tooling.
Start with the tooling anyway. The Site Audit module (drupal/site_audit:^4.1, compatible with Drupal ^10.2 || ^11) generates a comprehensive static analysis report covering caching configuration, database health, cron status, Views caching, 404 counts, PHP errors from Watchdog, and extension health. Run it via Drush:
drush aa --html --bootstrap --detail --skip=insights > report.htmlIt doesn't need to be installed into the target site — non-intrusive, repeatable, and scriptable into a CI pipeline. This is what a monthly health scorecard looks like. Not a manual checklist, not a gut-check, not "we looked at the dashboard." A generated, documented, comparable-over-time audit report.
Pair that with the Security Review module for misconfiguration scanning and the Hacked! module for detecting unexpected changes to core and contrib files. Neither is exotic. Both belong in any serious maintenance toolchain, and their absence from a vendor's process should prompt questions.
Now for the part that requires actual expertise — the EOL calendar.
PHP 8.1 is already EOL. A site running PHP 8.1 with Drupal 10 is in a grey zone where upstream dependency support has already dropped. Drupal 11.3.x requires PHP 8.3 or 8.4 — PHP 8.1 and 8.2 are not supported on Drupal 11.x at all. PHP 8.5 support begins with 11.3.x, and it will be *required* for Drupal 12. You can surface your running versions in seconds:
drush statusBut knowing the versions is only half the job. Someone on your support plan needs to be tracking what those versions mean against the published EOL calendar and raising the conversation before it's a crisis.
The hard deadlines are already on the calendar. Security support for Drupal 11.2.x and 10.5.x ends around June 17, 2026. Drupal 10 reaches full end of life on December 9, 2026. Any support plan signed today and running a Drupal 10 site needs a D10 → D11 migration timeline built into it — not as a future conversation, but as a named deliverable with a date.
And then there's Drupal 12, scheduled for the week of December 7, 2026. That's the same month D10 goes EOL, which creates a hard deadline on both ends simultaneously. D10 sites need to be on D11 before that window. D11 sites need a clear PHP 8.5 compatibility story. This is not a surprise — it's been on the roadmap — but a surprising number of maintenance contracts will sail straight into it with no plan.
Architectural governance means someone reviews what's being added to the codebase before it becomes debt. A new contributed module gets an architectural review — is it actively maintained, what's its security history, does it duplicate something core already handles in D11? A new custom module gets a code review against Drupal coding standards and the service container patterns that make it upgrade-safe. This is the "someone who will tell you something you don't want to hear" standard. It is, predictably, the first thing cut from a proposal when a vendor is competing on price.
The Checklist That Separates a Plan from a Promise
If you're a director or tech lead reviewing a support contract — whether you're renewing one or evaluating a new vendor — here's what should be in the document, explicitly, not implied:
- Tiered SLAs by advisory severity, with Highly Critical defined as a same-day response obligation
- Named notification sources: drupal.org/security feed, security newsletter, PSA feed — and a named process for monitoring them
- Drupal Steward acknowledged as a mitigation option for Highly Critical advisories
- Staging/UAT environment listed as a required component of the update workflow, with SLAs measured to UAT-ready
- Monthly Site Audit report (
drush aa) as a scheduled deliverable — not ad hoc - EOL milestone tracking: PHP version, Drupal core minor version, and contrib module EOL dates surfaced proactively, on a schedule
- A named D10 → D11 migration plan if the site is currently on Drupal 10, with December 9, 2026 as the hard deadline
- Architectural review loop for any new module or significant code addition — not just patch application
- An escalation path that is not a ticket queue — a named contact, a phone number, a defined process for when the site is down at 11 PM on a Friday
Ticket #00847 gets resolved by Monday morning. That's a warranty. A plan gets ahead of the conditions that create Ticket #00847 in the first place.
Mapping out a D10 → D11 migration or evaluating what a real support contract should look like for your organization? Let's have that conversation as an architectural review — not a sales call.
We'll look at where your current plan has gaps before the December deadline makes the decision for you.
0 Comments
Login or Register to post comments.