Ein Onlineshop ist nicht dann skalierbar, wenn er an normalen Tagen funktioniert. Entscheidend ist, was passiert, wenn viele Kunden gleichzeitig kaufen, ein wichtiges Update ansteht oder der Checkout unter Last arbeiten muss.
Bei Kampagnen, saisonalen Aktionen, Black Friday, Newsletter-Versand oder Social-Media-Reichweite werden viele Prozesse gleichzeitig ausgelöst. Besucher rufen Produktseiten auf, nutzen Filter und Suche, legen Waren in den Warenkorb, prüfen Gutscheine, laden Versandarten, starten Zahlungen und schließen Bestellungen ab. Dadurch entsteht nicht nur mehr Traffic. Es entstehen auch mehr Datenbankabfragen, mehr externe Aufrufe und mehr parallele Prozesse.
Deshalb reicht es nicht, nur die durchschnittliche Ladezeit zu betrachten. Wichtiger ist die Frage, wie sich der Shop verhält, wenn viele Kunden gleichzeitig kaufen wollen. Besonders relevant sind Produktdetailseiten, Suche, Warenkorb, Checkout und Zahlungsabschluss.
Der Checkout ist der kritischste Bereich eines Onlineshops. Hier laufen viele Informationen zusammen: Kundendaten, Warenkorb, Versandarten, Zahlungsarten, Gutscheine, Steuern, Verfügbarkeiten und Bestellabschluss.
Wenn der Checkout langsam wird oder einzelne Schritte unzuverlässig reagieren, betrifft das direkt den Umsatz. Kunden brechen eher ab oder wenden sich an den Kundenservice, weil sie unsicher sind, ob die Bestellung funktioniert hat.
Deshalb sollte der Checkout nicht unnötig überladen sein. Jede Erweiterung, die in Warenkorb, Preislogik, Versandberechnung oder Zahlungsabwicklung eingreift, sollte bewusst geprüft werden. Nicht jedes Plugin ist kritisch. Kritisch sind vor allem die Erweiterungen, die an umsatzrelevanten Stellen mitlaufen.
Viele Unternehmen reagieren darauf, indem Updates verschoben werden. Dadurch entstehen technische Schulden, die langfristig Wartung und Sicherheit erschweren – bis ein einzelner Update-Sprung zum Projektrisiko wird.
Das eigentliche Problem ist nicht die Anzahl der Plugins, sondern der Grund, warum sie installiert wurden. Plugins sollten Funktionen ergänzen, nicht strukturelle Defizite ausgleichen. Ein skalierbarer Onlineshop basiert auf einer klar definierten Systemarchitektur, in der Erweiterungen gezielt eingebunden werden.
Selbstcheck: Wie viele Plugins betreibt Ihr Shop aktuell – und wie viele davon lösen strukturelle Probleme, die eigentlich ins ERP oder in die Prozessdefinition gehören? Wenn ein Update des Core-Systems regelmäßig verschoben wird, weil Plugins danach nicht mehr funktionieren könnten, ist die Grenze überschritten.
Die Frage „Wie viele Plugins sind zu viel?“ führt oft in die falsche Richtung. Ein Shop kann mit wenigen schlecht integrierten Erweiterungen instabiler sein als mit mehreren sauber gepflegten Erweiterungen.
Entscheidend ist, wo ein Plugin eingreift. Besonders sensibel sind Erweiterungen in diesen Bereichen:
- Checkout
- Warenkorb
- Preis- und Rabattlogik
- Versandarten
- Zahlungsarten
- Produktdaten
- Schnittstellen zu ERP, Warenwirtschaft oder Marktplätzen
Ein Plugin, das nur eine kleine Darstellung im Frontend ergänzt, ist meist weniger kritisch als eine Erweiterung, die Preise berechnet, Zahlungsarten steuert oder Bestellungen verändert.
Der Mehrwert liegt deshalb nicht darin, pauschal Plugins zu reduzieren. Sinnvoller ist eine Bewertung: Welche Erweiterungen sind notwendig? Welche erzeugen Last? Welche sind updatekritisch? Welche greifen in zentrale Prozesse ein? Und welche können entfernt, ersetzt oder sauberer gelöst werden?
Ein skalierbarer Shop muss nicht nur mehr Besucher aushalten. Er muss auch wartbar bleiben. Wenn Updates immer wieder verschoben werden, ist das ein deutliches Warnsignal.
Oft liegt das Problem nicht am fehlenden Willen. Es fehlt eine sichere Grundlage für Änderungen. Wenn nicht klar ist, welche Plugins, Schnittstellen oder individuellen Anpassungen betroffen sind, wird jedes Update zum Risiko. Besonders kritisch ist das, wenn keine Testumgebung vorhanden ist.
Dann muss im laufenden System entschieden werden, ob ein Update eingespielt werden kann. Das führt dazu, dass notwendige Aktualisierungen liegen bleiben. Damit steigt nicht nur der technische Aufwand, sondern auch das Risiko für spätere größere Probleme.
Ein belastbarer Shop braucht deshalb klare Voraussetzungen für Updates: eine gepflegte Übersicht der Erweiterungen, nachvollziehbare Abhängigkeiten, eine Testumgebung und definierte Prüfprozesse für kritische Bereiche wie Checkout, Versand, Zahlung und Bestellübergabe.
Viele Skalierungsprobleme entstehen nicht im sichtbaren Shop, sondern im Backend. Wenn Bestellungen zwar eingehen, aber anschließend manuell geprüft, korrigiert oder übertragen werden müssen, ist der Prozess nicht wirklich skalierbar.
Typische Bremsen sind doppelte Produktpflege, unklare Bestandsführung, manuelle Korrekturen bei Preisen, fehleranfällige Versandlogiken oder nicht sauber angebundene Marktplätze. Der Shop ist dann nur der sichtbare Teil eines größeren Problems.
Für einen stabilen Betrieb muss klar sein, welches System welche Aufgabe übernimmt. Produktdaten, Bestände, Preise, Kundengruppen, Bestellungen, Versandinformationen und Buchhaltungsdaten sollten nicht zufällig zwischen Systemen hin- und hergeschoben werden. Es braucht klare Systemrollen und nachvollziehbare Datenflüsse.
Bevor ein Shop optimiert oder neu aufgebaut wird, sollte zuerst geprüft werden, wo die tatsächlichen Engpässe liegen. Sonst werden nur Symptome behandelt.
Sinnvoll ist eine Prüfung dieser Bereiche:
- Welche Seiten oder Prozesse werden bei Last langsamer?
- Welche Plugins greifen in Checkout, Preislogik, Versand oder Zahlung ein?
- Welche Updates wurden verschoben und warum?
- Gibt es eine Testumgebung für Änderungen?
- Welche Schnittstellen sind geschäftskritisch?
- Wo entstehen manuelle Prüfungen im Tagesgeschäft?
- Welche Daten werden doppelt gepflegt oder nachträglich korrigiert?
- Welche Prozesse bremsen bei mehr Bestellungen zuerst?
Diese Fragen liefern mehr Erkenntnis als eine pauschale Aussage wie „Der Shop ist zu langsam“ oder „Wir brauchen einen Relaunch“.
Nicht jeder gewachsene Shop braucht sofort einen Relaunch. Wenn die technische Grundlage stabil ist, können gezielte Optimierungen ausreichen. Dazu gehören zum Beispiel die Bereinigung von Plugins, eine bessere Testumgebung, klarere Schnittstellen, optimierte Checkout-Prozesse oder ein strukturierter Update-Prozess.
Ein Neuaufbau wird dann sinnvoll, wenn zentrale Prozesse nur noch durch Workarounds funktionieren, Updates kaum noch sicher möglich sind oder die bestehende Grundlage nicht mehr zuverlässig weiterentwickelt werden kann.
Wichtig ist: Ein neuer Shop löst nicht automatisch alte Strukturprobleme. Wenn Datenflüsse, Systemrollen und Prozesse nicht sauber geplant werden, entstehen dieselben Probleme später erneut.
Ob JTL-Shop, Shopware oder Shopify sinnvoll ist, hängt nicht nur vom Funktionsumfang des Shopsystems ab. Entscheidend ist, wie der Shop in die bestehende Systemlandschaft passt und welche Prozesse darüber abgebildet werden sollen.
JTL-Shop ist vor allem dann naheliegend, wenn ein Unternehmen bereits mit JTL-Wawi arbeitet und Shop, Warenwirtschaft, Lager und weitere JTL-Komponenten eng verzahnt werden sollen. Shopware bietet sich an, wenn individuelle Anforderungen, flexible Shop-Strukturen oder komplexere E-Commerce-Prozesse im Vordergrund stehen. Shopify kann passend sein, wenn eine cloudbasierte Shop-Lösung mit schlankem Betrieb, moderner Oberfläche und gut nutzbarem Backend gewünscht ist.
eloquium unterstützt Unternehmen nicht nur bei der technischen Umsetzung, sondern auch bei der Auswahl des passenden Shopsystems. Gemeinsam mit unseren Kunden prüfen wir, welche Anforderungen bestehen, welche Systeme bereits im Einsatz sind, welche Schnittstellen benötigt werden und welche Lösung langfristig zum Unternehmen passt.
Wir sind kein Systemhaus, das Lizenzen verkauft, und keine Agentur, die Shops baut. Wir sind Architekturpartner – und begleiten Unternehmen dabei, ihre Shop-Infrastruktur so aufzustellen, dass sie mit dem Wachstum mithalten kann. Bei eloquium begleiten wir Unternehmen häufig in Workshops, in denen bestehende Shop-Architekturen transparent gemacht, technische Risiken identifiziert und eine stabile Grundlage für Wachstum geschaffen wird.
Shop-Architektur und Systemauswahl
Wir analysieren bestehende Shop-Setups, identifizieren strukturelle Schwachstellen und bewerten, welches System zu den Anforderungen passt. Wir arbeiten mit Shopware und JTL-Shop und können systemunabhängig einschätzen, wann ein Wechsel sinnvoll ist – und wann nicht.
Performance-Analyse und Hosting-Optimierung
Wir prüfen Hosting-Struktur, Datenbankdesign, Caching-Strategien und Monitoring-Setup. Wo strukturelle Schwächen Performance unter Last kosten, entwickeln wir konkrete Maßnahmen – vor dem nächsten Peak, nicht danach.
ERP-Anbindung und Backend-Struktur
Wir definieren, welches System Produktdaten, Bestände und Auftragslogiken führt – und wie Shop und ERP konsistent zusammenspielen. Die Führungsrolle des ERP ist dabei kein Konzept, sondern eine technisch verankerte Entscheidung.
Migrationsbegleitung
Wir begleiten Shop-Migrationen als Architekturprojekte: Prozessdefinition, Datenmigration, Schnittstellenarchitektur, Testphase und Go-live. Kein Systemwechsel ohne strukturelle Neuordnung.
Betrieb, Monitoring und kontinuierliche Optimierung
Wir richten Monitoring-Strukturen ein, begleiten Lasttests und unterstützen bei der Definition von Eskalationsprozessen. Ein Shop, der läuft, ist nicht fertig – er braucht einen Betriebsrahmen.
Unser Ansatz in einem Satz: Wir bauen nicht nur Shops. Wir schaffen auch die Architektur, in der Shops dauerhaft stabil und skalierbar betrieben werden können.
Ein Onlineshop ist nicht schon skalierbar, weil er im Alltag funktioniert. Skalierbarkeit zeigt sich bei Peaks, Updates und neuen Anforderungen.
Wenn der Checkout bei Aktionen langsamer wird, Updates zum Risiko werden oder Mitarbeiter immer mehr manuell prüfen müssen, sollte die Shop-Struktur überprüft werden. Der wichtigste Hebel ist dann nicht die nächste Einzelfunktion, sondern ein Shop-Betrieb, der auch bei Wachstum kontrollierbar bleibt.
Typische Signale: Performance-Einbrüche unter Kampagnenlast, Updates, die nicht mehr eingespielt werden können, wachsende manuelle Prozesse in der Auftragsverarbeitung und Bestandsführung sowie eine zunehmende Abhängigkeit von Einzelpersonen, die wissen, welche Plugins sich nicht vertragen. Wer mehrere dieser Punkte erkennt, sollte die Architektur prüfen – nicht erst beim nächsten Ausfall.
Wenn das bestehende System strukturelle Grenzen erreicht, die sich nicht mehr durch Plugins oder Hosting-Upgrades lösen lassen – insbesondere bei komplexeren ERP-Anforderungen, B2B-Preislogiken oder hohem Auftragsvolumen. Die richtige Frage ist nicht: Welches System ist besser? Sondern: Welche Architektur brauche ich für die nächsten drei Jahre?
Das ist keine Frage der Anzahl, sondern der Funktion. Problematisch werden Plugins, wenn sie strukturelle Defizite kaschieren, die eigentlich ins ERP oder in die Prozessdefinition gehören. Ein gutes Indiz: Wenn man mehrere Plugins für die gleiche Anwendung hat, sollte man genauer hinschauen.
Nicht zwangsläufig. Eine Shop-Migration ist aber die beste Gelegenheit, die ERP-Shop-Schnittstelle strukturell neu zu definieren. Wer die Migration nutzt, um Führungsrollen, Datenflüsse und Prozesslogiken zu klären, bekommt ein tragfähigeres Gesamtsystem. Wer nur den Shop tauscht, nimmt die alten Schnittstellenprobleme mit.
Agenturen bauen Shops. Wir analysieren, ob ein Shop architektonisch für das geplante Wachstum ausgelegt ist – und begleiten die strukturellen Entscheidungen dahinter: Systemauswahl, ERP-Anbindung, Prozessdefinition, Migrationsplanung. Das Ergebnis ist keine Website, sondern eine tragfähige technische Grundlage.
Diese Gedanken haben wir zuerst auf LinkedIn geteilt – folgen Sie uns dort für weitere Einblicke.