A Drupal site is not “maintained” because someone remembers to run updates. Sustainable maintenance has a named owner, a tested path from update to production, and a way to respond when a dependency or security issue changes the plan. This guide lays out that operating model.
Establish the system record
Document Drupal core version, PHP/runtime requirements, modules, themes, custom code, hosting, integrations, and support contacts. Keep environments and deployment steps reproducible. Record which modules are business-critical and who owns their function. Drupal Views contextual filters.
Review the current release and security information on a schedule. Treat end-of-support dates and dependency compatibility as planning inputs, not surprises discovered during a rushed update.
Make updates routine and reversible
Use version control and a staging environment representative of production. Review release notes and compatibility, take a verified backup, apply changes through a repeatable deployment, and check status reports, logs, forms, search, and key content workflows.
Test restoration as well as backup creation. Define who approves a production release and how to roll back code and database changes together if a deployment causes a material problem.
Assign operational ownership
Name a person or team for update triage, incident response, editor support, access review, and vendor escalation. Use least privilege and remove stale accounts. Keep production access auditable and separate routine editorial permissions from infrastructure administration. See also Content types and fields.
Set expectations for response times and maintenance windows. A plan that depends on an unavailable contractor or undocumented personal account is not resilient.
Review the site as it changes
Check accessibility, broken links, performance, forms, backups, logs, and content quality at an agreed cadence. Review contributed modules for maintenance and security posture before adding them. Revisit the content model when editors repeatedly work around it.
Track technical debt and upgrades as work with owners and dates. Maintenance is an ongoing service to users and editors, not a once-a-year version bump.
What would you do?
Who owns the update, backup, and incident decisions for your Drupal site today? Share your experience in the comments.
Have a related project in mind? Talk with Acorn.
Share your perspective