Drupal 10 endet am 9. Dezember: rechtzeitig auf Drupal 11

Am 9. Dezember 2026 erreicht Drupal 10 sein Lebensende: Nach diesem Datum erscheinen keine neuen Versionen von Drupal 10 mehr, auch keine Sicherheitsversionen (Drupal.org). Betroffen ist ein großer Teil des Bestands, denn 43,2 Prozent der an Drupal.org meldenden Installationen ab Drupal 8 liefen in der Woche ab dem 4. Oktober 2026 noch auf Drupal 10 (Drupal.org). Der Weg führt über Drupal 11, denn eine Hauptversion lässt sich beim Upgrade nicht überspringen (Drupal.org). Dieser Leitfaden zeigt, welche Plattform Drupal 11 verlangt, wie Module und eigener Code geprüft werden und wie das Upgrade bis Dezember in einen realistischen Zeitplan passt. Wer das nicht selbst übernehmen möchte, findet die Umsetzung bei unserer Drupal-Agentur.

Was am 9. Dezember 2026 endet

Drupal 10.0.0 erschien am 15. Dezember 2022 (Drupal.org). Knapp vier Jahre später, am 9. Dezember 2026, ist Schluss: Laut Release-Plan der Release-Manager des Drupal-Kerns erreicht Drupal 10 an diesem Tag sein Lebensende, danach werden keine neuen Versionen von Drupal 10 mehr veröffentlicht (Drupal.org). In derselben Woche erscheint Drupal 12 (Drupal.org).

Die letzte Nebenversion ist Drupal 10.6.0 (Drupal.org). Sicherheitsversionen erscheinen bei Drupal in festen Fenstern, in der Regel am dritten Mittwoch eines Monats (Drupal.org). Derzeit gelten diese Fenster für Drupal 11.4.x, 11.3.x und 10.6.x (Drupal.org). Nach dieser Regel fällt das letzte reguläre Sicherheitsfenster vor dem Lebensende auf den 18. November 2026. In seltenen Fällen kann eine Sicherheitsversion auch außerhalb der Fenster erscheinen; sie wird dann vorher öffentlich angekündigt (Drupal.org).

Drupal 10 erreicht sein Lebensende am 9. Dezember 2026. Das ist dieselbe Woche, in der Drupal 12 veröffentlicht wird. Nach diesem Datum werden keine neuen Versionen von Drupal 10 mehr veröffentlicht.

Drupal.org, Release-Plan „Drupal core release schedule“ (eigene Übersetzung)

Im Dezember laufen mehrere Termine zusammen, wie die Übersicht der Zweige zeigt.

Was das Lebensende praktisch bedeutet, regelt die Richtlinie des Drupal-Sicherheitsteams: Sicherheitsmeldungen gibt es nur für stabile Versionen in den unterstützten Hauptversionen (Drupal.org). Unterstützt heißt dabei zweierlei, nämlich unterstützt vom Drupal-Kern und vom jeweiligen Projektverantwortlichen (Drupal.org). Nach dem 9. Dezember fällt Drupal 10 aus diesem Kreis heraus, für den Kern ebenso wie für die beigesteuerten Module, die darauf laufen.

Wie viele Websites noch auf Drupal 10 laufen

Wie groß der Bestand ist, zeigt die Nutzungsstatistik auf Drupal.org. Sie zählt je Woche die Installationen, die melden, welche Version sie verwenden (Drupal.org). In der Woche ab dem 4. Oktober 2026 waren das 531.499 Installationen ab Drupal 8. Davon liefen 229.721 auf Drupal 10, also 43,2 Prozent (Drupal.org). Auf Drupal 11 waren es 208.459 Installationen oder 39,2 Prozent (Drupal.org).

Innerhalb von Drupal 10 verteilt sich der Bestand ungleich. 170.190 Installationen meldeten Drupal 10.6, das sind 74,1 Prozent der Drupal-10-Installationen (Drupal.org). Die übrigen 59.531 Installationen oder 25,9 Prozent liefen auf 10.0 bis 10.5 (Drupal.org), also auf Nebenversionen, für die der Release-Plan schon heute kein Sicherheitsfenster mehr vorsieht (Drupal.org). Für diese Websites ist der erste Schritt überfällig. Dazu kommen 17,4 Prozent der meldenden Installationen auf Drupal 8 oder 9 (Drupal.org), deren Lebensende am 17. November 2021 und am 1. November 2023 lag (Drupal.org).

Warum der Weg nur über Drupal 11 führt

Drupal lässt beim Upgrade keine Hauptversion aus (Drupal.org). Der Grund liegt in der Technik: Mitgeführt werden nur die Aktualisierungen zwischen aufeinanderfolgenden Hauptversionen, ältere werden entfernt (Drupal.org). Das betrifft Konfiguration, Datenbankschema und Felder. Eine Website auf Drupal 10 kann deshalb im Dezember nicht direkt auf Drupal 12 gehen, auch wenn beide Termine in dieselbe Woche fallen.

Für den ersten Schritt verlangt Drupal 11 mindestens Drupal 10.3.0 als Ausgangsstand, denn alle Kernaktualisierungen vor 10.3.0 sind in Drupal 11 entfernt (Drupal.org). Für den zweiten Schritt gilt dasselbe Prinzip eine Stufe höher: Vor dem Upgrade auf Drupal 12 muss eine Website mindestens auf Drupal 11.3.0 stehen (Drupal.org). Der Pfad führt also von 10.6 auf 11.4 und später auf 12. Wer heute noch eine ältere Nebenversion von Drupal 10 betreibt, hebt sie zuerst auf den aktuellen 10.6-Stand.

Drupal 11 ist dabei kein kurzer Zwischenhalt. Hauptversionen erscheinen alle zwei Jahre (Drupal.org), und jede wird so lange unterstützt, bis zwei weitere Hauptversionen erschienen sind (Drupal.org). Mit dem Erscheinen von Drupal 12 erhält Drupal 11 eine Wartungs-Nebenversion mit derselben Schnittstelle und tritt in eine Phase langfristiger Unterstützung ein (Drupal.org). Ein festes Enddatum für Drupal 11 nennt der Release-Plan bislang nicht.

Die Plattform zuerst: PHP und Datenbank

Drupal 10 verlangt mindestens PHP 8.1 (Drupal.org), Drupal 11 setzt PHP 8.3 oder neuer voraus (Drupal.org). Eine Drupal-10-Website auf PHP 8.1 oder 8.2 muss deshalb vor dem Upgrade die PHP-Version wechseln. Die Tabelle zeigt, welche PHP-Versionen Drupal laut Drupal.org je Version unterstützt und wie lange das PHP-Projekt sie mit Sicherheitskorrekturen versorgt.

Daraus ergibt sich eine sinnvolle Reihenfolge: PHP 8.3 und 8.4 laufen sowohl mit Drupal 10.6 als auch mit Drupal 11.3 und 11.4 (Drupal.org). Wer die PHP-Version noch unter Drupal 10 umstellt, trennt zwei Änderungen voneinander. Das Sicherheitsfenster einer Drupal-Nebenversion gilt, solange eine unterstützte PHP-Version verwendet wird (Drupal.org). Lassen Abhängigkeiten eine ältere PHP-Version fallen, kann Drupal die Sicherheitsversorgung für diese Installationen nicht mehr zusichern (Drupal.org). PHP 8.1 ist seit dem 31. Dezember 2025 ohne Sicherheitskorrekturen, PHP 8.2 folgt am 31. Dezember 2026 (php.net). Die Prüfschritte für einen solchen Wechsel beschreibt unser Beitrag zum Supportende von PHP 8.2 am Beispiel WordPress.

Auch der Datenbankserver muss passen: Drupal 11 verlangt MariaDB ab 10.6, MySQL ab 8.0, PostgreSQL ab 16 oder SQLite ab 3.45, Drupal 12 hebt MariaDB und PostgreSQL noch einmal an (Drupal.org). Wer MySQL einsetzt, prüft den Datenbankserver gleich mit, siehe unseren Beitrag zu MySQL 8.0 am Support-Ende.

Module, Themes und eigener Code

Drupal 11 hat mehrere Kernmodule entfernt, die in Drupal 10 bereits als veraltet markiert waren: Actions UI, Activity Tracker, Book, Forum, Statistics und Tour (Drupal.org). Wer eines davon nutzt, hat zwei Wege: das Modul vor dem Upgrade nicht mehr verwenden oder es noch unter Drupal 10.3 oder neuer durch die gleichnamige Version aus den beigesteuerten Modulen ersetzen (Drupal.org). Bei den Themes steht der nächste Wechsel schon fest: Das Verwaltungstheme Claro ist ab Drupal 11.5.0 veraltet und fällt mit Drupal 12.0.0 aus dem Kern (Drupal.org), ebenso das Frontend-Theme Olivero (Drupal.org). Wer im Zuge des Upgrades das Theme wechselt, prüft dabei auch die Barrierefreiheit; dazu mehr unter BFSG-Optimierung.

Für beigesteuerte Module und eigenen Code nennt die Dokumentation zwei Werkzeuge aus dem Drupal-Projekt: Upgrade Status zeigt, wo die Kompatibilität mit Drupal 11 fehlt, und Drupal Rector ersetzt Code, der in Drupal 10 als veraltet markiert ist (Drupal.org). Beide sind quelloffen und gehören in die Testumgebung, nicht auf die Live-Website. Die Dokumentation rät, Versionen für Drupal 11 auch von Hand zu prüfen, weil der Bericht nicht jede kompatible Version erkennt (Drupal.org).

• Kernversion und PHP-Version der Website notieren
• Aktive Module und Themes auflisten, getrennt nach Kern, beigesteuert und eigenentwickelt
• Je beigesteuertem Modul prüfen, ob eine Version für Drupal 11 vorliegt
• Entfernte Kernmodule wie Book, Forum oder Statistics im Bestand suchen
• Angepasste Scaffold-Dateien wie .htaccess dokumentieren, denn beim Upgrade ändern sich alle Kerndateien (Drupal.org)
• Zugang zur Kommandozeile mit Composer und Drush klären (Drupal.org)
• PHP-Version und Datenbankserver mit den Anforderungen von Drupal 11 abgleichen

Für die Bestandsaufnahme reichen wenige Befehle auf der Kommandozeile der Testumgebung. Der letzte zeigt, welche Pakete einem Upgrade auf Drupal 11 noch im Weg stehen.

Wenn ein Modul noch nicht bereit ist

• Im Issue-Bereich des Moduls nach einem Patch für Drupal 11 suchen (Drupal.org)
• Module, die nur mit Patch laufen, über den Lenient-Endpunkt von Drupal einbinden (Drupal.org)
• In der composer.json zwei Hauptversionen eines Moduls zulassen, etwa ^6.1 || ^7.0, um die Übergangszeit zu überbrücken (Drupal.org)
• Mit den Projektverantwortlichen des Moduls zusammenarbeiten und die Anpassung beisteuern
• Ein selten genutztes Modul ersetzen oder entfernen, statt das Upgrade daran scheitern zu lassen
• Fachlich wichtige Funktionen als eigenes Modul umsetzen, etwa über unsere individuelle Programmierung

Das Upgrade in fünf Schritten

Die Dokumentation auf Drupal.org beschreibt das Upgrade für Installationen, die mit Composer verwaltet werden, und empfiehlt, es zuerst lokal durchzuführen und erst danach auf den Server zu bringen (Drupal.org). Wir gehen in dieser Reihenfolge vor, jeder Schritt zuerst in der Testumgebung:

1. Drupal 10 aktualisieren: Kern auf die aktuelle 10.6-Version, beigesteuerte Module auf ihren neuesten Stand.
2. PHP und Datenbank anheben: PHP 8.3 oder 8.4, Datenbankserver nach den Anforderungen von Drupal 11.
3. Entfernte Module ersetzen und Code anpassen: Bericht von Upgrade Status abarbeiten, Drupal Rector für eigene Module und Themes nutzen.
4. Kern per Composer anheben: Kernpakete auf Drupal 11 setzen, Probelauf, dann Aktualisierung und Datenbankaktualisierungen (Drupal.org).
5. Prüfen und ausrollen: Dateirechte, Protokolle, Cron und Tests, danach Übernahme auf die Live-Website (Drupal.org).

# Schreibrechte für die Einstellungsdateien öffnen
chmod u+w web/sites/default
chmod u+w web/sites/default/*settings.php
chmod u+w web/sites/default/*services.yml

# Kernpakete auf Drupal 11 setzen, noch ohne Aktualisierung
composer require 'drupal/core-recommended:^11' \
  'drupal/core-composer-scaffold:^11' \
  'drupal/core-project-message:^11' --no-update
composer require drush/drush --no-update

# Seit Drupal 11.4 ist symfony/runtime ein Composer-Plugin
composer config allow-plugins.symfony/runtime true

# Probelauf, dann Aktualisierung
composer update --dry-run
composer update

# Datenbankaktualisierungen ausführen
drush updatedb:status
drush updatedb

# Rechte zurücksetzen
chmod 755 web/sites/default
chmod 644 web/sites/default/*settings.php
chmod 644 web/sites/default/*services.yml

Findet Composer keine Lösung für die Abhängigkeiten, hilft laut Dokumentation eine engere Vorgabe wie ^11.4 statt ^11 (Drupal.org). Seit Drupal 11.4 bringt der Kern außerdem symfony/runtime als Composer-Plugin mit, das ausdrücklich zugelassen werden muss (Drupal.org); sonst stockt die Aktualisierung an einer Rückfrage.

Was nach dem Upgrade geprüft wird

• Dateirechte der Einstellungsdateien zurücksetzen und prüfen (Drupal.org)
• Protokolle beim Durchklicken verfolgen, etwa mit drush watchdog:tail (Drupal.org)
• Cron einmal von Hand ausführen (Drupal.org)
• Vorhandene automatisierte Tests laufen lassen (Drupal.org)
• Formulare, Suche, Redaktionsoberfläche und Sprachversionen von Hand testen
• Caches leeren und die Ladezeiten der wichtigsten Seiten mit dem Stand vor dem Upgrade vergleichen

Zeitplan bis zum 9. Dezember

Dieser Beitrag erscheint am 30. Oktober 2026. Bis zum Lebensende von Drupal 10 bleiben damit 40 Tage. Für eine Website mit überschaubarer Zahl an Modulen reicht das in der Regel, wenn die Bestandsaufnahme jetzt beginnt. Wichtig ist, die Termine des Release-Plans mitzudenken:

1. Bis Mitte November: Bestandsaufnahme, PHP-Wechsel auf 8.3 oder 8.4 und Modulprüfung in der Testumgebung.
2. 18. November 2026: nach der Regel des Release-Plans das letzte reguläre Sicherheitsfenster vor dem Lebensende (Drupal.org). Erscheint dort eine Sicherheitsversion für 10.6, wird sie noch eingespielt.
3. Bis Ende November: Upgrade auf Drupal 11.4 in der Testumgebung abschließen, Abnahme durch die Redaktion, Termin für die Umstellung festlegen.
4. Anfang Dezember: Umstellung der Live-Website, möglichst vor der Woche ab dem 7. Dezember, in der Drupal 12.0 und 11.5 erscheinen (Drupal.org).
5. Danach: Drupal 11.5 im üblichen Wartungsrhythmus einplanen. Jede Nebenversion wird ein Jahr lang unterstützt, sechs Monate mit Fehler- und Sicherheitskorrekturen, sechs weitere nur mit Sicherheitskorrekturen (Drupal.org).

Der Puffer vor der Woche ab dem 7. Dezember hat einen weiteren Grund: In einer Woche, in der eine neue Haupt- oder Nebenversion des Kerns erscheint, gibt es keine Sicherheitsversionen für beigesteuerte Projekte (Drupal.org). Wer zusätzlich einen Shop betreibt, hat zum Jahreswechsel weitere Termine, etwa bei der E-Rechnung, siehe ZUGFeRD direkt aus Shopware.

Und wenn es knapp wird? Eine Website, die den Termin nicht hält, läuft am 10. Dezember weiter, aber ohne neue Versionen von Drupal 10 (Drupal.org). Dann gilt es, die Angriffsfläche zu verkleinern: nicht genutzte Module deinstallieren, Zugänge zur Verwaltung beschränken, Protokolle beobachten und den Termin für das Upgrade verbindlich in den Januar legen. Ein Dauerzustand sollte das nicht werden.

Upgrade oder Systemwechsel?

Das Lebensende ist für manche Betreiber der Anlass, das System grundsätzlich zu hinterfragen. In der Regel ist das Upgrade innerhalb von Drupal der kürzere Weg: Inhaltsmodell, Adressen und Berechtigungen bleiben erhalten, geändert wird die technische Basis. Ein Wechsel auf ein anderes CMS ist dagegen ein Migrationsprojekt mit Inhaltsaudit, Adresszuordnung und Weiterleitungen, wie wir es im Beitrag zur CMS-Migration beschreiben. Bis zum 9. Dezember ist ein solcher Wechsel bei einer größeren Website kaum zu schaffen. Sinnvoll ist dann, zuerst auf Drupal 11 zu gehen und die Systemfrage danach ohne Zeitdruck zu klären.

Vergleichbare Schritte bei anderen Systemen beschreiben die Beiträge zum Upgrade auf TYPO3 14 LTS und zum Supportende von Magento 2.4.7. Einen Überblick gibt unsere Seite zu CMS-Lösungen.

So begleiten wir das Upgrade auf Drupal 11

Als Drupal-Agentur übernehmen wir das Upgrade von der Bestandsaufnahme bis zum Betrieb danach. Aus der Bestandsaufnahme entsteht ein Plan mit Aufwand, Reihenfolge und Termin.

Wenn Sie vorab klären möchten, ob Upgrade oder Neuaufbau besser zu Ihrer Website passt, beginnt das mit einer Beratung. Für das Upgrade selbst gilt: Je früher die Bestandsaufnahme steht, desto mehr Puffer bleibt bis zum 9. Dezember.