Unsere Shopify-Ausstiegsstrategie: Headless-E-Commerce-Alternativen im Vergleich

Shopify beherrscht seine Aufgabe sehr gut. Die Conversion im Checkout ist hoch, das App-Ökosystem umfangreich und die Zuverlässigkeit im Betrieb ausgezeichnet. Für Händler, die Produkte verkaufen möchten, ohne Infrastruktur aufzubauen, ist das Leistungsangebot überzeugend. Das sollte klar gesagt werden, bevor wir erläutern, warum wir unseren Shop dort geschlossen haben: Die Entscheidung fiel nicht, weil Shopify grundsätzlich unzureichend wäre. Vielmehr passte es schlecht zu den konkreten betrieblichen Anforderungen, die sich bei uns angesammelt hatten.

Die meisten Berichte über einen „Ausstieg aus Shopify“ drehen sich um Transaktionsgebühren, Einschränkungen der Themes oder den Wunsch nach einer individuellen Shopoberfläche. Das sind reale Gründe, aber nicht die entscheidenden. Grundlegender ist, dass Shopify auf einen bestimmten Händlertyp ausgerichtet ist: hohes Verkaufsvolumen, standardisierter Katalog, Direktverkauf an Endkunden. Weichen Ihre Anforderungen von diesem Profil ab, werden die Grenzen der Plattform zum Hindernis.

Was Shopify gut löst

Der Checkout ist das stärkste Argument für Shopify. Jahrelange Optimierung über Millionen von Shops hat einen Ablauf hervorgebracht, der Käufe erfolgreich abschließt, Sonderfälle sauber behandelt und Zahlungsmethoden verschiedener Märkte ohne individuelle Integrationsarbeit einbindet. Einen vergleichbaren Checkout von Grund auf zu entwickeln ist ein mehrmonatiges Projekt mit erheblichem dauerhaftem Wartungsaufwand.

Ebenso ausgereift sind die Funktionen für den laufenden Betrieb: Bestellverwaltung, Fulfillment, Retouren und Kundendienstwerkzeuge. Die Verwaltungsoberfläche gibt klare Abläufe vor, beruht aber auf fundierter Erfahrung damit, wie E-Commerce-Workflows im großen Maßstab funktionieren. Teams, die nichttechnische Mitarbeiter in die Bestellverwaltung einarbeiten müssen, finden die Bedienung von Shopify deutlich einfacher als die jeder derzeit verfügbaren Headless-Alternative.

Trotz seines Rufs für versteckte Kosten löst das App-Ökosystem echte Probleme. Bewertungsplattformen, Abonnementabrechnung, Treueprogramme und erweiterte Datenanalysen funktionieren als Integrationen, weil Shopify die dafür benötigten Webhooks, Datenmodelle und Authentifizierung standardisiert hat. In einer Headless-Architektur muss jede dieser Integrationen individuell entwickelt oder von Anbietern bezogen werden, die Ihre gewählte Plattform möglicherweise nicht nativ unterstützen.

Welche Einschränkungen zum Hindernis wurden

Die i18n-Einschränkungen waren der erste Reibungspunkt. Shopifys Unterstützung für mehrere Sprachen hat sich gegenüber den Anfängen deutlich verbessert, behandelt nicht englischsprachige Märkte aber weiterhin als nachrangig. Inhalte in einem Dutzend Sprachen über die Shopify-Verwaltung zu pflegen ist im Betrieb mühsam, und mit wachsendem Katalog nehmen diese Schwierigkeiten zu. Übersetzungs-Apps helfen, verursachen aber Kosten und zusätzliche Komplexität bei der Synchronisierung, die eine native Lösung vermeiden würde.

Mit der Zeit wurde die Kontrolle über die Daten zur grundlegenderen Frage. Alle wesentlichen Betriebsdaten – Bestellverlauf, Kundendaten und Produktkatalog – liegen in Shopifys Datenbank und sind über eine von Shopify kontrollierte API zugänglich. Deren Aufruflimits, die Regeln zur Datenaufbewahrung und die Exportformate bestimmt Shopify, nicht der Händler. Für Teams, die Analysen auf ihren eigenen Betriebsdaten ausführen müssen, ist das eine strukturelle Einschränkung und keine Konfigurationsfrage.

Ein drittes Hindernis war die Komplexität der Preismodelle. Produkte mit vielen Varianten, kundensegmentspezifische Preise und angebotsbasierte Abläufe für Geschäftskunden stoßen an Shopifys Variantenlimits (100 pro Produkt, bis Shopify das Limit im Oktober 2025 auf 2.048 erhöhte) und Preisstrukturen. Dafür werden immer kompliziertere Umgehungslösungen nötig. Die daraus entstehende Komplexität der Liquid-Vorlagen wird zur Wartungslast, die mit dem Katalogwachstum schlecht skaliert.

Der Vergleich: Medusa v2, Saleor und Commerce.js

Die Bewertung folgte vier Kriterien: Kontrolle über die Daten (vollständige Datenbankkontrolle, keine vom Anbieter vorgegebenen API-Limits), Umfang der i18n-Unterstützung (native Unterstützung für mehrere Währungen und Sprachen sowie regionale Preise), Entwicklerfreundlichkeit (Dokumentationsqualität, TypeScript-Unterstützung und lokaler Entwicklungsablauf) und Reife im Betrieb (Produktivinstallationen, bekannte Fehlerbilder und Größe der Community).

Medusa v2 schnitt bei der Entwicklerfreundlichkeit am besten ab. Die Neuentwicklung in v2 verbessert die ursprüngliche Architektur erheblich: Das Modulsystem ist gut durchdacht, die TypeScript-Typen sind umfassend und die lokale Entwicklung ist schnell. Die Dokumentation hat sich deutlich verbessert und zeigt, dass das Team die Entwicklerfreundlichkeit ernst nimmt. Die Grenze liegt in der betrieblichen Reife: v2 ist relativ neu (Medusa 2.0 erschien im Oktober 2024), und Berichte über Produktivinstallationen sind seltener und weniger vielfältig als bei etablierten Plattformen. Teams, die zu Medusa wechseln, gehören damit tatsächlich zu den frühen Anwendern.

Saleor ist von den drei Plattformen am stärksten in der Praxis erprobt, mit mehr Produktivinstallationen und einer sehr gut konzipierten GraphQL-API. Die Mehrkanalarchitektur mit getrennten „Kanälen“ für unterschiedliche Märkte, Shopoberflächen oder Kundensegmente bewältigt die Preis- und Katalogkomplexität, die uns von Shopify weggeführt hat, eleganter als die Alternativen. Die betriebliche Reife ist unter den drei geprüften Plattformen am höchsten. Dafür ist die Lernkurve steiler, und die konsequent auf GraphQL ausgerichtete API erfordert Investitionen in Werkzeuge, bevor produktives Arbeiten möglich wird.

Commerce.js nimmt eine andere Position ein: Es ist eine Headless-API statt einer vollständigen Handelsplattform und darauf ausgelegt, mit anderen Diensten kombiniert zu werden. Für Teams mit starken Entwicklungsressourcen, die jede Komponente detailliert kontrollieren möchten, ist das eine passende Wahl. Für Teams, die Shopifys Betriebsaufwand reduzieren möchten, ohne vergleichbaren Entwicklungsaufwand in anderer Form aufzubauen, ist es wahrscheinlich weniger geeignet. Als gehostete API bietet es außerdem keine vollständige Kontrolle über die Datenbank, unser erstes Kriterium. Stand Oktober 2026 hat Chec, das Unternehmen hinter Commerce.js, seine GitHub-Organisation archiviert (im Oktober 2024). Prüfen Sie daher den aktuellen Status des Dienstes, bevor Sie ihn in Betracht ziehen.

Der Migrationsweg

Der am stärksten unterschätzte Aufwand eines Plattformwechsels liegt in der Datenmigration, nicht in der Migration der Codebasis. Produktkatalog, Kundendaten und Bestellverlauf von Shopify auf eine neue Plattform zu übertragen erfordert individuelle Extraktionsskripte, Datenumwandlungen für das Zielschema und einen sorgfältigen Umgang mit Sonderfällen. Produkte mit mehr als 100 Varianten, Kunden mit komplexen Adressverläufen und teilweise ausgelieferte Bestellungen machen zwar nur einen kleinen Teil der Datensätze aus, beanspruchen aber einen großen Teil der Entwicklungszeit für die Migration.

Der betriebliche Übergang – die Phase, in der Bestellungen während der Validierung der Migration durch beide Systeme laufen müssen – verlangt sorgfältige Planung, um doppelte Auslieferungen oder Kundenmitteilungen zu vermeiden. In dieser Phase treten bei den meisten Migrationen zuvor nicht eingeplante Probleme auf: Die entscheidenden Sonderfälle hängen vom jeweiligen Katalog und Bestellverlauf des Händlers ab und sind keine allgemeinen E-Commerce-Probleme.

Die Erkenntnis aus dieser Bewertung und der Beobachtung ähnlicher Entscheidungen anderer Teams lautet: Die Plattformwahl ist weniger entscheidend als die Qualität der Migrationsplanung. Medusa und Saleor können beide einen E-Commerce-Produktivbetrieb unterstützen, wie es Commerce.js zum Zeitpunkt unserer Bewertung konnte. Erfolgreich sind bei Headless-Migrationen die Teams, die vor dem Beginn in das Verständnis der Unterschiede zwischen den Datenmodellen investieren, statt erst während der Migration.