Drupal 10 endet im Dezember 2026 — und der Weg hat eine Bedingung.

Der Stand.

Stand der Recherche: Oktober 2026. Drupal arbeitet mit einem planbaren Rhythmus: Hauptversionen in festen Abständen, dazwischen Nebenversionen, und jede Hauptversion wird bis zum Erscheinen der übernächsten gepflegt.

Das Besondere an diesem Übergang ist, dass Drupal 12 und das Ende von Drupal 10 praktisch zusammenfallen — es gibt also keine Schonfrist, in der man gemütlich auf 11 wechselt, während 10 noch versorgt wird.

Die Bedingung über 11.3.

Der Punkt, der die Planung bestimmt und am häufigsten übersehen wird: Drupal 12 lässt sich nur von Drupal 11.3 oder einer höheren Fassung aus aktualisieren. Frühere Aufstiegspfade wurden entfernt.

Praktisch heißt das: Wer heute auf Drupal 10 steht, kann nicht direkt auf 12 springen. Der Weg führt über Drupal 11, und dort muss mindestens 11.3 erreicht werden, bevor der nächste Schritt möglich ist.

Das ist kein Beinbruch, verändert aber den Zeitplan: Es sind zwei Vorgänge statt einem, und zwischen ihnen sollte Zeit für Prüfung liegen. Wer das erst im November merkt, hat ein Problem (Update auf Drupal 11).

Was das Ende bedeutet.

• Keine Sicherheitsupdates mehr vom Sicherheitsteam — weder für den Kern noch für Module in dieser Fassung.
• Veröffentlichte Lücken bleiben offen. Drupals Sicherheitsmeldungen sind öffentlich und detailliert.
• Module ziehen nach. Hersteller stellen die Pflege für alte Hauptversionen ein.
• Nachweisfrage bei personenbezogenen Daten.
• Bei öffentlichen Stellen kommt die Frage nach dem Stand der Technik dazu — Drupal ist dort verbreitet.

Ein Hinweis zur Einordnung: Drupal hat traditionell ein sehr aktives Sicherheitsteam und veröffentlicht Lücken geordnet und nachvollziehbar. Das ist im Betrieb ein Vorteil — und nach dem Ende der Pflege ein Nachteil, weil die Information öffentlich ist und die Lücke offen bleibt.

Die PHP-Frage.

Die Anforderungen steigen mit jeder Hauptversion spürbar: Drupal 10 verlangt mindestens PHP 8.1, Drupal 11 mindestens 8.3, Drupal 12 mindestens 8.5.

Das ist für die Planung wichtiger als bei anderen Systemen, weil der Sprung über zwei Hauptversionen auch zwei PHP-Anhebungen bedeutet. Prüf früh, welche Fassungen dein Hosting anbietet — und ob die höchste nötige überhaupt schon verfügbar ist (Hosting-Anforderungen, PHP aktualisieren).

Nebenwirkung: Eigener Code und ältere Module laufen unter neuem PHP nicht unverändert. Das ist meist der größere Teil der Arbeit, nicht der Drupal-Sprung selbst.

Eigene Version prüfen.

1. Im Backend steht die Fassung im Statusbericht — dort auch Warnungen zu veralteten Modulen.
2. Über die Kommandozeile lässt sie sich zuverlässig abfragen.
3. Statusbericht vollständig lesen — er ist bei Drupal ungewöhnlich aussagekräftig.
4. Modulliste ziehen samt Versionen und Pflegestand.
5. PHP-Version prüfen.
6. Eigene Module und Themes identifizieren.

Punkt drei lohnt besonders: Drupals Statusbericht meldet veraltete Module, fehlende Aktualisierungen, Konfigurationsprobleme und Sicherheitshinweise an einer Stelle. Das ist eine Qualität, die andere Systeme nicht in dieser Form haben — und sie wird selten genutzt.

Die Wege.

Zeile vier ist ein eigener Fall: Von Drupal 7 aus gibt es keinen Aktualisierungspfad, sondern ein Migrationsverfahren, bei dem Inhalte in eine neue Installation überführt werden (Von Drupal 7 migrieren).

Ein realistischer Zeitplan.

Wer heute auf Drupal 10 steht und die Frist einhalten will:

1. Jetzt: Bestandsaufnahme. Statusbericht, Modulliste, eigener Code, PHP.
2. Dann: Module klären. Was gibt es für Drupal 11, was nicht?
3. Dann: Testumgebung aufsetzen und PHP anheben.
4. Dann: Sprung auf Drupal 11, prüfen, live nehmen.
5. Dann: Auf 11.3 oder höher innerhalb der 11er-Reihe.
6. Später: Auf Drupal 12, wenn die Module so weit sind.

Schritt vier ist das eigentliche Ziel für dieses Jahr. Drupal 11 ist aktuell gepflegt, und wer dort steht, hat die Frist eingehalten — der Schritt auf 12 kann in Ruhe folgen.

Wichtig: Nicht beide Sprünge in eine Woche legen. Zwischen 11 und 11.3 sollte das System im Betrieb gelaufen sein.

Module entscheiden.

Der Kern springt zuverlässig — Drupal ist in dieser Hinsicht berechenbar. Über Aufwand und Machbarkeit entscheiden die beigesteuerten Module:

• Gepflegt, Fassung für Drupal 11 vorhanden — unproblematisch.
• Fassung in Arbeit — Zeitpunkt klären, eventuell warten.
• Eingestellt — Ersatz suchen, Funktion streichen oder selbst übernehmen.
• Inzwischen im Kern — Drupal übernimmt regelmäßig verbreitete Module, dann wird das Modul überflüssig.
• Eigene Module — anpassen, Schnittstellen prüfen.

Der vierte Punkt ist bei Drupal häufiger als anderswo und eine angenehme Überraschung: Funktionen, für die früher ein Modul nötig war, sind inzwischen Teil des Kerns. Vor der Suche nach Ersatz lohnt der Blick, ob Drupal es selbst kann (Module).

Für die Prüfung gibt es Werkzeuge, die eine Installation auf Verträglichkeit mit der nächsten Hauptversion analysieren und veraltete Programmierschnittstellen im eigenen Code finden. Die zu nutzen spart erheblich Zeit.

Was es bedeutet.

Ich nenne keine Pauschale, weil die Spanne groß ist. Was den Aufwand treibt: viele beigesteuerte Module, davon eingestellte; eigener Code mit veralteten Schnittstellen; ein individuell gebautes Theme; eine mehrsprachige Installation; angebundene Fremdsysteme.

Was ihn senkt: wenige, gepflegte Module; ein Theme nahe am Standard; sauber als eigenes Modul umgesetzte Anpassungen statt Eingriffen im Kern; ein Hoster mit umschaltbarem PHP.

Ein Drupal-spezifischer Vorteil: Weil das System konsequent auf Konfiguration setzt, die sich exportieren und versionieren lässt, sind Vorgänge besser reproduzierbar als bei vielen anderen Systemen. Wer das nutzt, hat deutlich weniger Reibung.

Wenn die Frist verstreicht.

Die Website läuft weiter — es verschwindet nichts. Was wegfällt, sind Sicherheitsupdates vom Projekt.

Für diesen Fall gibt es im Drupal-Umfeld kommerzielle Anbieter, die eine verlängerte Versorgung für ausgelaufene Fassungen anbieten. Das ist eine ernsthafte Option für große Installationen, bei denen ein Sprung nicht rechtzeitig machbar ist — und es ist eine Brücke, keine Lösung.

Unabhängig davon gilt: befristet absichern. Zugriff auf den Verwaltungsbereich beschränken, nicht genutzte Module entfernen, Sicherungen prüfen, Sicherheitsmeldungen verfolgen und bei kritischen Funden sofort handeln — und einen festen Termin für den Sprung setzen (Sicherheit).

Wann ablösen.

Gegen einen Versionssprung spricht, wenn die Installation über Jahre gegen das Drupal-Modell gebaut wurde, wenn ein erheblicher Teil der Module eingestellt ist, wenn das Design ohnehin erneuert werden soll oder wenn im Haus niemand mehr mit Drupal arbeiten mag.

Dagegen spricht ein gewichtiges Argument für den Verbleib: Drupal kann Dinge, die andere Systeme nur mit erheblichem Aufwand nachbauen — differenzierte Rechte, komplexe Inhaltsmodelle, Mehrsprachigkeit, Workflows mit Freigaben. Wer das nutzt, verliert beim Wechsel mehr, als die Rechnung zunächst zeigt.

Ich sage dir ehrlich, welcher Weg bei dir trägt — und bei Drupal ist meine Antwort häufiger „bleiben und aktualisieren“ als bei anderen Systemen (Wechsel zu WordPress, Relaunch).

Wenn du nicht weiterkommst.

Wenn du auf Drupal 10 sitzt und wissen musst, was bis Dezember machbar ist. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Bei einem laufenden Ausfall hilft der Notfall-Support, dauerhaft begleitet die Drupal-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management-Systeme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme nicht nur aus der Anwendung, sondern von innen: Datenmodell, Rechtekonzept, Templating, Modularchitektur, Caching, Betrieb.

Bei Drupal zahlt sich das besonders aus, weil das System konsequenter durchkonstruiert ist als die meisten anderen: Alles ist Entität, alles hat Felder, alles läuft über definierte Schnittstellen. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo eine Installation gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob deine Installation weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.