Shopify vs. OXID eSales

OXID eSales ist ein Shopsystem aus Freiburg, das Du selbst betreibst. Server, Datenbank, PHP-Version und Deployment liegen bei Dir oder Deinem Hoster. Shopify liefert dieselbe Ebene als Dienst: Du bekommst Storefront, Checkout und Admin, aber keinen Zugriff auf die Infrastruktur darunter.

Dieser Unterschied entscheidet mehr als jede Funktionsliste. Beim Selbstbetrieb bestimmst Du, wo die Daten liegen, wann ein Update eingespielt wird und welche Bibliothek in welcher Version läuft. Dafür trägst Du Verfügbarkeit, Sicherheit und Lastspitzen selbst, mit eigenem Personal oder einem Dienstleister mit Bereitschaft.

Bei Shopify entfällt diese Schicht. Skalierung an Aktionstagen, Sicherheitspatches und Plattform-Updates laufen ohne Dein Zutun. Der Preis dafür ist Verbindlichkeit: Checkout-Logik, Datenhaltung und Release-Termine folgen dem Anbieter. Wer regulatorisch begründen muss, wo Bestelldaten liegen, klärt diesen Punkt besser früh als spät.

OXID stellt eine Community Edition als Open Source bereit, darüber liegen kommerzielle Editionen mit erweitertem Funktionsumfang und Herstellersupport. Konkrete Zahlen nennen wir hier bewusst nicht, weil sie sich ändern. Wichtiger ist die Struktur: Ein freier Download ist noch kein Kostenmodell.

Zum Selbstbetrieb gehören Hosting, Monitoring, Backups, Sicherheitsupdates, Testumgebungen und die Entwicklerzeit für Versionssprünge. Diese Posten stehen in keiner Lizenzübersicht, tauchen aber jeden Monat in Deinem Budget auf. Sie sind planbar, wenn Du sie einmal sauber erfasst hast, und teuer, wenn nicht.

Shopify bündelt Betrieb, Skalierung und Updates in ein Abo, dazu kommen transaktionsabhängige Anteile und die Apps, die Dein Geschäft braucht. Die Kosten wachsen mit dem Umsatz statt mit der Infrastruktur. Vergleichbar werden beide Modelle erst über mehrere Jahre, nicht über eine Jahresrechnung.

OXID ist ein PHP-System, dessen Klassen Du erweitern kannst. Module greifen direkt in Preisfindung, Bestellstrecke und Datenmodell ein. Fast jede Anforderung lässt sich damit abbilden. Der Preis steht in der Zukunft: Jede Erweiterung am Kern musst Du bei jedem Versionssprung erneut prüfen.

Shopify dreht das um. Der Kern bleibt unberührt, Erweiterungen hängen sich über Apps, APIs und definierte Erweiterungspunkte an. Updates brechen dadurch selten etwas, dafür gibt es Grenzen: Tiefe Eingriffe in den Checkout stehen erst im Plus-Angebot offen, manche Sonderlogik lässt sich nicht abbilden.

OXID hat seine Stärke im B2B des deutschen Mittelstands. Kundengruppen, Staffel- und Sonderpreise, Freigabeprozesse, mehrere Mandanten unter einer Installation und die enge Kopplung an ein ERP sind dort seit Jahren gelebte Praxis und nicht erst nachträglich ergänzt worden. Das merkt man dem System an.

Shopify bildet B2B über Firmenprofile mit zugeordneten Katalogen, Zahlungszielen und Bestellberechtigungen ab. Das trägt viele Handelsmodelle sauber, gehört aber zum Plus-Angebot und ist damit eine Frage der Vertragsstufe. Sehr eigenwillige Preislogik oder mehrstufige Genehmigungsketten brauchen zusätzliche Arbeit über Apps oder eigene Erweiterungen.

Entscheide anhand Deiner tatsächlichen Prozesse, nicht anhand von Funktionslisten. Nimm die zehn häufigsten Vorgänge im Vertrieb und prüfe jeden einzeln gegen beide Systeme. Was dabei in mehr als zwei Sonderfällen endet, ist der eigentliche Kostentreiber Deines Projekts und gehört auf den Tisch.

Shopify legt Märkte über ein Storefront: Sprachen, Währungen, Preise und Domains pro Markt, aber eine Themebasis und ein Katalog. Das hält den Pflegeaufwand niedrig, solange sich die Märkte im Sortiment ähneln. Stark abweichende Kataloge je Land führen dagegen schnell zu Kompromissen.

OXID arbeitet mit Mandanten und Subshops. Jedes Land oder jede Marke bekommt eigene Konfiguration, eigenes Sortiment und eigene Regeln. Das ist mächtiger, wenn sich Märkte wirklich unterscheiden, und aufwendiger, wenn nicht: Jede Änderung will in jedem Mandanten nachgezogen und getestet werden.

OXID hat ein kleineres Partner- und Entwicklernetz als Shopware oder Shopify. Das ist kein Qualitätsurteil, sondern eine Ressourcenfrage: Es gibt weniger fertige Erweiterungen, weniger öffentlich dokumentierte Lösungswege und einen engeren Markt, wenn Du eine Stelle nachbesetzen oder einen Dienstleister wechseln willst.

Bei Shopify ist die Lage umgekehrt. Der Markt für Apps, Themes und Entwickler ist groß, was Auswahl schafft und zugleich Prüfarbeit erzeugt. Du verlagerst einen Teil Deiner Abhängigkeit von eigenem Code auf Drittanbieter, deren Roadmap und Preisgestaltung Du nicht kontrollierst.

Ein Wechsel lohnt sich, wenn der Betrieb mehr Aufmerksamkeit bindet als das Geschäft. Typische Anzeichen: Ein Versionssprung wird seit Monaten verschoben, Änderungen am Shop hängen an einer einzelnen Person, und jede Kampagne beginnt mit der Frage, ob die Infrastruktur den Ansturm aushält.

Gegen einen Wechsel spricht, wenn Deine Kernprozesse tief im Code liegen und dort auch hingehören. Wer den Checkout an eigene Regeln bindet, Bestelldaten aus Compliance-Gründen im eigenen Haus halten muss oder ein ERP ohne API betreibt, findet in Shopify keine passende Antwort, sondern nur Umwege.

Zwischen beiden Polen liegt der Normalfall. Dann hilft ein nüchterner Schnitt: Welche Sonderlogik ist wirklich geschäftskritisch, welche ist nur historisch gewachsen. Häufig bleibt nach dieser Prüfung ein kleinerer Rest übrig, als die Diskussion vermuten lässt, und der Wechsel wird planbar.