Eine Drupal-Migration ist eines jener Projekte, die bequem in der Planung des nächsten Quartals bleiben, bis ein Datum sie dringend macht. Zwei Daten tun das gerade, und nur eines davon liegt in der Zukunft.

Drupal 7 verlor am 5. Januar 2025 den offiziellen Support. Jede Website, die noch darauf läuft, ist seit weit über einem Jahr ohne Sicherheitsabdeckung unterwegs. Drupal 10 erreicht am 9. Dezember 2026 sein Support-Ende, in derselben Woche, in der Drupal 12 erscheint, und erhält danach keinerlei Releases mehr. Wenn Sie auf einer dieser Versionen sind, lautet die Frage nicht mehr ob, sondern welcher Weg und zu welchen Kosten.

Wo Sie stehen: Von Drupal 10 auf Drupal 11 ist ein echtes Upgrade — dieselbe Website, an Ort und Stelle aktualisiert, typischerweise zwei bis sechs Wochen. Von Drupal 7 auf Drupal 11 ist überhaupt kein Upgrade, sondern ein Neubau mit angehängter Inhaltsmigration, typischerweise drei bis sechs Monate. Diese beiden zu verwechseln ist der teuerste Fehler in diesem Bereich, weil Drupal-7-Websites als Upgrade kalkuliert und dann um das Vierfache überzogen werden.

Zwei sehr unterschiedliche Migrationen

Das Wort Migration umfasst zwei Aufgaben, die außer dem Namen kaum etwas gemeinsam haben.

Drupal 10 auf 11 ist ein Upgrade. Die Architektur bleibt gleich. Ihre Entities, Felder, Views und Konfiguration wandern mit. Die Arbeit besteht überwiegend aus Abhängigkeitsverwaltung: sicherstellen, dass jedes Contrib-Modul ein für Drupal 11 kompatibles Release hat, veraltete API-Aufrufe aus Ihrem eigenen Code entfernen und auf eine unterstützte PHP-Version wechseln. Das ist methodisch statt schwierig, und eine gut gepflegte Website ist in vierzehn Tagen erledigt.

Drupal 7 auf Drupal 11 ist ein Neubau. Drupal 8 hat die Plattform auf Symfony-Komponenten neu geschrieben und dabei Modul-API, Theming-Schicht und Konfigurationssystem ersetzt. Nichts wandert automatisch mit außer Inhalten, und selbst diese kommen über einen eigens gebauten Migrationsprozess statt über ein Upgrade-Skript. Ihre Module existieren nicht mehr, Ihr Theme muss in Twig neu geschrieben und Ihr eigener Code gegen eine andere Architektur neu umgesetzt werden.

Genau deshalb haben Drupal-7-Websites so lange durchgehalten. Ehrlich formuliert: Sie aktualisieren keine Website, Sie bauen eine neue und bringen die Inhalte mit.

Drupal-Migration: was jeder Weg kostet

Die folgenden Zahlen gehen von Agentursätzen und einer Website mittlerer Komplexität aus. Komplexität meint hier die Zahl der Inhaltstypen, Contrib-Module und eigenen Module, nicht die Zahl der Seiten.

Drupal 10 auf 11, gut gepflegte Website. Zwei bis vier Wochen, grob 6.000 bis 15.000 Pfund. Das ist der günstige Fall: Module sind aktuell, eigener Code ist überschaubar, und die Hauptarbeit ist das Testen.

Drupal 10 auf 11, vernachlässigte Website. Vier bis acht Wochen, grob 15.000 bis 35.000 Pfund. Hier blockieren Contrib-Module ohne Drupal-11-Release, eigener Code gegen inzwischen entfernte APIs und eine PHP-Version, die ebenfalls wechseln muss. Jedes verwaiste Modul wird zur Entscheidung: Ersatz suchen, Wartung übernehmen oder Verhalten neu implementieren.

Drupal 7 auf Drupal 11. Drei bis sechs Monate, üblicherweise 40.000 bis 120.000 Pfund und mehr bei großen oder stark angepassten Websites. Diese Spanne ist breit, weil es in Wahrheit ein Neubaubudget ist. Die Inhaltsmigration selbst ist oft die kleinere Hälfte; Theme, eigene Funktionalität und Integrationen sind die größere.

Drupal 7 auf eine andere Plattform. Manchmal die richtige Antwort. Wenn der ursprüngliche Grund für Drupal nicht mehr gilt, weil die Website inzwischen eine gewöhnliche Marketingseite mit Blog ist, kann ein Wechsel weniger kosten als eine Migration innerhalb von Drupal und die Betriebskosten dauerhaft senken. Unser Vergleich von WordPress und individueller Webentwicklung behandelt, wo diese Grenze verläuft, und der Leitfaden zur Drupal-Webentwicklung ist ehrlich dazu, wann Drupal nicht die Antwort ist.

Warum Contrib-Module Ihren Zeitplan bestimmen

Fast jede Drupal-Upgrade-Schätzung steht und fällt mit dem Contrib-Audit, und das ist das Erste, was sich lohnt.

Listen Sie jedes eingesetzte Contrib-Modul auf und prüfen Sie für jedes, ob ein stabiles Release für Ihre Zielversion existiert. Was Sie finden, fällt in vier Gruppen. Manche haben ein kompatibles Release und brauchen nichts. Manche haben einen Release-Kandidaten oder einen Patch in der Issue-Queue, den Sie über Composer anwenden können. Manche sind verwaist, und Sie müssen Ersatz finden, das Modul selbst übernehmen oder seine Funktion durch eigenen Code ersetzen. Und manche wurden in den Core aufgenommen, was die angenehme Überraschung der Übung ist.

Dieses Audit verwandelt ein vages Projekt in ein zählbares. Bis es vorliegt, ist jedes Angebot eine Vermutung, und ein Anbieter, der Ihnen ohne dieses Audit einen Festpreis nennt, kalkuliert entweder stark auf und oder wird gleich Änderungsanträge stellen.

Dieselbe Logik gilt für eigene Module, mit anderem Werkzeug. Drupals Deprecation-Tooling durchsucht eigenen Code und meldet Aufrufe von APIs, die entfernt wurden oder zur Entfernung anstehen, was aus „wir haben etwas eigenen Code" eine konkrete Liste aus Dateien und Zeilennummern macht.

Was tatsächlich schiefgeht

Bestimmte Fehlerbilder wiederholen sich in nahezu jeder Drupal-Migration.

Konfigurationsdrift zwischen Umgebungen. Wurden Änderungen direkt in der Produktionsoberfläche statt über exportierte Konfigurationsdateien vorgenommen, ist Ihre Staging-Umgebung keine getreue Kopie und Ihr Testen weniger wert, als Sie denken. Das mitten in der Migration zu entdecken, ist häufig und kostet immer Zeit.

Inhalte, die nie so strukturiert waren, wie alle glaubten. Drupal-7-Websites haben oft Inhalte auf undokumentierte Weise angesammelt: zweckentfremdete Felder, ein Taxonomie-Vokabular in der Rolle eines Workflow-Status, eingefügtes HTML mit Inline-Styles im Body. Eine Migration bringt all das auf einmal ans Licht, und jeder Fall braucht eine Entscheidung von jemandem, der weiß, wozu der Inhalt dient.

Medien- und Dateiverwaltung. Drupals Medienverwaltung hat sich nach Drupal 7 erheblich geändert. Dateien, Bildstile und eingebettete Medien lassen sich selten eins zu eins abbilden, und Websites mit großen Mediatheken sollten dafür gezielt Budget einplanen, statt anzunehmen, es komme mit der Inhaltsmigration gratis mit.

URL- und SEO-Kontinuität. Das ist der Punkt, der dem Geschäft schadet und nicht dem Zeitplan. Ändern sich URL-Aliase ohne Weiterleitungen, verlieren Sie die Rankings, die die alte Website erarbeitet hat. Jede Migration braucht ein vollständiges URL-Inventar, eine Weiterleitungskarte und eine Überprüfung nach dem Livegang. Unser Leitfaden zur Website-Migration ohne Traffic-Verlust beschreibt diesen Prozess im Detail, und er gilt für Plattformwechsel genauso wie für Domainwechsel.

Mehrsprachige Inhalte. Läuft die Website in mehreren Sprachen, dauert die Migration deutlich länger. Die Sprachverwaltung wurde nach Drupal 7 neu gebaut, und übersetzte Inhalte, übersetzte Konfiguration und sprachspezifische URL-Muster brauchen jeweils eigene Aufmerksamkeit.

Wie Sie die Arbeit sequenzieren

Die Reihenfolge zählt mehr, als die meisten Teams erwarten, und eine falsche verursacht Nacharbeit.

Beginnen Sie mit dem Contrib- und Code-Audit, vor jeder Schätzung. Bringen Sie die Website dann auf eine unterstützte PHP-Version und das aktuellste Release ihrer bestehenden Hauptversion, weil das eine ganze Kategorie von Störgeräuschen aus dem eigentlichen Upgrade entfernt. Erst danach gehen Sie den Hauptversionsschritt an.

Bauen Sie die neue Umgebung neben der alten auf, statt an Ort und Stelle zu aktualisieren. So haben Sie einen Ort, an dem Sie die Inhaltsmigration wiederholt testen können, und das werden Sie brauchen, denn Migrationen laufen viele Male, bevor sie einmal echt laufen.

Behandeln Sie die Inhaltsmigration wie Code. Drupals Migrations-Framework erlaubt es, Migrationen in Konfiguration zu definieren und erneut auszuführen, sodass Sie zurücksetzen, die Zuordnung anpassen und neu starten können. Teams, die Inhalte stattdessen in der neuen Website von Hand korrigieren, können nicht mehr neu ausführen, und dann wird jede Inhaltsänderung in der alten Website zum manuellen Abgleich.

Planen Sie zum Schluss einen Redaktionsstopp und halten Sie ihn kurz. Lange Stopps führen dazu, dass Redakteure Sie umgehen, und genau das erzeugt die Drift, die Sie vermeiden wollten.

Sollten Sie Drupal ganz verlassen?

Eine faire Frage, die eine ehrliche statt einer defensiven Antwort verdient.

Bleiben Sie bei Drupal, wenn die Gründe für Ihre ursprüngliche Wahl fortbestehen: komplexe Inhaltsmodellierung, feingranulare Berechtigungen, Mehrsprachigkeit, aufwendige redaktionelle Workflows oder Pflichten zu Barrierefreiheit und öffentlicher Verwaltung. Darin ist Drupal weiterhin wirklich stark, und der Upgrade-Pfad von hier aus ist inzwischen stabil, mit planbarem Zwei-Jahres-Rhythmus für Hauptversionen.

Erwägen Sie einen Wechsel, wenn sich die Website von diesen Anforderungen entfernt hat. Viele Drupal-7-Seiten sind praktisch nur noch eine Marketingseite mit News und Kontaktformular. Diese innerhalb von Drupal zu migrieren bedeutet, Neubaupreise für Fähigkeiten zu zahlen, die Sie nicht mehr nutzen.

Die Entscheidung sollte am Inhaltsmodell und am redaktionellen Aufwand hängen, nicht daran, welche Plattform Ihr Entwickler bevorzugt. Wenn niemand formulieren kann, was Drupal für Sie leistet, das eine einfachere Plattform nicht könnte, ist das aufschlussreich.

Holen Sie das Audit, bevor Sie ein Angebot holen

Mecanik führt Drupal-Upgrades und -Migrationen im Rahmen unserer Webentwicklungs-Leistungen durch. Wir beginnen mit dem Contrib- und Code-Audit, weil das aus einem offenen Projekt einen festen Umfang macht und sich auch dann lohnt, wenn Sie die Arbeit anschließend anderswo vergeben.

Für Drupal-10-Websites ist es sinnvoll, den Schritt auf Drupal 11 jetzt zu planen statt im November, wenn alle anderen dasselbe tun. Für Drupal-7-Websites ist die Sicherheitslage bereits das Argument. Liegt Ihr Engpass eher bei Kapazität als bei Fachwissen, behandelt unser Leitfaden zum Beauftragen eines Drupal-Entwicklers , worauf zu achten ist.

Sagen Sie uns, auf welcher Version Sie sind und wie viele Contrib- und eigene Module die Website nutzt, und wir sagen Ihnen, welchen der oben beschriebenen Wege Sie tatsächlich vor sich haben.

Siehe auch: Legacy-PHP-Modernisierung: Leitfaden 2026 , Symfony vs Laravel 2026: Welches PHP-Framework? , Entwicklung von Medizin- und Gesundheitswebsites im UK 2026 .

Häufig gestellte Fragen

Wann endet der Support für Drupal 10? Drupal 10 erreicht am 9. Dezember 2026 sein Support-Ende, in derselben Woche, in der Drupal 12 erscheint. Danach gibt es keinerlei Releases mehr, auch keine Sicherheitsupdates, sodass jede verbleibende Website ohne Support läuft.

Was kostet eine Drupal-Migration? Ein Upgrade von Drupal 10 auf 11 kostet bei gut gepflegter Website typischerweise 6.000 bis 15.000 Pfund und steigt auf 15.000 bis 35.000 Pfund, wenn Module und eigener Code vernachlässigt wurden. Drupal 7 auf Drupal 11 ist ein Neubau mit Inhaltsmigration und liegt üblicherweise bei 40.000 bis 120.000 Pfund.

Warum ist Drupal 7 auf Drupal 11 so viel teurer? Weil es kein Upgrade ist. Drupal 8 hat die Plattform auf Symfony-Komponenten neu gebaut und Modul-API, Theming-Schicht und Konfigurationssystem ersetzt. Module müssen ersetzt, Themes in Twig neu geschrieben und eigener Code neu umgesetzt werden, während Inhalte über eine eigens gebaute Migration übernommen werden.

Wie lange dauert ein Upgrade von Drupal 10 auf 11? Zwei bis vier Wochen bei einer Website mit aktuellen Contrib-Modulen und wenig eigenem Code, vier bis acht Wochen, wenn verwaiste Module oder entfernte APIs umgangen werden müssen. Ein vorgeschaltetes Contrib-Audit macht die Schätzung verlässlich.

Kann ich stattdessen von Drupal zu WordPress migrieren? Manchmal ist das die richtige Entscheidung, besonders wenn eine Drupal-7-Website zu einer gewöhnlichen Marketingseite ohne komplexe Inhaltsmodellierung, Berechtigungen oder Mehrsprachigkeit geworden ist. Entscheiden Sie anhand von Inhaltsmodell und redaktionellem Aufwand, nicht nach Plattformvorliebe.