Migration von Drupal zu Payload: ein praktischer Leitfaden für Hochschulen und Behörden

Drupal 7 erreichte am 5. Januar 2025 das End of Life, Drupal 10 folgt im Dezember 2026. Für Institutionen, die die letzten zwei Jahre mit der Migration von D7 auf D10 verbracht haben, zeichnet sich bereits die nächste Migrationsentscheidung ab.

In dieser Lage befindet sich derzeit eine beträchtliche Zahl von Universitäten, Behörden und NGOs. Drupal hat diese Sektoren historisch dominiert: Drupals eigene Zahlen beziffern den Anteil auf 80 % der 100 weltweit führenden Universitäten. Diese Verbreitung ist verdient. Drupals Sicherheitsarchitektur, die eingebaute Multisite-Unterstützung, das feingliedrige Berechtigungsmodell und die quelloffene Lizenzierung machten es zu einer ernsthaften Wahl für Organisationen mit komplexen Anforderungen an die Content-Governance.

Warum diese Sektoren auf Drupal liefen

Drupals Berechtigungssystem ist wirklich ausgefeilt. Rollenbasierte Zugriffskontrolle mit Granularität je Inhaltstyp und je Feld, dazu konfigurierbare Publikationsabläufe, bildet gut ab, wie Universitäten und Behörden ihre Redaktionsteams strukturieren: Abteilungen verantworten ihre Inhalte eigenständig, Redakteure verfassen Entwürfe ohne Veröffentlichungsrecht, und Inhalte durchlaufen eine Freigabestufe, bevor sie live gehen. Das sind echte Anforderungen, keine Randfälle.

Multisite war eine weitere tragende Funktion. Eine Universität betreibt womöglich Dutzende Fakultätsseiten, Fachbereichsportale und Bibliothekssysteme unter einer Drupal-Installation, mit gemeinsamer Infrastruktur und einer gemeinsamen Identitätsschicht. Das zu ersetzen, ohne über die Zielarchitektur sorgfältig nachzudenken, erzeugt später Probleme.

Auch Drupals Erfolgsbilanz zählt in der Beschaffung. Behörden und Institutionen, die öffentlichen Ausschreibungen unterliegen, müssen oft belegen, dass die Technologiewahl eine dokumentierte Sicherheitsbilanz, breite Verbreitung in der Community und Präzedenzfälle in vergleichbaren Organisationen aufweist. Drupal hat all das, und das ist ein legitimer Grund, warum es so lange die Voreinstellung war.

Was End of Life tatsächlich bedeutet

EOL bedeutet nicht, dass die Website aufhört zu funktionieren. Es bedeutet, dass die Sicherheitspatches aufhören: keine neuen Kompatibilitäts-Releases für Module, keine Sicherheitshinweise der Community, keine Korrekturen für Schwachstellen, die nach dem Stichtag entdeckt werden.

Für Organisationen mit Compliance-Anforderungen (DSGVO, Barrierefreiheitsvorgaben, Datenschutzregelungen speziell für Bildungs- oder Behördenkontexte) ist der Betrieb eines nicht unterstützten CMS ein Risiko, das Prüfern auffällt und in Beschaffungsverfahren negativ bewertet wird.

Erweiterte Sicherheitssupport-Programme gibt es von Anbietern wie HeroDevs und Tag1 Consulting, aber das sind bezahlte Überbrückungen, keine langfristige Architektur.

Dass Drupal 10 im Dezember 2026 das End of Life erreicht, ist besonders für Institutionen relevant, die in den letzten zwei Jahren von D7 auf D10 migriert sind. Die Arbeit dieser Migration liegt noch nicht lange zurück, und der Zeitplan bewegt sich bereits wieder.

Die Entscheidung an der Weggabelung

Wenn eine Version das EOL erreicht, gibt es zwei realistische Wege: das Upgrade innerhalb von Drupal oder die Prüfung einer Alternative.

Das Upgrade von D10 auf D11 ist besser zu bewältigen als der Schritt von D7 auf D10. Für Drupal 10 geschriebene Module brauchen in der Regel Kompatibilitätsaktualisierungen; vollständige Neufassungen sind selten. Die Drupal Association hat den Zyklus der Hauptversionen planbarer gemacht, mit einer neuen Version etwa alle zwei Jahre. Für Organisationen, deren Teams Drupal gut kennen und deren Anwendungsfall zu Drupals Modell passt, ist der Verbleib im Drupal-Upgrade-Zyklus eine vertretbare Wahl.

Der Fall für die Prüfung einer Alternative liegt anders. Er greift, wenn die Institution gegen Drupals Architektur gearbeitet hat: wenn die Headless-Auslieferung einem System nachgerüstet wurde, das nicht dafür entworfen war, wenn das Frontend durch Drupals Theme-Schicht eingeschränkt ist, oder wenn die redaktionelle Arbeit genug Umgehungen angesammelt hat, dass das Team vor dem Veröffentlichen zurückschreckt. Für Organisationen, die API-first-Auslieferung über native Apps, KI-Abruf oder Mehrkanal-Distribution brauchen, funktioniert Drupals Headless-Modus, trägt aber einen architektonischen Überbau, den ein eigens dafür gebautes Headless-CMS nicht hat.

Wir arbeiten ausschließlich mit Payload, also sagen wir offen, wo wir stehen: Für Organisationen, die echte Headless-Auslieferung, ein Code-first-Inhaltsmodell und eine Plattform brauchen, die sie selbst hosten und vollständig besitzen können, ist Payload einen direkten Vergleich wert. Für Organisationen, deren vorrangige Anforderung der Verbleib in einem großen, beschaffungserprobten Upgrade-Pfad mit langer Community-Bilanz ist, ist Drupal 11 eine legitime Wahl, und das würden wir Ihnen vorab sagen.

Warum Payload ein glaubwürdiger Vergleich ist

Payload ist TypeScript-nativ, code-first und von Grund auf headless gebaut. Das Inhaltsmodell liegt im Code, versioniert mit der Codebasis, geprüft wie jede andere Änderung. Es gibt keine separate CMS-Konfigurationsschicht, die aus dem Takt gerät mit dem, was die Entwickler tatsächlich gebaut haben.

Inhalte werden als JSON über eine REST- und GraphQL-API gespeichert und ausgeliefert. Jede Collection und jedes Feld ist ohne separate Entkopplungsschicht erreichbar. Ein Next.js-Frontend konsumiert dieselben Daten wie eine mobile App, ein KI-Abrufsystem oder eine Integration von Dritten, weil die Inhalte nie an eine bestimmte Rendering-Schicht gebunden waren.

Payload läuft auf Node.js, verbindet sich mit PostgreSQL oder MongoDB und wird auf der Infrastruktur ausgeliefert, die die Sicherheits- und Compliance-Anforderungen einer Institution vorgeben. Kein Anbieter hält den Hosting-Vertrag oder die Daten.

WAYF hat eine Partnerschaft mit Payload auf oberster Stufe und trägt aktiv zu dessen Open Source bei. Diese Tiefe zählt bei einer Migration: Wir haben die Collections, die Zugriffskontroll-Plugins und die Multi-Tenant-Konfigurationen gebaut, die Inhaltsmodelle in Unternehmen und Institutionen verlangen.

Drupal und Payload, Begriff für Begriff

Drupal-Begriff	Entsprechung in Payload	Was der Wechsel bedeutet
Inhaltstyp (Node-Bundle)	Collection, in TypeScript definiert	Das Modell wandert in versionierten Code
Feld	Typisiertes Feld auf einer Collection	Bildet sich meist direkt ab; formatierter Langtext ist die Ausnahme
Paragraphs	Blocks-Feld	Jedes Bundle wird ein benannter Block mit eigenem Schema
Taxonomie-Vokabular	Collection, über ein Relationship-Feld referenziert	Begriffe werden Dokumente mit eigenen Feldern und URLs
Medien-Entitäten und Dateien	Upload-Collection	Payload erzeugt Ableitungen über die eigene Bildpipeline
Benutzer, Rollen und Rechte	Zugriffskontrolle auf Collections und Feldern	Wandert aus der Oberflächen-Konfiguration in Code
Views	Keine Entsprechung	Listen entstehen im Frontend gegen Payloads Abfrage-API

Paragraphs sind die engste strukturelle Entsprechung, bestehende Bundles überstehen den Wechsel also weitgehend. Die Zeile zu Views verdient genaues Lesen, und der Abschnitt weiter unten beschreibt, was an ihre Stelle tritt.

Was die Migration umfasst

Eine Migration von Drupal zu Payload läuft unabhängig von der Größe der Institution durch fünf Phasen.

Inhaltsprüfung. Vor jeder technischen Arbeit müssen die vorhandenen Inhalte katalogisiert werden: welche Inhaltstypen existieren, wie viele Nodes von jedem, welche Felder in Gebrauch sind und welche angelegt und dann liegen gelassen wurden, was eigene Module zum Inhaltsmodell beitragen und welche Inhalte überhaupt eine Migration wert sind. Große Drupal-Installationen tragen oft Inhalte aus Jahren mit sich, die veraltet oder doppelt sind oder von nirgendwo mehr verlinkt werden. Eine Migration ist eine vernünftige Gelegenheit, das zurückzulassen, statt es weiterzuschleppen.

Neuentwurf des Inhaltsmodells. Drupals Node-und-Feld-Modell lässt sich nicht direkt auf Payloads Collections abbilden. Diese Phase legt fest, wie das neue Modell aussieht: welche Drupal-Inhaltstypen zu Payload-Collections werden, wie Paragraph- und Blockstrukturen zu Payload-Blöcken oder Rich-Text-Konfigurationen übersetzt werden, wie Taxonomie-Vokabulare auf Beziehungsfelder oder Collections mit kontrolliertem Vokabular abgebildet werden. Das ist die folgenreichste Phase, denn die hier getroffenen Entscheidungen wirken sich auf jeden weiteren Schritt aus.

Datenextraktion und -transformation. Drupal stellt Inhalte über Drush, seine REST-API und JSON:API bereit. Die Daten zu extrahieren ist im Allgemeinen unkompliziert; sie so umzuformen, dass sie zum neuen Inhaltsmodell passen, ist die Stelle, an der sich die Arbeit ballt. Unstimmigkeiten bei Feldtypen, eingebettete Medienverweise, Revisionshistorien und URL-Aliasse verlangen alle ausdrückliche Entscheidungen. Ein Transformationsskript bildet Drupals Ausgabe auf Payloads Importformat ab und läuft gegen eine Staging-Umgebung, bevor umgeschaltet wird.

Neuaufbau der Zugriffskontrolle. Drupals Berechtigungsmodell ist feingliedrig und oft stark angepasst. Payload unterstützt Zugriffskontrolle auf Feld- und Collection-Ebene sowie ein vollständiges rollenbasiertes System mit der passenden Plugin-Architektur. Eine Drupal-Berechtigungsstruktur in Payload neu aufzubauen setzt voraus, das bestehende Modell zuerst zu dokumentieren, und Institutionen stellen dabei häufig fest, dass sie es nirgends schriftlich haben.

Frontend und Umschaltung. Wenn die Organisation im Zuge der Migration auf ein entkoppeltes Frontend wechselt, läuft diese Arbeit parallel zur Datenarbeit. URL-Struktur und Weiterleitungstabelle müssen vor der Umschaltung abgestimmt sein. Eine Vorlaufphase, in der beide Systeme laufen, gibt dem Team Zeit, neue Inhalte gegen alte zu prüfen und alles aufzufangen, was das Transformationsskript übersehen hat.

Bei den meisten Migrationen dauert die Phase aus Erkundung und Neuentwurf des Inhaltsmodells zwei bis drei Wochen. Der Aufbau läuft danach vier bis acht Wochen. Migrationen in Unternehmensgröße mit Entsprechungen für eigene Module, umfangreichen Integrationen oder Multisite-Konfigurationen liegen eher bei drei bis fünf Monaten.

Was Migrationen schwerer macht

Manche Drupal-Konfigurationen erweitern den Umfang auf Weisen, die von außen nicht offensichtlich sind.

Eigene Module mit komplexer Fachlogik brauchen Entsprechungen, die in Payload oder als eigene Dienste gebaut werden. Webformulare mit bedingter Logik und Einreichungsabläufen gehören zu den arbeitsintensivsten Teilen einer Migration. Paragraph-Bundles, die über Jahre durch schrittweise Ergänzungen gewachsen sind, müssen oft aufgeräumt werden, bevor sie sich sauber abbilden lassen. Multisite-Installationen verlangen früh eine Entscheidung darüber, ob Mandanten zusammengeführt, die Struktur in einem Payload-Multi-Tenant-Modell nachgebildet oder getrennte Payload-Instanzen betrieben werden.

Integrationen, die für Hochschulen und Behörden typisch sind, erweitern den Umfang ebenfalls: Campus-Management-Systeme, Werkzeuge für die Beziehungspflege zu Bürgern und Studierenden, Single-Sign-on-Anbieter, automatisierte Prüfungen der Barrierefreiheit und Übersetzungsabläufe haben jeweils Anknüpfungspunkte, die auf der neuen Plattform neu herzustellen sind. Keiner dieser Punkte ist ein Hindernis, aber sie früh sichtbar zu machen ist der Unterschied zwischen einer Migration, die pünktlich fertig wird, und einer, die überzieht.

Die Mechanik, Feld für Feld

Paragraphs. Ein Paragraph-Bundle ist eine wiederverwendbare Struktur mit eigenen Feldern, über eine Entity-Referenz an einen Node gehängt. Payloads Blocks-Feld erfüllt dieselbe Aufgabe, die meisten Bundles wandern also mit unveränderten Namen hinüber. Die Arbeit steckt im Aufräumen von Bundles, die über die Jahre gewachsen sind.

Feldtypen. Text, Zahl, Boolean, Datum und E-Mail bilden sich direkt ab. Entity-Referenzen werden zu Relationship-Feldern, Link-Felder zu einer Gruppe aus URL und Beschriftung. Formatierter Langtext braucht eine Entscheidung: Das gespeicherte HTML wird in Payloads Lexical-Format überführt, und darin eingebettete Entitäten werden zu Referenzen aufgelöst statt als Markup stehen zu bleiben. Das ist der am wenigsten vorhersehbare Teil der Transformation.

Medien und Dateien. Drupals Medien-Entitäten tragen eigene Felder und sind damit eigenständige Entitäten. In Payload werden sie zu einer Upload-Collection, Alternativtext, Bildnachweis und Lizenz wandern also mit der Datei. Migrieren Sie das Original, lassen Sie Payload die Ableitungen selbst erzeugen, lassen Sie Drupals Bildstile zurück, und behalten Sie eine Zuordnung von alter auf neue Kennung.

Taxonomie. Ein Vokabular wird eine Collection, jeder Begriff ein Dokument darin, Begriffe behalten also eigene Felder und URLs. Hierarchische Vokabulare tragen eine Selbstreferenz auf den übergeordneten Begriff.

Mehrsprachigkeit. Eine Drupal-Entity, die sowohl revisionierbar als auch übersetzbar ist, hält ihre Übersetzungen innerhalb der Revision: Eine Revision kann mehrere Sprachen tragen, und die kanonische Fassung eines Nodes ist die Standardübersetzung seiner Standardrevision. Payload arbeitet mit lokalisierten Feldern, bei denen ein Dokument alle Sprachen hält. Die Transformation liest jede Übersetzung über die Identität der Entity und den Sprachcode, schreibt sie in die passende Sprache eines einzigen Payload-Dokuments und erhält dabei den Veröffentlichungsstatus der Revision, die Sie ausgewählt haben. Was Sie aus Drupal herausbekommen, hängt von der Version und dem gewählten Weg ab: Die Kern-JSON:API handelt pro Anfrage eine einzelne Sprache aus und greift auf einen Fallback zurück, wenn eine Übersetzung fehlt. Wenn Ihr Export einen Datensatz je Sprache und Entity liefert, falten Sie diese Datensätze zu jenem Dokument zusammen. Zählen Sie die benötigten Übersetzungen ausdrücklich auf und prüfen Sie das Fallback-Verhalten, damit keine stillschweigend fehlt.

Listen, die früher Views gebaut hat. Drupal beschreibt eine View als Auflistung von Inhalten, die über das Modul Views UI in der Administrationsoberfläche erstellt und bearbeitet wird und als sortierbare Tabelle, Raster, Block, JSON oder RSS-Feed ausgegeben werden kann. Payload liefert keine entsprechende Oberfläche. Listen werden im Frontend geschrieben und über Payloads Abfragesprache gelesen, die Local API, REST API und GraphQL gemeinsam nutzen und die Operatoren für Gleichheit, Vergleich, Zeichenkettensuche, Mengenzugehörigkeit und Existenz kennt, dazu Und-/Oder-Logik, Sortierung und Seitenaufteilung. Änderungen an Listen wandern damit in die Warteschlange der Entwicklung, also zählen Sie Ihre in der Redaktion gebauten Views, bevor Sie einen Termin zusagen.

Die Weiterleitungszuordnung. Pfad-Aliase und die über Jahre gewachsene Weiterleitungstabelle müssen beide mitwandern. Exportieren Sie beide, bauen Sie die Zuordnung, bevor das Frontend fertig ist, und behalten Sie auf jedem Dokument eine Alt-Kennung, damit die Zuordnung eine Modelländerung übersteht.

Wie wir das angehen

Ein Drupal-Wechsel ist ein CMS-Replatforming. Wenn wir eine solche Migration abstecken, definieren wir das Inhaltsmodell schriftlich, bevor Code entsteht, in demselben Dokument, das den Preis und den Liefertermin festlegt. Dieses Dokument bildet Inhaltstypen auf Payload-Collections ab, legt Feldtypen und Beziehungen fest, definiert die Anforderungen an die Zugriffskontrolle und listet auf, was im Umfang enthalten ist und was nicht. Ein Meilenstein vor dem Launch gibt Ihrem Team Zeit, den Aufbau gegen die Abnahmekriterien zu prüfen, bevor umgeschaltet wird.

Wir halten eine Payload-Partnerschaft auf oberster Stufe und tragen aktiv zu deren Open Source bei. Das zählt hier, weil eine treffsichere Abschätzung bei einer Migration davon abhängt, dieselben Strukturen schon gebaut zu haben: Multi-Tenant-Konfigurationen, Zugriffskontroll-Plugins und Feldtyp-Abbildungen, die Institutionen mit komplexer Content-Governance tatsächlich brauchen.

Buchen Sie ein Gespräch. Bringen Sie den Auftrag mit, in welcher Form er auch vorliegt: eine Liste von Inhaltstypen, eine Website-Prüfung oder eine Beschreibung des Problems. Wir sagen Ihnen, ob eine Migration sinnvoll ist und wie ein vernünftiger erster Schritt aussieht.

Häufige Fragen

1. Wie lange dauert eine Migration von Drupal zu Payload?

   Erkundung und Neuentwurf des Inhaltsmodells dauern bei den meisten Projekten zwei bis drei Wochen, der Aufbau danach vier bis acht Wochen. Migrationen in Unternehmensgröße mit Entsprechungen für eigene Module, umfangreichen Integrationen oder Multisite-Konfigurationen liegen eher bei drei bis fünf Monaten.

2. Was passiert mit Paragraphs?

   Sie werden zu Blocks. Payloads Blocks-Feld nimmt mehrere benannte Blocktypen auf, jeder mit eigenem Schema, in einer Reihenfolge, die die Redaktion bestimmt. Das ist die Aufgabe, die ein Paragraph-Bundle in Drupal erfüllt. Die meisten Bundles wandern mit unveränderten Feldnamen hinüber.

3. Was passiert mit Drupals Feldtypen und Medien?

   Das meiste bildet sich direkt ab: Entity-Referenzen werden zu Relationship-Feldern, Link-Felder zu einer Gruppe aus URL und Beschriftung. Formatierter Langtext ist die Ausnahme, denn das gespeicherte HTML wird in Payloads Lexical-Format überführt. Medien-Entitäten werden zu einer Upload-Collection.

4. Was ersetzt Views?

   Nichts in der Administrationsoberfläche. Payload liefert keine Entsprechung zu Views. Listen werden im Frontend geschrieben und über Payloads Abfragesprache gelesen, die Local API, REST API und GraphQL gemeinsam nutzen. Änderungen an Listen wandern damit in die Warteschlange der Entwicklung, also zählen Sie Ihre in der Redaktion gebauten Views, bevor Sie einen Termin zusagen.

5. Wie werden Weiterleitungen behandelt?

   Pfad-Aliase und die gewachsene Weiterleitungstabelle wandern beide mit. Exportieren Sie beide, bauen Sie die Zuordnung, bevor das Frontend fertig ist, und behalten Sie auf jedem Dokument eine Alt-Kennung, damit die Zuordnung eine Modelländerung übersteht.

6. Wer betreibt die Plattform nach dem Launch?

   Sie selbst, wenn Sie möchten. Payload läuft auf Node.js und wird auf der Infrastruktur betrieben, die Ihre Sicherheits- und Compliance-Anforderungen vorgeben, sodass kein Anbieter den Hosting-Vertrag oder die Daten hält. Der Kern ist quelloffen, wird öffentlich gepflegt, ist selbst hostbar und bindet Sie an keinen Anbieter. Den Betrieb können Sie auch uns übergeben, als eigenes Mandat mit eigenem Preis.

7. Wie läuft eine Zusammenarbeit mit WAYF an?

   Ein Gespräch, das nichts kostet, danach eine kostenpflichtige Erkundung, daraus ein Festpreis. Wir definieren das Inhaltsmodell schriftlich, bevor Code entsteht, in demselben Dokument, das Preis und Liefertermin festlegt. Ein Meilenstein vor dem Launch lässt Ihr Team den Aufbau prüfen, bevor umgeschaltet wird.

Quellen

• Drupal 7 has reached end of life
• Drupal core release schedule
• Drupal for Higher Education
• endoflife.date/drupal
• Infonomic: Migrating from Drupal to Payload CMS
• Payload CMS documentation
• WAYF on Payload’s partner directory
• Drupal User Guide, Verwendung von Views
• Drupal-API, Entity-CRUD, Bearbeitung und Anzeigemodi
• Drupal JSON:API-Modul, Übersetzungen
• Payload CMS, Dokumente abfragen
• Payload CMS, Blocks-Feld