Skip to main content
AI bot ProDigi
ProDigi
Online
Hello, my name is ProDigi – you tell me the goal, I'll find the best way to get there! How can I help you?
2.08.2026 16:04 o'clock

Drupal maintenance for complex websites

Drupal maintenance for releases you can rely on

We test core, module and security updates on development or staging, roll out approved changes in a controlled way, and document the version state, the test results and anything still open. For public bodies, universities and complex organisations.

Request maintenanceSee the Drupal audit

What ongoing Drupal maintenance covers

Updates are not simply installed. Dependencies, configuration and the central user journeys have to keep working afterwards.

Getting updates safely into production

We assess the available updates, prepare them under version control and agree the release with the teams responsible.

  • core, module and security updates
  • known dependencies and compatibility risks
  • an agreed release and rollback path

Testing changes beforehand

Updates run on development or staging first. There we check the technical logs and the critical processes we agreed on.

Documenting the decisions

The closing record sets out the changes, the test results, the open points and the recommended next step.

What we look after on a regular basis

The actual scope follows the system, the operating model, the custom code and the testing routes we agree.

Code and dependencies

We keep the supported Drupal version and its dependencies up to date in a controlled way. Changes stay traceable through the repository and the lock file.

  • Drupal core and contributed modules
  • project themes and custom modules
  • Composer packages and the lock file
  • release notes and security advisories

Request maintenance

Preparing operations

Database updates, configuration, cache, cron, queues and any project-specific deployment steps are part of the release.

Checking the critical journeys

Depending on what we agree, we test forms, search, sign-in, roles, multilingual behaviour, interfaces and the central pages.

From the update to a documented release

The process creates clear approval points for IT, editorial teams, business units and any other suppliers involved.

  1. Assess what is there and what is available

    Version state, advisories, dependencies and release notes determine a sensible scope.

    The result is a bounded update and test plan.

  2. Try the changes on development

    We update deliberately, reconcile database and configuration, and check the technical logs.

    Problems surface before the production window, not during it.

  3. Prepare the approval

    Smoke tests, visual checks and the agreed regression tests secure the central functions.

    Backup gate, approval and rollback are settled in advance.

  4. Publish to production

    The deployment runs in the agreed window. Afterwards we check the central journeys and the logs again.

    Changes and remaining findings are documented.

What stays traceable after maintenance

A fresh backup is not yet a tested restore. We therefore document the testing and rollback state we actually agreed on, without promising more than that.

Request maintenance

What you receive

  • the documented version and package state
  • a list of the changes made
  • test results for the agreed user journeys
  • known remaining findings and dependencies
  • release and rollback status
  • the recommended next action

Which starting point suits your system?

Ongoing maintenance assumes a system that is basically maintainable. Other situations need their own starting point.

Regular maintenance

The platform is fundamentally sound and should be kept up to date on a planned basis within a supported Drupal version.

A single, clearly bounded update can be the starting point too.

Request maintenance

Technical Drupal audit

When the version state, the risks, the ability to update or the technical debt are unclear to begin with.

See the Drupal audit

Major upgrade

Moving to a new major Drupal version needs a compatibility analysis and a project scope of its own.

Request an upgrade

An acute incident

An outage, a suspected compromise or a critical advisory is assessed separately. We do not offer a 24/7 emergency channel; response times are agreed explicitly.

Assess an incident

End of support for Drupal 10

After that date, according to Drupal.org, no further Drupal 10 releases will be published.

See the official release schedule

Plan the upgrade window now

The actual effort depends on modules, custom code, interfaces and the operating model. Checking those dependencies early is what makes budget, participants and release windows plannable.

  • target state and technical upgrade path
  • compatibility of modules, custom code and integrations
  • test, approval and rollback plan for the move
Request an upgrade
See the Drupal audit

Maintenance inside complex organisations

One example is the university-wide Drupal platform of the University of Siegen, which we support and develop further after its relaunch.

University of Siegen

Since the web relaunch we have supported the university-wide Drupal platform in maintenance and further development. Bug fixing, stabilisation and targeted features run through agreed budgets and approval routes.

Our work combines technical maintenance with coordination across the central IT department, development, quality assurance and the editorial requirements of the individual faculties.

The platform is carried forward through agreed maintenance, approval and development cycles.

Frequently asked questions about Drupal maintenance

On the update route, rollback planning, audits and major upgrades.

Yes. We start by establishing the version state, the repository, hosting, deployment, custom code and the access that exists. If maintainability cannot be judged reliably, we recommend a technical Drupal audit before the handover.

Regular updates are prepared under version control and tested on development or staging first. Before the production window we agree the backup gate, the approval, the critical user journeys and the rollback path.

Problems should become visible on development. If a critical error occurs during the maintenance window, the agreed rollback path, a root cause analysis and a fresh approval attempt take over. A backup on its own is not yet a tested restore.

An audit makes sense when the version state, custom code, hosting, deployment, security posture or technical debt cannot yet be judged reliably. It creates the basis for maintenance, remediation or an upgrade.

Drupal 10 reaches end of life on 9 December 2026. According to the official release schedule, no further Drupal 10 releases will appear after that. Moving to a supported major version is not a routine monthly update: it needs its own compatibility analysis, changes to custom code and integrations, and an agreed test and release plan.

We check the critical components and baseline values agreed in advance as a regression test. That does not replace a full accessibility, performance or security audit.