Wann lohnt der Wechsel des Shopsystems? Anzeichen und Alternativen
Kurz gesagt
Ob ein Shopsystem an Grenzen stößt, zeigen Ihre eigenen Zahlen: Wartezeit auf eine Anpassung, fehlgeschlagene Kaufversuche und Arbeitsstunden je Änderung. Die Schwellen dieses Beitrags sind redaktionelle Prüfwerte und keine belegten Systemgrenzen: mehr als acht Wochen Wartezeit auf eine Anpassung, über ein Prozent fehlgeschlagene Kaufversuche oder über vier Arbeitsstunden je Änderung. Ein einzelner Wert rechtfertigt in Deutschland, Österreich und der Schweiz keinen Wechsel; rechnen Sie den jährlichen Aufwand des Umwegs gegen die einmaligen Wechselkosten und prüfen Sie zuerst Upgrade, Zusatzdienst oder Hosting.
Das Wichtigste
- Ein einzelnes Signal rechtfertigt keinen Wechsel; messen Sie Wartezeit, Fehlerrate und Änderungskosten über zwölf Monate.
- Redaktionelle Wartezeit-Schwelle: mehr als acht Wochen von der Freigabe einer Anpassung bis zum Livegang.
- Redaktionelle Fehler-Schwelle: mehr als ein Prozent der Kaufversuche endet mit einem technischen Fehler.
- Redaktionelle Kostenschwelle: mehr als vier Arbeitsstunden je Standardänderung, Tendenz über zwölf Monate steigend.
- Für Ladezeiten nennt Google Feldwerte: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden, CLS bis 0,1 am 75. Perzentil.
- Redaktionelle Frist von 24 Monaten: Ein Wechsel ist nach der Beispielrechnung dieses Beitrags wirtschaftlich, wenn sich die einmaligen Kosten binnen 24 Monaten amortisieren; das ist keine amtliche Frist.
Änderungen am Shop, die früher eine Stunde gekostet haben, brauchen plötzlich Wochen; Kaufversuche brechen mit Fehlermeldungen ab; die Ladezeiten verschlechtern sich trotz aufgeräumter Bilder. Solche Beobachtungen zeigen noch nicht, ob das System oder seine Konfiguration die Ursache ist. Dieser Beitrag ordnet sie in prüfbare Kennzahlen, nennt redaktionelle Schwellenwerte und stellt den Systemwechsel neben die Alternativen, die Sie zuerst prüfen sollten.
Worauf es ankommt
Ein Shopsystem kann an drei Stellen an seine Grenzen stoßen: Es lässt sich nicht mehr rechtzeitig ändern, es verliert Kaufversuche durch technische Fehler, oder es verursacht je Änderung unverhältnismäßig viel Arbeit. Für jede dieser Stellen brauchen Sie eine Zahl aus einem festen Zeitraum, nicht den Eindruck einer schlechten Woche.
Die Werte kommen aus Quellen, die Sie selbst führen: dem Änderungsprotokoll, den Server- und Fehlerprotokollen, den Felddaten der Ladezeiten und der Kostenrechnung. Eine amtliche Vorgabe für den Wechsel nennen die geöffneten Quellen nicht. Die Werte in der folgenden Tabelle sind deshalb redaktionelle Schwellen: Sie markieren den Punkt, an dem Sie prüfen sollten, nicht den Punkt, an dem Sie wechseln müssen. Ersetzen Sie sie durch Ihre eigenen Werte, sobald zwölf Monate Betrieb vorliegen.
Die Signale mit Schwellenwerten
Die Tabelle ordnet jedem Signal die Messquelle, eine redaktionelle Schwelle und die erste Prüfung zu, bevor Sie über einen Wechsel sprechen.
| Signal | Wie Sie messen | Redaktionelle Schwelle | Was Sie zuerst prüfen |
|---|---|---|---|
| Wartezeit auf eine Anpassung | Änderungsprotokoll: Datum der Freigabe bis zum Livegang, Mittel über zwölf Monate | über acht Wochen im Mittel oder feste Release-Termine als einziger Weg | Kann eine Vorlage, eine Einstellung oder ein Testzugang die Änderung früher liefern? |
| Sicherheitskorrekturen | Veröffentlichungen von Kernversion und Erweiterungen, dazu das Datum der Installation | nicht binnen 30 Tagen verfügbar oder installierbar | Wird die eingesetzte Version noch unterstützt, und gibt es einen Patch-Weg? |
| Zahl der Änderungen | Änderungsprotokoll je Kalenderjahr | mehr als 24 Änderungen im Jahr, die eine Codeänderung verlangen | Lassen sich wiederkehrende Anfragen in Einstellungen oder Vorlagen abbilden? |
| Fehlerrate im Kaufvorgang | Fehlerprotokoll: Kaufversuche und technisch fehlgeschlagene Versuche über vier Wochen | über ein Prozent der Kaufversuche | Liegt der Fehler im Shop, im Zahlungsdienst oder in einer Erweiterung? |
| Ladezeiten | Core Web Vitals der Felddaten am 75. Perzentil, getrennt nach Mobilgerät und Desktop | LCP über 2,5 Sekunden, INP über 200 Millisekunden oder CLS über 0,1 | Serverressourcen, Bilder, Skripte und Cache einzeln messen |
| Erreichbarkeit | eigene Verfügbarkeitsmessung je Monat, geplante Wartung getrennt gezählt | über 3,6 Stunden ungeplanter Ausfall im Monat | Ursache in Hosting, Datenbank oder Anwendung trennen |
| Arbeitszeit je Änderung | Rechnungen und Stunden je Änderung über zwölf Monate | über vier Stunden oder 360 Euro je Standardänderung, Tendenz steigend | Aufwand derselben Änderung im Zielsystem an einem Testzugang gegenrechnen |
| Kosten je Bestellung | Kostenrechnung des Shops je Jahr, geteilt durch die Bestellungen | Anstieg zwei Jahre in Folge, obwohl die Bestellzahl wächst | Sind es Lizenz-, Dienst- oder eigene Personalkosten? |
Die Fehlerrate zählen Sie in Kaufversuchen, nicht in Sitzungen: Ein Kaufversuch ist jeder Vorgang, der in eine Bestellung münden soll. Als technischer Fehler zählt eine Serverantwort mit Fehlercode oder ein abgebrochener Zahlungsschritt; ein Abbruch durch die Kundschaft gehört nicht dazu.
Für die Ladezeiten stützt sich die Zeile auf die Dokumentation von Google: Die drei Werte gelten dort am 75. Perzentil der Seitenaufrufe, getrennt für Mobilgeräte und Desktop, als Ziel. Google Search Central schreibt, dass diese und andere Aspekte der Nutzerfreundlichkeit den Anforderungen der Ranking-Systeme entsprechen (Stand der Seite: 18. Dezember 2025).
Die Erreichbarkeit rechnen Sie in Ausfallzeit um: Die Verfügbarkeitstabelle des Google-SRE-Buchs ordnet 99,5 Prozent Verfügbarkeit ohne geplante Wartung 3,6 Stunden je Monat zu. Geplante Wartungsfenster sind in diesen Werten nicht enthalten und zählen Sie deshalb getrennt.
So rechnen Sie, ob sich der Wechsel lohnt
Ein einzelnes Signal sagt noch nichts über den Nutzen. Ob der Wechsel wirtschaftlich ist, entscheidet die Amortisation: einmalige Wechselkosten geteilt durch den jährlichen Aufwand des Umwegs, vermindert um die jährlichen Mehrkosten des neuen Systems. Die Rechnung setzt dabei voraus, dass der Wechsel den gesamten Umweg-Aufwand beseitigt; nur dann ist die Differenz aus Umweg und Mehrkosten des neuen Systems der jährliche Vorteil. Die folgende Beispielrechnung unterstellt genau das. In Ihrem Fall setzen Sie stattdessen nur die angenommene Differenz zwischen Alt- und Zielsystem ein. Die Zahlen sind erfunden (Beispielrechnung) und dienen nur dem Rechenweg.
| Position | Rechnung | Fall A | Fall B |
|---|---|---|---|
| Bestellungen im Monat | Annahme | 400 | 400 |
| Deckungsbeitrag je Bestellung | 35 Prozent von 60 Euro | 21 Euro | 21 Euro |
| Technisch fehlgeschlagene Kaufversuche im Monat | Fehlerprotokoll | 14 | 40 |
| Verlorener Deckungsbeitrag im Jahr | Deckungsbeitrag mal fehlgeschlagene Versuche mal zwölf | 3.528 Euro | 10.080 Euro |
| Änderungen im Jahr | Änderungsprotokoll | 16 | 40 |
| Aufwand je Änderung | 4 Stunden zu 90 Euro | 360 Euro | 360 Euro |
| Aufwand der Änderungen im Jahr | Änderungen mal Aufwand je Änderung | 5.760 Euro | 14.400 Euro |
| Aufwand des Umwegs im Jahr | verlorener Deckungsbeitrag plus Aufwand der Änderungen | 9.288 Euro | 24.480 Euro |
| Jährliche Mehrkosten des neuen Systems | Annahme 200 Euro je Monat | 2.400 Euro | 2.400 Euro |
| Einmalige Wechselkosten | Angebote | 22.000 Euro | 22.000 Euro |
| Amortisation (Annahme: Umweg entfällt ganz) | Wechselkosten geteilt durch (Aufwand des Umwegs minus Mehrkosten) | 3,2 Jahre | 1,0 Jahr |
Im Fall A dauert die Amortisation 3,2 Jahre und liegt damit über der redaktionellen Frist von 24 Monaten: Bei diesen Zahlen tragen sich die Wechselkosten in zwei Jahren nicht, und die Alternativen unten sind zuerst zu prüfen. Im Fall B liegt sie bei rund einem Jahr; dort ist ein Wechselprojekt wirtschaftlich zu begründen. Die 24 Monate sind eine Vorgabe dieses Beitrags, keine amtliche Frist.
Was ein Mindestmaß an Änderungsmanagement ist
Der BSI-Baustein OPS.1.1.3 Patch- und Änderungsmanagement (IT-Grundschutz-Kompendium, Edition 2023) verlangt von Institutionen, die IT-Grundschutz anwenden, dass Patches und Änderungen geeignet geplant, genehmigt und dokumentiert werden und bei ihrer Installation Rückfall-Lösungen vorhanden sind; vorab getestet werden sollten sie (OPS.1.1.3.A1). A15 verlangt, Patches zeitnah nach Veröffentlichung zu bewerten und zu priorisieren. Der Baustein bindet nicht aus sich selbst; er gilt, wenn Gesetz oder Vertrag auf ihn verweisen. Als Prüfmaßstab taugt er trotzdem: Wer nicht sagen kann, wann zuletzt ein Patch eingespielt wurde und wie der Rückweg aussieht, hat für die Wechselentscheidung keine Grundlage.
Für Versionssprünge kommt eine zweite Quelle hinzu: Nach Semantic Versioning 2.0.0 erhöht sich die Hauptnummer (MAJOR) bei Änderungen, die nicht abwärtskompatibel sind. Behandeln Sie ein solches Upgrade als eigenes Projekt mit Testfällen und einer Rückfall-Lösung; wie Tests und Freigaben aufgebaut werden, beschreibt der BSI-Baustein OPS.1.1.6.
Was Sie vor dem Wechsel versuchen können
Ein Systemwechsel greift mehrere Ursachen zugleich an; wie teuer er gegenüber den anderen Wegen ist, entscheiden die eingeholten Angebote und Ihre eigenen Zahlen. Die Tabelle stellt sechs Wege nebeneinander; prüfen Sie sie von oben nach unten als Prüfreihenfolge dieses Beitrags.
| Alternative | Was sie löst | Was sie nicht löst |
|---|---|---|
| Fehlerquelle eingrenzen | Fehler aus Bildern, Skripten, Server oder einer Erweiterung | fehlende Funktionen und einen langsamen Änderungsweg |
| Hauptversion aktualisieren | veraltete Software und fehlende Sicherheitskorrekturen | ein Datenmodell, das Ihre Prozesse nicht abbildet |
| Zusatzdienst für eine Aufgabe (Suche, Kaufabschluss, Produktdaten) | einen einzelnen Engpass, ohne alle Daten umzuziehen | den Engpass im Kern; jede Anbindung ist eine weitere Schnittstelle |
| Hosting und Ressourcen erhöhen | Laufzeiten und Ausfälle aus der Umgebung | Wartezeiten im Änderungsprozess und fehlende Funktionen |
| Vorlagen und Selbstbedienung ausbauen | Änderungsstau bei wiederkehrenden Anfragen | Anforderungen, die eine Codeänderung verlangen |
| Systemwechsel | mehrere Ursachen zugleich | nichts ohne Datenübernahme, Test und Umstellung |
Alles, was über eine Einstellung hinausgeht, bekommt denselben Test- und Rückweg wie ein Umzug. Wie ein Systemwechsel abläuft, steht unter Shopsystem wechseln; welche Kosten das Zielsystem mitbringt, rechnen Sie mit den Gesamtkosten eines Shopsystems und dem Vergleich Monolith oder Headless. Bleibt der Engpass der Änderungsweg selbst, prüfen Sie vorher einen getrennten Frontend-Aufbau (Headless Commerce) und den Lebenszyklus des Systems (Update-Politik und Versionen).
Typische Fehler
- Nach Gefühl wechseln. Ohne Zahlen aus zwölf Monaten lässt sich hinterher nicht sagen, ob der Wechsel das Problem gelöst hat. Erheben Sie die Kennzahlen vor der Entscheidung.
- Die Ursache im System vermuten. Ladezeiten und Fehler stammen auch aus Bildern, Drittanbieter-Skripten, Erweiterungen oder dem Hosting. Messen Sie je Ursache, bevor Sie migrieren.
- Nur Listenpreise vergleichen. Die laufenden Kosten und die Wechselkosten entscheiden. Rechnen Sie mit den Positionen Ihrer eigenen Kostenrechnung.
- Anpassungen als Systemfunktion zählen. Prüfen Sie für jede Eigenentwicklung aus dem Altsystem, ob sie im Zielsystem kompatibel ist und übernommen werden kann, und berücksichtigen Sie nötige Anpassungen, Neubauten oder Ersatz. Zählen Sie sie, bevor Sie Angebote einholen.
- Wartezeit und Ausfall verwechseln. Lange Freigabewege und technische Ausfälle brauchen unterschiedliche Gegenmaßnahmen. Ein Wechsel behebt nicht automatisch beide.
So gehen Sie vor
- Legen Sie den Messzeitraum fest: zwölf Monate für Änderungen und Kosten, vier Wochen für Fehlerrate, Ladezeiten und Erreichbarkeit.
- Führen Sie ein Änderungsprotokoll mit Zweck, Freigabedatum, Livegang, Stunden und Kosten je Änderung.
- Erheben Sie die Fehlerrate aus dem Fehlerprotokoll und die Ladezeiten aus den Felddaten, getrennt nach Mobilgerät und Desktop.
- Vergleichen Sie Ihre Werte mit den Schwellen und halten Sie je Signal schriftlich fest, ob es überschritten ist.
- Rechnen Sie die Amortisation des Wechsels und danach den Aufwand jeder Alternative aus der Tabelle.
- Erst wenn der Aufwand des Umwegs bleibt und die Amortisation unter Ihrer Frist liegt, planen Sie das Projekt, holen Angebote ein und legen Rückweg und Abbruchkriterien fest.
Kann Ihr System eine Anforderung gar nicht erfüllen, hilft der Kennzahlenvergleich nicht weiter: Solche Anforderungen sammeln Sie als Liste und prüfen die Kandidaten danach aus (Shopsystem auswählen).