Looking after a Drupal site after launch
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. When the team that built the site has moved on, the first problem is often access rather than code: who holds the repository, the hosting account, the domain and the backups.
What keeps a site healthy is split across documents that are often confused: a warranty on the work that built it, a maintenance agreement that keeps it current, and an SLA that sets response times. Which one a contract buys decides what happens when something breaks.
Articles on support and takeovers
What a software development warranty actually covers (and what it doesn't)
What a software warranty covers and excludes, how response targets work, and which contract terms turn a broad promise into a measurable commitment.
12 questions to ask a Drupal agency before you sign
A due-diligence guide to evaluating a Drupal agency's ownership terms, delivery team, pricing, support, and post-launch responsibilities.
Warranty, maintenance and SLA are three different things
How warranties, maintenance agreements, and service-level commitments differ, what each covers, and where each belongs in a software contract.
Your agency disappeared. Here is how to take the site back.
A recovery checklist for securing access, code, hosting, data, and future ownership when the agency behind a live system stops responding.
How a takeover runs
- Audit. The codebase, the hosting and the update backlog, with the risks ranked. Nothing is deployed to production until the audit is finished.
- Reconcile. The running site and the repository checked against each other, and the site put under version control.
- Scope. A maintenance scope written against the audit, with the response commitments you need.
- Update. Security releases applied on a copy of the site, tested, then deployed in dependency order.
- Monitor and report. Alerts on the failures that happen quietly, and a report every month.
How we run this work
The takeover audit is a deliverable you keep, whether or not you go on with us. Support runs in business hours, with published response targets: a first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Cover outside business hours is an option, priced separately. We maintain SPREP's site and the sites SPREP has added since, each one after its launch.
- Drupal support and maintenance: for sites we built and sites we inherit.
- Drupal site audit: a fixed-price review of what is in the site, before you decide who looks after it.
- Drupal security audit: when the worry is whether the site has been, or could be, compromised.
- White-label Drupal support: the same work, delivered under an agency's name.
- Our warranty: what it covers, and where maintenance picks up.