Mandantenfähiges CMS: lohnt sich das für kleine Agenturen?

Dies ist die Perspektive unserer Agentur, wann mandantenfähige CMS-Architekturen wirklich sinnvoll sind.

TL;DR. Ein mandantenfähiges CMS beherbergt jede Kunden-Website in einer Anwendungsinstanz mit strikter Datentrennung auf Datenbankebene - eine Verwaltung, ein Update-Zyklus und eine Editor-Erfahrung ersetzen die Wartungs-Tretmühle pro Kunde. Für kleine Agenturen liegt der Break-even etwa zwischen drei und sieben Kunden-Websites; ab acht verdrängt die Single-Tenant-Alternative spürbar die eigentliche Projektarbeit. Das Layout sperrt sie allein nicht im Code ab - das leisten Block-Schemata.

TL;DR (zum Überfliegen)

Die Verwaltung separater CMS-Installationen für jeden Kunden verursacht steigenden operativen Aufwand.
Die Mandantenarchitektur konsolidiert alle Kunden in einer Verwaltung mit strikter Datenbankisolierung.
Die Investition zahlt sich meist dann aus, wenn eine Agentur mehr als nur eine Handvoll ähnlicher KMU-Websites verwaltet.

Wenn Sie eine kleine Webagentur führen, kennen Sie den Effekt vermutlich: Jede neue Kunden-Website fügt operativen Aufwand hinzu. Eine zusätzliche Verwaltung, die gepflegt werden will. Eine zusätzliche Plugin-Matrix, die nachverfolgt werden muss. Ein zusätzlicher Sicherheitsupdate-Rhythmus. Nach zehn Kunden wird “Pflege der Websites” teurer als das eigentliche Bauen.

Mandantenfähige CMS-Architektur ist die technische Antwort auf dieses Betriebsproblem - aber der Begriff wird unterschiedlich gebraucht. Dieser Beitrag schaut praktisch hin: Was bedeutet er konkret, was löst er, und ab wann lohnt er sich für eine kleine Agentur?

Was “mandantenfähig” wirklich heißt

Ein mandantenfähiges System ist eine einzige Anwendungsinstanz, die mehrere verschiedene Kunden sicher bedient, deren Daten strikt isoliert hält und dieselbe zugrunde liegende Infrastruktur gemeinsam nutzt.

Ein mandantenfähiges System ist Software, die mehrere getrennte Kunden (oder Mandanten, oder Sites) in einer laufenden Instanz beherbergt - bei strikter Trennung der Daten (wie in Architektur-Leitfäden wie der Microsoft-Dokumentation zur Mandantenarchitektur detailliert beschrieben). Die typischen Gegenmodelle:

Single-Tenant: eine Installation pro Kunde. WordPress in der Standardform. Jeder Kunde hat seine eigene WordPress-Installation, eigene Datenbank, eigene Verwaltung.
Mehrere Instanzen (auch “siloed” genannt): eine Installation pro Kunde, aber eine gemeinsame Verwaltungsschicht. WordPress Multisite kommt dem nahe - eine PHP-Installation, aber jede Site hat eigene Admin-URL und eigene Plugin-Matrix.
Mandantenfähig: eine Installation, eine Verwaltungsoberfläche, mehrere isolierte Arbeitsbereiche darin. Wer Zugriff auf mehrere Arbeitsbereiche hat, wechselt mit einem Dropdown. Daten, Medien, Audit-Logs und Inhalte sind pro Arbeitsbereich auf Datenbank-Ebene getrennt.

Die Unterscheidung zählt, weil die Betriebskosten beim mandantenfähigen Modell deutlich sinken - und niedrig bleiben, wenn die Kundenanzahl wächst.

Die Agentur-Mathematik

Stellen Sie sich eine Agentur mit drei Kunden-Websites vor, jede auf einem anderen Stack. Die Kosten für das “Lichter-an-halten” sehen ungefähr so aus:

Drei Sätze Admin-Zugangsdaten zu pflegen.
Drei Plugin-Update-Zyklen zu verfolgen.
Drei Sicherheits-Patch-Reihen anzuwenden.
Drei Editor-Erfahrungen, die Sie Ihren Kunden beibringen müssen.
Drei Hosting-Rechnungen.

Bei drei Projekten ist das ärgerlich, aber zu schaffen. Bei zehn dominiert der operative Aufwand das Projekt-Ergebnis. Die Agentur-Inhaber stecken in Wartung statt in Design - und die wiederkehrenden Gebühren decken kaum die Zeit.

Ein mandantenfähiges CMS verschmilzt all diese Reihen zu einer. Eine Verwaltung, ein Plugin-Set, ein Update-Zyklus, eine Editor-Erfahrung, eine Hosting-Rechnung (die der Plattform). Die Grenzkosten für eine neue Kunden-Website sind “neuen Arbeitsbereich anlegen” - nicht “neuen Stack aufsetzen”.

Ab wann lohnt es sich?

Nach unserer Erfahrung kommt es darauf an, wie viele Kunden-Websites Sie betreuen und wie unterschiedlich deren Anforderungen sind.

Eine bis zwei Websites: vermutlich nicht. Der Single-Stack-Aufwand pro Projekt ist erträglich.
Drei bis sieben Websites: nützlich. Die operative Vereinfachung wirkt, und ein konsistenter Editor über alle Sites ist ein echter Vorteil für Ihre Kunden.
Acht oder mehr Websites: aus unserer Sicht schwer dagegen zu argumentieren. Die Single-Tenant-Alternative wird oft zur Wartungs-Tretmühle, die echte Projektarbeit verdrängt.

Der Break-even sinkt zusätzlich, wenn Ihre Kunden ähnliche Bearbeitungsbedürfnisse haben (eine Inhaltsbearbeitung auf einer Hotel-Site sieht aus wie eine Inhaltsbearbeitung auf einer Klinik-Site). Er steigt, wenn jeder Kunde einen völlig eigenen Funktions-Wunschzettel hat.

Was Mandantenfähigkeit nicht löst

Es lohnt sich, ehrlich zu den Grenzen zu sein:

Sie sperrt das Layout nicht im Code ab. Ein mandantenfähiges CMS kann trotzdem einen freien Editor anbieten, mit dem der Kunde das Design beschädigen kann. Der Designschutz kommt aus einer anderen architektonischen Entscheidung (typisierte Block-Schemata im Code).
Sie eliminiert die pro-Kunde-Arbeit nicht. Sie schreiben weiterhin das Design, das Schema, die Deployment-Konfiguration. Was wegfällt, ist die pro-Kunde-Verwaltungs-Arbeit.
Sie skaliert nicht magisch. Ein einziger Plattform-VPS hat begrenzte CPU und Festplatte. Bei sehr vielen Kunden (hunderten) werden Datenbank-Tuning und Connection-Pool zum echten Thema.

Worauf Sie bei der Auswahl achten sollten

Wenn Sie ein mandantenfähiges CMS für einen Agentur-Stack erwägen, sind das die Fragen, die wirklich zählen:

Greift die Mandanten-Trennung auf Datenbank-Ebene oder nur in der Anwendung? Datenbank-Trennung (Foreign Keys, pro-Sprache eindeutige Indizes mit Mandanten-Scope) ist strukturell schwerer zu umgehen als reine Anwendungs-Trennung.
Kann ein Kunden-Nutzer versehentlich auf Medien eines anderen Kunden zugreifen? Die Auswahl-Filter in der Verwaltung sollten nur Datensätze des aktuellen Mandanten zeigen. Querverweise sollten von einem Constraint blockiert werden, nicht nur durch UI-Verstecken.
Was passiert beim Löschen eines Mandanten? Erstaunlich viele Systeme verwaisen Daten beim Mandanten-Delete. Achten Sie auf eine explizite Cascade-or-Block-Politik mit auditiertem Force-Cascade.
Wie unterscheidet sich die Editor-Erfahrung pro Mandant? Wenn jeder Mandant ein anderes Theme, Plugin-Set oder Editor-Verhalten hat, haben Sie den pro-Kunde-Aufwand wieder eingeführt, dem Sie entkommen wollten.
Wie sieht der Disaster-Recovery-Plan aus? Ein Plattform-VPS bedeutet ein Disaster-Radius. Verschlüsselte Backups, externe Aufbewahrung und ein dokumentiertes Restore-Verfahren sind keine Option, sondern Pflicht.

Wo Kernset einzuordnen ist

Nach unserer Erfahrung ist Kernset bei der Mandantenfähigkeit klar positioniert. Mandanten-Trennung greift auf Datenbank-Constraint-Ebene, nicht nur in der Anwendung. Auswahl-Filter zeigen nur den aktuellen Mandanten. Cross-Mandant-Medienverweise sind durch Foreign-Key-Scoping blockiert. Mandanten-Delete ist standardmäßig BLOCK (ein Super-Admin-Force-Cascade braucht Flag und Slug-Bestätigung). Backups sind verschlüsselt, mit einem von der Anwendungs-Verschlüsselung getrennten Schlüssel, unabhängig rotierbar.

Die Editor-Erfahrung ist über alle Mandanten identisch - und wir betrachten das als Funktion, nicht als Einschränkung. Eine konsistente Verwaltung bedeutet ein mentales Modell für Ihr Team und für Ihre Kunden.

Häufige Fragen

Bedeutet Mandantenfähigkeit, dass meine Kunden die Daten der anderen sehen können?

Nein. In einem richtig konfigurierten mandantenfähigen CMS sorgt eine strikte Datenbankisolierung (wie z. B. Row-Level Security oder Foreign-Key-Constraints) dafür, dass Kunden vollständig von den Inhalten, Medien und Einstellungen anderer Kunden abgeschottet sind.

Wann Sie Kernset NICHT wählen

Wenn Ihre Kunden ihr eigenes CMS auswählen wollen, eigene Block-Typen bauen oder auf einem Stack laufen, den Sie nicht kontrollieren - ist Kernset das falsche Werkzeug. Es ist für Agenturen, die die operative Schicht über viele ähnliche Kunden-Websites standardisieren wollen, nicht für Agenturen, deren Kunden jeweils einen maßgeschneiderten Stack verlangen.

Wenn Sie ein oder zwei Websites bauen und der Aufwand klein bleibt, ist Single-Tenant in Ordnung. Mandantenfähigkeit lohnt sich in der Mitte der Agentur-Kurve, nicht am unteren Ende.

Weiterlesen

Die Architekturseite von Kernset behandelt die Implementierungsdetails: das Block-Modell, die drei Hosting-Modi für Kunden-Websites, die öffentliche Inhalts-API und das Audit-Log-Konzept. Wenn Mandantenfähigkeit für Ihren Stack passt, ist das die nächste Seite.

Gegen Ihr Portfolio testen

Wenn Ihre Kundenanzahl die Projektarbeit zu verdrängen beginnt, ist der schnellste Weg zur Entscheidung, ob Mandantenfähigkeit für Ihre Agentur passt, ein Vergleich mit Ihren zwei unübersichtlichsten aktuellen Stacks. Frühzugang anfragen - jede Nachricht liest ein Mensch.