Drupal Multisite zu Next.js Monorepo Migration

Warum die Drupal-Multisite-Architektur zusammenbricht

Drupal Multisite war 2012 eine clevere Idee. Ein Codebase, gemeinsame Module, für jede Abteilung, Franchise-Filiale oder Bürostandort eine neue Subsite. Universitäten betrieben auf diese Weise 15–30 Subsites. Regierungsorganisationen gingen noch weiter.

Dann kam die Realität.

Jedes Modul-Update wird zu einer koordinierten Bereitstellung über alle Sites hinweg. Ein Sicherheits-Patch für eine Subsite bedeutet Ausfallrisiko für alle. Ihre School of Engineering möchte ein Custom-Modul, das mit dem Theme der School of Business kollidiert. Ihre Franchise in Denver benötigt andere Content-Workflows als die in Portland, aber sie teilen sich eine Datenbankkonfiguration, die echte Isolation fast unmöglich macht.

Die Architektur, die dir im ersten Jahr Zeit spart, kostet im dritten Jahr das Dreifache.

Die spezifischen Schmerzpunkte, die wir sehen

• Modul-Update-Albträume: Ein einzelner drush updb verteilt sich auf jede Subsite. Ein fehlerhafter Hook bringt 20 Sites gleichzeitig zum Absturz.
• Theming-Inkonsistenz: Gemeinsame Basis-Themes divergieren, wenn jede Site Overrides hinzufügt. Sub-Branding wird zum Krieg der CSS-Spezifität-Hacks.
• Datenbank-Kopplung: Gemeinsame Tabellen bedeuten, dass eine falsch konfigurierte Migration Daten über Tenants hinweg beschädigen kann. Wir haben das bei einem Regierungsportal mit 40+ Agentur-Sites gesehen.
• Performance-Decke: Drupals Server-seitiges PHP-Rendering erreicht bei Skalierung eine Grenze. TTFB von 1,5–2,5 Sekunden ist auf Multisite-Installationen unter Last üblich.
• Talentmangel: Drupal-Entwickler zu finden, die Multisite-Architektur, Paragraphs und Custom Entity References verstehen, wird jedes Jahr schwerer. React/Next.js-Talente sind dagegen reichlich vorhanden.
• Compliance und Sicherheit: Gemeinsame Codebases machen Site-Level Sicherheitsaudits fast unmöglich — ein Dealbreaker für Compliance-Anforderungen in Regierung und .edu.

Was Sie bekommen: Next.js Monorepo mit Tenant-Middleware und Supabase RLS

Die Zielarchitektur ersetzt Ihre gesamte Drupal Multisite mit einer einzelnen Next.js-Anwendung mit App Router, einer Monorepo-Struktur für gemeinsamen und mandantenspezifischen Code, Middleware für Routing und Authentifizierung, sowie Supabase mit Row Level Security für echte Datenisolation.

Wie Tenant-Middleware funktioniert

Next.js Middleware fängt jeden Request ab, bevor er Ihre Pages erreicht. Für eine Universität sieht das so aus:

/departments/engineering → tenant: engineering
/departments/business → tenant: business
/locations/denver → tenant: denver-franchise

Die Middleware extrahiert den Tenant-Slug, setzt den Supabase RLS-Kontext, und die Page wird nur mit Daten dieses Tenants gerendert. Keine gemeinsamen Datenbankabfragen, die über Abteilungen hinweg durchsickern. Keine separaten Bereitstellungen pro Site.

Ihre middleware.ts erkennt den Tenant vom URL-Pfad oder der Subdomain, setzt einen app.current_tenant-Parameter in der Supabase-Session, und jede nachfolgende Abfrage wird automatisch auf die Daten dieses Tenants beschränkt.

Supabase Row Level Security: Echte Datenisolation

Jede Tabelle — programs, faculty, events, news, pages — erhält eine tenant_id-Spalte. RLS-Richtlinien erzwingen Isolation auf Datenbankebene:

CREATE POLICY "tenant_isolation" ON programs
  FOR ALL
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

Das ist keine Anwendungsebenen-Filterung, die ein Bug umgehen könnte. Es ist PostgreSQL, das erzwingt, dass eine Abfrage der Engineering-Abteilung buchstäblich keine Records der Business-Abteilung sehen kann. Für Regierungssites mit sensiblen Daten über Agenturen ist das genau die Isolation, die Prüfer sehen wollen.

Monorepo-Architektur

Mit Turborepo organisiert sich der Codebase in:

• packages/ui: Gemeinsame Komponentenbibliothek mit Sub-Brand-Theming über CSS-Custom-Properties
• packages/config: Tenant-Konfiguration — Logos, Farben, Navigationsstrukturen, Feature-Flags
• apps/web: Die Next.js-Anwendung mit dynamischen [tenant]-Routes
• packages/db: Supabase-Client mit RLS-bewussten Abfrage-Helfern

Jede Franchise-Filiale oder Abteilung erhält ihre eigene Konfigurationsdatei, nicht ihre eigene Bereitstellung. Fügen Sie einen neuen Standort hinzu, indem Sie eine JSON-Config und eine Zeile in der Tenants-Tabelle hinzufügen. Keine Infrastrukturänderungen.

Unser Migrationsprozess

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

Wir bilden jede Drupal-Subsite ab — Content-Typen, Taxonomien, Menüs, URL-Aliase, Media-Assets, Benutzerrollen und Integrationen. Für Universitäten bedeutet das die Katalogisierung von SIS-Verbindungen, SAML-SSO-Konfigurationen und CRM-Webhooks. Für Franchises ist es Standort-Finder, lokale SEO-Schemas und Buchungsintegrationen.

Wir aktivieren Drupals JSON:API und führen paginierte Exporte durch, um die vollständige Datenform zu verstehen: /jsonapi/node/program?page[limit]=50&include=field_department,field_faculty.

Für Drupal 7-Sites (immer noch häufig in Regierungsbehörden) abfragen wir MySQL direkt, da JSON:API nicht verfügbar ist:

SELECT n.nid, n.title, fdb.body_value, fds.field_subtitle_value
FROM node n
JOIN field_data_body fdb ON fdb.entity_id = n.nid
JOIN field_data_field_subtitle fds ON fds.entity_id = n.nid
WHERE n.type = 'program';

Phase 2: Datenarchitektur und Supabase-Setup (1–2 Wochen)

Wir entwerfen das Supabase-Schema mit ordnungsgemäßer Normalisierung und Tenant-Isolation von Anfang an. Drupals Entity-Attribute-Value-Speicherung wird in saubere relationale Tabellen abgeflacht. RLS-Richtlinien werden geschrieben und getestet, bevor Daten ankommen.

Tenant-Konfiguration geht in eine tenants-Tabelle mit Spalten für Branding, Feature-Flags, Navigation und Integrationszugangsdaten.

Phase 3: Next.js Application Build (3–8 Wochen)

Hier findet der Großteil der Entwicklung statt. Wir bauen:

• Dynamische Tenant-Routes: app/[tenant]/page.tsx, app/[tenant]/programs/[slug]/page.tsx
• Middleware: Tenant-Erkennung, Authentifizierung, Redirect-Mapping, Locale-Handling
• Gemeinsame Komponenten: Program-Finder mit Faceted Search, Faculty-Verzeichnisse, Event-Kalender, News-Feeds — alle RLS-scoped
• Admin-Interfaces: Tenant-scoped Dashboards, wo Department-Admins nur ihre Inhalte verwalten
• ISR-Konfiguration: revalidatePath für Content-Updates ohne vollständige Rebuilds
• SAML-SSO-Integration: Kritisch für Universitäten und Regierungsportale

Wir nutzen KI-gestützte Entwicklung (Claude Code, Cursor), um die Konvertierung von Drupal Paragraphs zu React-Komponenten zu beschleunigen, was typischerweise 70–80% von unkomplizierten Content-Type-Zuordnungen handhabt.

Phase 4: SEO-Erhaltung und Redirects (1 Woche)

Das ist nicht verhandelbar. Universitäten sammeln über Jahrzehnte Tausende von Backlinks an. Regierungssites haben normative URLs, die funktionsfähig bleiben müssen.

SEO-Erhaltungsstrategie

Wir exportieren jeden URL-Alias aus Drupal — einschließlich /node/1234-Pfade, auf die externe Sites unvermeidlich verlinken. Diese werden in eine Redirect-Map geladen, die Next.js Middleware bei jedem Request verarbeitet.

Die Middleware handhabt:

• Pfad-basierte Redirects: /school-of-business/mba-program → /departments/business/programs/mba
• Node-ID-Redirects: /node/4521 → /departments/engineering/faculty/smith
• Subdomain-Konsolidierung: business.university.edu → university.edu/departments/business
• Canonical-URL-Durchsetzung: Vermeidung doppelter Inhalte über Tenant-Routes
• Structured-Data-Injection: Departments-spezifische JSON-LD-Schemas, LocalBusiness-Markup für Franchise-Standorte

Wir verifizieren jeden Redirect mit automatisierten Crawls vor Go-Live. Search Console erhält die aktualisierte Sitemap sofort eingereicht. Bei .edu-Sites stabilisiert sich der organische Traffic typischerweise innerhalb von 2–3 Wochen und verbessert sich innerhalb von 6–8 Wochen, wenn die Core Web Vitals Gewinne greifen.

Timeline und Preisgestaltung

Umfang	Timeline	Investition
Klein (1–5 Subsites, Franchise)	4–8 Wochen	$50K–$100K
Mittel (10–15 Subsites, Universität)	8–12 Wochen	$150K–$300K
Enterprise (20–40+ Subsites, Regierung)	12–16 Wochen	$300K–$600K

Drupal 7-Sites fügen ~20% hinzu wegen MySQL-Extraktionsarbeit. SAML-SSO und SIS/CRM-Integrationen fügen Komplexität am oberen Ende hinzu. Laufendes Hosting auf Vercel + Supabase kostet typischerweise $200–$500/Monat — ein Bruchteil dessen, was Sie für Drupal-Hosting-Infrastruktur über mehrere Subsites verteilt zahlen.

Das Fazit

Drupal Multisite löste in seiner Zeit ein echtes Problem. Aber die Verwaltung von 20 Subsites auf gemeinsamer PHP-Infrastruktur, mit schrumpfendem Talentpool und wachsenden Compliance-Bedenken, ist kein langfristiger Plan. Ein Next.js Monorepo mit Supabase RLS bietet Ihnen echte Tenant-Isolation, Sub-Sekunden-Page-Loads, eine Developer Experience, die Menschen wirklich erfreut, und eine Architektur, die durch Bearbeiten einer Konfigurationsdatei skaliert statt Infrastruktur einzurichten.

Eine App. Eine Bereitstellung. Jeder Tenant auf Datenbankebene isoliert. Das ist die Migration, die es wert ist.