Ich bin Adobe AEM Sites Business Practitioner Expert und Magento Certified Developer Plus. Mein eigenes Projekt läuft auf Payload — einem Open-Source-CMS. Diese beiden Sätze beschreiben keinen Widerspruch; sie beschreiben ziemlich genau die Frage, um die es bei jeder CMS-Auswahl wirklich geht.
Meine Erfahrung nach fünfzehn Jahren Web- und CMS-Projekten: 80 bis 90 Prozent der Vorhaben, die ein neues CMS brauchen, ließen sich technisch problemlos mit einem Open-Source-System lösen. Trotzdem landet ein erheblicher Teil bei einer Enterprise-Suite. Die Gründe dafür sind selten technische — und genau deshalb lohnt es sich, sie offen zu benennen.
Warum die meisten Projekte mit Open Source auskämen — und es oft trotzdem anders kommt
Es gibt sehr viele kleine, gute Open-Source-CMS. Ihr Problem ist selten die Technik, sondern der Markt drumherum: Für ein Nischensystem finden sich kaum Agenturen oder Freelancer, die ein größeres Projekt Jahre später noch verlässlich weiterbetreuen. Also bleibt man bei den wenigen bekannten Open-Source-Systemen — oder greift zur Enterprise-Lösung, oft schlicht, weil ohnehin andere Produkte desselben Herstellers im Haus sind.
Verschoben hat sich in meinem Denken über die Jahre nur eines: Ich halte Enterprise-CMS heute nicht mehr pauschal für überdimensioniert. Sie haben ihre Berechtigung — nur eben nicht in jedem zweiten Mittelstandsprojekt, in dem sie verkauft werden.
Wo Enterprise wirklich gewinnt
AEM ist die richtige Wahl, wenn weitere Bausteine des Adobe-Ökosystems tatsächlich mitgenutzt werden — Adobe Analytics, Real-Time CDP, AEM Assets. Wer diese Kette wirklich fährt, bekommt einen integrierten Stack, den man mit Open-Source-Komponenten erst mühsam zusammensetzen müsste.
Der entscheidendere Faktor ist aber selten das Ökosystem, sondern die Zahl der Menschen, die mit dem System arbeiten. AEM bietet Funktionen für die komplette Steuerung einer Content-Strecke — Inhalte, die über Monate im Voraus geplant werden und zugleich viele Ausspielkanäle betreffen. Das ist der echte Mehrwert gegenüber Open Source. Dazu kommen Compliance, Hosting und SaaS-Betrieb ab Werk — alles Dinge, die man bei Open Source erst selbst herstellen muss.
Wo Enterprise an den Mittelstand überverkauft wird
Eine Enterprise-Content-Suite landet bei größeren Setups schnell im Bereich von rund 200.000 Euro Lizenzkosten pro Jahr. Die Projektkosten sind ein eigenes Kapitel: Größenordnung 150.000 bis 300.000 Euro, nur um den Funktionsstand der alten Website überhaupt wieder zu erreichen.
Das wäre vertretbar, wenn der Mehrwert anschließend gehoben würde. In der Praxis bleibt der Fokus aber häufig auf dem Kerngeschäft — Produkt, Vertrieb, Conversion —, und der ambitionierte Content-Plan rutscht nach hinten. Wenn am Ende nur ein bis fünf Personen Inhalte pflegen, bleibt der eigentliche Enterprise-Mehrwert ungenutzt. Schlimmer noch: Die Enterprise-Denke färbt auf das ganze Projekt ab — alles wird größer, schwerer und teurer gedacht, als der Mittelständler es je gebraucht hätte.
Wo Open Source beißt
Andersherum ist Open Source kein Selbstläufer. Es steht und fällt mit der Community: Fehlt sie, kommen keine Innovationen und keine Sicherheits-Fixes mehr — und ein CMS ohne Sicherheits-Updates ist mittelfristig ein Haftungsthema, kein Sparmodell.
Der zweite Klassiker ist der Plugin-Wildwuchs. Weil es für ein großes Open-Source-CMS für fast alles eine Erweiterung gibt, füllt sich ein Projekt rasch mit Plugins und driftet in Richtung Spaghetti-Architektur. Und Self-Hosting wird fast immer unterschätzt — Betrieb, Backups, Updates, Skalierung sind echte, wiederkehrende Kosten, kein Einmalaufwand.
Die Fragen, die ich in der Auswahl stelle
Wenn mich eine Geschäftsführung fragt „welches CMS für uns?", beantworte ich das nicht mit einer Feature-Tabelle. Ich stelle Fragen — diese zuerst:
- Wie viele Menschen werden tatsächlich mit dem System arbeiten?
- Wie oft werden Inhalte aktualisiert — täglich, monatlich, kampagnenweise?
- Gibt es Compliance-Vorgaben? EU oder US, SaaS oder zwingend Self-Hosting?
- Wird Hersteller-Support mit SLA gebraucht — oder trägt ein internes Team das Risiko?
- Wie groß ist das Lizenz-Budget über einen 3- bis 5-Jahres-Horizont, nicht nur im ersten Jahr?
Technisch kann jedes ernstzunehmende CMS Seiten, Inhalte und Blöcke ausspielen und an jedes System angebunden werden. Die Auswahl entscheidet sich nicht an Features — sondern daran, wie ein Team damit arbeiten will.
Eine Lehre aus der Praxis
Ein Projekt aus der Erinnerung, bewusst anonym: Es wurde ein vollwertiges CMS eingeführt, obwohl ein deutlich schlankeres Setup gereicht hätte. Viele Prozesse wurden weiter aus der alten, eng am Produktkatalog gedachten Logik heraus entworfen — während faktisch das CMS das führende System für die eigentliche Website war. Diese Diskrepanz machte Abstimmungen und Feature-Tests zäh.
Typisch war das Muster am Ende jeder Iteration: Erst dann wurde sichtbar, was eigentlich schon eine Iteration früher hätte passieren müssen. Das CMS hatte eine zusätzliche Komplexitätsschicht eingezogen, die das Team nicht mehr sauber überblicken konnte. Der Kunde trug das mit — es gab eine echte Vision dahinter. Aber das Team war zu klein, um ein so komplexes Konstrukt zu betreuen, erst recht bei weltweiten Rollouts. Die Vision war nicht falsch. Sie war nur nicht tragfähig für die vorhandene Mannschaft.
Die Lehre daraus ist unspektakulär und genau deshalb wichtig: Die richtige CMS-Wahl beginnt nicht beim System, sondern beim Team und seiner realen Arbeitsweise. Genau dieser Schritt — die nüchterne Systemauswahl vor der ersten Zeile Code — ist Teil meiner Arbeit im Technical Consulting. Wenn bei Ihnen gerade eine CMS-Entscheidung ansteht, klären wir in einem unverbindlichen 30-Minuten-Gespräch, welche der Fragen oben bei Ihnen die Antwort schon vorgibt.