Written by
Founder & CEO, Gspikes
I own and run Gspikes, the agency I founded in 2018. Before going all-in, I led SEO at Chain Reaction — one of the region's largest digital agencies — and shipped production code at Orange and Forbes. Everything published here comes from projects I've personally built, migrated, or ranked.
Last updated · August 2026
Nobody budgets properly for maintenance. I understand why — the launch is exciting and the patching schedule isn’t — but I’ve seen what a year of “we’ll handle updates ourselves” does to a Drupal site, and the repair bill always dwarfs the plan that would have prevented it.
The 2026 numbers
| Tier | Monthly cost | What it covers |
|---|---|---|
| Security-only | $300–$800 | Core + contrib security patches, uptime monitoring, backups verified |
| Standard support | $800–$2,500 | All updates (not just security), bug fixes, small content/config changes, defined response times |
| Support + development | $2,500–$10,000+ | Everything above plus real engineering hours — features, improvements, quarterly reviews |
Institutions with compliance requirements (government, healthcare, higher-ed) should expect the upper bands — audit trails, staged rollouts, and SLA paperwork are labor, not markup.
What a plan must include — the non-negotiables
- A same-week response to security advisories. Drupal publishes advisories on Wednesdays. Highly-critical ones get exploited within days — sometimes hours. Ask any prospective provider: “What happened in your shop the last time a critical dropped?” A good answer names a process; a bad answer is a pause.
- Updates applied through staging with tests — not clicked directly on production. You’d be shocked how much “maintenance” is someone pressing update on live and hoping.
- Verified backups. Not “backups exist” — backups restored, on a schedule, to prove they work. An untested backup is a hope, not a plan.
- Deprecation cleanup as they go. This is the quiet one. Fixing deprecated code monthly is what makes the next major upgrade an evening instead of a project — I showed the math in the Drupal 10 vs 11 piece.
Why the cheap plan costs the most
The $300 plan defers everything but security. Two years later, the site needs a version upgrade and every deferred update lands at once — module compatibility chains, theme breakage, config drift. I’ve quoted that cleanup at more than three years of the plan the client skipped. The economics of maintenance are boring and absolute: pay a little always, or a lot suddenly. The same logic applies before you even launch — a well-maintained site is also what keeps your next migration on the cheap end of the range.
One rule I’d never sign without
The team that maintains the platform should be able to change it. Support contracts that can only patch — never refactor, never improve — guarantee slow decay. Every plan we run at Gspikes includes engineering hours for exactly this reason, and it’s the first thing I’d demand from anyone else too. (If you’re weighing a support retainer against hiring in-house instead, the hiring cost breakdown does that comparison properly.)
Our own plans live on the Drupal services page. If you just want your current arrangement sanity-checked — coverage, price, response times — send it over; a second opinion is free and I enjoy reading other people’s SLAs more than I should.
