Wenn ein B2B-Shop nicht mehr so wächst wie geplant, kann das viele Gründe haben, und einer davon ist die Plattform. Probleme mit SaaS-Shopsystemen entstehen dabei nicht nur durch die Last. Sie entstehen auch dort, wo die Geschäftslogik über den Standardumfang hinauswächst: bei der ERP-Anbindung, der Synchronisation der Produktdaten, bei Rollen und Freigaben, bei Update-Zyklen und bei API-Limits. Ob das auf Ihren Shop zutrifft, lässt sich prüfen.
Dieser Leitfaden zeigt, woran Sie Skalierungsgrenzen erkennen, wie Sie sie messen und welche Handlungsoptionen es gibt, mit und ohne Plattformwechsel. Er vergleicht keine Anbieter, sondern liefert Kriterien.
Key Takeaways: Skalierungsgrenzen von SaaS-Shopsystemen
- SaaS-Shopsysteme erleichtern den Start. Grenzen können entstehen, wenn Sortimente, Preislogiken und ERP-Anforderungen komplexer werden.
- Typische Engstellen sind die ERP-Anbindung, die Synchronisation der Produktdaten, Rollen und Freigaben, Update-Zyklen, Performance und API-Limits.
- Ob eine Grenze erreicht ist, zeigen messbare Indikatoren, die sich funktionalen, technischen und wirtschaftlichen Grenzen zuordnen lassen.
- Nicht jede Grenze erfordert einen Systemwechsel: Erweiterung, Migration und Architekturwechsel sind drei verschiedene Wege.
- Eine Entscheidung beginnt mit der Bestandsaufnahme von Systemlandschaft und Geschäftslogik, nicht mit der Plattformwahl.
Was Skalierbarkeit im B2B bedeutet
Skalierbarkeit meint im B2B nicht nur, mehr Bestellungen pro Minute abzuwickeln. Es geht darum, ob eine Plattform wachsende Geschäftslogik abbilden kann: kundenspezifische Preislisten, mehrstufige Freigaben, komplexe Sortimentssteuerung und die Anbindung an ERP, CRM und PIM.
In diesem Leitfaden unterscheiden wir drei Ebenen. Das ist ein für diesen Beitrag gewähltes Modell, keine allgemeingültige Definition.
- Funktional: Kann die Plattform die Geschäftslogik abbilden?
- Technisch: Bewältigt sie Last, Datenmengen und Anfragen?
- Wirtschaftlich: Bleiben Betrieb, Wartung und Weiterentwicklung vertretbar?
Standard-SaaS-Plattformen liefern eine vorkonfigurierte Infrastruktur. Das senkt den Einstiegsaufwand. Geschäftsprozesse, die der Standard nicht abdeckt, müssen über Apps, Plugins oder Middleware ergänzt werden, und diese Lösungen wollen gepflegt, aktualisiert und aufeinander abgestimmt werden, auch wenn sich Plattform oder ERP ändern.
Im B2B kann sich diese Einschränkung früher zeigen als im B2C, weil digitale Kanäle dort oft dieselbe Komplexität abbilden sollen wie der Innendienst: individuelle Konditionen, Budgetfreigaben, Rechnungskauf und Rahmenverträge.
Ein SaaS-Shop ist ein Anzug von der Stange. Er sitzt von Anfang an, und kleine Änderungen sind schnell gemacht. Wächst das Geschäft, kommt der Moment, in dem sich der Schnitt nicht mehr durch Änderungen anpassen lässt. Konkret heißt das: Apps, Plugins und Middleware erweitern den Standard, die Grundstruktur der Plattform ändern sie meist nicht.
Wo SaaS-Shopsysteme an Integrationsgrenzen stoßen
Drei Bereiche lohnen einen genauen Blick: die ERP-Anbindung, die Synchronisation der Produktdaten und die Berechtigungsstrukturen.
ERP-Anbindung
Preise, Lagerbestände, Kundenstammdaten, Kreditlimits und Lieferzeiten kommen im B2B meist aus dem ERP. Fließen diese Daten nicht zuverlässig in beide Richtungen, können Fehler entstehen. Und je mehr Systeme beteiligt sind, desto schwieriger lässt sich nachvollziehen, wo ein Fehler in Angeboten, Bestellungen oder Rechnungen entstanden ist.
Die Schnittstelle selbst ist dabei oft nicht das Problem. Schwieriger ist es, die B2B-Logik des ERP abzubilden: Netto- und Bruttopreise, Steuerzonen, Rabattstaffeln, Zahlungsbedingungen. Was der Shop-Standard nicht abdeckt, landet in einer Middleware-Schicht, und je komplexer die Logik, desto aufwändiger und fehleranfälliger kann diese Schicht im laufenden Betrieb werden.
Synchronisation der Produktdaten
Wer viele Artikel mit Varianten, technischen Datenblättern und mehrsprachigen Beschreibungen pflegt, braucht eine zentrale Datenquelle, meist ein PIM-System. Entscheidend ist dann die Verbindung zum Shop.
Läuft die Übertragung über CSV-Importe oder Konnektoren von Drittanbietern, funktioniert das, solange sich Daten planbar ändern, bei täglichen Updates aus ERP und PIM können dagegen Synchronisationskonflikte entstehen, die von Hand oder mit zusätzlicher Automatisierung gelöst werden müssen. Welche Architekturen für die Verbindung von Pimcore und Shop infrage kommen, vergleicht unsere Übersicht der Pimcore-Commerce-Architekturen anhand von vier Modellen und elf Kriterien.
Rollen, Rechte und Freigaben
B2B-Einkauf läuft oft über mehrere Personen. Unternehmen arbeiten mit mehrstufigen Freigaben, Budgetgrenzen pro Rolle, separaten Einkäufer-Konten und Kostenstellen, und bilden Standardfunktionen diese Strukturen nur teilweise ab, entstehen individuelle Workarounds, die nach Plattform-Updates erneut geprüft werden müssen.
Wo Betriebsgrenzen liegen
Neben der Integration zeigen sich Grenzen im laufenden Betrieb: bei Updates, bei der Performance und bei API-Limits.
Update-Zyklen
SaaS-Anbieter steuern Zeitpunkt und Umfang ihrer Updates. Das reduziert den eigenen Wartungsaufwand, begrenzt aber die Möglichkeit, Änderungen individuell zu planen oder aufzuschieben. Verändert ein Update die Checkout-Logik oder wird ein Plugin inkompatibel, bleibt dem Betreiber wenig Handlungsspielraum, und ein ERP-Connector, der nach einem Update nicht mehr korrekt synchronisiert, kann den Bestellfluss unterbrechen.
Performance bei hoher Komplexität
Ob komplexe Preisberechnungen oder große Kataloge zu Antwortzeit-Engpässen führen, hängt von der Plattformarchitektur ab, von der Implementierung der Preisberechnung, von Caching und Indexierung, vom Datenmodell und von den verfügbaren Ressourcen. Kundenspezifische, mengenabhängige oder zeitgesteuerte Preise, die in Echtzeit auf der Produktseite berechnet werden, und Kataloge mit vielen Attributen und Sprachversionen sind typische Prüffälle. Messen Sie deshalb die Antwortzeiten bei typischer und bei hoher Last (siehe Schritt 3).
API-Limits bei Headless-Frontends
Headless-Architekturen trennen das Frontend vom Backend und versprechen Flexibilität, dafür hängt das Frontend aber an den APIs der Plattform, und deren Limits können die Leistung begrenzen.
Anbieter dokumentieren diese Limits unterschiedlich, etwa je API-Typ und Tarif. Bei BigCommerce gelten laut Entwicklerdokumentation (abgerufen im Oktober 2026) für die REST-APIs je nach Tarif 150 bis 450 Anfragen pro 30 Sekunden, ein Tarif ohne Limit ist einigen Enterprise-Kunden vorbehalten, und auch dort kann der Anbieter übermäßige Nutzung begrenzen. Prüfen Sie deshalb vor einer Headless-Entscheidung, welche API Ihr Frontend nutzt und welche Limits dafür gelten. Wir kennen diese Limits aus eigenen Anbindungen von Pimcore an BigCommerce über den Data Director; planbar werden sie, wenn Synchronisationsläufe von Anfang an darauf ausgelegt sind. Ein Limit sagt noch nichts über die Geschwindigkeit eines Shops, und ein hohes Limit garantiert keine gute Performance.
Wann SaaS ausreicht und wann nicht
Wann SaaS ausreicht
Arbeitet Ihr Geschäftsmodell mit standardisierten Preisen, einem überschaubaren Sortiment und geringer ERP-Komplexität, decken aktuelle SaaS-Plattformen den Funktionsumfang oft solide ab, und der Betrieb bleibt dabei schlank. Typische Fälle sind Einsteiger im B2B-Commerce, Hersteller mit Direktvertrieb an Endkunden und Unternehmen in der Evaluierungsphase. Kein Hosting, kein Patching, keine Server-Verantwortung.
Drei Anzeichen für eine Grenze
Drei Muster deuten darauf hin, dass die bestehende Lösung an eine Grenze stößt.
- Ihre App-Landschaft wächst schneller als Ihr Umsatz. Neue Anforderungen erfordern jeweils ein neues Plugin, eine neue Middleware oder eine neue Schnittstelle, die Gesamtkomplexität steigt, die Wartbarkeit sinkt.
- Zentrale Geschäftslogik verteilt sich über mehrere Tools, statt im Systemkern zu liegen. Preisberechnungen laufen dann teilweise im ERP, teilweise im Shop und teilweise in einer externen App, und Änderungen müssen an mehreren Stellen nachgezogen werden.
- Eigene Innovationen hängen an Release-Zyklen und Plattformgrenzen. Was strategisch wichtig ist, muss warten, weil die Plattform es technisch nicht abbilden kann.
In vier Schritten die Skalierbarkeit bewerten
Die vier Schritte führen von der Bestandsaufnahme zur Zielarchitektur.
Schritt 1: Systemlandschaft erfassen
Erfassen Sie alle Systeme, die mit dem Shop kommunizieren. Dazu gehören ERP, PIM, CRM, Warenwirtschaft, Payment, Versand und Marktplätze. Dokumentieren Sie für jede Schnittstelle die Datenrichtung (in eine oder in beide Richtungen), die Frequenz, das Format und das Fehlerverhalten, denn gerade das Fehlerverhalten entscheidet oft darüber, wie stabil eine Verbindung im Alltag läuft.
Schritt 2: Geschäftslogik kartieren
Listen Sie alle Geschäftsprozesse auf, die über den Shop laufen oder laufen sollten: Preisberechnung, Freigaben, Retouren, Rechnungsstellung, Kundenportal. Bewerten Sie jeden Prozess einzeln. Läuft er nativ in der Plattform, über ein Plugin oder über eine externe Lösung, und wer pflegt diese Lösung?
Schritt 3: Indikatoren und Kosten erheben
Ob eine Grenze erreicht ist, lässt sich nicht aus dem Bauchgefühl ableiten. Wir empfehlen, einige Indikatoren über mehrere Monate zu beobachten und mit der Geschäftsentwicklung zu vergleichen, weil einzelne Ausreißer, etwa durch eine Aktion oder ein Update, das Bild verzerren können. Zielwerte hängen von Ihrem Shop ab. Allgemeingültige Schwellen gibt es nicht.
- Antwortzeiten (technisch): Ladezeit von Produkt-, Listen- und Checkout-Seiten bei typischer und bei hoher Last.
- Schnittstellen (technisch): Fehlerquote und Verzögerung der Synchronisation mit ERP und PIM sowie die Zahl der Datenkonflikte, die von Hand korrigiert werden.
- Erweiterungen (wirtschaftlich): Zahl der Apps, Plugins und Schnittstellen im Verhältnis zur Umsatzentwicklung.
- Änderungsaufwand (funktional und wirtschaftlich): Dauer von der Anforderung bis zum Livegang und Anteil der Anforderungen, die nur über Workarounds umsetzbar waren.
- Geschäftslogik (funktional): Anteil der Prozesse, die nativ in der Plattform laufen, gegenüber Plugins und externen Lösungen (aus Schritt 2).
Dazu kommen die tatsächlichen Gesamtbetriebskosten (TCO) der aktuellen Lösung, der wirtschaftliche Maßstab: Plattformlizenz, Plugin-Kosten, Middleware, externe Entwicklung, Hosting, Wartung und interner Aufwand für manuelle Prozesse. Ein einzelner Wert beweist nichts. Aussagekräftig wird das Bild, wenn mehrere Indikatoren in dieselbe Richtung zeigen.
Unsere Einordnung: Eine Plattformgrenze wird zum Handlungsproblem, wenn sich technische oder funktionale Einschränkungen wiederholt nachweisen lassen und ihre Folgen für Kosten, Betriebsstabilität oder Weiterentwicklung relevant werden. Das ist eine Faustregel, kein Standard.
Schritt 4: Zielarchitektur definieren
Auf Basis der ersten drei Schritte legen Sie fest, welche Architektur Ihre Anforderungen trägt: Welche Plattform? Welches Betriebsmodell? Welche Integrationen? Welche Verantwortlichkeiten? Vergleichen Sie die erwarteten Gesamtkosten der Zielarchitektur mit denen der aktuellen Lösung.
Einen strukturellen Vergleich von Monolith, Headless und Composable Commerce nach Aufwand, Betriebskomplexität und Fünf-Jahres-Kosten finden Sie auf unserer Seite zu Composable Commerce.
Erweiterung der bestehenden Plattform
In vielen Fällen lässt sich die Plattform durch gezielte Erweiterungen ausbauen: ein PIM als zentrale Datenquelle, eine stabile Middleware für die ERP-Anbindung oder ein eigenes Frontend. Bei Pimcore-Projekten setzen wir dafür unseren Data Director ein, der ERP-Systeme an Pimcore anbindet und Daten in beide Richtungen überträgt. Das kann das Projektrisiko senken, die Umsetzung verkürzen und bestehende Prozesse erhalten. Es verlagert aber Komplexität in zusätzliche Bausteine, die Sie betreiben müssen.
Migration auf eine andere Plattform
Reicht die Erweiterung nicht aus, kann eine Migration nötig werden. Sie beginnt mit der Anforderungsanalyse, nicht mit der Plattformwahl: Welche ERP-Logik, welche Preisstrukturen und welche Freigabeprozesse müssen abgebildet werden? Ohne diese Klärung bleibt die Aufwandsschätzung unsicher, und nach dem Go-live drohen Überraschungen, die sich nur mit Nacharbeit beheben lassen. Eine gründliche Analyse kostet Zeit, kann aber spätere Korrekturen ersparen.
Feature-Listen allein sagen wenig über die Eignung einer Plattform. Entscheidend ist nicht, ob eine Funktion existiert, sondern wie sie in Ihrer Systemlandschaft arbeitet: Wie verhält sich die Preislogik unter Last? Wie stabil ist die ERP-Synchronisation bei täglichen Batch-Läufen?
Architekturwechsel
Beim Architekturwechsel werden Funktionen und Verantwortlichkeiten zwischen Shop, Frontend, Integrationen und weiteren Systemen neu verteilt. Wer mehrere Märkte oder Frontends bedient oder seine Architektur schrittweise modernisieren will, kann dabei einen Wechsel zu Composable Commerce prüfen; wann sich das lohnt, beschreibt unser Beitrag „Composable Commerce im DACH-Mittelstand: Wann es sich lohnt – und wann nicht“.
Fazit: Skalierungsgrenzen bewerten, bevor die Plattform entschieden wird
Skalierungsgrenzen sind keine Plattformfrage allein. Sie hängen an Integrationen, Betriebsmodell, Datenmanagement und Wachstumsplanung zugleich. SaaS-Plattformen sind ein valider Startpunkt, und sie können zum Engpass werden, wenn die Geschäftslogik die Plattformgrenzen überschreitet.
Der Einstieg ist klein: Erfassen Sie Ihre Systemlandschaft, erheben Sie einige Indikatoren und entscheiden Sie erst danach, ob Erweiterung, Migration oder Architekturwechsel infrage kommt.
Wenn Sie die Ergebnisse gemeinsam einordnen möchten: Schildern Sie uns, wo Ihr Shop steht und was er leisten soll. Wir melden uns mit den richtigen Fragen und einem Vorschlag, wie es weitergeht. Ein paar Zeilen reichen.
Wir melden uns mit den richtigen Fragen und einem Vorschlag, wie es weitergeht.
