A Drupal site rarely fails all at once. It drifts: security releases go unapplied, a contributed module loses its maintainer, and a change nobody wrote down breaks the next update. We keep Drupal sites current and watched. Core and contributed modules are updated on staging, tested, then deployed; monitoring covers the failures that happen quietly; and the same named team handles your changes every month. When another team built the site, the work starts with a takeover audit, so both of us know what we are inheriting.
- Who this is for
- An organisation running Drupal with no Drupal specialist in-house. A team that inherited a site after its builder moved on. A site whose update backlog has grown past what anyone has time to clear. An owner who wants response commitments written down instead of implied.
What you get
- Security releases of Drupal core and contributed modules, applied on staging, tested, then deployed
- Contributed modules kept current, with a warning before a module you rely on reaches end of life
- Uptime and error monitoring that alerts a person, not a shared inbox
- A monthly maintenance report: updates applied, tickets closed, risks we are watching
- A named team that already knows your codebase
- Version control and a deployment path, set up if the site had none
- A written list of the undocumented changes made to core and contributed modules
- Change requests handled as scheduled work, not as emergencies
The monthly report is the part you see. It is written for the person who pays for the site, not for a developer, and it says what was done, what is still open and what is coming up.
Sample Monthly maintenance report August 2026 · example.org
- Uptime
- 99.96%
- Updates applied
- 9
- Tickets closed
- 6
- Open risks
- 2
Updates applied
- Drupal core 10.5 security release Tested on staging
- Webform, minor release Tested on staging
- PHP 8.3 patch release Applied
Tickets
- Search results miss PDF content Closed
- New field on the event form Closed
- Slow admin content listing In progress
Risks we are watching
- High Drupal 10 security support ends on 9 December 2026; the upgrade to Drupal 11 is quoted separately.
- Low A contributed slideshow module has no maintainer; a replacement is proposed.
An engineer reads it and replies within one business day.
How the work runs
For a site we built, maintenance picks up where the warranty leaves off and the first steps are already done. For a site another team built, every step below happens in order, and nothing is deployed to production until the audit is finished.
How Drupal maintenance starts and runs
- Audit The codebase, the hosting and the update backlog, with the risks ranked. You keep the audit report
- Reconcile The running site and the repository checked against each other, and the site put under version control. You keep the repository
- Scope A maintenance scope written against the audit, with the response commitments you need. You keep the agreement
- Update Security releases applied on a copy of the site, tested, then deployed in dependency order. You keep the change log
- Monitor and report Alerts on the failures that happen quietly, and a report every month. You keep the monthly report
Warranty, maintenance and an SLA are not the same thing
Each covers something different, and it matters which one a contract buys. We tell you which of them your site needs. The full policy is on the warranty page.
| Question | Warranty | Maintenance | SLA |
|---|---|---|---|
| What it covers | Defects in what we built, and the security releases of Drupal core and contributed modules while it runs | Keeping a running site healthy: updates, dependencies, backups, monitoring and small changes | Measurable commitments: response times by severity, availability targets, escalation |
| How it is paid | Comes with a development project, nothing extra | A monthly agreement | Priced for what it obliges us to staff |
| How long | 1 year by default, up to 3 years | While the agreement runs | As written in the agreement |
| A site we did not build | Not covered | Covered, after an audit | Agreed in writing |
Taking over a site somebody else built
Nobody can commit to a system they have not read, so a takeover starts with an audit rather than a contract. It establishes:
- What is deployed: the Drupal version, every contributed and custom module, the patches applied, and how far behind security releases the site is.
- Whether the code in the repository is the code that is running.
- Whether backups exist, and whether a restore has ever been performed.
- The deployment path, and whether changes can be made without touching production by hand.
The audit is a deliverable you keep, whether or not you go on with us. If you first want to know what is in the site before deciding who looks after it, the Drupal site audit is a fixed-price review of its own. Sometimes it shows that the site needs an upgrade or a migration before maintenance is worth paying for; then we say so and quote that work separately. Where the worry is specifically whether the site has been or could be compromised, a Drupal security audit goes deeper than the takeover audit. Agencies that need the same work delivered under their own name use white-label Drupal support.
The SPREP sites we maintain
SPREP, the Secretariat of the Pacific Regional Environment Programme, had WeebPal redesign sprep.org and rebuild its Drupal theme in 2017, then came back for the second redesign in 2024. SPREP has since given us further sites, several of them developed from the sprep.org base, and we maintain each one after launch.
Other systems we keep running
The same arrangement runs outside the SPREP family: a conference and member site, a custom web application, an online store and a company site with online visa applications. WeebPal built each of them and maintains them today.
The JFC learning platform, which we deployed and customised from EverLMS, is maintained the same way; see the JFC case study. From H&N Corporation:
I've had the pleasure of partnering with WeebPal for the past 5 years. Working with WeebPal has been a truly valuable and reliable experience.
What it costs
Maintenance is a monthly agreement in the Maintenance and support band on our pricing page, with no lock-in period. Where a site sits in that band depends on the state of the system and the commitments you need, not on a page count: traffic and uptime expectations, the number of environments, how many contributed and custom modules are carried, the integrations that have to keep working, and the volume of tickets the site generates.
A site we did not build starts with the paid takeover audit, which turns those factors into a number that stays fixed for the term. Support runs in business hours; cover outside them is an option and adds to the monthly price. New features are not maintenance: they are quoted as project work at the size they are, from Micro upwards.
Work we have delivered
The full case studies behind the screenshots on this page.
-
Pacific Islands Roundtable
The Pacific Islands Roundtable site: a standalone Drupal build we designed and developed after a referral from SPREP, and maintain.
Read the case study -
PRISMSS
PRISMSS: a bilingual English and French Drupal site we designed and built for SPREP's invasive species support service, and maintain.
Read the case study -
SPREP Virtual Library
The SPREP Virtual Library: a Drupal digital repository we designed and built for SPREP's publications, reports and media, and still maintain.
Read the case study
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
What if there is no repository, or nobody can find it?
It is recoverable. We take the running codebase off the server, put it under version control, and compare it with the matching releases of Drupal core and the contributed modules to work out what was modified. The result is a list of the changes somebody made to core or to contributed modules: the undocumented patches that break an update and then get blamed on it. The site ends up with a repository and a deployment path whether or not it had them before, which stays useful whoever maintains it afterwards.
Do we have to hand over production credentials on day one?
No, and we would rather you did not. The audit runs on a copy: a database dump, the files directory and read access to the codebase are enough to start. Production access comes later, for a specific change we have agreed to make. If your security policy requires it, the work can run entirely inside your own environment, under accounts you issue and can revoke.
The previous developer left the code in a bad state. Will you refuse the work?
Not usually. We tell you what it would cost to bring the site to a state that can be maintained safely, and quote that separately from the monthly maintenance, so you see both numbers rather than one blended figure. What we will not do is take a monthly fee for a site we have already said we cannot keep secure. If a rebuild would cost less than years of working around the existing code, we say so, even when the rebuild would not be ours.
Can you work alongside our existing developer or agency?
Yes. One way to split it: we take the Drupal-specific work, such as keeping core and contributed modules current, while your own team keeps building features. It works when the boundary is written down: who deploys, who owns which part of the repository, and what happens when changes from each side collide. We ask for that in writing at the start rather than finding out where the boundary was during an incident.
Can you just do the security updates?
Yes. It is the smallest arrangement: security releases of core and contributed modules applied, tested on staging and deployed, with the monthly report. For a stable site with few changes it is often all that is needed.
Can you keep a Drupal 7 site running?
We can keep it running, but we cannot keep it secure the way a supported version is: community support for Drupal 7 ended on 5 January 2025, so security releases no longer arrive. We will say that plainly rather than imply a protection that does not exist, and quote the migration as separate work.
Not covered here? Ask us directly.
Hand us the siteAn engineer reads it and replies within one business day.
Run
Related services
Tell us what you are running and who looks after it now
Send the Drupal version, the hosting and the module list if you have it. We will say what state the site is in before proposing anything.
An engineer reads it and replies within one business day.