Drupal 12: Was Sich Ändert Und Wann Sie Wechseln

Drupal 12 ist für die Woche vom 7. Dezember 2026 geplant, und Drupal 10 erreicht am 9. Dezember 2026 sein End of Life. Beide Daten stehen auf derselben Seite des Drupal-Core-Release-Zeitplans, zwei Zeilen auseinander, und die meisten Betreiber einer Drupal-10-Website haben keines von beiden bemerkt. Die erste Alpha des neuen Majors wurde am 2. September 2026 getaggt, die Form des Releases ist also inzwischen aktenkundig statt spekulativ.

Diese Kollision ist die ganze Geschichte. Ein neuer Major ist für Websitebetreiber normalerweise nicht dringend, weil man ein oder zwei Jahre auf dem vorherigen Major sitzen bleiben kann, während das Ökosystem nachzieht. Diesmal verliert der vorherige Major in derselben Woche seine Sicherheitshinweise, in der der neue erscheint, und das macht aus einem technischen Ereignis eine Frist mit Compliance-Kante.

Es folgt der Kalender, wie drupal.org ihn veröffentlicht, was sich im Code tatsächlich ändert, was die neuen Plattform-Untergrenzen für Ihr Hosting bedeuten, die drei realistischen Upgrade-Wege mit Kostenbändern und ein Plan, rückwärts gerechnet vom Dezember. Der beruhigende Teil kommt früh: Ein Drupal-Major-Sprung besteht überwiegend aus Löschen, nicht aus Neuerfindung.

Wann erscheint Drupal 12, und muss ich wechseln? Drupal 12.0.0 ist für die Woche vom 7. Dezember 2026 geplant und erscheint zusammen mit Drupal 11.5.0. Drupal 10 erreicht zwei Tage später, am 9. Dezember 2026, sein End of Life, danach werden keine Sicherheitshinweise mehr dafür veröffentlicht. Eine Drupal-11-Website steht vor einem kleinen Upgrade. Eine Drupal-10-Website muss zuerst über Drupal 11.4 oder neuer, die Arbeit besteht also aus zwei Sprüngen statt einem.

Die beiden Daten, die Ihre nächsten sechs Monate bestimmen

Die Release-Manager veröffentlichen den gesamten Zyklus im Voraus, und der aktuelle ist ungewöhnlich aufgeräumt. Drupal 11.4.0 kam in der Woche vom 29. Juni 2026, und dieses Release beendete den Sicherheitssupport für Drupal 11.2.x und Drupal 10.5.x. Das Tag 12.0.0-alpha1 ging am 2. September 2026 hinaus. Die Beta-Anforderungen mussten bis zum 11. September 2026 erfüllt sein, mit 12.0.0-beta1 und 11.5.0-beta1 in der Woche vom 14. September und Release Candidates in der Woche vom 9. November.

Die Woche vom 7. Dezember erledigt dann drei Dinge auf einmal. Drupal 12.0.0 erscheint, Drupal 11.5.0 erscheint daneben, und der Sicherheitssupport endet für Drupal 11.3.x und Drupal 10.6.x. Zwei Tage später, am 9. Dezember 2026, erreicht Drupal 10 als Ganzes sein End of Life, und es wird überhaupt kein Release mehr davon geben.

Warum Drupal 10 und Drupal 12 in derselben Woche landen

Das ist Policy, kein Zufall. Die Übersicht über den Release-Prozess hält fest, dass Major-Versionen alle zwei Jahre in geraden Jahren erscheinen und dass jeder Major mindestens vier Jahre lang unterstützt wird, bis zwei weitere Majors erschienen sind. Drupal 10.0.0 kam am 15. Dezember 2022 heraus. Drupal 11 erschien im August 2024 und Drupal 12 erscheint im Dezember 2026, das ist der zweite weitere Major, und vier Jahre sind vergangen. Die Uhr lief exakt nach Plan ab.

Dieselbe Policy regelt die Minors. Jede Minor-Version wird ein Jahr lang unterstützt, mit Bugfixes und Sicherheitsfixes in den ersten sechs Monaten und nur noch Sicherheitsfixes in den letzten sechs. Deshalb erhält heute nur 10.6.x noch Hinweise, und deshalb verliert 11.3.x seine Abdeckung in dem Moment, in dem 11.5.0 erscheint.

Drupal 11 endet nicht, wenn Drupal 12 beginnt. Das Release von 11.5.0 in derselben Woche startet die von der Policy so genannte Long-Term-Support-Phase, in der der vorherige Major einen API-gleichen Minor behält, auf ein LTS-Release von Symfony wechselt und alle sechs Monate einen Wartungs-Minor mit schrumpfendem Umfang erhält. Drupal.org veröffentlicht kein festes End-of-Life-Datum für Drupal 11, die eigene Dokumentation zu veralteten Erweiterungen nennt jedoch eine Unterstützung bis Mitte bis Ende 2028.

Wie viele Websites noch auf Drupal 10 sitzen

Die Zahlen sind öffentlich und sie sind nicht bequem. Die Core-Nutzungsstatistik von drupal.org verzeichnet für die Woche ab dem 23. August 2026 468.877 Websites, die eine Core-Version melden. Davon laufen 205.568 auf irgendeinem Zweig von Drupal 10 und 168.857 auf Drupal 11. Rund 44 Prozent der meldenden Installationsbasis läuft auf der Version, die im Dezember keine Hinweise mehr bekommt.

Die schärfere Zahl steckt in dieser Zahl. Nur 10.6.x hat noch Sicherheitsabdeckung, und auf 10.6.x entfallen 139.911 dieser Websites. Die übrigen 65.657 laufen auf 10.0 bis 10.5, sie betreiben also schon heute, im September, einen nicht unterstützten Minor, ohne auf den Dezember zu warten.

Diese Zählungen stammen von Websites, die freiwillig über das Modul Update Status melden, die tatsächliche Population ist also größer und verteilt sich ähnlich. Praktisch gelesen heißt das: Sehr viele Organisationen werden versuchen, dieselbe Upgrade-Arbeit im selben Quartal zu buchen, und die Agenturkapazität im Oktober und November wird der Engpass sein, nicht der Code.

Was End of Life für eine Drupal-Website wirklich bedeutet

End of Life ist kein Schalter, der die Website zerstört. Ihre Drupal-10-Installation liefert am 10. Dezember genau so Seiten aus wie am 8. Dezember. Was sich ändert: Das Drupal-Sicherheitsteam veröffentlicht für diesen Code keine Hinweise und Patches mehr, ab diesem Datum bleibt also jede neu entdeckte Schwachstelle in Drupal 10 Core dauerhaft offen.

Der zweite Effekt ist langsamer und richtet mehr Schaden an. Die Sicherheitsabdeckung von Contrib-Modulen hängt davon ab, dass das Modul ein stabiles Release auf einem unterstützten Core-Zweig hat. Sobald Maintainer die Drupal-10-Kompatibilität fallen lassen, verlassen die Module auf Ihrer Website also ebenfalls still den Hinweisprozess. Sie werden darüber nicht benachrichtigt. Das Modul taucht einfach nicht mehr in Sicherheitsreleases auf, und der Bericht über verfügbare Aktualisierungen auf Ihrer eigenen Website sieht weiterhin grün aus.

Der dritte Effekt: Der Ausstieg wird teurer, je länger Sie warten. Eine Drupal-10-Website, die im November aktualisiert wird, wird gegen einen gepflegten Core-Zweig mit funktionierendem Update-Pfad aktualisiert. Dieselbe Website im Juni darauf ist ein Rettungsprojekt, weil die Contrib-Module, von denen sie abhängt, sechs weitere Monate Zeit hatten, ohne sie weiterzuziehen.

Cyber Essentials, Versicherungen und Vertragsklauseln

Hier hört ein nicht unterstütztes CMS auf, ein rein technisches Thema zu sein. Die Cyber-Essentials-Anforderungen für IT-Infrastruktur v3.3 des NCSC vom April 2026 halten fest, dass jede Software auf Geräten im Geltungsbereich lizenziert und unterstützt sein muss und entfernt werden muss, sobald sie nicht mehr unterstützt wird, oder über eine definierte Teilmenge aus dem Geltungsbereich genommen werden muss, die jeglichen Verkehr aus dem und ins Internet unterbindet. Die Kontrolle gilt für Server, IaaS, PaaS und SaaS, eine Drupal-Installation auf einem Server im Geltungsbereich ist also klar erfasst.

Eine öffentlich erreichbare Drupal-10-Website lässt sich nicht vom Internet abschotten. Nach dem 9. Dezember 2026 bleiben also zwei Antworten: aktualisieren oder akzeptieren, dass diese Kontrolle nicht erfüllt ist. Wenn Ihre Organisation Cyber Essentials oder Cyber Essentials Plus hält und jährlich erneuert, wird Ihnen das bei der nächsten Bewertung schriftlich gestellt.

Seien Sie vorsichtig mit weitergehenden Behauptungen. Ob eine konkrete Cyber-Versicherung oder ein Kundenvertrag betroffen ist, hängt vollständig vom Wortlaut ab, und die relevanten Klauseln verlangen meist unterstützte Software oder herstellergepflegte Versionen, statt Drupal zu nennen. Lesen Sie Ihre eigene Police und Ihre eigenen Rahmenverträge vor dem Dezember statt nach einem Vorfall, denn das ist der günstige Zeitpunkt dafür.

Was in Drupal 12 tatsächlich anders ist

Sehr wenig, und das ist die ehrliche und nützliche Antwort. Die Release Notes zu 12.0.0-alpha1 sagen es klar: 12.0.x wird nahezu identisch mit 11.5.x sein, abgesehen davon, dass veralteter Code entfernt wird, einschließlich ganzer veralteter Module, dass Abhängigkeiten auf neue Major-Versionen angehoben werden und dass die Systemanforderungen steigen. Für alles Weitere verweisen die Notes auf den Zweig 11.5.x.

Es gibt eine Handvoll echter Verhaltensänderungen, die man kennen sollte. Der Standardalgorithmus zum Hashen von Passwörtern wechselt zu argon2id, wobei bcrypt über Kernel-Parameter verfügbar bleibt, wo argon2 fehlt. Die robots.txt im Core sperrt jetzt Suchergebnisseiten mit Query-Parametern, was Suchmaschinen davon abhält, unendliche Facettenkombinationen zu crawlen. Websites mit angepasster robots.txt müssen diese Disallow-Regeln von Hand ergänzen. HTMX, das der Core bereits mitliefert, wechselt für beta1 von Version 2 auf Version 4.

Eines ist leicht zu übersehen. Drupal direkt unter Windows in einer Produktivumgebung zu betreiben, gilt in Drupal 12 als veraltet, weil es keine automatisierte Windows-Testumgebung gibt und kaum Entwickler darauf testen. Für die lokale Entwicklung bleibt Windows unterstützt. Wenn Sie produktiv auf Windows fahren, ist das eine Hosting-Entscheidung für die nächsten Monate, keine Codeänderung.

Die Erweiterungen, die den Core verlassen

Drupal verschiebt seit Jahren schmale Module aus dem Core in Contrib-Projekte, und Drupal 12 setzt das fort. Die alpha1-Notes führen Ban, Contact, Field Layout, History, Settings Tray, Shortcut und Telephone als entfernt auf, dazu das Theme Stable 9. Auch das Feld-Plugin Text with Summary ist in ein eigenes Contrib-Modul gewandert. Ban wurde bereits in 11.3 als veraltet markiert, Contact, Field Layout, History und Telephone in 11.4 sowie Settings Tray, Shortcut und Text with Summary in 11.5.

Zwei davon werden überraschen. Shortcut und Settings Tray sind Verwaltungsfunktionen, die sehr viele Redaktionsteams täglich nutzen, ohne sie je für optional zu halten, und gerade Settings Tray trägt die Inline-Konfiguration von Blöcken, auf die sich Redakteure verlassen.

Wichtiger als die Liste ist die Mechanik des Umgangs damit. Der richtige Schritt ist, die Contrib-Version vor dem Upgrade in Ihre Composer-Anforderungen aufzunehmen, statt das Modul zu deinstallieren. Deinstallieren zerstört die Konfiguration der Erweiterung, und Drupals Modul-Discovery schaut zuletzt in den Core. Sobald das Contrib-Projekt vorhanden ist, nutzt Drupal also einfach dieses. Beachten Sie außerdem, dass Drush die Warnungen auf update.php über fehlende Erweiterungen umgehen kann, der Fehler zeigt sich dann erst danach als Meldung im Statusbericht.

Der Verlust von Migrate Drupal trifft am härtesten

Die Module Migrate Drupal und Migrate Drupal UI werden in Drupal 12 entfernt und, anders als der Rest, nicht in ein Contrib-Projekt überführt. Drupal 12 behält die Migrate-API und die Ziel-Plugins für modernes Drupal, aber es behält nicht die Quell-Plugins für Drupal 6 und Drupal 7.

Lesen Sie das noch einmal, wenn Ihnen eine Drupal-7-Website gehört. Das Werkzeug, das eine alte Drupal-Datenbank liest und in eine moderne schreibt, existiert in Drupal 11 und existiert in Drupal 12 nicht. Die Ansage von drupal.org ist eindeutig: Websites auf Drupal 6 oder Drupal 7, die die Migrations-API nutzen wollen, sollen weiterhin nach Drupal 11 migrieren und danach über den gewöhnlichen Update-Prozess von Drupal 11 auf Drupal 12 wechseln.

Damit wird aus einer vagen Absicht eine harte Reihenfolge. Ein Drupal-7-Neubau, der nach dem Supportende von Drupal 11 landet, muss entweder eigene Quell-Plugins bauen, einen älteren Core wiederherstellen, um die Migration in einer Wegwerfumgebung laufen zu lassen, oder die Inhalte auf anderem Weg exportieren und wieder einlesen. Alle drei sind teurer, als die Migration nach Drupal 11 zu machen, solange Drupal 11 ein aktuelles, gepflegtes Ziel ist. Unser Leitfaden zu Kosten, Optionen und Fristen einer Drupal-Migration beschreibt die Form dieser Arbeit im Detail.

Die neuen Abhängigkeits-Untergrenzen

Ein Major ist die Gelegenheit, bei der Drupal seine Plattformanforderungen anheben darf, und Drupal 12 nutzt sie auf ganzer Linie. Diese Untergrenzen sind der Teil des Upgrades, über den sich nicht verhandeln lässt, weil sie bei der Installation erzwungen werden.

PHP 8.5, und nichts Älteres

Drupal 12 verlangt PHP 8.5. Die Tabelle der PHP-Anforderungen zeigt Drupal 12.0 mit Unterstützung für PHP 8.5 und Ablehnung von allem darunter, während Drupal 11.3 und 11.4 die Versionen 8.3, 8.4 und 8.5 akzeptieren. Diese Überlappung ist Ihre Migrationsroute: Bringen Sie die Website auf PHP 8.5, während sie noch auf Drupal 11.4 läuft, prüfen Sie das Verhalten, und wechseln Sie erst dann Drupal.

Die Untergrenze ist großzügig statt strafend. PHP 8.5 erschien am 20. November 2025, und die Seite zu unterstützten Versionen auf php.net nennt aktiven Support bis zum 31. Dezember 2027 und Sicherheitssupport bis zum 31. Dezember 2029. Dort zu landen kauft drei Jahre, bevor dieses Gespräch erneut ansteht.

Datenbanken und Symfony

Die Anforderungen an den Datenbankserver für Drupal 12 lauten MySQL 8.0 oder neuer, MariaDB 10.11 oder neuer, PostgreSQL 18 oder neuer sowie SQLite 3.45 mit der Erweiterung json1. PostgreSQL-Websites sollten diese Untergrenze besonders sorgfältig prüfen, denn die alpha1-Release-Notes nennen PostgreSQL 19, während die Anforderungsseite und der Installer-Code beide 18 nennen. Prüfen Sie das bei beta1 erneut, bevor Sie Datenbankarbeit buchen.

Darunter wechselt Symfony von 7.4 auf 8.1 und Guzzle von 7 auf 8. Der Support für mehrere ältere Bibliotheks-Majors entfällt, darunter doctrine/lexer 2, egulias/email-validator 3 und guzzlehttp/psr7 2. Eigener Code, der Symfony-Klassen direkt typisiert, ist die Stelle, an der sich das zeigt.

Was die Untergrenzen für Ihr Hosting bedeuten

Der Sprung bei MariaDB ist der, der Shared- und Managed-Hoster erwischt. Drupal 11 akzeptiert MariaDB 10.6, dessen Community-Wartung laut der MariaDB-Wartungsrichtlinie am 6. Juli 2026 endete, eine Drupal-11-Website darf also derzeit völlig legitim auf einer nicht mehr gewarteten Datenbank-Engine sitzen. Drupal 12 hebt die Untergrenze auf 10.11, das bis zum 16. Februar 2028 gewartet wird. Wenn Ihr Hoster heute kein PHP 8.5 und kein MariaDB 10.11 anbietet, muss der Hosting-Wechsel vor dem Drupal-Wechsel passieren, und genau diese Umstellung der Reihenfolge macht aus einer Zweiwochen-Aufgabe eine Zweimonats-Aufgabe. Unsere Notiz dazu, was Drupal wirklich gut betreibt, behandelt die Plattformseite.

Warum das Deprecation-Modell Drupal 12 beherrschbar macht

Hier ist der Mechanismus, den den meisten Websitebetreibern nie jemand erklärt hat, und er ist der Grund, warum Drupal-Majors nicht mehr angsteinflößend sind. Die Policy zu fortlaufenden Upgrades verpflichtet den Core auf ein einfaches Versprechen: Das nächste Major-Release hat dieselbe öffentliche API wie das letzte Minor-Release des vorherigen Majors. Neue APIs kommen in Minors dazu, alte werden in Minors als veraltet markiert, und gelöscht wird ausschließlich an der Major-Grenze.

Die praktische Folge lohnt sich im Klartext. Wenn Ihr eigener Code und Ihre Contrib-Module auf Drupal 11.5 ohne Deprecation-Warnungen laufen, laufen sie auf Drupal 12. Aus dem Upgrade wird statt einer Neufassung ein Anheben von Abhängigkeiten plus ein Datenbank-Update, weil alles, was gebrochen wäre, Ihnen schon Monate früher als Warnung gemeldet wurde, die Sie in Ruhe hätten beheben können.

Deshalb sagen die Release Notes auch, man solle zuerst auf 11.4 oder neuer aktualisieren, und empfehlen nachdrücklich 11.5. Der Datenbank-Update-Pfad aus Releases vor 11.4.0 wurde aus Drupal 12 ersatzlos entfernt, eine Website auf 11.3 oder älter hat also keinen Weg in die 12, bis sie im 11er-Zweig aufsteigt. Das ist kein Ratschlag, das ist ein fehlender Codepfad.

Die Werkzeuge, die Deprecations melden

Zwei Projekte erledigen die Arbeit, und beide werden derzeit gepflegt. Upgrade Status ist der websiteweite Scanner. Sie installieren ihn auf der Website, von der aus Sie aktualisieren, nicht auf der, auf die Sie aktualisieren, denn die veralteten APIs müssen vorhanden sein, damit er Aufrufe darauf finden kann. Er prüft, ob Ihre Umgebung die Systemanforderungen des nächsten Majors erfüllt, gleicht Ihre Contrib-Projekte mit verfügbaren Aktualisierungen ab, führt PHPStan für veraltete PHP-API-Nutzung aus und liest Twig-Templates, info.yml-Dateien, composer.json und veraltete Konfigurationsschlüssel. Release 5.0.0-alpha3 vom 2. Juli 2026 erklärt Kompatibilität mit Drupal 10.4, 11 und 12.

Er kategorisiert außerdem, was er findet, und das ist der Teil, der Geld spart. Probleme werden danach sortiert, ob eine Maschine sie beheben kann oder ein Mensch, Sie können also die manuelle Hälfte kalkulieren, bevor Sie sich auf ein Datum festlegen. Er läuft unter Drush als upgrade_status:analyze, und seine Code-Climate-JSON-Ausgabe passt in GitLab CI.

Drupal Rector ist die andere Hälfte. Es schreibt die mechanisch behebbaren Deprecations in Ihren eigenen Modulen und Themes um, mit einem --dry-run-Flag, um den Diff vorher anzusehen. Version 1.1.2 erschien am 7. August 2026. Zusammen kann ein kompetenter Entwickler damit für eine mittelgroße Website in zwei bis drei Tagen einen belastbaren Bereitschaftsbericht erstellen.

Weg eins: Drupal 11 auf Drupal 12

Wenn Sie auf Drupal 11.4 oder 11.5 mit aktuellen Contrib-Modulen sind, ist das ein kleines Stück Arbeit. Der offizielle Upgrade-Leitfaden besteht überwiegend aus Composer-Befehlen: die Metapakete der Version 12 mit --no-update anfordern, eine explizite Anforderung von drupal/core entfernen, composer update --dry-run laufen lassen, dann echt ausführen und die Datenbank-Updates mit drush updatedb anwenden.

Die eigentliche Arbeit liegt links und rechts davon. Vorher: Upgrade Status laufen lassen, Contrib-Ersatz für jede entfernte Core-Erweiterung ergänzen, die Sie tatsächlich nutzen, und bestätigen, dass Ihr Hoster PHP 8.5 anbietet. Danach: Rechnen Sie damit, dass sich jede Core-Scaffold-Datei geändert hat, .htaccess eingeschlossen, jede Anpassung daran muss also bewusst neu angewendet statt blind gemergt werden.

Wenn sich eine Abhängigkeit nicht auflösen lässt, benennt composer why-not drupal/core ^12 den Blocker. Zwei Majors eines Moduls in der composer.json zuzulassen, etwa "^6.1 || ^7.0", ist der übliche Weg, ein Projekt mitten im Übergang zu überbrücken. Wenn Sie ein Modul brauchen, das einen funktionierenden Patch, aber kein getaggtes Release hat, existiert der Drupal Lenient Composer Endpoint genau dafür und wird weiterhin gepflegt.

Weg zwei: Drupal 10 auf Drupal 12 sind zwei Sprünge

Es gibt kein direktes Upgrade von Drupal 10 auf Drupal 12. Die Dokumentation von Upgrade Status sagt das ausdrücklich, und die Entfernung des Datenbank-Update-Pfads vor 11.4 erzwingt es. Sie gehen von Drupal 10.6 auf Drupal 11.4 oder 11.5, prüfen die Website, und gehen von dort auf Drupal 12.

Richtig geplant ist das nicht die doppelte Arbeit. Der Sprung von Drupal 10 auf Drupal 11 trägt fast das gesamte Risiko, denn dort sitzen die Kompatibilitätsprobleme der Contrib-Module und dort trifft eigener Code auf entfernte APIs. Der zweite Sprung ist der kleine, oben beschriebene. Teams, die beides in ein einziges Änderungsfenster pressen, können hinterher meist nicht sagen, welcher der beiden etwas kaputt gemacht hat.

Die Reihenfolge, die funktioniert: den Drupal-11-Sprung jetzt machen, die Website mehrere Wochen auf 11.4 oder 11.5 laufen lassen, damit echtes Redaktions- und Besucherverhalten Auffälligkeiten zutage fördert, und Drupal 12 im neuen Jahr nehmen, sobald Contrib-Module stabile Releases dagegen getaggt haben. Dass der erste Sprung vor dem Dezember passiert, ist das Entscheidende, denn er ist der Sprung, der Sie von nicht unterstütztem Code herunterholt.

Weg drei: Drupal 7 oder 8 ist ein Neubau, kein Upgrade

Alles älter als Drupal 9 ist eine andere Übung. Drupal 7 erreichte am 5. Januar 2025 sein End of Life und Drupal 6 im Februar 2016. Keines von beiden lässt sich überhaupt an Ort und Stelle aktualisieren, weil sie der modernen Architektur vorausgehen. Sie werden migriert, das heißt, eine neue Website wird auf aktuellem Drupal gebaut und die Inhalte werden mit der Migrate-API hineingezogen. Eine Drupal-8-Website hat technisch einen Pfad an Ort und Stelle, der aber durch vier aufeinanderfolgende Majors führt und jedes Contrib-Modul muss jeden davon überleben, deshalb ist es normalerweise günstiger, auch sie als Neubau zu behandeln.

Die Kosten dominiert alles, was nicht Inhalt ist. Das Theme wird neu gebaut, eigene Module werden gegen eine völlig andere API neu geschrieben, und Integrationen werden neu angebunden. Nach unserer Erfahrung ist die Inhaltsmigration selbst meist die kleinere Hälfte des Budgets, was das Gegenteil dessen ist, was die meisten Betreiber bei einer Anfrage erwarten, und der Grund, warum wir das als Webentwicklung statt als Upgrade kalkulieren.

Für diese Websites wirkt die Dezember-Frist anders, beißt aber trotzdem, wegen der Entfernung von Migrate Drupal. Ihr Ziel muss Drupal 11 sein, nicht Drupal 12, und Drupal 11 wird laut der eigenen Dokumentation von drupal.org bis Mitte bis Ende 2028 unterstützt. Das gibt einem Drupal-7-Betreiber ein echtes Fenster, aber ein Fenster mit hartem Ende, und 2028 einen sechsmonatigen Neubau zu starten, um ein Ziel in 2028 zu treffen, ist kein Plan.

Was jeder Weg im Vereinigten Königreich kostet

Das sind Hausschätzungen aus unserer eigenen Umsetzung, keine veröffentlichten Sätze, und die Spanne innerhalb jedes Bandes wird fast ausschließlich vom Gesundheitszustand der Contrib-Module bestimmt, nicht von der Größe der Website. Britische Agenturen berechnen für diese Arbeit grob 600 bis 900 Pfund pro Tag. Ein Upgrade von Drupal 11 auf 12 auf einer gepflegten Website sind drei bis acht Tage inklusive Tests, was bei rund 2.000 bis 6.000 Pfund landet. Hat dieselbe Website veraltete Contrib-Module, rechnen Sie mit zwei bis vier Wochen und 6.000 bis 12.000 Pfund.

Eine Drupal-10-Website bezahlt beide Sprünge. Gut gepflegt kostet der Sprung von Drupal 10 auf 11 6.000 bis 15.000 Pfund, und der Drupal-12-Sprung kommt mit 2.000 bis 6.000 Pfund dazu, also 8.000 bis 21.000 Pfund insgesamt über vier bis acht Wochen. Vernachlässigt kostet allein der erste Sprung 15.000 bis 35.000 Pfund, und das Gesamtergebnis landet zwischen 17.000 und 41.000 Pfund. Ein Drupal-7-Neubau dauert drei bis sechs Monate und kostet üblicherweise 40.000 bis 120.000 Pfund, mehr bei großen oder stark angepassten Websites.

Das Contrib-Audit, das Ihr Datum festlegt

Upgrade-Projekte scheitern selten am Core. Sie scheitern am vierzehnten Modul der Liste, dem, an dessen Installation sich niemand erinnert, das kein mit dem nächsten Major kompatibles Release hat und einen Maintainer, der zuletzt 2023 etwas geschrieben hat. Machen Sie dieses Audit, bevor Sie sich auf ein Datum festlegen, denn es ist das Audit, das das Datum erzeugt.

Lassen Sie Upgrade Status laufen, exportieren Sie den Bericht und sortieren Sie Ihre Module in vier Körbe. Der erste sind Projekte mit einem stabilen Release für den Ziel-Major, die nichts kosten. Der zweite sind Projekte mit einem Patch oder einem Development-Release in der Issue-Queue, die etwas Integrationsarbeit kosten und das Risiko tragen, dass der Patch nie landet. Der dritte sind Projekte mit einem offenen Issue ohne Patch, für die jemand einen schreiben muss. Der vierte sind Projekte ganz ohne Aktivität.

Der vierte Korb bestimmt Ihren Zeitplan, und seine Größe ist heute wissbar statt im November. Eine Website mit dreißig Contrib-Modulen und nichts im vierten Korb ist eine geradlinige Aufgabe. Dieselbe Website mit vier Modulen im vierten Korb ist ein anderes Projekt mit anderem Budget, und der Unterschied zwischen diesen beiden Angeboten ist ein Tag Scannen.

Was tun mit einem verwaisten Modul

Es gibt vier ehrliche Optionen, und die richtige hängt davon ab, was das Modul tut. Entfernen, wenn die Funktion nicht mehr genutzt wird, was nach einigen Jahren redaktioneller Drift häufiger zutrifft, als Teams erwarten. Ersetzen durch ein gepflegtes Projekt, das dieselbe Aufgabe erledigt, samt der Konfigurationsmigration, die dazugehört.

Die Wartung übernehmen, was in Drupal eine echte Option und weniger einschüchternd ist, als es klingt. Drupal.org hat einen dokumentierten Prozess dafür, Maintainer eines nicht mehr unterstützten Projekts zu werden, und für ein kleines Modul, von dem Ihr Geschäft abhängt, kann eine Übernahme günstiger sein als ein Ersatz. Die Kosten sind laufend statt einmalig, kalkulieren Sie das ehrlich ein.

Oder das Verhalten in einem eigenen Modul nachbauen, zugeschnitten auf das, was Sie wirklich nutzen. Ein Contrib-Modul löst den allgemeinen Fall für alle, während Sie meist eine schmale Scheibe davon brauchen. Diese Scheibe gegen aktuelle APIs nachzubauen ist häufig eine Zweitagesaufgabe gegen eine Zweiwochen-Portierung, und sie entfernt die Abhängigkeit dauerhaft. Unsere Hinweise zum Beauftragen eines Drupal-Entwicklers behandeln, wie man jemanden auf genau dieses Urteilsvermögen prüft.

Ein Zeitplan, rückwärts gerechnet vom 9. Dezember 2026

Beginnen Sie beim Enddatum, dann schreibt sich der Plan von selbst. Bis Ende September lassen Sie Upgrade Status gegen Drupal 12 auf einer Kopie der Produktion laufen und bringen die vier Körbe zu Papier. Das ist eine Übung von zwei bis drei Tagen und das einzige Artefakt, mit dem sich alles andere ehrlich kalkulieren lässt.

Bis Mitte Oktober bestätigen Sie, dass Ihr Hosting PHP 8.5 und die Datenbank-Untergrenzen liefern kann, und starten den Wechsel, falls nicht. Entscheiden Sie außerdem die Contrib-Fragen, denn an jeder einzelnen hängt eine Vorlaufzeit. Bis Anfang November ist auf einer Drupal-10-Website das Upgrade auf Drupal 11.4 oder 11.5 abgeschlossen, und die Website läuft produktiv auf dem neuen Zweig.

Bis Anfang Dezember beobachten Sie das Release 12.0.0, statt darauf zu reagieren. Wenn Sie dann auf Drupal 11 sind, nehmen Sie Drupal 12 im Januar oder Februar 2027, sobald Contrib-Projekte stabile Releases dagegen getaggt haben. Es gibt keinen Preis dafür, in der Release-Woche zu aktualisieren, und Drupal 11.5 bleibt unterstützt. Der Preis ist dafür, nicht mehr auf Drupal 10 zu sein, wenn die Hinweise aufhören.

Was es kostet, nichts zu tun

Die direkte Folge: Jede Drupal-Core-Schwachstelle, die nach dem 9. Dezember 2026 offengelegt wird, bleibt auf Ihrer Website dauerhaft offen. Drupals Hinweishistorie enthält Remote-Code-Execution-Lücken, die ernst genug waren, um binnen Stunden nach Veröffentlichung ausgenutzt zu werden, und ein ungepatchtes CMS auf einer öffentlichen IP wird von automatisiertem Scannen gefunden, nicht von einem gezielten Angreifer, der Sie ausgesucht hat.

Die indirekten Kosten kommen früher und sind meist größer. Wer die Kontrolle zu unterstützter Software in einer Cyber-Essentials-Bewertung nicht besteht, kann die Eignung für Aufträge verlieren, die das Zertifikat verlangen, was in der öffentlichen Beschaffung im Vereinigten Königreich verbreitet ist. Contrib-Module liefern für Ihren Zweig keine Fixes mehr. Und das Upgrade selbst wird jeden Monat teurer, weil die Lücke zwischen Ihrer Codebasis und dem gepflegten Ökosystem wächst, ohne dass jemand etwas anfasst.

Es gibt auch eine leisere Folge. Eine Website, die niemand aktualisieren darf, wird meist zu einer Website, die niemand ändern darf, und Feature-Arbeit hört auf, weil jede Änderung gegen eine API gebaut werden müsste, die verschwindet. So wird aus einer fünf Jahre alten Drupal-Website ein Neubau statt eines Upgrades. Wenn Sie diese Entscheidung abwägen, ist unser Leitfaden zur Drupal-Webentwicklung ein besserer Ausgangspunkt als ein Angebot.

Zwei legitime Gründe zu warten

Warten ist in zwei Situationen vertretbar, und nur, wenn Sie bewusst warten. Der erste: Sie sind bereits auf Drupal 11.4 oder 11.5. Diese Zweige werden unterstützt, sie sind die vorgesehene Startrampe für Drupal 12, und es bringt nichts, einen brandneuen Major in seinen ersten Wochen zu nehmen, während Contrib-Projekte noch Releases taggen. Bis zum ersten Quartal 2027 zu warten ist die professionelle Wahl, nicht die bequeme.

Der zweite: eine Drupal-7-Website mit bereits finanziertem und terminiertem Neubau. Drupal 7 nach Drupal 11 zu migrieren und sofort danach nach Drupal 12, ist verschwendete Bewegung. Landen Sie auf Drupal 11, betreiben Sie es, und nehmen Sie Drupal 12 später als gewöhnliche Wartung.

Nicht vertretbar ist es, ohne gebuchten Plan auf Drupal 10 zu sitzen. Wenn das auf Sie zutrifft, ist die Mindestposition bis Ende September ein Scan-Bericht, ein benannter Zielzweig und ein Datum im Kalender. Alles andere kann sich verschieben. Wenn Sie diese Bewertung von jemandem gemacht haben möchten, der sie schon geführt hat: Unser Team für Softwareentwicklung macht Versions-Audits als Arbeit mit festem Umfang.

Wo Sie anfangen

Machen Sie zuerst den Scan. Nahezu jedes schlechte Drupal-Upgrade-Angebot dieser Welt entstand ohne einen, und deshalb sind so viele davon in beide Richtungen falsch. Zwei bis drei Tage Ausgabe von Upgrade Status und Drupal Rector sagen Ihnen, in welchem der fünf Kostenbänder oben Sie tatsächlich stehen, und diese eine Zahl verändert das Gespräch mit Ihrem Vorstand mehr als jede allgemeine Belehrung über Major-Versionen.

Mecanik führt diese Audits durch und die Upgrades, die darauf folgen, auf Drupal-10-Websites vor dem Dezember und auf Drupal-11-Websites, die 2027 in Ruhe wechseln wollen. Eigene Modularbeit, Integrationen und das Aufräumen der Deprecations liegen bei unserer Softwareentwicklung, während ein Neubau oder ein Hosting-Wechsel zur Webentwicklung gehört. Wenn die Sicherheitslage der Grund ist, warum das auf Ihrem Schreibtisch gelandet ist, beginnen Sie mit unserer Notiz zu Drupal-Sicherheitshinweisen und echtem Risiko, und wenn organischer Traffic die Sorge während eines Versionswechsels ist, behandelt der Beitrag zum technischen Drupal-SEO-Setup, was zu schützen ist.

Häufig gestellte Fragen

Wann erscheint Drupal 12 und wann erreicht Drupal 10 sein End of Life? Drupal 12.0.0 ist für die Woche vom 7. Dezember 2026 geplant und erscheint zusammen mit Drupal 11.5.0, und Drupal 10 erreicht am 9. Dezember 2026 sein End of Life. Beide Daten stehen im Drupal-Core-Release-Zeitplan. In derselben Woche endet der Sicherheitssupport für die Minor-Zweige 11.3.x und 10.6.x. Drupal 12.0.0-alpha1 wurde am 2. September 2026 getaggt.

Kann ich direkt von Drupal 10 auf Drupal 12 aktualisieren? Nein. Der Datenbank-Update-Pfad aus Releases vor Drupal 11.4.0 wurde aus Drupal 12 entfernt, eine Drupal-10-Website muss also zuerst auf Drupal 11.4 oder neuer und danach auf Drupal 12. Drupal.org empfiehlt 11.5.0 oder höher vor dem Major-Wechsel. Planen Sie es als zwei Sprünge, wobei der Sprung von Drupal 10 auf 11 nahezu das gesamte Risiko und die Kosten trägt.

Wie lauten die Systemanforderungen von Drupal 12? Drupal 12 verlangt PHP 8.5 und lässt PHP 8.4 und älter fallen. Die Datenbank-Untergrenzen sind MySQL 8.0, MariaDB 10.11, PostgreSQL 18 und SQLite 3.45 mit der Erweiterung json1. Symfony wechselt auf 8.1 und Guzzle auf 8.0. Drupal direkt unter Windows produktiv zu betreiben, gilt als veraltet, für die lokale Entwicklung bleibt Windows unterstützt.

Was ist an Drupal 12 gegenüber Drupal 11.5 tatsächlich neu? Fast nichts, und das ist Absicht. Die alpha1-Release-Notes halten fest, dass 12.0.x nahezu identisch mit 11.5.x ist, abgesehen von entferntem veraltetem Code, angehobenen Abhängigkeits-Majors und höheren Systemanforderungen. Nennenswerte Verhaltensänderungen sind argon2id als Standardalgorithmus zum Hashen von Passwörtern, HTMX in Version 4 und eine robots.txt im Core, die Suchergebnisseiten mit Query-Parametern sperrt.

Was kostet ein Drupal-12-Upgrade im Vereinigten Königreich? Auf einer gepflegten Drupal-11-Website drei bis acht Tage Arbeit zu üblichen britischen Agentursätzen von 600 bis 900 Pfund pro Tag, also grob 2.000 bis 6.000 Pfund. Eine Drupal-10-Website bezahlt beide Sprünge und landet gut gepflegt zwischen 8.000 und 21.000 Pfund und vernachlässigt zwischen 17.000 und 41.000 Pfund. Ein Drupal-7-Neubau dauert drei bis sechs Monate und kostet üblicherweise 40.000 bis 120.000 Pfund. Das sind Hausschätzungen, keine veröffentlichten Sätze.