Wenn der Onlineshop dem CMS entwachsen ist

Zu Beginn arbeiten die meisten Onlineshops nach einem einfachen Modell: Katalog, Warenkorb, einige Zahlungs- und Versandarten. Ein fertiges CMS ermöglicht einen schnellen Markteintritt, das Testen der Nachfrage und spart Budget für Funktionen, die noch nicht gebraucht werden. Ein solcher Onlineshop sollte sich gemeinsam mit dem Unternehmen weiterentwickeln.

Die Probleme beginnen später. Das Sortiment wächst, es kommen Lager, ein Treueprogramm, B2B-Preise, Marktplätze und komplexe Integrationen hinzu. Jede neue Funktion erfordert ein weiteres Modul, die Synchronisation läuft verzögert, und das Ändern eines Banners hängt plötzlich vom Entwickler ab. Das Unternehmen sieht, dass das System die Entwicklung bremst, weiß aber nicht, ob die Plattform komplett gewechselt werden muss.

Die Aussage „der Onlineshop ist dem CMS entwachsen“ bedeutet nicht, dass jedes fertige System schlecht ist. Oft lässt sich das Problem durch Optimierung, eine Aktualisierung der Architektur oder den Austausch eines einzelnen Moduls lösen. Eine Migration ist dann gerechtfertigt, wenn die Einschränkungen der Plattform systemisch werden und das Unternehmen regelmäßig mehr kosten als ein kontrollierter Wechsel.

Anzeichen 1. Der Katalog ist komplexer geworden als die Möglichkeiten der Plattform

Ein kleiner Katalog lässt sich leicht in einer Standardstruktur verwalten. Mit wachsendem Sortiment entstehen jedoch Varianten, Ausstattungen, Sets, Kompatibilitäten, regionale Preise, personalisierte Angebote und komplexe Attribute.

Das System beginnt das Geschäft zu bremsen, wenn:

• Manager Produkte duplizieren, um verschiedene Varianten zu zeigen;
• Filter langsam arbeiten oder chaotische URLs erzeugen;
• der Katalogimport regelmäßig hängen bleibt;
• eine einzige Attributänderung die manuelle Bearbeitung Hunderter Positionen erfordert;
• Bestände und Preise im Shop nicht mit dem Warenwirtschaftssystem übereinstimmen;
• der Katalog nicht gleichzeitig auf der Website, in der App und auf Marktplätzen genutzt werden kann.

In einer solchen Situation ist es wichtig, nicht nur das CMS, sondern auch das Datenmodell zu prüfen. Manchmal liegt das Problem an einer falschen Katalogstruktur, die ein Umzug auf eine andere Plattform nur an einem neuen Ort nachbilden würde.

Anzeichen 2. Integrationen sind zu einer Kette manueller Vorgänge geworden

Ein moderner Shop arbeitet selten isoliert. Er tauscht Daten mit CRM, ERP, Lager, Zahlungssystemen, Versanddienstleistern, Telefonie, Treueprogramm und Werbeplattformen aus.

Hat jedes System seine eigene Kopie der Daten, entstehen Konflikte: Eine Bestellung hat unterschiedliche Status, ein Produkt wird ohne Bestand verkauft, der Preis wird verspätet aktualisiert und eine Rücksendung landet nicht in der Analyse.

Ein Zeichen für ein Architekturproblem ist, wenn das Team die Systeme ständig manuell „abgleicht“. Eine Integration braucht eine definierte Single Source of Truth, Synchronisationsregeln, ein Fehlerprotokoll und die erneute Verarbeitung fehlgeschlagener Vorgänge. Lässt sich ein solcher Prozess im CMS nicht ohne instabile Workarounds aufbauen, sollte das Unternehmen eine andere Architektur prüfen.

Anzeichen 3. Jede Änderung dauert unvorhersehbar lange

Die Plattform sollte dem Unternehmen helfen, Hypothesen schnell zu testen. Wird die Einführung einer neuen Versandart oder Rabattform zu einem monatelangen Projekt, verliert der Shop nicht nur Budget, sondern auch Zeit.

Gemessen werden sollte:

• wie viel Zeit von der geschäftlichen Anforderung bis zum Release vergeht;
• wie oft die Änderung eines Moduls andere beschädigt;
• wie viele manuelle Tests nach einem Update nötig sind;
• welcher Teil des Budgets in die Pflege veralteter Abhängigkeiten fließt;
• wie viele Aufgaben aus Angst vor Eingriffen in den Systemkern verschoben werden.

Eine hohe Komplexität von Änderungen bedeutet nicht immer, dass ein neues CMS nötig ist. Ursache können fehlende Tests, Dokumentation, Staging oder ein fehlender Release-Prozess sein. Zuerst muss die organisatorische Schuld von den Einschränkungen der Plattform getrennt werden.

Anzeichen 4. Die Performance skaliert nicht mit dem Traffic

Ein Shop kann an einem normalen Tag stabil laufen und beim Sale ausfallen. Das bedeutet, dass sich das eigentliche Problem nicht bei durchschnittlicher Last, sondern bei Spitzen zeigt.

In ein Performance-Audit gehören:

• Server-Antwortzeit für Katalog, Suche und Warenkorb;
• LCP, INP und CLS auf realen Mobilgeräten;
• Cache-Verhalten nach Preis- und Bestandsänderungen;
• Last während des Produktimports;
• Funktion von Warteschlangen, Hintergrundaufgaben und Webhooks;
• Auslastung der Datenbank;
• Degradationsszenario bei Ausfall eines externen Dienstes.

Nicht jedes Geschwindigkeitsproblem erfordert ein Replatforming (den Umzug der Website auf eine andere Plattform). Oft reicht es, Caching, CDN, Suche, Bilder oder Datenbank zu optimieren oder schwere Prozesse in Warteschlangen auszulagern. Lässt der CMS-Kern jedoch keine separate Skalierung kritischer Komponenten zu, wird die Einschränkung systemisch.

Anzeichen 5. Das Admin-Panel zwingt das Team zu Umwegen

Der Käufer sieht nur die Storefront des Onlineshops, die operative Effizienz hängt jedoch vom Admin-Panel ab. Wenn Content-Manager zusätzliche Tabellen führen, Manager Bestellungen manuell kopieren und das Marketing den Entwickler bittet, Metadaten zu ändern, verursacht die Plattform versteckte Kosten.

Ein bezeichnendes Symptom ist, dass kritische Geschäftsprozesse außerhalb des Systems existieren. Zum Beispiel werden Rabattregeln im Chat gespeichert, der Rückgabestatus in einer Tabelle und die Kategoriezuordnung für den Marktplatz auf dem Computer eines einzelnen Mitarbeiters.

Vor der Migration müssen diese Prozesse beschrieben werden. Die neue Plattform soll das alte Admin-Panel nicht einfach nachbilden, sondern überflüssige manuelle Schritte beseitigen und Verantwortlichkeiten transparent machen.

Anzeichen 6. Sicherheit und Updates sind zum Umsatzrisiko geworden

Eine veraltete CMS-Version, Module ohne Support und Änderungen ohne Testumgebung erzeugen ein angesammeltes Risiko. Das Team schiebt Updates womöglich auf, weil es nicht weiß, was nach der Installation eines Patches nicht mehr funktioniert.

Zu den kritischen Signalen gehören:

• Ende des Supports für Schlüsselkomponenten;
• keine Möglichkeit, das System ohne vollständigen Stillstand zu aktualisieren;
• fehlende Protokollierung von Aktionen;
• unkontrollierte Zugriffsrechte;
• Speicherung von Secrets im Code;
• keine geprüften Backups;
• Abhängigkeit von einem einzigen Entwickler, der das System kennt.

Wenn technische Schulden jedes Update zur Gefahr machen, braucht das Unternehmen einen Modernisierungsplan — unabhängig davon, ob es beim aktuellen CMS bleibt.

Anzeichen 7. Die Betriebskosten steigen, der Nutzen nicht

Die Entscheidung über eine Migration sollte nicht nach dem Preis eines Moduls, sondern nach den Gesamtbetriebskosten getroffen werden. Die TCO umfassen Lizenzen, Hosting, Entwicklung, Support, Tests, Störungen, manuelle Arbeit und entgangene Chancen.

Wenn das Team den Großteil seiner Zeit mit der Pflege alter Lösungen verbringt und neue Funktionen ständig verschoben werden, kann das System formal günstig, für das Unternehmen aber teuer sein.

Es ist sinnvoll, die Kosten über 24–36 Monate für mehrere Szenarien zu vergleichen, nicht nur das Startbudget. Eine Migration ist am Anfang fast immer teurer, senkt aber manchmal die Betriebskosten und beschleunigt die Entwicklung. In anderen Fällen liefert die Optimierung des bestehenden Systems ein besseres Ergebnis bei geringerem Risiko.

Welche Daten vor der Entscheidung gesammelt werden sollten

Vor dem technischen Audit sollten messbare Kennzahlen vorbereitet werden:

• Anzahl der Produkte, Varianten, Kategorien und Sprachen;
• Bestellvolumen in normalen Zeiten und zu Spitzenzeiten;
• Anzahl der Integrationen und Häufigkeit des Datenaustauschs;
• Release-Dauer einer typischen Funktion;
• Anzahl der Störungen und Kosten ihrer Behebung;
• Geschwindigkeit der wichtigsten Seiten;
• Anteil manueller Vorgänge;
• Kosten für Infrastruktur und Support;
• organischer Traffic und Seiten, die nicht verloren gehen dürfen;
• Geschäftspläne für die nächsten zwei bis drei Jahre.

Ohne diese Daten wird die Diskussion schnell zum Streit „fertiges CMS gegen Custom“. Tatsächlich hängt die richtige Entscheidung von den Prozessen und der Größe des jeweiligen Shops ab.

Vier Entwicklungsoptionen

Headless (eine Architektur mit getrennter Oberfläche) ist nicht automatisch die „bessere“ Lösung. Es trennt das Frontend vom Backend und kann nützlich sein, wenn ein Katalog Website, App, B2B-Portal und weitere Kanäle bedient. Eine solche Architektur erhöht jedoch die Integrationskomplexität und erfordert APIs, Monitoring und Entwicklungsdisziplin. Mehr zum Prinzip lesen Sie im GL.ua-Beitrag über Headless CMS.

Wie man ohne Voreingenommenheit entscheidet

Die praktische Reihenfolge sieht so aus:

1. Geschäftsziele und Einschränkungen für zwei bis drei Jahre festlegen.
2. Ein technisches Audit des aktuellen Systems durchführen.
3. Die drei bis fünf Probleme mit den höchsten Kosten für das Geschäft bestimmen.
4. Für jedes Problem mindestens zwei Lösungsoptionen prüfen.
5. TCO, Zeitrahmen, Migrationsrisiko und Anbieterabhängigkeit bewerten.
6. Die Architekturhypothese an einem Prototyp oder einem begrenzten Modul prüfen.
7. Eine Roadmap und Erfolgskriterien erstellen.

Wichtig ist, nicht mit der fertigen Schlussfolgerung „wir brauchen Custom“ zu beginnen. Manchmal reicht es, das bestehende CMS richtig zu konfigurieren, den Katalog neu zu strukturieren und die Integrationen zu stabilisieren. Ein ehrliches Audit sollte das ebenso klar zeigen wie den Bedarf an einer Migration.

Wie man ein Replatforming vorbereitet

Ist die Entscheidung für den Wechsel gefallen, sollte die Migration in Arbeitsstränge aufgeteilt werden:

• Katalog und Datenmodell;
• Kunden, Bestellungen und Historie;
• Preise, Bestände und Integrationen;
• Inhalte und Medien;
• SEO und URL-Karte;
• Rollen und operative Prozesse;
• Analytics;
• Tests und Schulung des Teams.

Es müssen nicht alle Funktionen im ersten Release übertragen werden. Oft ist es sicherer, zuerst den Verkaufskern zu starten und Nebenfunktionen in späteren Phasen hinzuzufügen. Kritische Punkte — Zahlung, Versand, SEO, Sicherheit und Analytics — dürfen jedoch nicht „auf nach dem Start“ verschoben werden.

Mehr über grundlegende E-Commerce-Lösungen lesen Sie im Artikel über die Erstellung eines Onlineshops und die Entwicklung der Technologien.

Fazit

Ein Onlineshop ist dem CMS nicht dann entwachsen, wenn das Team seine Oberfläche leid ist, sondern wenn systemische Einschränkungen regelmäßig Verkauf, Integrationen und Entwicklung bremsen. Die Entscheidung sollte auf Daten beruhen: Kosten von Änderungen, Performance, Anzahl manueller Vorgänge, Risiken und Geschäftspläne.

Das Team von GL.ua kann ein technisches Audit der Plattform durchführen, Engpässe beschreiben und Szenarien vergleichen: Optimierung, schrittweiser Austausch von Komponenten, Replatforming oder eine Custom/Headless-Architektur. Ziel des Audits ist nicht, eine vorab festgelegte Technologie zu verkaufen, sondern eine Lösung zu finden, die der tatsächlichen Größe des Shops und seinen Geschäftsprozessen entspricht.