Drupal-Wartung: was läuft anders als bei WordPress?

Am 9. Dezember 2026 endet der Sicherheitssupport für Drupal 10. Von heute aus gerechnet sind das 69 Tage.

Das ist kein Richtwert und keine Einschätzung. Es ist ein Datum im Release-Kalender von drupal.org. Ab diesem Tag erscheinen für Drupal 10 keine Sicherheitsupdates mehr. In derselben Woche, der Woche vom 7. Dezember, kommt Drupal 12 heraus.

Und damit ist der Unterschied schon benannt, um den es hier geht. Bei WordPress ist Wartung ein Dauertakt: Es kommt, was kommt, und es wird eingespielt. Bei Drupal läuft derselbe Dauertakt, und zusätzlich steht ein Termin im Kalender, an dem eine ganze Hauptversion aus der Unterstützung fällt. Dieser Termin steht Jahre vorher fest. Das ist der Vorteil. Und es ist der Grund, warum Drupal-Wartung schiefgeht, wenn man sie rein als Monatsaufgabe begreift.

Der Stichtag ist das eigentliche Thema

Drupal arbeitet mit festen Hauptversionen und einem veröffentlichten Lebenszyklus. Jede Hauptversion hat ein Enddatum, und dieses Datum wird eingehalten. Drupal 10 ist am 9. Dezember 2026 fertig.

Fertig heißt: Die Software läuft weiter. Sie läuft am 10. Dezember genauso wie am 8. Nur erscheint ab dann kein Sicherheitsupdate mehr, egal was gefunden wird. Eine Lücke im Kern wird für Drupal 11 und 12 geschlossen und für Drupal 10 nicht. Der Fehler sitzt dann auf Ihrer Seite und bleibt dort.

Bei WordPress gibt es diesen Punkt in dieser Form nicht. Dort gibt es eine Hauptversion, die weiterläuft, und Sicherheitsupdates, die nachgezogen werden. Das klingt angenehmer und ist in der Wartung teilweise auch bequemer. Es hat aber eine Kehrseite: Es gibt keinen Termin, der Ihnen von außen sagt, dass jetzt etwas zu tun ist. Bei Drupal sagt es Ihnen der Kalender.

Was im Dezember nicht mehr geht

Die naheliegende Reaktion auf ein Enddatum ist, sich den Termin vorzumerken und kurz davor zu handeln. Bei einem Versionswechsel funktioniert das nicht, und zwar aus einem Grund, der nichts mit Drupal zu tun hat, sondern mit den Erweiterungen.

Eine Drupal-Installation besteht nicht nur aus dem Kern. Darauf liegen Module, ein Theme, oft eigene Entwicklung. Jedes dieser Teile muss für die neue Hauptversion freigegeben sein. Ist ein Modul nicht portiert, lässt sich der Wechsel nicht durchführen, auch wenn der Kern längst bereitsteht. Dann haben Sie drei Möglichkeiten: warten, bis jemand das Modul portiert, es selbst portieren, oder die Funktion anders bauen.

Alle drei brauchen Zeit, und keine davon ist im Dezember verfügbar. Deshalb ist die Arbeit, die jetzt ansteht, nicht der Wechsel selbst. Es ist die Bestandsaufnahme: Was liegt auf dieser Installation, und was davon ist für die nächste Hauptversion bereit? Diese Frage lässt sich in überschaubarer Zeit beantworten. Sie muss nur vorher gestellt werden.

Das Sicherheitsfenster steht im Kalender

Der zweite Unterschied ist weniger dramatisch und im Alltag wichtiger. Drupal veröffentlicht Sicherheitsreleases in angekündigten Fenstern. Auf drupal.org steht dazu wörtlich, die Fenster lägen „usually on the third Wednesday of the month". Aktuell gilt das Fenster für Drupal 11.4.x, 11.3.x und 10.6.x.

Zwei Dinge sind daran brauchbar. Erstens: Sie wissen vorher, wann etwas kommen kann. Ein Mittwoch im Monat ist planbar, ein beliebiger Dienstagabend nicht. Zweitens, und das ist die eigentliche Information in dieser Zeile: Es werden mehrere Minor-Versionen gleichzeitig versorgt, nicht nur die neueste. Sie müssen also nicht jede Zwischenversion sofort mitgehen, um im sicheren Bereich zu bleiben. Sie müssen nur innerhalb der versorgten Spanne bleiben.

Das ist ein anderer Rhythmus als bei WordPress, wo Sicherheitsreleases dann erscheinen, wenn sie fertig sind. Was im WordPress-Monat tatsächlich anfällt, haben wir an anderer Stelle durchgerechnet: WordPress-Wartung: was monatlich tatsächlich zu tun ist. Der Vergleich lohnt, weil er zeigt, dass es nicht um mehr oder weniger Aufwand geht, sondern um eine andere Verteilung.

Updates laufen nicht über einen Klick im Backend

Bei WordPress können Sie sich im Backend anmelden, auf „Aktualisieren" klicken, und die Sache ist erledigt. Bei Drupal ist das in der Regel nicht der Weg. Module und Kern werden über Composer verwaltet, also über eine Abhängigkeitsdatei im Projekt. Ein Update ist dort ein Vorgang, der auf einer Arbeitskopie läuft und anschließend ausgeliefert wird.

Das klingt nach Umstand und ist in der Wartung ein Vorteil, weil nichts ungeprüft auf der Live-Seite landet. Es hat aber eine Konsequenz, die man vorher wissen sollte: Für Drupal-Wartung braucht es eine funktionierende Umgebung neben der Live-Seite und Zugriff auf das Projekt, nicht nur auf das Backend. Wer eine Drupal-Seite betreut, braucht die Composer-Datei und den Zugang zum Repository. Ohne beides lässt sich die Seite nicht sauber warten.

Das ist übrigens die häufigste Lücke, die wir bei übernommenen Drupal-Projekten finden. Nicht veraltete Module. Sondern eine Installation, bei der niemand mehr sagen kann, wo die Abhängigkeitsdatei liegt und wer sie zuletzt angefasst hat. Warum wir trotz dieses Mehraufwands mit Drupal arbeiten, steht in Warum wir bei WOAR auf Drupal setzen.

Der Wechsel von 10 auf 11 ist kein Neubau — aber auch keine Wartung

Eine gute Nachricht zuerst. Der Sprung von Drupal 10 auf 11 ist nicht der Bruch, den viele noch von Drupal 7 auf 8 erinnern. Damals war ein Versionswechsel faktisch ein Neuaufbau. Seit Drupal 8 ist der Weg schrittweise: veraltete Schnittstellen werden angekündigt, in der nächsten Hauptversion entfernt, und was dazwischen angepasst wurde, läuft weiter. Inhalte, Struktur und Konfiguration bleiben.

Trotzdem gehört dieser Wechsel nicht in einen Wartungsvertrag, und wir verkaufen ihn auch nicht so. Auf unserer Seite zur Website-Wartung und Betreuung steht ausdrücklich, dass Relaunches keine Wartung sind. Ein Hauptversionswechsel ist näher am Relaunch als am Monatsupdate: Er braucht eine Prüfung, einen Testlauf und ein Zeitfenster, in dem jemand verfügbar ist, falls etwas klemmt.

Was die Wartung leistet, ist etwas anderes, und es ist das Wertvollere: Sie hält die Installation in dem Zustand, in dem dieser Wechsel ein planbares Projekt bleibt und keine Rettungsaktion wird. Eine Drupal-Seite, die zwei Jahre lang keine Zwischenversion mitgegangen ist, kostet beim Sprung ein Mehrfaches. Nicht wegen des Kerns, sondern wegen der angesammelten Modulrückstände.

Was das für einen Wartungsvertrag bedeutet

Konkret heißt das, dass bei einer Drupal-Seite zwei Dinge im Vertrag stehen müssen, die bei WordPress nicht zwingend nötig sind.

Erstens: Wer beobachtet den Versionsstand? Nicht „wird aktualisiert", sondern: Jemand sieht nach, in welcher Hauptversion die Seite läuft und wie lange die noch versorgt wird. Das ist eine Aufgabe, die zweimal im Jahr fünf Minuten dauert und einmal im Lebenszyklus entscheidend ist.

Zweitens: Wer meldet, wenn der Versionswechsel ansteht, und mit welchem Vorlauf? Ein Enddatum, das drei Wochen vorher gemeldet wird, ist keine Meldung. Es ist eine Mitteilung.

Unsere Betreuung ist in drei Stufen aufgeteilt: Basis 79 € · Plus 189 € · Pro 389 € im Monat, netto. Was in welcher Stufe enthalten ist, steht auf der Seite zur Website-Wartung. Welche Punkte unabhängig von uns in jedem Wartungsvertrag stehen sollten, haben wir hier aufgeschrieben: Was muss in einem Wartungsvertrag für die Website stehen?

Vier Dinge, die Sie selbst nachsehen können

Dafür brauchen Sie niemanden. Melden Sie sich in Ihrem Drupal-Backend an und gehen Sie der Reihe nach vor.

Welche Hauptversion läuft? Unter Berichte → Statusbericht steht die Drupal-Version oben. Beginnt sie mit einer 10, betrifft Sie der 9. Dezember 2026.

Wie viele Module meldet derselbe Bericht als veraltet? Die Zahl selbst ist weniger wichtig als die Frage, seit wann sie dort steht. Ein Rückstand von zwei Wochen ist normal. Einer von zwei Jahren ist eine Entscheidung, die irgendwann jemand getroffen hat, ohne sie zu treffen.

Wer hat Zugriff auf die Composer-Datei? Wenn Sie diese Frage nicht in einem Satz beantworten können, ist das der wichtigste der vier Punkte. Nicht wegen der Wartung. Wegen des Falls, dass Sie den Dienstleister wechseln wollen.

Gibt es eine Testumgebung? Wenn Updates direkt auf der Live-Seite eingespielt werden, funktioniert das meistens. Der Satz „funktioniert meistens" ist bei einer Seite, über die Anfragen kommen, allerdings die ungemütlichere Variante.

Wenn Sie bei einem der vier Punkte hängen bleiben, können wir uns das ansehen. Eine Bestandsaufnahme Ihrer Drupal-Installation ist überschaubar: Versionsstand, Modulliste, Portierungsstand für die nächste Hauptversion, dazu eine Aufwandsangabe für den Wechsel. Schreiben Sie, was bei Ihnen läuft, dann sagen wir Ihnen, ob der 9. Dezember für Sie ein Termin ist oder nicht.

69 Tage sind kein Grund zur Eile. Für die Bestandsaufnahme reichen sie bequem. Für die Bestandsaufnahme plus Portierung eines Moduls, das niemand gepflegt hat, reichen sie knapp.