Soll Ihr Shop headless werden oder seine bestehende Plattform verbessern?

Drei Entscheidungen vor dem Plattformvergleich trennen

Ein neues Frontend, ein neuer Checkout und ein neues Commerce-Backend sind unterschiedliche Vorhaben. Ein Team kann Shopify behalten und sein Theme durch ein separates Frontend ersetzen. Die Shopify-Dokumentation zum Storefront-API-Warenkorb beschreibt eine Checkout-URL, die Käufer zum Shopify-Checkout führt. Ein eigenes Frontend bedeutet daher keine uneingeschränkte Kontrolle über jeden Checkout-Schritt. Prüfen Sie benötigte Erweiterungspunkte für den gewählten Tarif und die Integration vor der Architekturfreigabe.

Headless beschreibt diese Trennung. Composable Commerce setzt Funktionen aus Komponenten zusammen; es verlangt nicht, jede Funktion auf ein anderes Produkt zu verteilen. Formulieren Sie zuerst eine beobachtbare Einschränkung: Ein Konfigurator kann nötige Optionen nicht darstellen, zwei Kanäle benötigen denselben Katalog mit unterschiedlicher Präsentation oder der Redaktionsprozess unterstützt den vorgesehenen Kaufablauf nicht. „Der Shop wirkt alt“ ist ein Gestaltungsauftrag, noch kein ausreichender Grund für einen Backend-Wechsel.

Der Leitfaden zur CMS-Auswahl behandelt Redaktion und Wiederverwendung von Inhalten. Hier geht es um Bestellungen, Zahlungen und Betriebsverantwortung. Die E-Commerce-Entwicklung übersetzt solche Einschränkungen in einen umsetzbaren Projektumfang.

Den gesamten Betriebsaufwand vergleichen

Lassen Sie Angebote nach Discovery, Frontend, Commerce-Konfiguration, Datenmigration, Integrationen, Tests und Umstellung aufteilen. Ergänzen Sie laufende Plattform- und App-Gebühren, Frontend-Hosting, Monitoring, Updates, Störungsbehebung und Redaktionssupport. Zahlungsgebühren und interner Betriebsaufwand müssen sichtbar bleiben. Eine allgemeingültige prozentuale Ersparnis durch Headless lässt sich nicht seriös nennen: Mehr Frontend-Freiheit kann zugleich ein zusätzlich zu betreibendes System schaffen.

Benennen Sie die verantwortliche Datenquelle für Katalogattribute, verkaufbaren Bestand, Preise, Bestellungen, Zahlungen und Rückerstattungen. Die Zuständigkeit darf je Datensatz unterschiedlich sein. Unterscheiden Sie physischen Bestand, verfügbare Verkaufsmenge und Reservierungen. Legen Sie fest, wann eine Variante bei veralteter Bestandsquelle nicht mehr verkauft werden darf. Eine schnellere Seite korrigiert keine Bestandsregel ohne Zuständigen.

Einen echten Bestellablauf im Pilot testen

Illustratives Beispiel, kein Kundenergebnis: Ein Händler behält sein Commerce-Backend und erstellt für eine Produktfamilie ein separates Frontend. Der Test umfasst Variantenauswahl, Rabatt, Versandoption, Zahlung, Lagerexport, Versandnachricht und Teilrückerstattung. Führen Sie denselben Ablauf im bestehenden Shop aus, damit beide Varianten mit denselben Regeln und Daten verglichen werden.

Testen Sie repräsentative Mobilgeräte und langsamere Verbindungen, nicht nur den Entwickler-Laptop. Dokumentieren Sie Umgebung, Plattform- und API-Versionen, Testprodukte, Soll- und Ist-Ergebnis sowie den Ablageort der Nachweise. Prüfen Sie außerdem eine nicht verfügbare Variante, einen abgelaufenen Rabatt, eine abgelehnte Zahlung, eine unterbrochene Browsersitzung und eine Adresse, die die Versandmöglichkeiten verändert. Vereinbaren Sie, welche Fehler den Start verhindern und welche mit Termin in einen Folge-Backlog dürfen. Leistungs- und Verfügbarkeitsziele ergeben sich aus Ausgangswerten und Geschäftsbedarf, nicht aus einer beliebigen Branchenzahl.

Das Team soll außerdem ohne Entwickler einen Preis ändern, Inhalte in der Vorschau prüfen und eine Retoure bearbeiten. Ein erfolgreicher Kauf bei unbrauchbaren internen Abläufen reicht nicht. Erhalten Sie das Einwilligungsverhalten und prüfen Sie, dass Analytics denselben Kauf nicht im Frontend und im Checkout doppelt zählt.

Doppelte und fehlende Ereignisse beherrschen

Die Shopify-Dokumentation zur Webhook-Prüfung beschreibt Signaturprüfung und das Erkennen doppelter Zustellungen. Das sind unterschiedliche Aufgaben: Eine berechtigte Wiederholung darf keine zweite Lieferung oder Rückerstattung auslösen. Speichern Sie die Verbindung zwischen Bestellung, Zahlungstransaktion und Folgeoperation dauerhaft und sichern Sie Wiederholungen auf Ebene des Geschäftsvorgangs ab.

Illustrative Abstimmungsübung: Erstellen Sie zehn Testbestellungen mit jeweils einer erfolgreich eingezogenen Zahlung. Erstatten Sie eine davon vollständig. Erwartet werden zehn bezahlte Bestellungen und eine vollständige Rückerstattung, nicht neun Bestellungen. Gleichen Sie Commerce-Datensätze, Zahlungstransaktionen und Lagerexporte anhand stabiler Kennungen, Währung und Betrag ab. Scheitert der Bestellexport nach erfolgreicher Zahlung, muss die Abwicklung wiederhergestellt oder die Bestellung geklärt werden; der Käufer wird nicht erneut belastet. Unerwartete Differenzen gehören zu einem benannten Verantwortlichen. Summen dürfen nicht stillschweigend passend gemacht werden.

Stellen Sie ein Ereignis absichtlich zweimal zu, halten Sie ein anderes zurück und verarbeiten Sie eine Änderung verspätet. Prüfen Sie, dass Duplikate keine zweite Geschäftswirkung haben, fehlende Verarbeitung beim Abgleich auffällt und ein verspätetes Ereignis keinen neueren gültigen Zustand überschreibt. Abgleichfrequenz und Eskalationsfristen gehören in den vereinbarten Umfang. Dies sind vorgeschlagene Abnahmetests, keine Behauptungen über die Standardeinstellungen jeder Plattform.

Die Medusa-Dokumentation zu Events und Subscribers unterscheidet asynchrone Folgeaktionen von notwendigen Schritten eines Commerce-Ablaufs. Prüfen Sie jede Komponentenarchitektur darauf: Eine zwingende Bestellvalidierung darf nicht wie eine optionale Benachrichtigung behandelt werden, die nach Bestellabschluss ausfallen kann. Quellen geprüft am 3. November 2026.

Rückkehr zur alten Version ohne Verlust der Bestellhistorie proben

Beginnen Sie nur dann mit einem begrenzten Frontend-Rollout, wenn alter und neuer Weg sicher dasselbe vorgesehene Backend nutzen können. Benennen Sie die Person, die zurückschalten darf, und testen Sie den alten Weg während des Piloten. Erhalten Sie Warenkörbe, soweit unterstützt, sowie wichtige URLs. Prüfen Sie Weiterleitungen, Canonicals, Sprachrouten und Rücklinks aus dem Checkout. Das Zurücksetzen von Frontend-Code macht eine eingezogene Zahlung nicht rückgängig.

Ein Backend-Wechsel benötigt einen eigenen Umstellungsplan. Halten Sie fest, welches System neue Bestellungen annehmen darf, welcher Datenstand übertragen wurde, welcher Endbestand gilt und wie Bestellungen rund um die Umstellung zur Abwicklung gelangen. Vermeiden Sie zwei unabhängige Schreiber für dieselbe Bestellung oder denselben Bestandsdatensatz. Versprechen Sie nach unumkehrbaren Datenänderungen keinen sofortigen Rollback. Testen Sie, ob eine Vorwärtskorrektur, ein Exportabgleich oder eine kontrollierte Bestellpause erforderlich ist.

Nach dem Pilot die kleinste passende Änderung beauftragen

Verbessern Sie den bestehenden Shop, wenn er den erforderlichen Ablauf mit weniger Betriebsaufwand erfüllt. Wählen Sie ein separates Frontend, wenn es die gemessene Einschränkung beseitigt und das Team die zusätzliche Verantwortung übernimmt. Ersetzen Sie das Backend erst, wenn dessen Commerce-Grenzen auch nach realistischen Erweiterungsversuchen bestehen bleiben.

Der veröffentlichte MyMerch-Fall belegt Shopify-Prozess- und Frontend-Arbeit. Er dokumentiert keine Headless-Migration und belegt keine Conversion-Steigerung für Ihren Shop. Bringen Sie den fehlerhaften Ablauf, die Systemliste und die Pilot-Ergebnisse in ein Gespräch zur Commerce-Abgrenzung mit. Diese Informationen sind nützlicher als ein bevorzugtes Architektur-Schlagwort.