Weg von Drupal Multisite: Den richtigen Pfad nach Drupal 7 wählen und Websites geordnet umziehen

Ein praxisnaher Leitfaden für Teams, die viele Websites auf Drupal Multisite betreiben: die drei realistischen Optionen nach dem Ende von Drupal 7, wie Sie Inhaltstypen, Views und Module pro Website prüfen, ein Bewertungsbogen dafür, welche Websites Drupal rechtfertigen, und ein Umstellungsplan, der URLs und Aufzeichnungen erhält.

Drupal Multisite findet sich vor allem an Hochschulen, in Behörden und großen Verbänden, wo ein fähiges Team es einst eingerichtet hat, um Dutzende Abteilungswebsites aus einer Codebasis zu bedienen. Inzwischen hat sich das Team verändert, die Websites haben sich vervielfacht, und viele Netzwerke laufen noch auf Drupal 7, dessen Sicherheitsunterstützung durch die Community am 5. Januar 2025 endete. Was auch immer Sie hierhergeführt hat, die Frage ist dieselbe: Welche dieser Websites brauchen wirklich Drupal, und was ist der risikoärmste Weg, den Rest umzuziehen? Dieser Leitfaden arbeitet diese Entscheidung durch und danach den Umzug selbst.

Wie Drupal Multisite aufgebaut ist

Die Drupal-Dokumentation beschreibt Multisite als den Betrieb separater, unabhängiger Websites aus einer Codebasis, jede mit eigener Datenbank, Konfiguration, eigenen Dateien und eigener Domain. Auf der Festplatte hat jede Website einen eigenen Ordner im sites-Verzeichnis, der mindestens ihre Dateien und manchmal eigene Module und Themes enthält. Zwei Folgen prägen jede Migration:

Gemeinsamer Code, getrennte Daten. Ein Core- oder Modul-Update erreicht alle Websites gleichzeitig, was der ursprüngliche Reiz und das Hauptrisiko ist. Ein Modul, von dem eine Website abhängt, lässt sich nicht entfernen, ohne alle anderen zu prüfen.
Jede Website ist eine eigene Migration. Da jede Website eine eigene Datenbank und Konfiguration hat, gibt es keinen einzelnen "Netzwerk-Export". Sie planen, ziehen um und testen Website für Website.

Ihre drei Optionen, ehrlich verglichen

Option	Was dazugehört	Am besten für	Hauptkosten
Umstieg auf aktuelles Drupal	Neue Websites auf aktuellem Drupal bauen und Inhalte mit der Migrate API von Drupal übernehmen. Von Drupal 7 aus ist das ein Neubau mit Migration, kein Update an Ort und Stelle.	Websites mit komplexen Inhaltsmodellen, intensiver Nutzung von Views, eigenen Modulen, Integrationen oder einem Team, das Drupal gut kennt	Entwicklerzeit pro Website und laufende Drupal-Wartung
Kostenpflichtiger erweiterter Support für Drupal 7	Drupal 7 weiterbetreiben, mit Sicherheitsupdates von einem Anbieter im Extended Security Support Provider Program der Drupal Association (derzeit HeroDevs und Tag1 Consulting)	Zeit gewinnen, während eine Migration geplant und finanziert wird	Eine wiederkehrende Gebühr, und die Migration liegt weiterhin vor Ihnen
Wechsel auf eine andere Plattform	Websites auf einem anderen CMS oder Website-Builder neu bauen	Broschüren-, Informations-, Veranstaltungs- und Abteilungswebsites mit einfachen Inhalten	Neubau jeder Website; Verlust von Drupal-spezifischen Funktionen, die Sie tatsächlich genutzt haben

Die meisten großen Netzwerke landen bei einer Mischung: Eine Handvoll komplexer Websites bleibt auf Drupal, der lange Rest wechselt auf etwas Einfacheres, und einige werden stillgelegt. Die Arbeit besteht darin, zu entscheiden, welche Website wohin geht.

Prüfen Sie das Inhaltsmodell jeder Website

Drupal-Websites unterscheiden sich weit stärker voneinander als WordPress-Websites, weil Inhaltstypen, Felder und Views pro Website gebaut werden. Bevor Sie etwas bewerten, halten Sie fest, was jede Website tatsächlich nutzt. Ein Drupal-Entwickler kann das meiste aus den Admin-Bildschirmen oder mit Drush auslesen; es geht darum, alles in einer Tabelle zu erfassen.

Element	Was zu erfassen ist	Warum es wichtig ist
Inhaltstypen	Jeder Typ, Anzahl der Einträge, letzter erstellter Eintrag	Viele Typen mit wenigen Einträgen deuten auf Überbau hin; ein Typ mit 5,000 Einträgen braucht eine skriptgestützte Migration
Felder	Referenzfelder, Field Collections oder Paragraphs, Dateifelder	Strukturierte Beziehungen sind am schwersten auf eine einfachere Plattform zu übertragen
Taxonomien	Vokabulare und wie sie Navigation oder Filter steuern	Gefilterte Listen brauchen auf der neuen Plattform eine Entsprechung
Views	Jede View, wo sie erscheint, ob sie Nutzern Filter anbietet	Öffentliche Filter (ein Personalverzeichnis, eine Kurssuche) sind oft der Grund, warum eine Website existiert
Formulare	Webforms, ihre Einsendungen, Aufbewahrungspflichten	Einsendungen können Aufzeichnungen sein, die Sie aufbewahren müssen
Benutzer und Rollen	Redakteure, Mitglieder, öffentliche Konten	Passwörter lassen sich in der Regel nicht auf eine andere Plattform übertragen
Eigene und Community-Module	Was jedes für diese Website leistet	Jedes ist entweder eine nachzubauende Funktion oder eine wegfallende Abhängigkeit
Integrationen	Single Sign-on, Studierenden- oder Mitgliedersysteme, Zahlung, Suche	Sie entscheiden meist, ob eine Website Drupal verlassen kann
Traffic und Links	Besuche in 12 Monaten, wichtigste Einstiegsseiten, Seiten mit externen Links	Bestimmt den Aufwand für Weiterleitungen

Bewerten Sie, welche Websites Drupal rechtfertigen

Geben Sie jeder Website einen Punkt für jedes "Ja" unten. Die Schwelle legen Sie selbst fest, aber in der Praxis gehören Websites mit drei oder mehr Punkten meist auf aktuelles Drupal oder ein anderes vollwertiges CMS, und Websites mit null oder einem Punkt sind gute Kandidaten für einen einfacheren Builder.

Hat strukturierte Inhalte, die andere Seiten abfragen (ein Verzeichnis, ein Katalog, eine Kurs- oder Personensuche).
Hat Filter oder Suche für Nutzer, die über eine einfache Website-Suche hinausgehen.
Hängt von einem eigenen Modul ab, das echte Arbeit leistet.
Ist mit einem internen führenden System integriert.
Hat eingeloggte Nutzer außer Redakteuren.
Hat ein Redaktionsteam, das mehrere Rollen und gestufte Prüfung braucht.
Hat mehr als ein paar hundert aktiv gepflegte Seiten.

Bewerten Sie die Websites gemeinsam mit ihren Verantwortlichen. Sie wissen oft, dass sich die aufwendige View auf ihrer Startseite seit Jahren niemand angesehen hat, und ebenso oft kennen sie eine Abhängigkeit, an die sich sonst niemand erinnert.

Die Websites umziehen, die gehen

Inhalte

Bei einfachen Websites ist der schnellste Weg meist eine strukturierte Kopie: Crawlen Sie die Live-Website, um jede Seite und ihre URL zu erfassen, und bauen Sie dann Seite für Seite neu auf, wobei Sie gleich überarbeiten. Bei Websites mit Hunderten Einträgen desselben Typs (News, Veranstaltungen) exportieren Sie diese als CSV oder JSON, mit Hilfe eines Entwicklers oder über Views Data Export, und importieren sie, wo die neue Plattform es erlaubt, oder Sie entscheiden, dass nur die letzten zwei Jahre umziehen und der Rest archiviert wird.

Dateien

Kopieren Sie den Dateiordner jeder Website. Prüfen Sie auf private Dateien (Drupal kann Dateien außerhalb des öffentlichen Ordners ausliefern), die oft Dokumente enthalten, die zugangsbeschränkt bleiben müssen; sie brauchen eine bewusste Entscheidung, keinen Massen-Upload auf eine öffentliche Website.

Aufzeichnungen

Behörden und Hochschulen haben oft Aufbewahrungspflichten für Webinhalte und Formulareinsendungen. Bevor Sie etwas abschalten, exportieren Sie, was Sie aufbewahren müssen, legen Sie es in Ihrem Archivsystem ab und notieren Sie, wo es gelandet ist. Eine statische Archivkopie der alten Website, offline aufbewahrt, ist eine günstige Versicherung.

Adressen

Erstellen Sie pro Website eine Weiterleitungstabelle: alter Pfad, neue Adresse, permanente Weiterleitung. Drupal-Websites haben oft sowohl einen Systempfad (node/123) als auch einen Alias; nehmen Sie bei Seiten mit Traffic beide auf. Wenn Websites auf neue Domains umziehen, behalten Sie die alten Domains und Weiterleitungen viele Monate lang bei.

Eine Umstellungsreihenfolge, die Schäden begrenzt

Phase	Websites	Ziel
1. Stilllegen	Ohne Verantwortliche, ohne Traffic	Archivieren, weiterleiten, entfernen. Verkleinert sofort das Netzwerk und die Angriffsfläche.
2. Pilot	Zwei oder drei einfache Websites mit engagierten Verantwortlichen	Prozess, Templates und Weiterleitungsmethode erproben.
3. Langer Rest	Übrige Websites mit niedriger Punktzahl, in Wellen nach Verantwortlichen	Den Großteil umziehen, solange der Prozess frisch ist.
4. Komplex	Websites mit hoher Punktzahl	Mit ausreichender Entwicklungszeit auf aktuelles Drupal oder ein anderes vollwertiges CMS migrieren.
5. Abschalten	Die alte Installation	Erst wenn nichts mehr davon abhängt, auch keine Weiterleitungen.

Zuerst stillzulegen klingt verkehrt herum, funktioniert aber: Jede Website, die aus dem alten Netzwerk verschwindet, ist eine Website weniger, die ungeschützt bleibt, während Sie den Rest abarbeiten.

Governance für die neue Struktur

Das alte Netzwerk hatte vermutlich einen einzigen technischen Torwächter. Die neue Struktur sollte diesen Engpass nicht wiederherstellen, aber auch nicht jeder Abteilung einen ungeprüften Veröffentlichen-Button geben. Legen Sie vor dem Umzug der ersten Website fest, wem jede Website gehört, wer veröffentlichen darf, welche Websites eine Freigabe vor dem Livegang brauchen und wer Funktionen wie Formulare oder einen Shop hinzufügen darf. Unsere Vorlage für eine Website-Governance-Richtlinie und der Leitfaden zum Freigabe-Workflow für Inhalte behandeln das.

Wo We.Inc passt und wo nicht

We.Inc ist ein White-Label-Website-Builder für Organisationen, die viele Websites unter einer Marke betreiben. Er passt zu den Websites mit niedriger Punktzahl in Ihrer Tabelle, nicht zu denen mit hoher. Es gibt keinen Drupal-Importer, keine Entsprechung zu Views mit öffentlichen Filtern und keine eigenen Inhaltstypen; Websites werden mit KI aus Templates oder einer Beschreibung neu gebaut und dann von Ihrem Team geprüft. Was er für den langen Rest bietet:

Eine Marke (Logo, Farben, Schriften), angewendet auf jede Website, mit jeder Abteilung als Kunde dieser Marke.
Markenweite Standards dafür, was Websites können, pro Website überschreibbar, einschließlich einer einstufigen Freigabe, bevor eine Website live geht.
Eigene Domains pro Website und Weiterleitungsregeln in den SEO-Einstellungen jeder Website.
Code-Download als ZIP oder Export nach GitHub, damit die umgezogenen Inhalte nie gefangen sind.

Die Marke wird einmal festgelegt und auf jede Abteilungswebsite angewendet, statt über ein gemeinsames Theme durchgesetzt zu werden.

Markenweite Standardschalter mit der Überschrift Was Ihre Kunden tun dürfen, über einer Teamliste — Standards legen fest, was jede neue Website darf, und ersetzen das Aktivieren Modul für Modul.

Eine Liste Wartet auf Ihre Freigabe mit einer Website und Buttons zum Freigeben und Veröffentlichen oder zum Anfordern von Änderungen — Einstufige Freigabe, bevor eine Website live geht, für Abteilungen, die eine Kontrolle brauchen. Die wartende Anfrage auf dieser Demo-Marke wurde für den Screenshot inszeniert.

Ein Dialog Projekt exportieren mit den Tabs GitHub, ZIP, Vercel und Domain und einer Option für ein privates Repository — Jede Website lässt sich in ein GitHub-Repository exportieren oder als ZIP herunterladen.

Barrierefreiheit entsteht nicht automatisch: Mit KI gebaute Seiten müssen vor dem Launch von Ihrem Team getestet werden, besonders bei Behörden unter ADA Title II (siehe unseren Leitfaden zur Title-II-Frist). Wenn Ihre Audit-Tabelle einen langen Rest einfacher Websites zeigt, vereinbaren Sie eine Demo und bringen Sie sie mit. Für den breiteren Vergleich lesen Sie White-Label-Builder versus Enterprise-CMS; wenn ein Teil Ihres Bestands auf WordPress läuft, siehe Weg von WordPress Multisite.

Quellen

Zuletzt geprüft am 2026-10-25.

Drupal.org, Drupal 7 End of Life (Ende der Sicherheitsunterstützung, Extended Security Support Provider Program).
Drupal.org, Multisite Drupal.
Drupal.org, Multisite folder structure in Drupal.
Drupal.org, Upgrading Drupal (Migrate API).

Häufige Fragen

Wann hat Drupal 7 sein Lebensende erreicht?

Laut Drupal.org endete die Sicherheitsunterstützung für Drupal 7 am 5. Januar 2025. Kostenpflichtiger erweiterter Sicherheitssupport ist bei Anbietern im Extended Security Support Provider Program der Drupal Association erhältlich.

Kann ich Drupal 7 Multisite an Ort und Stelle aktualisieren?

Nicht im üblichen Sinne. Der Wechsel von Drupal 7 auf eine aktuelle Version bedeutet, neue Websites zu bauen und Inhalte zu migrieren, typischerweise mit der Migrate API von Drupal, Website für Website, weil jede Website eine eigene Datenbank hat.

Welche Drupal-Websites sollten auf Drupal bleiben?

Websites mit strukturierten Inhalten, die andere Seiten abfragen, öffentlichen Filtern, eigenen Modulen mit echter Funktion, Integrationen mit internen Systemen, eingeloggten Nutzern, Redaktionsteams mit mehreren Rollen oder vielen aktiv gepflegten Seiten. Einfache Informationswebsites sind gute Kandidaten für eine einfachere Plattform.

In welcher Reihenfolge sollten Websites migriert werden?

Legen Sie zuerst Websites ohne Verantwortliche oder Traffic still, pilotieren Sie dann zwei oder drei einfache Websites, ziehen Sie den langen Rest in Wellen um, migrieren Sie komplexe Websites mit ausreichender Entwicklungszeit und schalten Sie die alte Installation erst ab, wenn nichts mehr davon abhängt.

Kann We.Inc Drupal-Websites importieren?

Nein. Es gibt keinen Drupal-Importer, und We.Inc hat keine eigenen Inhaltstypen oder gefilterten Listen im Stil von Views. Es eignet sich für einfache Abteilungs- und Informationswebsites, die aus Templates neu gebaut und von Ihrem Team geprüft werden.