Drupal Support: Was ein Retainer abdecken sollte

Die meisten, die Drupal Support suchen, besitzen die Website bereits. Sie haben sie von einer Agentur geerbt, die weitergezogen ist, oder von einem Entwickler, der gegangen ist, und nun ist ein Update überfällig, ein Formular verschickt nichts mehr, oder eine Sicherheitsmeldung ist eingetroffen und niemand kann sagen, ob sie zutrifft. Gewünscht ist keine Verkaufsseite, sondern ein Leistungsverzeichnis: was die Arbeit ist, was ein fairer Vertrag sagt und was das kosten sollte.

Genau das ist dieser Text. Er beschreibt die Arbeit, die eine Drupal-Website jeden Monat wirklich braucht, die betrieblichen Fakten, die darüber entscheiden, ob ein Retainer etwas taugt, und realistische britische Preisbänder. Lesen Sie ihn mit dem Angebot eines Anbieters daneben, denn nützlich wird es dort, wo Sie merken, welche dieser Fragen das Angebot nicht beantwortet.

Zwei Dinge unterscheiden Drupal von gewöhnlicher Website-Wartung. Die Sicherheitsmeldungen folgen einem veröffentlichten Zeitplan, Ihr Zeitfenster ist also messbar und lässt sich vertraglich festhalten. Und eine Drupal-Website ist ein Zusammenbau beigesteuerter Module mit unabhängigen Maintainern, jemand muss also ein bewegliches Upgrade-Ziel für Sie verfolgen.

Was sollte ein Drupal-Support-Retainer abdecken? Die Überwachung der Sicherheitsmeldungen, die auf genau Ihren Modulbestand zutreffen, Core- und Contrib-Updates in einem festen Zyklus über Staging, den Nachweis, dass Backups sich wirklich zurückspielen lassen, die Überwachung von Verfügbarkeit und Anwendungsfehlern sowie ein benanntes Änderungsbudget für kleine Arbeiten. In Großbritannien reicht das von rund £250 im Monat für eine einfache Broschüren-Website bis £2,000 oder mehr für eine komplexe. Darunter kaufen Sie Überwachung, keinen Support.

Was Drupal Support Monat für Monat wirklich bedeutet

Fragen Sie drei Agenturen nach einem Angebot, und Sie bekommen drei Pakete namens Essential, Business und Enterprise, jedes eine Aufzählung von Substantiven. Die Substantive sind nicht die Arbeit. Die Arbeit ist eine Reihe wiederkehrender Aufgaben, die entweder nach Plan stattfinden oder gar nicht, und die nützliche Übung besteht darin, einen Anbieter jede davon als Tätigkeit beschreiben zu lassen, mit Verantwortlichem und Frequenz.

Es sind acht. Überwachung der Sicherheitsmeldungen und Einspielen der Patches. Updates für Core und beigesteuerte Module. Upgrades von Abhängigkeiten und Plattformversionen. Backup-Prüfung und Restore-Tests. Überwachung von Verfügbarkeit und Anwendungsfehlern. Prüfung auf Performance-Regressionen. Redaktionelle Unterstützung. Und ein Änderungsbudget für die kleinen Arbeiten, die immer eintreffen.

Ein Vertrag, der alle acht nennt, ist nicht automatisch gut, aber ein Vertrag, der vier nennt, ist eindeutig unvollständig, und die vier, die wegfallen, sind fast immer dieselben: Restore-Tests, Performance-Regressionen, Plattform-Upgrades und das Änderungsbudget. Das sind die teuren, deshalb verschwinden sie.

Warum die Paketnamen die Arbeit verbergen

“Unbegrenzte Support-Tickets” sagt nichts darüber, wer am dritten Mittwoch des Monats einen Core-Sicherheitspatch einspielt. “Proaktives Monitoring” sagt nichts darüber, ob ein Mensch den Alarm um zwei Uhr nachts liest oder ob er bis Montag liegen bleibt. “Nach bestem Bemühen” sagt überhaupt nichts.

Ersetzen Sie jede Formulierung durch drei Fakten: die Tätigkeit, ihre Frequenz und die benannte Rolle, die sie ausführt. Die meisten Paketseiten lösen sich unter dieser Behandlung auf, und die, die es überstehen, gehören zu den Anbietern, mit denen sich ein Gespräch lohnt.

Das Patch-Fenster ist das ganze Produkt

Drupal veröffentlicht Sicherheitsreleases nach Zeitplan, was ungewöhnlich und außerordentlich nützlich ist. Core-Sicherheitsreleases gehen in einem Fenster am dritten Mittwoch des Monats heraus, beginnend um 1200 America/New York, was je nach Jahreszeit 1600 oder 1700 UTC entspricht. Beigesteuerte Projekte haben jeden Mittwoch ein Fenster für Sicherheitsreleases , Meldungen zu Contrib-Modulen treffen also weit häufiger ein als Core-Meldungen und meist in Schüben.

Die Folge ist, dass nicht die Schwachstelle das Risiko ist. Alle, die Drupal betreiben, erhalten dieselbe Schwachstelle im selben Moment, offen veröffentlicht. Das Risiko ist die Lücke zwischen der Veröffentlichung der Meldung und dem Patch auf Ihrer Produktivseite, denn in dieser Lücke ist der Fehler dokumentiert, indexiert und wird von Leuten gescannt, die die Meldung schneller gelesen haben als Ihr Anbieter.

Jede andere Klausel in einem Supportvertrag ist Dekoration neben der Zahl der Stunden in dieser Lücke. Die erste Frage an einen künftigen Anbieter ist also Arithmetik, keine Philosophie. Wann genau liest am dritten Mittwoch des nächsten Monats ein Mensch die Meldung, und bis wann ist der Patch live? “Innerhalb unseres üblichen SLA” ist darauf keine Antwort.

Wie Drupal Risiko bewertet, und was das für Ihren Vertrag heißen sollte

Jede Drupal-Meldung trägt eine Zahl, und diese Zahl ist das am wenigsten genutzte Werkzeug der Plattform für das Schreiben von Klauseln. Drupal bewertet Schwachstellen mit dem NIST Common Misuse Scoring System, NISTIR 7864 und erzeugt daraus eine Punktzahl von 0 bis 25 über sechs Metriken: Angriffskomplexität, Authentifizierung, Auswirkung auf Vertraulichkeit, Auswirkung auf Integrität, Verfügbarkeit eines Exploits und Verbreitung des Ziels.

Die Punktzahl bildet fünf veröffentlichte Stufen ab. 0 bis 4 ist Not Critical, 5 bis 9 ist Less Critical, 10 bis 14 ist Moderately Critical, 15 bis 19 ist Critical und 20 bis 25 ist Highly Critical. Diese Bänder sind öffentlich, stabil und für keine der beiden Seiten auslegbar.

Damit wären sie das natürliche Rückgrat eines Support-SLA, und fast niemand nutzt sie. Statt private Schweregrade zu erfinden, über die ein Anbieter später streiten kann, schreiben Sie die Reaktionszusage direkt gegen die Drupal-Punktzahl: Highly Critical innerhalb einer genannten Stundenzahl gepatcht, auch außerhalb der Geschäftszeiten, Critical innerhalb eines Arbeitstages, Moderately Critical im nächsten geplanten Zyklus, der Rest gebündelt. Keine Seite kann neu verhandeln, was “dringend” hieß, weil ein Dritter das bereits entschieden hat.

Highly Critical ist ein anderer betrieblicher Vorgang

Highly Critical Core-Releases sind selten, und Drupal behandelt sie anders. Das Sicherheitsteam veröffentlicht vorab eine öffentliche Ankündigung , damit Website-Betreiber eine Abdeckung organisieren können. PSA-2026-05-18 tat genau das und warnte am 18. Mai 2026 vor einem hochkritischen Core-Release für Mittwoch, den 20. Mai, das alle unterstützten Zweige betraf.

Diese Vorwarnung ist das, worum herum Ihr Retainer gebaut sein sollte, denn sie verwandelt einen Notfall in einen Termin. Ein Anbieter, der am Montag von der Ankündigung weiß und für den Mittwoch ein Deployment-Fenster reserviert hat, betreibt einen Supportdienst. Ein Anbieter, der es am Donnerstag erfährt, betreibt einen Newsletter.

Es gibt außerdem eine Abmilderung, die man kennen sollte. Drupal Steward ist eine kostenpflichtige, global verteilte Web Application Firewall der Drupal Association und des Sicherheitsteams, die für hochkritische Core-Lücken virtuelles Patchen auf Netzwerkebene bietet, sodass eine Website geschützt ist, während das Update getestet wird. Die Preise sind in US-Dollar veröffentlicht und skalieren mit dem Verkehr: unter 20 Dollar im Monat für eine Website mit rund 1 Million HTTP-Anfragen, unter 100 Dollar im Monat oberhalb von 10 Millionen. Das kauft Zeit, keine Immunität, und ein guter Retainer sagt, wer dafür zahlt.

Was die Richtlinie für Sicherheitsmeldungen nicht abdeckt

Drei Ausnahmen in der Richtlinie zu Prozess und Berechtigungen für Sicherheitsmeldungen verändern, was ein Retainer leisten muss, und die meisten Supportverträge schweigen zu allen dreien.

Meldungen werden nur für stabile Releases ausgegeben. Läuft auf Ihrer Website ein Modul in einer Alpha-, Beta-, Release-Candidate- oder Dev-Version, wird dafür nie eine Meldung veröffentlicht, und das Ausbleiben von Nachrichten bedeutet nichts. Die Abdeckung erfolgt zudem pro Projekt auf Opt-in-Basis statt automatisch, ein nicht abgedecktes Contrib-Modul kann also einen bekannten Fehler tragen, ganz ohne Benachrichtigungsweg.

Und dann die, die Betreiber kalt erwischt: Für externe Bibliotheken werden keine Meldungen ausgegeben, selbst wenn ein beigesteuertes Projekt deren Installation verlangt. Eine als Abhängigkeit eingebundene JavaScript- oder PHP-Bibliothek ist Ihr Problem, von Ihnen verfolgt, und sie taucht im Drupal-Feed nicht auf.

Abdeckung kann auch entzogen werden

Sicherheitsabdeckung ist nicht dauerhaft. PSA-2026-07-22 entzog dem Modul QA Accounts die Abdeckung mit der Begründung, es stelle Bedienkomfort über Sicherheit und sei nur für Websites gedacht, die aus dem Internet nicht erreichbar sind.

So sieht dieses Risiko aus. Ein Modul, das Sie vor Jahren unter Abdeckung installiert haben, kann sie still verlieren, und auf Ihrer Website ändert sich nichts, das Ihnen das sagen würde. Ein Inventar jedes installierten Projekts mit seinem aktuellen Abdeckungsstatus und seiner Release-Stabilität zu führen, ist echte wiederkehrende Arbeit, und sie gehört schriftlich in den Retainer.

Upgrades von Abhängigkeiten und Plattform sind Supportarbeit

Der am häufigsten ausgeschlossene Punkt in einem Drupal-Supportvertrag ist der, der am Ende darüber entscheidet, ob die Website überlebt. Drupals Plattformanforderungen bewegen sich, und sie bewegen sich in Schritten, die einen Hosting-Wechsel brauchen statt eines composer update.

Bei PHP verlangt Drupal 10 mindestens PHP 8.1 , während Drupal 11 seit 11.1 PHP 8.3 als Minimum fordert. PHP 8.5 wurde in Drupal 11.3 unterstützt, und Drupal 12.0 unterstützt ausschließlich PHP 8.5. Dieses letzte Detail wiegt schwerer, als es aussieht: Eine Website, die heute bequem auf PHP 8.1 sitzt, ist zwei erzwungene Plattformwechsel von Drupal 12 entfernt.

Die Datenbankanforderungen sind ebenso weit gewandert. Drupal 11 braucht MySQL 8.0 oder neuer, MariaDB 10.6 oder neuer, PostgreSQL 16 oder neuer oder SQLite 3.45 oder neuer. Drupal 10 akzeptierte MySQL 5.7.8, MariaDB 10.3.7 und PostgreSQL 12. Ein Managed Host, der noch MySQL 5.7 ausliefert, ist ein Blocker auf dem Upgrade-Pfad, kein Detail, und unsere Notiz dazu, was Drupal wirklich gut betreibt , beschreibt, wohin man wechselt.

Das Lebensende von Drupal 10 ist bereits ein Retainer-Problem

Drupal 10 erreicht am 9. Dezember 2026 sein Lebensende , und Drupal 12 erscheint in derselben Woche, beginnend am 7. Dezember 2026. Die Sicherheitsunterstützung für die Zweige 11.3.x und 10.6.x endet zum selben Zeitpunkt. Stand September 2026 erhalten die Zweige 11.4.x, 11.3.x und 10.6.x Sicherheitsreleases.

Gegen den Kalender gelesen sind das etwa drei Monate. Jede Drupal-10-Website ohne kalkulierten Upgrade-Plan im September 2026 wird den Dezember damit verbringen, entweder einen Eilaufschlag zu zahlen oder ohne Support zu laufen, und die zweite Möglichkeit sollte jemand bewusst entscheiden statt aus Trägheit.

Ein Retainer, der sein Geld wert ist, sollte vier Dinge bereits erzeugt haben: einen aktuellen Bericht zum Upgrade-Status, einen Scan des Custom-Codes und des Themes auf veraltete Aufrufe, eine Bereitschaftsprüfung jedes beigesteuerten Moduls gegen Drupal 11 und 12 sowie eine schriftliche Schätzung. Hat Ihr Anbieter davon bis jetzt nichts geliefert, ist genau das der Befund. Unsere Aufschlüsselung von Drupal-Migration, Optionen und Fristen beschreibt den Arbeitsumfang, und dieselbe Planung steckt in unseren Projekten zur Website-Entwicklung .

Backups sind nichts wert, bis ein Restore getestet ist

Fast jeder Drupal-Supportvertrag verspricht Backups. Sehr wenige versprechen ein Zurückspielen, und dieser Unterschied ist der ganze Wert der Position. Das NCSC sagt es in seinem Leitfaden für kleine Organisationen deutlich: Wenn Sie Ihr Backup erstellt haben , müssen Sie wissen, wie Sie es zurückspielen, und prüfen, dass es alles Wichtige enthält.

Ein Drupal-Restore hat drei bewegliche Teile, und unvollständige Backups scheitern am zweiten mit ermüdender Regelmäßigkeit. Sie brauchen die Datenbank, die öffentlichen und privaten Dateiverzeichnisse und die Konfiguration. Ein Backup, das die Datenbank erfasst, aber nicht das Dateiverzeichnis, stellt eine Website mit intakten Inhalten und ohne Bilder wieder her, was für ein Monitoring-Skript wie eine funktionierende Website aussieht und für einen Kunden wie eine Katastrophe.

Verlangen Sie einen datierten Restore-Test, ausgeführt in einer Wegwerf-Umgebung, mit einer schriftlichen Notiz, wie lange er gedauert hat und was gefehlt hat. Quartalsweise ist für die meisten Websites eine vernünftige Frequenz. Hat ein Anbieter nie einen gemacht, kennt er seine eigene Wiederherstellungszeit nicht, und Sie auch nicht.

Verfügbarkeits- und Fehlerüberwachung, und was Verfügbarkeit wirklich misst

Zwischen “der Server läuft” und “die Website funktioniert” liegt eine große Lücke, und Drupal sitzt mitten darin. Ein PHP-Fatal-Error, ein erschöpftes Speicherlimit, eine fehlgeschlagene Datenbankverbindung oder ein kaputter Cache-Rebuild erzeugen alle eine Seite, die eine naive Prüfung als Erfolg liest, oder ein schlichtes 500, auf das niemand achtet.

Am Server gemessene Überwachung sagt Ihnen, dass die Kiste antwortet. An der Anwendung gemessene Überwachung ruft eine echte Seite ab, folgt Weiterleitungen und prüft, dass erwartete Inhalte im Antworttext vorhanden sind. Das sind verschiedene Produkte mit verschiedenen Preisen, und ein Supportangebot, das “Uptime-Monitoring” sagt, ohne zu sagen welches, beschreibt das billigere von beiden.

Darunter liegt Drupals eigenes Protokoll. Der Bericht der letzten Protokollmeldungen und das PHP-Fehlerprotokoll sind die Stelle, an der ein scheiternder Cron-Lauf, eine veraltete Funktion oder ein Modul, das bei jedem Aufruf Ausnahmen wirft, lange vor der ersten Kundenbeschwerde sichtbar wird. Jemand muss sie planmäßig lesen. Unser Beitrag zu Uptime-SLAs, die etwas bedeuten , erklärt, wie sich die Prozentwerte in erlaubte Minuten übersetzen.

Ein Drupal-Support-SLA kritisch lesen

Die meisten Support-SLAs sind geschrieben, um unterzeichnet zu werden, nicht um benutzt zu werden, und sie werden unterzeichnet, weil sie schnell gelesen werden. Drei Klauseln tragen fast das gesamte Gewicht, und sie sorgfältig zu lesen dauert zehn Minuten.

Reaktionszeit ist nicht Lösungszeit

Ein SLA, das zwei Stunden Reaktionszeit verspricht, verspricht üblicherweise, dass jemand das Ticket binnen zwei Stunden bestätigt. Es verspricht nicht, dass irgendwer auf Ihre Website schaut. Anbieter, die es ernst meinen, verpflichten sich zu einem Lösungsziel oder mindestens zu einem Ziel für Diagnose und Umgehungslösung, mit getrennt genannter Zeit für die Behebung.

Wo sich Arbeit ehrlich nicht in eine Zeitbox pressen lässt, sagt ein aufrichtiger Vertrag das und verpflichtet sich stattdessen zu durchgehendem Einsatz bis zur Lösung. Das ist eine echte Zusage. “Zwei Stunden Reaktionszeit” für sich allein ist die Zusage, eine E-Mail zu schicken.

Die Definition der Schweregrade entscheidet alles

Jedes SLA hat eine Schweregradtabelle, und üblicherweise vergibt der Anbieter den Schweregrad. Das ist die Lücke. Lautet die Definition von Priorität 1 “Website nicht erreichbar”, dann ist ein Bezahlvorgang, der bei einem Drittel der Kunden scheitert, Priorität 3 und wird nächste Woche angesehen.

Schreiben Sie die Definitionen um die geschäftliche Auswirkung herum statt um den technischen Zustand, und nehmen Sie ausgearbeitete Beispiele in den Vertrag auf: ein scheiternder Zahlschritt, ein nicht erreichbarer Admin-Login, ein kaputtes Kontaktformular auf der Anfrageseite. Vereinbaren Sie dann, wer den Schweregrad vergibt und wie Sie eine Einstufung anfechten.

Abdeckungszeiten sind nicht Geschäftszeiten

“Geschäftszeiten” und “Abdeckung” meinen Verschiedenes und werden oft synonym verwendet. Abdeckung ist der Zeitraum, in dem die Uhr läuft und jemand handeln muss. Liegt die Abdeckung an Werktagen bei 09:00 bis 17:30, wird eine Meldung, die an einem Mittwoch im Dezember um 1700 UTC erscheint, frühestens am nächsten Morgen aufgegriffen.

Für Drupal gilt speziell: Das Core-Sicherheitsfenster öffnet um 1600 oder 1700 UTC. Ein britischer Anbieter, dessen Abdeckung um 17:30 endet, sitzt strukturell an dessen Rand, Regelungen außerhalb der Geschäftszeiten für Highly-Critical-Meldungen müssen also getrennt benannt und bepreist werden.

Was als Störung zählt und was ausgeschlossen ist

Der Abschnitt mit den Ausschlüssen ist die Stelle, an der ein Retainer still billiger wird, als er aussieht. Übliche Ausschlüsse sind einzeln völlig vernünftig und in Kombination unvernünftig: Fehler beim Hosting Dritter, Probleme durch Mitarbeitende des Kunden, Fehler in Modulen, die der Anbieter nicht installiert hat, alles rund um ein gekauftes Theme und alles, was der Anbieter als Änderung statt als Störung einstuft.

Der letzte Punkt ist die scharfe Kante. Verlangt eine Fehlerbehebung eine Konfigurationsänderung, und sind Konfigurationsänderungen abrechenbar, dann lässt sich fast jede Störung in die abrechenbare Spalte umbuchen. Fragen Sie direkt, wie der Anbieter eine Störung von einer Änderung unterscheidet, und bitten Sie um je zwei Beispiele aus seiner eigenen jüngeren Arbeit.

Prüfen Sie auch, was mit Dritten geschieht. Wenn das Zahlungs-Gateway, der CRM-Konnektor oder der Hoster schuld ist, koordiniert der Anbieter dann die Behebung, oder schließt das Ticket als außerhalb des Umfangs? Koordination ist echte Arbeit und ihr Geld wert, aber nur, wenn der Vertrag sagt, dass sie stattfindet.

Die drei Retainer-Modelle, ehrlich verglichen

Fast jede Drupal-Supportvereinbarung hat eine von drei Formen, und jede ist eine sinnvolle Antwort auf eine andere Lage. Der Fehler besteht darin, eine Form zu kaufen und das Verhalten einer anderen zu erwarten.

Feste Stunden im Monat

Sie kaufen einen Block Stunden, etwa 8 oder 16, und der Anbieter verwendet sie auf das, worum Sie bitten. Das ist transparent, zwischen Angeboten leicht vergleichbar und passt zu einer Organisation mit einem steten Rinnsal kleiner Änderungen und jemandem intern, der priorisieren kann.

Die Schwäche ist, dass Wartung mit Features um denselben Topf konkurriert. In einem hektischen Monat verliert das Sicherheitspatchen still gegen die Kampagnen-Landingpage, weil die Person, die die Stunden ausgibt, eine Deadline hat und der Patch sich nicht wie eine anfühlt. Kaufen Sie dieses Modell, dann zäunen Sie im Vertrag selbst einen Teil der Stunden für Wartung ein.

Unbegrenzte Fehlerbehebung plus angebotene Änderungen

Der Anbieter übernimmt Wartung und kleine Behebungen für eine feste Monatspauschale, und alles oberhalb einer vereinbarten Schwelle wird gesondert angeboten. Dieses Modell drängen die meisten Agenturen, und für eine stabile Website mit einem nervösen Betreiber ist es tatsächlich die richtige Antwort, weil es ein variables Risiko in eine feste Budgetzeile verwandelt.

Die Schwäche ist die Grenze. “Kleine Behebung” ist undefiniert, bis jemand eine braucht, und die Schwelle verschiebt sich je nachdem, wie der Monat läuft. Bestehen Sie auf einer schriftlichen Definition, idealerweise einer Zeitbox wie alles unter 30 Minuten, und auf einem Monatsbericht, der zeigt, was übernommen wurde.

Reiner Aufwand nach Zeit

Kein Retainer, ein Tagessatz und Arbeit, wenn Sie darum bitten. Das ist die ehrliche Wahl für eine risikoarme Website mit einem Betreiber, der Updates wirklich verfolgt, und für Organisationen mit eigener Kompetenz, die gelegentlich Spezialhilfe brauchen statt Abdeckung.

Die Schwäche ist, dass nie etwas Proaktives geschieht, weil niemand dafür bezahlt wird hinzusehen. Aufwand nach Zeit steht außerdem schlecht in der Warteschlange: Sie konkurrieren mit Retainer-Kunden um dieselben Entwickler, an einem schlechten Tag misst sich die Reaktion also in Wochen statt in Stunden.

Das Anreizproblem bei pauschalem Support

Pauschaler Support hat ein strukturelles Problem, über das in der Branche niemand gern spricht. Wird der Anbieter gleich bezahlt, egal wie viele Stunden eine Website verbraucht, dann schmälert jede Stunde auf Ihrer Website seine Marge, und das kaufmännisch rationale Verhalten ist, so wenige wie möglich aufzuwenden.

Das zeigt sich meist nicht als Vernachlässigung. Es zeigt sich als Vorliebe für die schnelle statt die richtige Behebung, für das Unterdrücken eines Symptoms statt für das Verfolgen einer Ursache und für das Aufschieben des Modul-Upgrades, das einen Tag Regressionstests kosten würde. In günstigen Tarifen zeigt es sich in der Gegenrichtung, wo die Pauschale nur aufgeht, wenn die Website tatsächlich nie angefasst wird.

Das Gegengewicht ist eine Berichtspflicht. Ein Monatsbericht mit verbrauchten Stunden, eingespielten Updates, bewerteten Meldungen und geschlossenen Tickets macht den Verbrauch für beide Seiten sichtbar und macht aus einem unrentablen Kunden ein Gespräch statt eines langsamen Serviceverfalls. Jeder Anbieter, der Vertrauen in das Modell hat, wird zustimmen. Ein Anbieter, der sich sperrt, sagt Ihnen, wofür das Modell wirklich da ist.

Wie gute Praxis operativ aussieht

Drei technische Praktiken trennen einen Drupal-Anbieter, der Ihre Website sicher betreuen kann, von einem, der improvisiert. Keine davon ist exotisch, und nach allen dreien lässt sich leicht fragen.

Composer, oder gar nichts

Drupals eigene Dokumentation ist beim Mischen von Update-Methoden unmissverständlich und warnt, dass Websites kritische Update-Probleme bekommen können , wenn Composer-Updates mit anderen Wegen kombiniert werden, und dass Composer, sobald es ein Modul verwaltet, auch den Core verwalten muss. Ein Anbieter, der Modulordner noch per FTP hochlädt, wird irgendwann ein vendor-Verzeichnis löschen, von dem ein beigesteuertes Modul abhing.

Fragen Sie, ob composer.json und composer.lock in der Versionsverwaltung liegen und ob Composer auf der Produktion läuft oder das gebaute Artefakt ausgeliefert wird. Beide Antworten können richtig sein. Keine Antwort zu haben, kann es nicht.

Eine Staging-Umgebung, die zur Produktion passt

Eine Staging-Website mit anderer PHP-Version, anderer Datenbankversion oder anderem Modulbestand testet nichts Nützliches. Der Sinn von Staging ist, einen Sicherheitspatch dort scheitern zu lassen, wo es kein Geld kostet, und das leistet es nur, wenn beide Umgebungen auf den Achsen übereinstimmen, die brechen.

Fragen Sie, wie Staging aus der Produktion aufgefrischt wird, wie oft, und ob es eine anonymisierte Kopie echter Inhalte hält. Eine Staging-Website mit drei Testknoten wird das Update nicht aufdecken, das eine View über 40.000 Zeilen zerlegt.

Konfiguration in der Versionsverwaltung

Drupal hält die Konfiguration standardmäßig in der Datenbank , und das Konfigurationsmanagement existiert, um sie in Dateien zu exportieren, die sich committen, prüfen und in eine andere Umgebung importieren lassen. Ein Team, das es nutzt, kann die Einstellungen der Website deterministisch reproduzieren. Ein Team, das es nicht nutzt, klickt sich auf der Produktion durch Adminmasken und hofft.

Das ist das klarste Signal in einem Anbietergespräch. Fragen Sie, wie eine auf Staging gemachte Änderung in die Produktion gelangt. Ist die Antwort eine Beschreibung statt einer Pause, ist der Rest des Gesprächs meist in Ordnung.

Wer das Deployment nicht beschreiben kann, hat geantwortet

Es gibt keine höfliche Formulierung dafür. Ein Anbieter, der nicht in einer ruhigen Minute beschreiben kann, wie Code vom Rechner eines Entwicklers auf Ihre Live-Website gelangt, sagt Ihnen, dass Deployments improvisiert sind. Improvisierte Deployments sind der Grund, warum Sicherheitspatches liegen bleiben: Niemand will den riskanten manuellen Ablauf an einem Mittwochabend fahren.

Die Offboarding-Klausel, die niemand liest

Irgendwann wechseln Sie den Anbieter, und die Klausel, die diesen Moment regelt, wird geschrieben, solange alle freundlich sind, und gelesen, wenn niemand es mehr ist. Sie sollte vier Dinge klar sagen.

Wem der Code gehört, einschließlich Custom-Modulen und Theme-Arbeit, und unter welcher Lizenz. Wo das Repository liegt und wie der Zugang übergeht. Dass ein vollständiger Export von Datenbank, Dateien und Konfiguration in einem genannten Format binnen einer genannten Zahl von Werktagen bereitgestellt wird. Und dass DNS, Hosting und Zugangsdaten zu Drittdiensten übergeben und nicht einbehalten werden.

Das Versagen ist meist keine Bosheit. Es ist ein Anbieter, der Ihre Website auf seinem eigenen Konto hostet, die einzige Kopie des Repositorys hält und sechs Wochen zum Antworten braucht, weil Sie kein zahlender Kunde mehr sind. Verlangen Sie die Offboarding-Klausel vor der Unterschrift und werten Sie Zögern als Information.

Drupal 7: Lebensende, Extended Support und die Lücke dazwischen

Die Sicherheitsunterstützung für Drupal 7 endete am 5. Januar 2025 . Die Community stellte die Patches ein, und das enorme Ökosystem beigesteuerter Module, das Drupal 7 nützlich machte, wurde parallel dazu nicht mehr gepflegt.

Die Drupal Association betreibt ein Extended Security Support Provider Program, und HeroDevs und Tag1 Consulting sind die darunter zertifizierten Anbieter. Diese Unterstützung zu kaufen ist eine legitime Entscheidung für eine Organisation, die dieses Jahr wirklich nicht migrieren kann, und sie ist spürbar besser als nichts.

Was sie nicht leistet, ist, die Website im gewöhnlichen Sinn sicher zu machen. Ein kommerzieller Anbieter patcht die Schwachstellen, die er findet oder gemeldet bekommt, nach eigenem Zeitplan, für den Modulbestand, den er zu decken zugesagt hat. Er stellt den öffentlichen Meldeprozess nicht wieder her, er deckt nicht jedes beigesteuerte Modul ab, das Sie zufällig installiert haben, und er erstreckt sich nicht auf die externen Bibliotheken, von denen diese Module abhängen. Extended Support ist eine kontrollierte Art, eine nicht unterstützte Plattform zu betreiben, und ein Supportvertrag ist kein Synonym für Sicherheit.

Sitzen Sie im September 2026 auf Drupal 7, lautet der ehrliche Rat, das Geld in die Migration zu stecken statt in Miete. Unser Leitfaden zur Drupal-Webentwicklung 2026 beschreibt die Plattform, wie sie heute dasteht, und die tiefere Betrachtung des Meldeprozesses steht in unserer Notiz zu Drupal-Sicherheit, Meldungen und echtem Risiko .

Redaktionelle Unterstützung und das Änderungsbudget

Zwei Punkte werden aus Supportverträgen herausgedrückt, weil sie schwer zu begrenzen sind, und beide sind die, die Kunden tatsächlich bemerken.

Redaktionelle Unterstützung heißt: jemand, der einen Inhaltstyp anlegen kann, eine View reparieren, die nicht mehr richtig filtert, eine Redakteurin nach einem Personalwechsel neu einweisen oder herausfinden, warum ein Bildstil Gesichter abschneidet. Das ist unspektakulär und häufig, und ein Retainer ohne diesen Punkt erzeugt einen Kunden, der aufhört zu fragen und anfängt, die Website zu umgehen.

Das Änderungsbudget ist die andere Hälfte. Jede Website sammelt eine Schlange kleiner Arbeiten an: ein Feld in einem Formular, eine Weiterleitung nach einem Seitenumzug, eine Änderung, wer Anfragen erhält. Für diese Schlange ein monatliches Kontingent in Stunden zu benennen, verhindert, dass daraus ein vierteljährliches Notprojekt wird. Zwei bis vier Stunden im Monat sind für eine kleine Website realistisch, 8 bis 16 für eine stark genutzte.

Was Drupal Support in Großbritannien kostet

Die Zahlen unten sind unsere Hausschätzungen für 2026, gestützt auf britische Agenturarbeit statt auf eine veröffentlichte Umfrage, und sie setzen einen Anbieter voraus, der die acht oben beschriebenen Tätigkeiten leistet, kein Monitoring-Abo mit angehängtem Support-Postfach.

In Prosa: Eine kleine Broschüren-Website liegt bei rund £250 bis £600 im Monat, was Meldungsüberwachung, einen monatlichen Patch-Zyklus, Backup-Prüfung und ein bis zwei Stunden Änderungen kauft. Eine mittelgroße Website mit Integrationen liegt bei etwa £700 bis £1,800, weil jede Integration eine Regressionsfläche hinzufügt, die nach jedem Core-Update erneut geprüft werden muss. Eine komplexe oder mehrsprachige Website mit Custom-Modulen beginnt bei rund £2,000 und erreicht £6,000 oder mehr.

Reine Überwachungsvereinbarungen, bei denen ein Anbieter die Meldungen beobachtet und Ihnen sagt, was zutrifft, aber nichts ausrollt, liegen niedriger bei etwa £250 bis £450 im Monat. Stellen Sie diese Bänder neben britische Agentur-Tagessätze von £600 bis £900, und ein Retainer von £1,500 kauft ungefähr zwei Entwicklertage. Das Detail zu den Sätzen steht in unserer Notiz zu Drupal-Entwicklersätzen, Fähigkeiten und Prüfung , das weitere Budgetbild in Kosten der Softwarewartung .

Was eine Website von einem Band ins nächste hebt

Der Instinkt ist, Support nach Traffic zu bepreisen, und Traffic ist beinahe irrelevant. Eine Website mit 200.000 Besuchen im Monat, zwanzig Modulen und ohne Integrationen ist billiger zu betreuen als eine mit zweitausend Besuchen, einem CRM-Konnektor, einem Zahlungs-Gateway und einer eigenen Migration.

Drei Dinge treiben die Kosten wirklich. Die Modulzahl, weil jedes beigesteuerte Modul ein zu beobachtender Meldungsfeed ist und bei jedem Core-Update ein Kompatibilitätsrisiko. Die Zahl der Integrationen, weil jede ein externer Vertrag ist, der sich unter Ihnen ändern kann, und ein Regressionstest, der erneut laufen muss. Und das redaktionelle Volumen, weil ein aktives Redaktionsteam stetig Supportfragen, Rechteänderungen und Anpassungen am Inhaltsmodell erzeugt.

Custom-Code ist der Multiplikator über alle drei. Eine Website mit 12.000 Zeilen eigenem Modulcode braucht bei jedem Minor-Release einen Deprecation-Scan und einen Regressionsdurchlauf, also einen Tag Arbeit, den eine rein beigesteuerte Website nicht hat. Daher kommt das oberste Band, und genau diese Arbeit sollen unsere Projekte zur Softwareentwicklung meist auffangen.

Fragen an einen künftigen Anbieter

Sechs Fragen, und die Antworten, die Sie beunruhigen sollten.

Auf welcher Drupal- und PHP-Version läuft unsere Website jetzt, und wie sieht der Upgrade-Pfad aus? Eine Antwort, für die jemand nachsehen muss, ist in Ordnung. Eine Antwort, die eine Woche später kommt, nicht. Wie erfahren Sie, dass eine Sicherheitsmeldung uns betrifft? “Wir beobachten drupal.org” ist schwach; ein Modulinventar pro Website ist die Antwort, die Sie wollen.

Führen Sie mich durch Ihren Deployment-Prozess. Zögern ist hier das stärkste Negativsignal im ganzen Gespräch. Wann haben Sie diese Website zuletzt aus einem Backup wiederhergestellt? “Wir machen tägliche Backups” ist keine Antwort darauf. Was ist vom Retainer ausgeschlossen, und wie entscheiden Sie, ob etwas eine Störung oder eine Änderung ist? Und schließlich: Wenn wir gehen, was bekommen wir und wie schnell?

Was passiert, wenn es keinen Retainer gibt

Das ist eher eine Abfolge als eine Warnung, und sie läuft auf jeder ungewarteten Drupal-Website etwa im selben Tempo.

In den ersten Monaten passiert nichts, und das ist das Problem, denn es lehrt alle, dass nichts passieren muss. Irgendwann zwischen Monat sechs und Monat zwölf überschreitet der Update-Rückstand den Punkt, ab dem Updates einzeln nicht mehr sicher sind, weil ein Modul nun einen neueren Core braucht, der ein neueres PHP braucht, das der Hoster nicht anbietet. Einen Patch einzuspielen ist zu einem Projekt geworden.

Dann fällt die Website ganz aus der Plattformunterstützung, und eine Browser- oder PHP-Änderung zerlegt etwas Sichtbares. Die Reparatur beginnt nun mit einem Upgrade, das niemand budgetiert hat, angeboten als Notfallarbeit, und die Teile der Website ohne Dokumentation werden neu gebaut statt repariert. Kommt es unterwegs zu einer Verletzung mit personenbezogenen Daten, erwartet die ICO eine Meldung binnen 72 Stunden nach Kenntnisnahme, wenn ein Risiko für Rechte und Freiheiten wahrscheinlich ist, und diese Frist halten Sie mit Protokollen und Backups ein, die Sie entweder haben oder nicht.

Die Rechnung für die Wiederherstellung ist verlässlich ein Mehrfaches des Retainers, der sie verhindert hätte, und der Unterschied ist nicht die Arbeitszeit. Es ist, dass geplante Arbeit an einem Dienstag mit Rollback-Plan geschieht und Notfallarbeit an einem Sonntag ohne.

Den Umfang klären, bevor Sie unterschreiben

Der Zweck von alldem ist nicht, Sie gegen Anbieter misstrauisch zu machen. Er ist, den Vergleich zweier Angebote aussagekräftig zu machen, denn derzeit sind die meisten Drupal-Supportangebote von Natur aus unvergleichbar: andere Worte, andere Ausschlüsse und keine gemeinsame Definition dessen, was die monatliche Arbeit ist.

Nehmen Sie die acht Tätigkeiten, die Drupal-Risikobänder, die drei Retainer-Modelle und die sechs Fragen und halten Sie sie gegen das, was auf Ihrem Schreibtisch liegt. Was das übersteht, ist ein echtes Angebot.

Mecanik betreut Drupal-Websites im Rahmen unserer Arbeit zur Website-Entwicklung und Softwareentwicklung , und der erste Auftrag ist meist ein Inventar statt einer Reparatur, weil die meisten Websites, die zu uns kommen, nicht sagen können, welche ihrer Module noch vom Feed der Sicherheitsmeldungen abgedeckt sind.

Häufig gestellte Fragen

Was sollte ein Drupal-Support-Retainer enthalten? Acht Tätigkeiten: Überwachung der Sicherheitsmeldungen gegen genau Ihren Modulbestand, Core- und Contrib-Updates in einem festen Zyklus, Upgrades von Abhängigkeiten und PHP-Plattform, Backup-Prüfung mit getesteten Restores, Überwachung von Verfügbarkeit und Anwendungsfehlern, Prüfung auf Performance-Regressionen, redaktionelle Unterstützung und ein benanntes Änderungsbudget in Stunden. Ein Vertrag, der nur vier nennt, ist unvollständig, und die vier, die meist fehlen, sind Restore-Tests, Performance-Prüfungen, Plattform-Upgrades und das Änderungsbudget.

Was kostet Drupal Support pro Monat in Großbritannien? Als Hausschätzung für 2026 liegt eine kleine Broschüren-Website bei rund £250 bis £600 im Monat, eine mittelgroße Website mit ein oder zwei Integrationen bei £700 bis £1,800 und eine komplexe mehrsprachige Website mit Custom-Modulen bei £2,000 bis £6,000. Reine Überwachungsvereinbarungen liegen bei etwa £250 bis £450. Gegen britische Agentur-Tagessätze von £600 bis £900 kauft ein Retainer von £1,500 ungefähr zwei Entwicklertage.

Wann veröffentlicht Drupal Sicherheitspatches? Drupal-Core-Sicherheitsreleases gehen in einem Fenster am dritten Mittwoch des Monats heraus, beginnend um 1200 America/New York, was je nach Jahreszeit 1600 oder 1700 UTC entspricht. Beigesteuerte Projekte haben jeden Mittwoch ein Fenster für Sicherheitsreleases. Hochkritischen Core-Releases geht eine öffentliche Ankündigung voraus, damit Website-Betreiber vorab eine Abdeckung organisieren können.

Ist Extended Support für Drupal 7 dasselbe wie Sicherheit? Nein. Die Sicherheitsunterstützung für Drupal 7 endete am 5. Januar 2025, und die Drupal Association zertifiziert HeroDevs und Tag1 Consulting unter ihrem Extended Security Support Provider Program. Diese Anbieter patchen, was sie abdecken, nach eigenem Zeitplan, für einen vereinbarten Modulbestand. Das stellt den öffentlichen Meldeprozess nicht wieder her, deckt nicht jedes installierte beigesteuerte Modul ab und erstreckt sich nicht auf externe Bibliotheken.

Wann erreicht Drupal 10 sein Lebensende? Drupal 10 erreicht am 9. Dezember 2026 sein Lebensende, in derselben Woche, in der Drupal 12 erscheint, beginnend am 7. Dezember 2026. Die Sicherheitsunterstützung für die Zweige 11.3.x und 10.6.x endet zum selben Zeitpunkt. Drupal 12 unterstützt ausschließlich PHP 8.5, Websites auf älteren PHP-Versionen brauchen also einen Hosting-Wechsel vor dem Upgrade, nicht danach.