Drupal 10 EOL am 9. Dezember 2026: Welche Migration-Strategie passt zu deiner Site?.

Geschrieben von Chris Schön am Jun 15, 2026

Header image forDrupal 10 EOL am 9. Dezember 2026: Welche Migration-Strategie passt zu deiner Site?

Noch rund sechs Monate, dann ist Schluss: Am 9. Dezember 2026 stellt das Drupal Security Team den Support für Drupal 10 ein. Wer bis dahin nicht migriert hat, betreibt eine Website ohne Sicherheitsnetz. Das klingt dramatisch — und ist es auch. Aber mit dem richtigen Plan ist das Zeitfenster absolut machbar.

Das Datum ist real: Was am 9. Dezember 2026 konkret passiert

Das End-of-Life-Datum für Drupal 10 steht fest und ist offiziell bestätigt. Ab diesem Tag gibt es keine Security Advisories, keine Patches und keinen Community-Support mehr für den 10.x-Zweig. Deine Site läuft zwar technisch weiter — aber jede nach dem Stichtag entdeckte Sicherheitslücke bleibt ungefixt.

Das betrifft nicht nur den Core: Auch Contributed Modules verlieren ihren Security-Coverage-Status für Drupal 10. Dazu kommt ein oft übersehener Aspekt: Drupal 10 basiert auf Symfony 6.4, das ebenfalls sein Support-Ende erreicht. Du hast also nicht nur ein CMS-Problem, sondern ein ganzes Dependency-Stack-Risiko.

Aktuell laufen laut OPTASY noch rund 245.000 Sites auf Drupal 10, während etwa 98.000 bereits auf Drupal 11 sind — ein Verhältnis von 2,5 zu 1. Wenn du zur Mehrheit gehörst, ist jetzt der richtige Zeitpunkt zu handeln.

Warum sechs Monate Vorlauf kritisch sind: Eine sauber durchgeführte Migration läuft über mehrere Monate — Scoping, Entwicklung, Testing, Deployment. Wer erst im letzten Quartal 2026 startet, hat keinen Puffer mehr für unvorhergesehene Probleme.

Die drei Migration-Pfade: Drupal 11, Drupal 12 oder Replatforming

Pfad 1: Upgrade auf Drupal 11 (empfohlen)

Der direkteste Weg. Die Migration von Drupal 10 auf 11 ist deutlich weniger komplex als frühere Major-Upgrades (etwa der Sprung von Drupal 7 auf 9). Drupal 11 erfordert mindestens PHP 8.3 und MySQL 8.0 (bzw. MariaDB 10.6). Deine Site muss auf mindestens Drupal 10.3.0 laufen, bevor du upgraden kannst — alle Core-Updates vor 10.3.0 wurden in Drupal 11 entfernt.

Einige Core-Module wurden in Drupal 11 entfernt: Actions UI, Activity Tracker, Book, Forum, Statistics und Tour. Falls du diese nutzt, brauchst du Contributed-Module-Alternativen.

Typischer Aufwand: Bei einer sauberen Codebasis 2–6 Wochen (je nach Anzahl Custom Modules und Contrib-Abhängigkeiten).

Pfad 2: Direkt auf Drupal 12 warten

Drupal 12 wird voraussichtlich in der Woche vom 10. August 2026 erscheinen — das ist der aktuell anvisierte Termin, nachdem das erste Release-Fenster im Juni nicht erreicht wurde. Falls die Beta-Deadline am 15. Mai nicht eingehalten wird, verschiebt sich der Release auf Anfang Dezember 2026.

Das Problem: Wenn du auf Drupal 12 wartest und es erst im Dezember erscheint, hast du praktisch null Übergangszeit. Contrib-Module brauchen nach einem Major-Release erfahrungsgemäß Wochen bis Monate für stabile Drupal-12-Versionen.

Empfehlung: Zuerst auf Drupal 11 migrieren, dann den Sprung auf 12 planen. Drupal 11 wird auch nach dem Release von Drupal 12 weiter unterstützt.

Pfad 3: Replatforming — weg von Drupal

Für Sites, die am Ende ihres funktionalen Lebenszyklus stehen oder deren Anforderungen sich grundlegend geändert haben, kann ein Plattformwechsel sinnvoll sein. Typische Szenarien: Low-Traffic-Sites, die mit einem Headless CMS oder einem Static Site Generator besser bedient wären, oder Organisationen, die ohnehin eine komplette digitale Neuausrichtung planen.

Typischer Aufwand: 3–12 Monate je nach Komplexität, deutlich höher als ein Drupal-Upgrade. Aber: Wenn du sowieso umbauen willst, ist das EOL-Datum ein guter Anlass.

Risiko-Bewertung für deine Site: Sicherheit, Performance, Custom-Code

Nicht jede Drupal-10-Site hat das gleiche Risikoprofil. Diese Checkliste hilft dir bei der Einschätzung:

Sicherheit & Compliance:

Custom Code & Module:

Infrastruktur:

Quick-Check mit dem Upgrade Status Module: Installiere das Modul upgrade_status auf deiner Dev-Umgebung. Es scannt deine gesamte Codebasis auf Deprecations, inkompatible Module und Umgebungsprobleme. In Kombination mit Drupal Rector lassen sich viele Deprecations sogar automatisch beheben.

composer require drupal/upgrade_status --dev
drush en upgrade_status

Der Report unter /admin/reports/upgrade gibt dir ein klares Bild, wie viel Arbeit tatsächlich ansteht.

Der Migrations-Fahrplan: Was du jetzt entscheiden musst

Die folgenden Meilensteine orientieren sich an einer Migration, die bis November 2026 abgeschlossen sein soll — mit Puffer vor dem Stichtag.

Sofort (Juni/Juli 2026):

August 2026:

September/Oktober 2026:

November 2026:

Die drei Fragen, die du dir jetzt stellen solltest

1. Wie sauber ist unsere Codebasis wirklich? Viele Teams überschätzen den Zustand ihres Custom Codes. Legacy-Workarounds, die in Drupal 8 oder 9 nötig waren, können in Drupal 11 überflüssig oder sogar hinderlich sein. Ein architektonisches Audit während der Migration kann langfristig Wartungsaufwand reduzieren.

2. Haben wir die Kapazitäten — oder brauchen wir Unterstützung? Eine Drupal-Migration ist kein Nebenprojekt. Wenn dein Team aktuell voll ausgelastet ist, plane frühzeitig externe Unterstützung ein. Die Verfügbarkeit erfahrener Drupal-Entwickler wird in den Monaten vor dem EOL-Datum erfahrungsgemäß knapper.

3. Ist Drupal noch die richtige Plattform für uns? Das ist keine ketzerische Frage, sondern eine strategische. Wenn deine Site-Anforderungen sich in den letzten drei Jahren grundlegend verändert haben, ist ein erzwungenes Upgrade der falsche Moment, um das zu ignorieren. Besser jetzt ehrlich evaluieren als in zwei Jahren erneut migrieren.

Häufige Fallstricke und wie du sie vermeidest

Contrib-Module nicht frühzeitig prüfen: Das größte Risiko sind Module, für die es noch keine Drupal-11-kompatible Version gibt. Prüfe die Issue-Queues auf drupal.org und plane Alternativen ein — oder erstelle selbst einen Kompatibilitäts-Patch.

Hosting-Umgebung vergessen: PHP 8.3 und MySQL 8.0 sind harte Anforderungen. Kläre das mit deinem Hosting-Provider bevor du mit der Migration startest. Besonders bei Shared-Hosting oder verwalteten Umgebungen kann das Wochen dauern.

Kein Staging, kein Rollback-Plan: Migriere niemals direkt auf Produktion. Eine vollständige Staging-Umgebung mit Datenbank-Dump und Config-Export ist Pflicht. Teste das Restore-Szenario, bevor du den Upgrade-Prozess startest.

Theme-Migration unterschätzen: Themes, die auf dem alten Classy-Base-Theme aufbauen, brauchen mehr Aufmerksamkeit. Starterkit-basierte Themes sind deutlich einfacher zu migrieren. Plane für Theme-Anpassungen extra Zeit ein.

Alles auf einmal machen wollen: Kombiniere die Migration nicht mit einem Redesign, neuen Features oder einem Content-Relaunch. Erst migrieren, dann optimieren. Sonst wird aus einem kontrollierbaren Projekt ein unkalkulierbares Risiko.

Nächste Schritte: Wie wir dich unterstützen können

Wenn du bis hierhin gelesen hast, hast du wahrscheinlich schon ein Gefühl dafür, wo deine Site steht. Die Fragen, die wir in einem ersten Gespräch typischerweise klären:

Diese Bestandsaufnahme dauert in der Regel ein bis zwei Stunden und gibt dir eine fundierte Grundlage für die nächsten Entscheidungen — unabhängig davon, ob du die Migration intern oder mit externer Unterstützung angehst. Melde dich bei uns, wenn du eine ehrliche Einschätzung für deine Site brauchst.