Drupal maintenance and support

What does Drupal maintenance cover?

Maintenance consists of four parts that can each fail independently: security, the stack underneath, backups and testing.
Your hosting provider usually covers part of that, and that's exactly where the confusion sits.

Security releases for core and contributed

Drupal publishes security advisories on Wednesdays in fixed windows, so they're plannable.
Core is the easy part: pull in the patch version with Composer, test on staging, deploy.
The work is in the contributed modules, because a business site runs on a few dozen of them, each with its own maintainer.
Some get a fix within the day, others get declared unsupported.
The second one isn't an update but a decision: replace it, take it over into custom code, or drop it.

PHP versions and the rest of the stack

Maintenance also covers what runs underneath Drupal, and that comes with hard deadlines.
Drupal 11 requires PHP 8.3 at minimum.
Drupal 10 runs from PHP 8.1, but PHP 8.1 has had no security fixes since 1 January 2026, and PHP 8.2 falls into the same gap after 31 December 2026.
So a site can be fully up to date at the Drupal level and still be running a PHP version nobody patches any more.
The same goes for the database, the web server and the Node version behind your theme build.

Backups you can rely on

A backup nobody looks at isn't a backup, it's an assumption.
The three mistakes I see most often: the database is kept but the files folder isn't, nobody checks whether the backup is still running, and the restore procedure isn't written down anywhere.
Under an SLA it works like this: the hosting partner makes an automatic backup every day and keeps it for 14 days, I check every month that those backups are actually being made, and before every update I make sure there is a fresh backup.
If an update fails, I restore that backup and look for a solution.

Testing after every update

An update is only done when the site still works.
A site can be online and broken at the same time: the form sends nothing, cron has stopped running, the search index is empty.
That's why after every update I check the most important pages and features, not just whether the homepage loads.

Why overdue maintenance costs more than maintenance

A backlog isn't standing still, it grows.
Being one minor release behind is routine work.
Being three years behind is a project, because the problems compound: the PHP version needs to move too, some modules no longer exist in a compatible version, and your custom code uses APIs that have been removed.

The version history makes that concrete.
Drupal 8 has been out of support since November 2021, Drupal 9 since November 2023, and Drupal 7 since 5 January 2025.
Sites still on those no longer need an update but a migration, and that difference is a factor in both time and budget.
On top of that, without maintenance the knowledge about your site disappears too: no changelog, no documented patches, no deploy log.
At the next incident you then pay for investigation first, and that costs more than the fix.

Ad hoc or an SLA: when do you choose which?

Ad hoc works as long as downtime doesn't cost money.
You report a problem, I schedule it in, you pay for the hours.
The difference with an SLA isn't in the work but in the timing: with ad hoc, turnaround depends on my calendar; with an SLA, capacity is reserved in advance and a response time is on paper.

• ✓ You sell online, or your site is the entry point for enquiries, so a day of downtime is a measurable loss.
  Then an SLA.
• ✓ If you fall under the European Accessibility Act or under the public-sector obligations from directive 2016/2102, you need to be able to substantiate your accessibility level, with an accessibility statement and a check after every release.
  Whether your service falls within scope depends on your sector and on how it's been transposed into Belgian or Dutch law: have that checked legally.
  In that case, an SLA.
• ✓ You have a brochure site with no login, payments or integrations, and your host handles the core updates.
  A round once a quarter is enough.
• ✓ You already have someone in-house who knows Drupal.
  Then an escalation agreement makes more sense, and that falls under technical management and consultancy.

What's in my SLA

An SLA is an agreement about time, scope and access, not a promise that nothing will ever break.
Below is what I set out, including what's not in it.
That last part is what the discussions are usually about.

Response time and resolution time are two separate agreements

Response time is how fast you get a first real reply, resolution time is how fast the problem is actually gone.
Mixing those two up is the most common mistake in support contracts, because I can put the first one on paper and the second depends on the cause.

You report a problem by email, and for a critical problem you also call or text.
The times above are response times, not resolution times.
Fixing the problem is a best-effort commitment: I look for a solution as fast as reasonably possible, but I don't guarantee a resolution time or uninterrupted availability, because that also depends on your hosting and other third parties.
I won't fix an outage at your payment provider or host any faster than they can.
A security update that Drupal marks as critical or high risk, I assess within 3 working days of publication. Then I install the update, or take temporary measures if it can't be installed safely yet.
A contract that guarantees resolution times nobody can meet is worthless at the first incident.

Scope: what's included and what isn't

• Included: security and maintenance updates of Drupal core and the contributed modules within the same major version, testing after every update, a monthly check of updates and backups, analysis and repair of outages and security problems, and answers to your questions about the site.
• Not included: major updates of Drupal or PHP, such as Drupal 10 to 11, and replacing modules that are no longer supported, new features or page types, design or layout changes, content, copy, photos and translations, SEO, ads and analytics, and anything outside the Drupal site itself, such as hosting, domain name and external services.
• Hour budget: a fixed number of hours per month. Every question and every change counts, added up per day and rounded up to the next quarter hour. Hours you don't use in a month expire at the end of that month. On request you get an overview of the work and the time used.
• Outside the budget: I always flag extra work up front, with an estimate or a quote, and I only start after you agree. A change that takes longer than 30 minutes is discussed first. Two exceptions: updates and security carry on when the hour budget is used up, up to 3 extra hours per contract year, and for a critical problem I can start right away for up to 3 hours to find the cause and limit the damage.

I keep a major version jump outside the monthly budget, because the budget is sized for maintenance, not for an upgrade project.
For a clean Drupal 10 site with little custom code, the jump to 11 stays limited; with a lot of custom code and modules without a compatible version, it adds up.
I estimate it per site upfront.
Outside scope doesn't mean I won't do it, only that you won't get a surprise invoice for it.

When I'm available

I work on working days, Monday to Friday excluding Belgian public holidays, within fixed support hours set out in the SLA.
All the response times above only run within those hours, so a report on Friday evening counts as received on Monday.

I don't promise a 24/7 on-call service.
I'm one person, David Porschmann, freelance Drupal specialist, and genuine on-call cover with guaranteed follow-up needs a team.
Work you ask for outside my working hours carries a 50% surcharge, except for a critical problem.
During holidays or illness there is no stand-in and the response times are paused. I announce planned absence in advance, where possible at least a week ahead.
If a site really has to run day and night, we put first line with your hosting provider and I'm the second line.

Who has access and who owns what

Access is always named to a person.
No shared admin accounts, no passwords in an email thread, two-factor authentication where possible, and each person's own SSH key.
We record per account who owns it and who has which access: Drupal, hosting, DNS, domain name and Search Console.
In Drupal you get your own role to manage the content. The configuration lives in code and I manage it, so an update never overwrites anything unexpectedly.

Just as important is what happens if we stop working together.
Your site's content and your domain name are yours. If I arrange the hosting, it runs through my account with the hosting partner, on your behalf, and that is written down in the SLA.
An SLA runs per year and renews by one year each time. You can cancel up to one month before the end.
If we stop, you get all access details within 10 working days and, on request, a full export of your site: code, database and files.
No barrier to leaving, because a client who stays because switching is too much hassle isn't a satisfied client.

What maintenance costs

An SLA includes a fixed number of hours per month for updates, checks, questions and small changes.
How many hours your site needs depends on the contributed modules, the custom code and the deployment process. I look at that per site up front, so the agreement fits what is actually running.
The SLA is invoiced per year in advance. Extra work is charged at 75 euros per hour excluding VAT. Hosting and domain name are invoiced separately.
The price is indexed every year and you hear the new price at least two months in advance. My hourly and day rates are on rates.

Taking over maintenance from another party

A takeover starts with an audit, not with the first update.
I map out what's there: versions, open advisories, unsupported modules, patches and whether they're documented, the custom code, and whether the backup has ever been restored.
That takes half a day to a full day and produces a list, ordered by impact.
Sometimes the outcome is that maintenance isn't the right answer.

Want me to take over maintenance?