Drupal 7 ist tot: deine drei Optionen und was sie realistisch kosten

2009 habe ich mich selbstständig gemacht, und mein erstes richtiges Werkzeug hieß Drupal. Ich habe mit diesem CMS mein Handwerk gelernt, habe damit über die Jahre Enterprise-Projekte umgesetzt, unter anderem für XING, Gruner+Jahr, Bonduelle und die UNESCO, und ich sage das alles nicht, um anzugeben (na gut, ein kleines bisschen vielleicht), sondern damit klar ist, aus welcher Perspektive dieser Artikel geschrieben ist: Ich bin kein Drupal-Gegner, der dich weglocken will. Ich bin seit 17 Jahren Drupal-Entwickler. Und genau deshalb muss ich es so deutlich sagen: Drupal 7 ist tot.

Nicht sterbend, nicht auslaufend – tot. Seit dem 5. Januar 2025 ist offiziell End of Life, es gibt keine Sicherheitsupdates mehr. Das ist jetzt anderthalb Jahre her. Und trotzdem laufen da draußen noch erstaunlich viele Drupal-7-Seiten, als wäre nichts passiert.

Erkennst du deine Situation hier wieder:

• Deine Website läuft „doch noch super", also wurde die Migration jedes Jahr aufs nächste geschoben?
• Die Agentur von damals gibt es nicht mehr, und niemand traut sich an die gewachsenen Custom-Module?
• Du hast drei Angebote eingeholt und drei Zahlen bekommen, die so weit auseinanderliegen, dass du keinem davon traust?

Dann ist dieser Artikel für dich. Ich erkläre die drei Wege, die es gibt. Und, wahrscheinlich wichtiger: warum die Angebote so unterschiedlich ausfallen.

Warum „läuft doch noch" keine Option ist

Zuerst das Unbequeme. Eine Website ohne Sicherheitsupdates ist keine stabile Website, sie ist eine tickende Uhr. Jede Lücke, die ab jetzt in Drupal 7 oder einem seiner tausenden Module gefunden wird, bleibt offen. Für immer. Und Drupal-Seiten sind für Angreifer ein dankbares Ziel, weil eine einzige bekannte Lücke sich automatisiert auf zehntausenden Installationen gleichzeitig ausnutzen lässt. Das ist keine Theorie, das haben wir in der Drupal-Welt schon schmerzhaft erlebt: Beim „Drupalgeddon" 2014 liefen laut Drupal-Sicherheitsteam automatisierte Angriffe binnen Stunden nach Bekanntwerden der Lücke, und jede Drupal-7-Seite, die nicht innerhalb von sieben Stunden gepatcht war, galt pauschal als kompromittiert.

Seit ich mich intensiv mit Cybersecurity beschäftige, sehe ich das noch einmal strenger als früher. Ein System ohne Patches zu betreiben, auf dem Kundendaten liegen, ist nicht nur ein technisches Risiko. Spätestens wenn personenbezogene Daten abfließen, wird daraus ein DSGVO-Thema mit Meldepflicht nach Art. 33: unverzüglich, möglichst binnen 72 Stunden an die Aufsichtsbehörde. Die Frage ist also nicht, ob du migrierst, sondern nur wohin. Und dafür gibt es im Kern drei Wege.

Option 1: Drupal 10 oder 11, der naheliegende Weg, der keiner ist

Der erste Reflex ist verständlich: „Wir haben Drupal, wir bleiben bei Drupal, das ist doch nur ein Update." Und hier muss ich die wichtigste Erwartung geraderücken, die es zu Drupal 7 gibt: Der Weg zu Drupal 10 oder 11 ist kein Update. Es gibt keinen Knopf, der aus einer Drupal-7-Seite eine Drupal-11-Seite macht. Die Architektur hat sich zwischen diesen Welten so grundlegend geändert, dass es faktisch ein Rebuild ist: Die Inhalte lassen sich über die Migrate API übernehmen, aber Theme, Konfiguration und vor allem die Custom-Module werden neu gebaut.

Wann ist das trotzdem der richtige Weg? Wenn Drupal für dich nie das Problem war. Wenn du die Stärken tatsächlich nutzt: komplexe Inhaltsstrukturen, mehrsprachige Seiten, fein granulare Rechte, redaktionelle Workflows. Modernes Drupal ist ein hervorragendes System, und wer einmal sauber auf 10 oder 11 angekommen ist, hat das Thema Großmigration auf absehbare Zeit hinter sich, weil die Upgrades seitdem deutlich sanfter geworden sind. Aber geh bitte mit der richtigen Erwartung hinein: Du kaufst einen Neubau nach vertrautem Grundriss, keinen neuen Anstrich.

Option 2: Der CMS-Wechsel, wenn Drupal nie richtig gepasst hat

Die zweite Option spricht selten jemand offen aus, also übernehme ich das: Manche Websites hätten nie auf Drupal laufen müssen. Ich habe über die Jahre einige Drupal-7-Seiten gesehen, die im Kern eine Unternehmensseite mit zwanzig Seiten Inhalt und einem Blog waren, aufgesetzt auf einem System, das für Verlagsplattformen taugt. Das war damals gut gemeint und ist heute unnötiger Ballast.

Wenn das deine Situation ist, dann ist die erzwungene Migration in Wahrheit eine Gelegenheit. Wer ohnehin alles neu bauen muss (siehe Option 1), kann genauso gut die Systemfrage neu stellen: Brauchst du die Mächtigkeit von Drupal überhaupt noch? Oder wärst du mit einem schlankeren System glücklicher, das deine Redaktion ohne Schulung bedienen kann? Das ist keine Niederlage für Drupal. Es ist die ehrliche Antwort auf die Frage, die 2011 niemand gestellt hat. Und ja, das aus dem Mund eines Drupal-Entwicklers: Werkzeuge sind für Aufgaben da, nicht umgekehrt.

Option 3: Headless. Drupal bleibt, das Frontend wird frei

Der dritte Weg ist der, den ich in den letzten Jahren am spannendsten finde, weil ich selbst viel mit Next.js arbeite (einem React-Framework für schnelle, moderne Web-Frontends): der Headless-Ansatz. Dabei bleibt Drupal als Redaktionssystem im Hintergrund (dort, wo es glänzt) und liefert die Inhalte über eine Schnittstelle an ein modernes Frontend, zum Beispiel in Next.js. Die Redaktion behält ihre gewohnte Arbeitsumgebung, die Besucher bekommen eine schnelle, moderne Website, und Frontend und Backend lassen sich künftig unabhängig voneinander weiterentwickeln.

Ehrlicherweise: Das ist der anspruchsvollste der drei Wege. Du betreibst danach zwei Systeme statt einem, und das Team braucht Kompetenz auf beiden Seiten. Für die kleine Unternehmensseite aus Option 2 ist das Overkill. Interessant wird Headless, wenn Inhalte an mehrere Kanäle ausgespielt werden, wenn Performance geschäftskritisch ist oder wenn die Website ohnehin eher Plattform als Broschüre ist.

Die drei Wege noch einmal im Überblick:

Was die Kosten wirklich treibt (und warum Angebote so streuen)

Jetzt zur Frage, die hinter jeder Anfrage steht: Was kostet das? Ich werde hier keine Zahlen nennen, und zwar nicht aus Berater-Koketterie, sondern weil jede Zahl ohne Blick auf deine Seite gelogen wäre. Was ich stattdessen erklären kann: die drei Faktoren, die den Aufwand bestimmen. Wenn du die für deine Seite kennst, kannst du jedes Angebot einordnen. Und du erkennst auch, welches Angebot deine Seite offensichtlich nie angeschaut hat.

Erster Faktor: die Anzahl und Komplexität deiner Content-Typen. Zwanzig Inhaltstypen mit Dutzenden Feldern, Referenzen und Taxonomien bedeuten ein Vielfaches an Migrations- und Modellierungsarbeit gegenüber einer Seite mit fünf simplen Typen. Zweiter Faktor, und das ist fast immer der größte: Custom-Module. Jede Zeile individuell entwickelter Code aus der Drupal-7-Zeit muss gesichtet, verstanden und neu gebaut werden. Oder gestrichen, was übrigens öfter geht, als man denkt, weil manche Funktion seit Jahren niemand mehr benutzt. Dritter Faktor: Integrationen. Jede Anbindung an CRM, Shop, Newsletter-System oder Login-Verfahren ist ein eigenes kleines Projekt mit eigenem Testaufwand.

Deshalb streuen die Angebote so stark: Wer nur auf die Startseite schaut, schätzt den ersten Faktor und übersieht die beiden teuren. Und deshalb ist das billigste Angebot oft das gefährlichste, weil die übersehenen Module nicht verschwinden, sondern als Nachträge wiederkommen, mitten im Projekt und ohne Verhandlungsspielraum. Eine seriöse Schätzung für eine Drupal-7-Migration beginnt darum immer mit einer Bestandsaufnahme: Welche Inhaltstypen gibt es, welche Module sind installiert, welche davon sind custom, welche Schnittstellen existieren, und welche Funktionen nutzt eigentlich noch irgendjemand. Das ist ein überschaubarer, klar umrissener erster Schritt, und er verwandelt ein diffuses Bauchgefühl in eine belastbare Entscheidungsgrundlage für einen der drei Wege.

Nach 17 Jahren mit diesem System gebe ich offen zu: Der Abschied von Drupal 7 hat auch bei mir einen nostalgischen Stich ausgelöst (wir hatten schöne Jahre zusammen). Aber Nostalgie ist keine Sicherheitsstrategie. Wie so eine Modernisierung aussehen kann, zeigen wir auf unserer Webtechnologie-Seite.

Wenn deine Seite noch auf Drupal 7 läuft und du wissen willst, welcher der drei Wege zu dir passt, oder du Angebote auf dem Tisch hast und eine ehrliche zweite Meinung brauchst: Sprich mich an, schreib mir eine E-Mail oder ruf einfach an. Lass uns gemeinsam auf deine Seite schauen, bevor es jemand anderes ungefragt tut.