Drupal an Universitäten: Migration zu Next.js + Supabase

Harvard verwendet Drupal. Ebenso Yale, Princeton, Stanford und Duke. Ebenso Ihre Universität. Sie kennen den Upgrade-Zyklus: D7 zu D8 war ein kompletter Neuaufbau. D8 zu D9 erforderte erhebliche Arbeit. D9 zu D10 beschädigte beigetragene Module. D10 zu D11 kommt Ende 2026 mit Symfony 7 und Twig 4. Für die Kosten einer weiteren Drupal-Migration kann Ihre Universität zu Next.js + Supabase wechseln und sich nie wieder einer erzwungenen CMS-Migration stellen.

Dies ist unser bildungsspezifisches Migrationsleitfaden. Für einen allgemeinen Überblick siehe unsere Drupal-Migrationsseite. Diese Seite behandelt, was Universitäts-Drupal-Installationen einzigartig komplex macht — und wie wir jedes Teil handhaben.

Das Drupal-Ökosystem für Hochschulen

Universitäts-Drupal-Installationen sind nicht wie Corporate-Websites. Es sind ausgedehnte, Multi-Stakeholder-Systeme — bildungsspezifische Inhaltstypen, tief verschachtelte Taxonomien, Abteilungs-Subsites mit unabhängigen Bearbeitern, Integrationen mit Studenteninformationssystemen. Ein generischer Migrationsansatz wird scheitern.

Bildungsspezifische Inhaltstypen

Ihre Drupal-Instanz hat wahrscheinlich 10+ benutzerdefinierte Inhaltstypen für Hochschulen:

• Program — Informationen zu Abschlüssen, Zertifikaten und Kursen mit Kreditstunden, Gebühren, Lieferart, Karriereergebnissen
• Faculty — Profile mit Forschungsinteressen, Publikationen, unterrichteten Kursen, Sprechzeiten
• Department — hierarchische Struktur (School of Engineering → CS Department → AI Lab)
• Event — akademischer Kalender, öffentliche Veranstaltungen, Abschlussfeier, abteilungsspezifische Veranstaltungen
• News — Universitätsnews, Abteilungsnews, Forschungsankündigungen, Pressemitteilungen
• Page — Hunderte von grundlegenden Inhaltseiten (About, Admissions, Financial Aid)
• Publication — Forschungspapiere, Berichte, Richtliniendokumente mit DOI-Links
• Job Posting — Positionen für Fakultäten, Mitarbeiterpositionen, Studentenbeschäftigung
• Profile — Verzeichniseinträge für Mitarbeiter ohne Fakultäten
• Testimonial — Erfolgsgeschichten von Studierenden und Alumni

Jeder bildet eine Supabase-Tabelle mit ordnungsgemäßem Relationaldesign. Programme erhalten degree_level, subject_area_id, delivery_mode, tuition und career_outcomes als JSONB. Fakultäten erhalten einen department_id Fremdschlüssel, publications als JSONB und research_areas als Array. Abteilungen verwenden parent_id für selbstreferenzielle Hierarchie.

Dies ist keine flache Inhaltsablage. Es ist ein ordnungsgemäßes relationales Schema, das Ihre Daten auf Weise abfragbar macht, die Drupal Views nie könnten.

Drupal Views → Next.js Server Components

Universitäts-Websites verlassen sich stark auf Drupal Views für filterbare Listen. Jeder von diesen wird zu einer schnelleren, flexibleren Next.js-Seite:

• Program Finder — Drupal View Filterung nach Thema, Abschlussgrad, Campus → Next.js /programs Seite mit Supabase-Abfrage + URL-basiertem Filterzustand. Zukünftige Studierende filtern nach Interessengebiet und erhalten sofortige Ergebnisse.
• Faculty Directory — Drupal View Filterung nach Abteilung, Forschungsgebiet → Next.js /faculty Seite mit Volltextsuche und Abteilungsfilterung gegen Supabase.
• Event Calendar — Drupal View Filterung nach Datum, Abteilung, Typ → Next.js /events Seite mit Datumsbereichsfilterung und iCal-Export.
• News Feed — Drupal View Filterung nach Abteilung, Kategorie → Next.js /news Seite mit ISR, damit neue Artikel innerhalb von 60 Sekunden nach Veröffentlichung erscheinen.
• Job Board — Drupal View Filterung nach Abteilung, Beschäftigungstyp → Next.js /careers Seite, die Daten aus Supabase mit Schließungsdatum-Logik abruft.

Der Unterschied: Drupal Views generieren vollständige Seite-Ladevorgänge bei jeder Filteränderung. Next.js Server Components mit Supabase geben gefilterte Ergebnisse in unter 100ms zurück, ohne einen vollständigen Seite-Neuaufbau.

Drupal Taxonomy → Supabase Relations

Drupal-Taxonomie-Vokabulare ordnen sich Tabellen zu:

• Subject Areas Vokabular → subject_areas Tabelle, programs.subject_area_id FK
• Departments Vokabular → departments Tabelle mit parent_id für Hierarchie
• Campus Locations Vokabular → campuses Tabelle, programs.campus_id FK
• Research Areas Vokabular → research_areas Tabelle + faculty_research_areas Join-Tabelle
• Event Types Vokabular → event_type Enum-Spalte oder Nachschlagetabelle

Drupal Entity Reference-Felder werden zu ordnungsgemäßen Fremdschlüsseln. Viele-zu-viele-Beziehungen (Faculty ↔ Research Areas) erhalten Join-Tabellen. Das Datenmodell wird explizit, anstatt hinter Drupals Entity API verborgen zu sein.

Paragraphs + Layout Builder → Component Blocks

Drupal Paragraphs sind der größte Schmerzpunkt bei Universitätmigrationen. Ihre Redaktion hat Seiten mit Dutzenden von Paragraph-Typen erstellt: Hero-Banner, Statistik-Abschnitte, Fakultäts-Spotlight, Programmkarten-Gitter, Accordion-FAQs, eingebettete Videos, Call-to-Action-Blöcke.

Wir speichern diese als JSONB in Supabase's pages.blocks Spalte:

[
  {"type": "hero", "title": "...", "subtitle": "...", "image": "...", "cta_url": "..."},
  {"type": "stats", "items": [{"number": "15:1", "label": "Student-Faculty Ratio"}]},
  {"type": "program_cards", "program_ids": [12, 45, 78]},
  {"type": "faculty_spotlight", "faculty_id": 234}
]

Eine Next.js-Komponenten-Registry rendert jeden Block-Typ. Redakteure verwalten Blöcke über Payload CMS oder ein benutzerdefiniertes Admin-Interface. Gleiche Flexibilität wie Paragraphs, schnelleres Rendering und kein Drupal-Cache-Rebuild-Warten.

Multi-Site Department Subsites

Große Universitäten betreiben 15–30 Drupal-Subsites — School of Business, School of Engineering, College of Arts & Sciences — jede auf separaten Drupal-Installationen oder Drupal multisite. Dies ist ein operativer Alptraum: Modul-Updates über 20 Websites, inkonsistentes Theming, duplizierte Infrastruktur.

Wir konsolidieren alles in einer Next.js-Anwendung mit /departments/[slug] Routes. Jede Abteilung erhält ihren eigenen Abschnitt mit Sub-Brand-Identität (benutzerdefinierte Akzentfarben innerhalb des Universitätsdesign-Systems). Abteilungsseiten, News, Veranstaltungen und Fakultäten begrenzen sich alle auf ihre Abteilung.

Der Schlüssel: Supabase Row Level Security (RLS). Abteilungsredakteure sehen und bearbeiten nur Inhalte, wo department_id ihrer zugewiesenen Abteilung entspricht. Der Redakteur der School of Business kann versehentlich keine Engineering-Inhalte bearbeiten. RLS erzwingt dies auf der Datenbankebene — nicht im Anwendungscode, nicht in CMS-Berechtigungen. Es ist strukturell.

Student Portal und SSO-Integration

Ihre aktuelle Drupal-Website authentifiziert Studierenden über CAS oder Shibboleth und verbindet sich mit Ihrem Identitätsanbieter (ADFS, Okta oder ein universitätsverwalteter Shibboleth IdP). Studierenden sehen personalisierte Inhalte: ihre Programmziele, Beraterinformationen, abteilungsspezifische Ressourcen.

Supabase Auth unterstützt SAML 2.0 nativ. Wir konfigurieren den Identitätsanbieter Ihrer Universität als SAML-Anbieter in Supabase. Der Ablauf:

1. Studierender klickt "Sign In" auf der Next.js-Website
2. Umleitung zu Universität IdP (Shibboleth/ADFS/Okta)
3. Studierender authentifiziert mit Universitätsanmeldedaten
4. IdP sendet SAML-Assertion zurück zu Supabase
5. Supabase gibt einen JWT mit der Rolle und Abteilung des Studierenden aus
6. RLS-Richtlinien kontrollieren, welche Daten sie sehen

Kein benutzerdefinierter Authentifizierungscode. Keine Session-Management-Kopfschmerzen. Der JWT trägt Claims, und Supabase RLS liest sie.

User Role Migration

Drupal-Rollen an Universitäten — Site Admin, Web Editor, Department Editor, Faculty, Student, Alumni — mappen zu einer user_roles Tabelle in Supabase mit Pro-Benutzer-Rollenzuweisungen. RLS-Richtlinien referenzieren diese Rollen:

• Site Admin: vollständiges Lesen/Schreiben auf allen Tabellen
• Department Editor: Lesen/Schreiben wo department_id = auth.jwt()->department_id
• Faculty: aktualisiere ihr eigenes Profil, füge Publikationen hinzu
• Student: schreibgeschützt auf öffentliche Inhalte, personalisiertes Dashboard-Daten

Die 7-Phasen-Bildungsmigration

Phase 1: Discovery und Content Audit (1–2 Wochen)

Screaming Frog Crawl aller URLs. Google Search Console Traffic-Analyse zur Identifizierung Ihrer wertvollsten Seiten. Inhaltstyp-Inventar über alle Subsites. Integrations-Audit: Was verbindet sich mit Drupal? Banner? PeopleSoft? Canvas? Slate? Barrierefreiheit-Baseline mit Lighthouse-Scores und etwaigen vorhandenen ADA-Beschwerde.

Phase 2: Architektur und Schema-Design (1 Woche)

Supabase-Schema mit Tabellen, Beziehungen und RLS-Richtlinien. Next.js Route-Struktur. Navigationshierarchie. Entscheidung über Admin-Interface: Payload CMS für nicht-technische Redakteure oder ein benutzerdefiniertes Supabase-Dashboard. Integrationsarchitektur für SSO, SIS-Datenabrufe und CRM-Webhooks.

Phase 3: Datenexport aus Drupal (1–2 Wochen)

D8/D9/D10: JSON:API Export via /jsonapi/node/program?page[limit]=50, paginiert durch jeden Inhaltstyp. D7: direkte MySQL-Abfragen gegen Drupals Feldtabellen. Medien-Export aus public:// und private:// Dateisystemen. Benutzer- und Taxonomie-Exporte. Menüstruktur-Extraktion.

Phase 4: Build (3–8 Wochen)

Next.js-Anwendung mit allen Seiten-Templates. Supabase-Tabellen mit transformierten Daten und aktive RLS-Richtlinien gefüllt. Program Finder mit facettierten Filtern. Fakultätsverzeichnis mit Suche. Abteilungsabschnitte. Student Portal mit SSO. Admin-Interface. Alle Integrationen — SIS-Datenabrufe, CRM-Webhooks, Campus-Tour-Buchung.

Phase 5: Content Import und Validierung (1–2 Wochen)

Drupal-Exporte zu Supabase-Insert-Scripts transformieren. Alle Inhaltstypen importieren. Medien zu Supabase Storage oder Vercel Blob hochladen. Medien-URLs in Inhalten umschreiben. Stichprobe 10% von jedem Inhaltstyp. Jede Filter-, Such- und Navigationspfad testen.

Phase 6: Redirect Mapping (1 Woche)

Dies ist kritisch für Universitäten. Ihre .edu-Domain hat Tausende von Backlinks von anderen Bildungsinstitutionen, Regierungswebsites und Forschungsdatenbanken. Diese Backlinks zu verlieren ist katastrophal für SEO-Autorität. Wir mappen jede Drupal-URL — Aliase, Systempfade (/node/1234) und Subsite-URLs — zu neuen Next.js Routes. Implementiert via Next.js Middleware für unbegrenzte Redirect-Kapazität.

Phase 7: Launch und Monitoring (laufend)

DNS-Cutover. Neue Sitemap-Einreichung zu Google Search Console. Tägliche 404-Überwachung für die ersten 30 Tage. Schulung des Personals für Payload CMS oder benutzerdefiniertes Admin. Schulung des Abteilungs-Admin. Schulung des Fakultäts-Selbstaktualisierungs-Workflows. 30-Tage-Hypercare mit täglicher Überwachung und wöchentlichen Check-ins mit Ihrem Web-Team.

Preisgestaltung

Institutionstyp	Seiten	Umfang	Zeitrahmen	Investment
Community College	Unter 500	Program Finder, grundlegendes Verzeichnis, News	6–8 Wochen	50–80K €
Mid-Size University	500–2.000	Program Finder, Fakultätsverzeichnis, Abteilungsabschnitte, Veranstaltungen	8–12 Wochen	80–150K €
Large University	2.000+	Multi-Campus, Abteilungs-Subsites, Student Portal, SSO, i18n	10–16 Wochen	120–200K €

Warum jetzt: Die D11 Uhr tickt

Drupal 11 kommt Ende 2026 mit Symfony 7 und Twig 4. Universitäten auf D10 sehen sich der Migrationsentscheidung in den nächsten 6–12 Monaten gegenüber. Eine D10-zu-D11-Migration kostet mindestens 30–60K € — und Sie sehen D12 in weiteren 3–4 Jahren.

Eine Next.js + Supabase-Migration kostet 50–200K € je nach Umfang, aber die Gesamtbetriebskosten über 5 Jahre sind niedriger als das Verbleiben bei Drupal. Keine erzwungenen Upgrades. Keine beigetragenen Modulfehler. Keine Drupal-Sicherheitshinweise, die Notfall-Patches erfordern. Ihr Framework wird nach Ihrem Zeitplan aktualisiert, nicht Drupals.

Für die Kosten einer weiteren Drupal-Migration, machen Sie sie zu Ihrer letzten.