Open Source oder SaaS: Was Sie beim Umstieg auf Shopify wirklich aufgeben
Shopware, Magento und WooCommerce sind Open Source, Shopify ist es nicht. Für viele Händler ist das der wichtigste Einwand gegen den Wechsel. Der Beitrag zeigt, was die Lizenz Ihres heutigen Shops tatsächlich regelt, an welcher Stelle Ihr Shop den offenen Code wirklich nutzt, wie viele Updates das im letzten Jahr bedeutet hat und welche Teile bei Shopify offen bleiben.
In Erstgesprächen mit Händlern, die heute auf Shopware oder Magento verkaufen, hören wir einen Satz regelmäßig, meist von der IT-Leitung: „Unser Shop ist Open Source. Bei Shopify gehört uns der Code nicht mehr, und wenn Shopify die Bedingungen ändert, sitzen wir fest.“
Der Einwand ist berechtigt, und er verdient eine genauere Antwort als „Shopify ist eben bequemer“. Denn hinter dem Satz stecken drei verschiedene Fragen: Was erlaubt mir die Lizenz heute? Was davon nutze ich tatsächlich? Und was gebe ich ab, wenn ich wechsle?
Shopify hat am 30. September einen Beitrag mit dem Titel Headless E-Commerce Open Source: Open Source oder SaaS? veröffentlicht. Er richtet sich an Unternehmen, die ein Headless-Setup planen, und kommt zu dem Schluss, dass beides kein Widerspruch sein muss: offene Technologien dort, wo Gestaltungsfreiheit zählt, und eine SaaS-Plattform für Infrastruktur, Wartung und Skalierung. Der fehlende Lizenzpreis sei nicht mit niedrigen Gesamtkosten gleichzusetzen.
Für einen Händler, der schon einen Open-Source-Shop betreibt, stellt sich die Frage von der anderen Seite. Er wählt nicht zwischen zwei neuen Modellen. Er hat Open Source bereits und will wissen, was er aufgibt. Dieser Beitrag beantwortet das in vier Schritten.
Open Source regelt den Code, nicht die Bedingungen
Eine Open-Source-Lizenz erlaubt Ihnen im Kern vier Dinge: die Software für jeden Zweck einzusetzen, ihren Code zu lesen, ihn zu verändern und ihn weiterzugeben. Sie regelt nicht, wer die Software pflegt, wie lange es Sicherheitsupdates gibt und zu welchen Konditionen Sie Erweiterungen bekommen. Das entscheidet der Hersteller, auch bei Open Source.
Wie weit diese beiden Ebenen auseinanderliegen können, haben die vergangenen Jahre gezeigt. Shopware hat 2025 eine Umsatzgrenze für die Community Edition eingeführt. Der Code blieb unter MIT, aber ab 1 Mio. € Bruttowarenwert im Jahr verlangt Shopware einen bezahlten Tarif, sonst entfällt der Zugang zum Plugin-Store. OXID hat die Community Edition 2022 auf nicht kommerzielle Nutzung beschränkt. Adobe hat Magento Open Source 2.4.6 im August ohne Sicherheitspatches zurückgelassen, während Adobe-Commerce-Kunden für dieselbe Version weiter Updates bekommen.
Lizenz und Bedingungen
Was offen ist und woran es trotzdem hängt
Die Lizenz regelt, was Sie mit dem Code tun dürfen. Ob Sie Updates, Plugins und Support bekommen, regeln Hersteller und Marktplatz. Bei sechs Systemen, die uns in Migrationsprojekten begegnen, liegen diese beiden Ebenen inzwischen weit auseinander.
Shopware 6
Community Edition
Umsatzgrenze seit 2025
- Frei
- Kern, Administration und Storefront. Shopware betont, dass die Community Edition vollständig unter MIT bleibt.
- Woran es hängt
- Seit dem 24. März 2025 gilt eine Fair Usage Policy. Ab 1 Mio. € Bruttowarenwert im Jahr ist ein Tarif ab Rise nötig. Ohne ihn sperrt Shopware den Zugang zu Shopware Account und Shopware Store, über die Store-Plugins gekauft und lizenziert werden.
Shopware 5
Community Edition
Wartung beendet
- Frei
- Der komplette Code, weiterhin öffentlich auf GitHub.
- Woran es hängt
- Shopware hat die Version Ende Juli 2024 eingestellt. Seitdem gibt es vom Hersteller keine Sicherheitsupdates mehr, nur noch kommerzielle Verlängerungen von Drittanbietern.
Magento Open Source
Kern von Adobe Commerce
Version entscheidet
- Frei
- Der Kern. Live Search, Produktempfehlungen und die B2B-Module gehören zu Adobe Commerce und damit zur kostenpflichtigen Lizenz.
- Woran es hängt
- Patches gibt es nur im regulären Support einer Version: für 2.4.6 seit dem 11. August 2026 nicht mehr, für 2.4.7 bis zum 31. Mai 2027, für 2.4.8 bis zum 31. Mai 2028. Den erweiterten Support danach bekommen nur Adobe-Commerce-Kunden.
WooCommerce
Plugin für WordPress
Erweiterungen im Jahresabo
- Frei
- Das Plugin selbst und alles, was im WordPress-Verzeichnis liegt.
- Woran es hängt
- Kostenpflichtige Erweiterungen aus dem Woo Marketplace laufen im Jahresabo. Ohne Verlängerung bleiben sie installiert, bekommen aber keine Updates und keinen Support mehr.
OXID eShop
Community Edition
Nur nicht kommerziell
- Frei
- Der Code liegt weiterhin öffentlich auf GitHub.
- Woran es hängt
- Für Versionen ab dem 15. August 2022 erlaubt die Lizenz der Community Edition nur Evaluieren, Testen und Proof of Concepts. Für den kommerziellen Einsatz verweist OXID auf den eigenen Vertrieb.
JTL-Shop
Community Free Edition
500 Artikel frei
- Frei
- Der Shop-Kern liegt unter MIT auf GitLab.
- Woran es hängt
- In der kostenlosen Edition kommen höchstens 500 Artikel aus JTL-Wawi in den Shop. Für mehr braucht es eine JTL-Edition ab JTL Advanced, seit September 2024 nur noch als Abonnement.
Zum Vergleich: Shopify
Abonnement
Kein offener Kern
- Frei
- Am Kern nichts. Offen sind Hydrogen, Liquid und die Entwicklerwerkzeuge, mehr dazu weiter unten im Beitrag.
- Woran es hängt
- Preise, Gebühren und Termine für technische Umstellungen legt Shopify fest. Als Shopify checkout.liquid abgeschaltet hat, mussten Händler ihre Checkout-Anpassungen nach Shopifys Zeitplan umbauen.
- Nutzung an Umsatz, Artikelzahl oder Version gebunden
- Wartung beendet oder kommerziell nicht frei
- Kern frei, Erweiterungen im Abo
Stand 2. Oktober 2026. Geprüft an den Lizenzdateien der Repositories auf GitHub und GitLab, an Shopwares Ankündigung zur Fair Usage Policy, Adobes Lifecycle Policy, der WooCommerce-Dokumentation zu Marketplace-Abos und dem JTL-Guide. Verträge mit Agenturen und Hostern kommen bei jedem System hinzu.
Das ist kein Vorwurf an die Hersteller. Wer eine Software entwickelt, muss damit Geld verdienen, und bei Open Source geschieht das eben über Tarife, Marktplätze und Support. Für Ihre Entscheidung folgt daraus aber etwas Wichtiges: Die Abhängigkeit von einem Hersteller gibt es auch heute. Sie liegt nur an einer anderen Stelle, nicht im Code, sondern bei Updates, Store-Zugang und Supportfenstern.
Der Vergleich mit Shopify lautet deshalb nicht „frei gegen abhängig“. Er lautet: welche Abhängigkeit, zu welchem Preis und mit wie viel eigener Arbeit. Wie Sie die Betriebskosten beider Seiten vollständig gegenüberstellen, steht in Shopsysteme vergleichen, wenn Sie schon eines betreiben. Und wie sich der Bruttowarenwert, an dem Shopwares Grenze hängt, beim Wechsel anders zählt, beschreibt Bruttowarenwert nach dem Plattformwechsel.
Was Sie am offenen Code tatsächlich nutzen
Von den vier Freiheiten der Lizenz nutzt ein Shop im Alltag vor allem die erste: Er läuft. Den Code liest meist die Agentur, wenn ein Fehler gesucht wird. Weitergegeben wird er praktisch nie. Bleibt das Verändern, und hier lohnt ein genauer Blick, denn nicht jede Anpassung braucht offenen Code.
Die meisten Änderungen an einem Shopware-, Magento- oder WooCommerce-Shop laufen über Wege, die der Hersteller dafür vorgesehen hat: Einstellungen im Backend, ein eigenes Theme, Plugins, die sich an dokumentierte Stellen im Ablauf hängen. Diese Wege gibt es auch bei Shopify, nur heißen sie anders und sind enger. Erst wenn jemand den Code des Systems selbst geändert hat, weil der vorgesehene Weg nicht reichte, nutzt Ihr Shop wirklich, dass der Code offen ist.
Inventur
Vier Ebenen der Anpassung, nur eine braucht offenen Code
Von außen nach innen: Je tiefer eine Anpassung liegt, desto stärker hängt sie am offenen Code. Die ersten drei Ebenen haben bei Shopify ein Gegenstück, die vierte nicht. Wählen Sie Ihr System.
Anpassungen in Shopware 6
-
Einstellungen
braucht keinen offenen Code
Heute
Administration, Regeln im Rule Builder, Abläufe im Flow Builder
Bei Shopify
Admin-Einstellungen, Rabatte, Shopify Flow
-
Theme und Templates
braucht keinen offenen Code
Heute
Twig-Templates mit sw_extends und SCSS im Theme-Plugin
Bei Shopify
Liquid-Theme mit Sections und Blocks
-
Erweiterungen über Schnittstellen
nutzt Erweiterungspunkte des Herstellers
Heute
Plugins in custom/plugins mit Event-Subscribern und Service-Decorators, Apps über die App-Schnittstelle
Bei Shopify
Apps, Functions, Checkout-Erweiterungen, Webhooks
-
Eingriffe in den Kern
braucht den offenen Code
Heute
Patches auf vendor/shopware, eingespielt per composer-patches
Bei Shopify
Gibt es nicht
So finden Sie die Liste
grep -n '"patches' composer.jsonJeder Treffer verweist auf eine Patch-Liste. Jede Zeile darin ist ein Eingriff in fremden Code.
Anpassungen in Magento 2
-
Einstellungen
braucht keinen offenen Code
Heute
Stores › Configuration, Warenkorb-Preisregeln
Bei Shopify
Admin-Einstellungen, Rabatte, Shopify Flow
-
Theme und Templates
braucht keinen offenen Code
Heute
Layout-XML und .phtml-Overrides unter app/design/frontend, auf Luma oder Hyvä
Bei Shopify
Liquid-Theme mit Sections und Blocks
-
Erweiterungen über Schnittstellen
nutzt Erweiterungspunkte des Herstellers
Heute
Module in app/code mit Plugins (Interceptors) und Observern
Bei Shopify
Apps, Functions, Checkout-Erweiterungen, Webhooks
-
Eingriffe in den Kern
braucht den offenen Code
Heute
preference-Einträge, die Magento-Klassen ersetzen, und Patches im Ordner patches/ oder m2-hotfixes/
Bei Shopify
Gibt es nicht
So finden Sie die Liste
grep -rl 'preference for="Magento' app/code --include=di.xmlgrep -n '"patches' composer.jsonDie erste Zeile listet Module, die Kernklassen austauschen, die zweite die Patch-Listen.
Anpassungen in WooCommerce
-
Einstellungen
braucht keinen offenen Code
Heute
WooCommerce › Einstellungen, Gutscheine, Versandzonen
Bei Shopify
Admin-Einstellungen, Rabatte, Versandprofile
-
Theme und Templates
braucht keinen offenen Code
Heute
Template-Overrides im Child-Theme unter woocommerce/, Code in functions.php
Bei Shopify
Liquid-Theme mit Sections und Blocks
-
Erweiterungen über Schnittstellen
nutzt Erweiterungspunkte des Herstellers
Heute
Plugins mit Actions und Filtern über add_action und add_filter
Bei Shopify
Apps, Functions, Checkout-Erweiterungen, Webhooks
-
Eingriffe in den Kern
braucht den offenen Code
Heute
Direkt geänderte Dateien im Ordner von WooCommerce oder in fremden Plugins
Bei Shopify
Gibt es nicht
So finden Sie die Liste
wp plugin verify-checksums --allMeldet jede Datei, die vom Original im WordPress-Verzeichnis abweicht. Gekaufte Erweiterungen vergleichen Sie mit dem Download des Herstellers.
Die Befehle laufen im Projektverzeichnis des Shops, bei WooCommerce mit WP-CLI. Eine leere Ausgabe heißt nicht, dass es keine Eingriffe gibt: Manche Projekte haben Kernklassen auch auf anderen Wegen ersetzt. Ihre Agentur kennt die Stellen meist aus dem Gedächtnis.
In den Projekten, die wir migrieren, ist die Liste der vierten Ebene meist kurz. Gerade deshalb lohnt es, sie vor der Plattformentscheidung vollständig zu kennen, denn sie ist die ehrliche Antwort auf die Frage, was Sie aufgeben. Jeder Eintrag fällt in eine von drei Gruppen.
Korrekturen, die sich erledigt haben. Viele Kern-Patches sind Fehlerbehebungen, die jemand vor Jahren eingespielt hat, bevor der Hersteller sie selbst ausgeliefert hat. Sie sind beim Umstieg schlicht hinfällig.
Geschäftsregeln am falschen Ort. Ein Rabatt, der in eine Kernklasse geschrieben wurde, weil es schneller ging als ein Plugin, ist eine Geschäftsregel. Bei Shopify wird sie zur Function, zur App oder zu einer Einstellung. Wohin welche Logik wandert, haben wir in Aus Plugins werden Dienste Schritt für Schritt aufgeschlüsselt.
Echte Abweichungen vom Standard. Das sind die Einträge, über die vor dem Wechsel gesprochen werden muss. Ein Beispiel ist eine eigene Logik für Bestellnummern, etwa mit Filialkürzel und Jahreszähler: Shopify erlaubt für die Bestellnummer nur ein Präfix und ein Suffix. Ein anderes ist ein zusätzlicher Schritt im Checkout, etwa für eine Prüfung vor der Zahlung. Die Reihenfolge der Checkout-Schritte ist bei Shopify fest. Für beides gibt es Umwege, aber keinen, der den alten Ablauf eins zu eins nachbildet.
Wenn Ihre Liste nur aus den ersten beiden Gruppen besteht, geben Sie beim Wechsel weniger auf, als der Satz „Shopify ist kein Open Source“ vermuten lässt. Wenn die dritte Gruppe lang ist oder Ihr Geschäftsmodell trägt, ist das ein ernstzunehmendes Argument für den Verbleib.
Was die Freiheit an Updates kostet
Der zweite Teil der Rechnung ist der Betrieb. Ein offenes System, das Sie selbst betreiben, gibt Ihnen die Freiheit, Updates einzuspielen, wann Sie wollen. Es nimmt Ihnen aber nicht die Pflicht ab, sie überhaupt einzuspielen. Wie oft das zuletzt nötig war, lässt sich aus den Veröffentlichungen der Hersteller auf GitHub genau zählen.
Oktober 2025 bis September 2026
Zwölf Monate Versionen, gezählt
Jeder Punkt ist eine Version, die ein Shop auf dieser Linie bewerten und in aller Regel einspielen musste, zusammen mit dem Test aller Plugins. Bei Shopify fällt diese Arbeit für den Kern weg. Was bleibt, betrifft nur Code, den Sie selbst geschrieben haben.
Shopware 6.7
Kern
- 6.7.3.0 am 06.10.2025, Funktionsversion
- 6.7.3.1 am 21.10.2025, Fehler- oder Sicherheitskorrektur
- 6.7.4.0 am 04.11.2025, Funktionsversion
- 6.7.4.1 am 12.11.2025, Fehler- oder Sicherheitskorrektur
- 6.7.4.2 am 14.11.2025, Fehler- oder Sicherheitskorrektur
- 6.7.5.0 am 02.12.2025, Funktionsversion
- 6.7.5.1 am 09.12.2025, Fehler- oder Sicherheitskorrektur
- 6.7.6.0 am 13.01.2026, Funktionsversion
- 6.7.6.1 am 14.01.2026, Fehler- oder Sicherheitskorrektur
- 6.7.6.2 am 20.01.2026, Fehler- oder Sicherheitskorrektur
- 6.7.7.0 am 02.02.2026, Funktionsversion
- 6.7.7.1 am 05.02.2026, Fehler- oder Sicherheitskorrektur
- 6.7.8.0 am 03.03.2026, Funktionsversion
- 6.7.8.1 am 11.03.2026, Fehler- oder Sicherheitskorrektur
- 6.7.8.2 am 18.03.2026, Fehler- oder Sicherheitskorrektur
- 6.7.9.0 am 16.04.2026, Funktionsversion
- 6.7.9.1 am 27.04.2026, Fehler- oder Sicherheitskorrektur
- 6.7.10.0 am 06.05.2026, Funktionsversion
- 6.7.10.1 am 19.05.2026, Fehler- oder Sicherheitskorrektur
- 6.7.10.2 am 01.06.2026, Fehler- oder Sicherheitskorrektur
- 6.7.11.0 am 16.06.2026, Funktionsversion
- 6.7.11.1 am 23.06.2026, Fehler- oder Sicherheitskorrektur
- 6.7.12.0 am 07.07.2026, Funktionsversion
- 6.7.12.1 am 07.07.2026, Fehler- oder Sicherheitskorrektur
- 6.7.12.2 am 23.07.2026, Fehler- oder Sicherheitskorrektur
- 6.7.13.0 am 05.08.2026, Funktionsversion
- 6.7.13.1 am 25.08.2026, Fehler- oder Sicherheitskorrektur
- 6.7.14.0 am 09.09.2026, Funktionsversion
- 6.7.14.1 am 16.09.2026, Fehler- oder Sicherheitskorrektur
- 6.7.14.2 am 23.09.2026, Fehler- oder Sicherheitskorrektur
30 Versionen
WooCommerce
Plugin, ohne Erweiterungen
- 10.3.0 am 22.10.2025, Funktionsversion
- 10.3.1 am 24.10.2025, Fehler- oder Sicherheitskorrektur
- 10.3.2 am 24.10.2025, Fehler- oder Sicherheitskorrektur
- 10.3.3 am 24.10.2025, Fehler- oder Sicherheitskorrektur
- 10.3.4 am 31.10.2025, Fehler- oder Sicherheitskorrektur
- 10.3.5 am 12.11.2025, Fehler- oder Sicherheitskorrektur
- 10.3.6 am 02.12.2025, Fehler- oder Sicherheitskorrektur
- 10.4.0 am 10.12.2025, Funktionsversion
- 10.4.2 am 12.12.2025, Fehler- oder Sicherheitskorrektur
- 10.4.3 am 22.12.2025, Fehler- oder Sicherheitskorrektur
- 10.5.0 am 06.02.2026, Funktionsversion
- 10.5.1 am 11.02.2026, Fehler- oder Sicherheitskorrektur
- 10.5.2 am 16.02.2026, Fehler- oder Sicherheitskorrektur
- 10.5.3 am 02.03.2026, Fehler- oder Sicherheitskorrektur
- 10.6.0 am 10.03.2026, Funktionsversion
- 10.6.1 am 12.03.2026, Fehler- oder Sicherheitskorrektur
- 10.6.2 am 31.03.2026, Fehler- oder Sicherheitskorrektur
- 10.7.0 am 14.04.2026, Funktionsversion
- 10.8.0 am 26.05.2026, Funktionsversion
- 10.8.1 am 28.05.2026, Fehler- oder Sicherheitskorrektur
- 10.9.0 am 23.06.2026, Funktionsversion
- 10.9.1 am 24.06.2026, Fehler- oder Sicherheitskorrektur
- 10.9.2 am 02.07.2026, Fehler- oder Sicherheitskorrektur
- 10.9.3 am 03.07.2026, Fehler- oder Sicherheitskorrektur
- 10.9.4 am 07.07.2026, Fehler- oder Sicherheitskorrektur
- 11.0.0 am 04.08.2026, Funktionsversion
- 11.0.1 am 10.08.2026, Fehler- oder Sicherheitskorrektur
- 11.1.0 am 03.09.2026, Funktionsversion
- 11.1.1 am 18.09.2026, Fehler- oder Sicherheitskorrektur
- 11.1.2 am 22.09.2026, Fehler- oder Sicherheitskorrektur
30 Versionen
Magento 2.4.8
Patches, dazu 2.4.9
- 2.4.8-p3 am 14.10.2025, Fehler- oder Sicherheitskorrektur
- 2.4.8-p4 am 10.03.2026, Fehler- oder Sicherheitskorrektur
- 2.4.8-p5 am 12.05.2026, Fehler- oder Sicherheitskorrektur
- 2.4.9 am 12.05.2026, Funktionsversion
4 Versionen
Shopify-Kern
Shopify spielt Änderungen laufend selbst ein
0 einzuspielen
Shopify-API
nur für eigene Apps und Functions
- 2025-10 am 01.10.2025, neue API-Version
- 2026-01 am 01.01.2026, neue API-Version
- 2026-04 am 01.04.2026, neue API-Version
- 2026-07 am 01.07.2026, neue API-Version
4 API-Versionen
Gezählt sind veröffentlichte Releases laut GitHub zwischen 1. Oktober 2025 und 30. September 2026, ohne Vorabversionen. Bei WooCommerce nur das Plugin, ohne WordPress und Erweiterungen. Bei Magento gibt Adobe für kritische Lücken zusätzlich einzelne Hotfixes heraus. Shopify veröffentlicht eine neue API-Version am ersten Tag jedes Quartals.
Nicht jede dieser Versionen muss am Tag ihres Erscheinens eingespielt werden. Bewertet werden muss jede, und bei Sicherheitskorrekturen bleibt wenig Spielraum. Bei Shopware kommt eine Regel hinzu, die in Wartungsverträgen oft untergeht: Direkt gepflegt wird nur die jeweils neueste Minor-Version. Ältere Stände bekommen Sicherheitskorrekturen nur noch über ein eigenes Security-Plugin. Wer zwei Monate nicht aktualisiert, ist also nicht automatisch ungeschützt, entfernt sich aber Schritt für Schritt vom gepflegten Stand.
Jedes dieser Updates trifft außerdem auf Ihre Plugins und auf Ihre Liste aus der vierten Ebene. Plugins müssen zur neuen Version passen. Kern-Patches müssen bei jedem Update neu geprüft und oft neu angepasst werden, weil sich der Code darunter geändert hat. Das ist der eigentliche Preis der vierten Ebene: nicht die einmalige Änderung, sondern ihre Pflege bei jedem Versionssprung.
Bei Shopify wird diese Pflicht kleiner, aber sie verschwindet nicht ganz. Für eigene Apps und Functions erscheint alle drei Monate eine neue API-Version. Jede wird mindestens zwölf Monate unterstützt, mit mindestens neun Monaten Überschneidung zur nächsten. Wer eigenen Code betreibt, muss ihn also etwa einmal im Jahr auf eine neuere Version heben. Apps aus dem App Store aktualisieren ihre Anbieter selbst.
Der ehrlichere Unterschied liegt woanders. Auf einem offenen System können Sie ein Update aufschieben, wenn es gerade nicht passt, auf Kosten der Sicherheit. Bei Shopify bestimmt Shopify den Kalender für Umstellungen. Als Shopify checkout.liquid abgeschaltet hat, mussten Händler ihre Checkout-Anpassungen auf die neuen Checkout-Erweiterungen umbauen, nach Shopifys Zeitplan, nicht nach ihrem. Solche Umstellungen kündigt Shopify lange vorher an, aber verhandelbar sind sie nicht. Was sich im Betrieb sonst noch verschiebt, von Servern bis zu Lastspitzen, steht in Eigener Server oder Cloud.
Was bei Shopify offen bleibt
Shopify ist keine Open-Source-Plattform, das schreibt Shopify im eigenen Beitrag selbst. Geschlossen ist aber vor allem der Kern: Katalog, Warenkorb, Checkout, Bestellungen und Kundenkonten. Um ihn herum liegt mehr offener und eigener Code, als viele Umsteiger erwarten.
Shopify, Schicht für Schicht
Wem welcher Baustein bei Shopify gehört
Von der Storefront bis zum Kern: Je weiter unten ein Baustein liegt, desto geschlossener ist er. Offen bleibt mehr, als der Satz „Shopify ist kein Open Source“ vermuten lässt, aber nicht der Teil, an dem Sie bisher Kern-Patches angebracht haben.
-
Hydrogen
Framework für eigene Storefronts, auf Basis von React
Code Offen, MIT-Lizenz
Betrieb Oxygen oder Ihr Hosting
Frei nutzbar und veränderbar. Die Daten holt die Storefront über die Storefront API, bezahlt wird im Checkout von Shopify.
-
Liquid
Template-Sprache der Themes
Code Offen, MIT-Lizenz
Betrieb Shopify
Die Sprache ist offen und steckt auch in Werkzeugen wie Jekyll. Die Objekte im Theme, etwa product oder cart, liefert nur Shopify.
-
CLI, App-Vorlage, Function-Beispiele
Werkzeuge für Themes, Apps und Functions
Code Offen, MIT-Lizenz
Betrieb Ihr Rechner, Ihre Pipeline
Damit werden Themes, Apps und Functions gebaut, getestet und ausgerollt.
-
Dawn und Horizon
Standard-Themes von Shopify
Code Einsehbar, nur für Shopify
Betrieb Shopify
Quelltext öffentlich auf GitHub, die Lizenz erlaubt die Nutzung nur für Themes auf Shopify. Abgeleitete Horizon-Themes dürfen nicht verkauft werden, die Lieferung an einen Händler für den eigenen Shop ist erlaubt.
-
Ihr Theme
eigenes oder angepasstes Liquid-Theme
Code Ihr Code
Betrieb Shopify
Mit der GitHub-Integration liegt es in Ihrem Repository, Änderungen aus dem Theme-Editor kommen dort als Commit an. Baut es auf Horizon auf, gilt dessen Lizenz mit.
-
Ihre Apps und Functions
eigene Logik an den Rändern
Code Ihr Code
Betrieb Apps: Sie, Functions: Shopify
Code und Repository gehören Ihnen. Functions laufen als WebAssembly bei Shopify. Eigene Functions in einer Custom App setzen Shopify Plus voraus.
-
Der Kern
Katalog, Warenkorb, Checkout, Bestellungen, Kundenkonten, Admin
Code Geschlossen
Betrieb Shopify
Nicht einsehbar und nicht veränderbar. Erreichbar über Admin API, Storefront API und Webhooks. Produkte, Kunden und Bestellungen lassen sich als CSV exportieren.
Lizenzen geprüft am 2. Oktober 2026 in den Repositories von Shopify auf GitHub. Welche Teile des Kerns sich über Functions und Checkout-Erweiterungen anpassen lassen, hängt teils vom Tarif ab.
Zwei Punkte daraus sind für Umsteiger besonders wichtig.
Ihr Theme gehört Ihnen, mit einer Einschränkung. Ein eigenes Liquid-Theme liegt mit der GitHub-Integration in Ihrem Repository, mit Versionsverlauf und allen Änderungen, auch denen aus dem Theme-Editor. Baut es auf Shopifys Standard-Theme Horizon auf, gilt dessen Lizenz mit. Sie dürfen das Theme für Ihren Shop nutzen und von Ihrer Agentur anpassen lassen, aber nicht als eigenes Produkt weiterverkaufen. Für die allermeisten Händler ist das keine Einschränkung, für Agenturen mit eigenen Themes schon.
Ihre Daten kommen wieder heraus. Produkte, Kunden und Bestellungen lassen sich als CSV exportieren, alles Weitere über die Admin API. Das ist kein Datenbank-Dump wie bei Ihrem heutigen Shop, und manches, etwa Menüs oder Metaobjekte, hat keinen Export im Admin. Aber der Weg hinaus existiert und ist dokumentiert. Welche Daten Sie wie sichern, haben wir in Datensicherung beim Shopify-Umstieg zusammengestellt.
Offenes Frontend, Backend als Dienst
Der Kern von Shopifys Beitrag ist die Kombination: ein Frontend mit offenen Technologien, ein Commerce-Backend als SaaS. Für Umsteiger kommt diese Variante in zwei Lagen vor.
Sie haben schon ein Headless-Frontend. Manche Shopware-Händler betreiben ihre Storefront mit Shopware Frontends auf Basis von Vue und Nuxt, manche Magento-Händler mit einem eigenen Next.js-Frontend. Hier lässt sich beim Umstieg mehr erhalten als bei einem klassischen Theme: Komponenten, Design und Seitenaufbau können bleiben. Neu geschrieben werden die Datenschicht gegen die Storefront API, der Warenkorb und die Kundenkonten. Der Checkout läuft danach immer bei Shopify, auch wenn alles davor Ihr eigener Code ist.
Sie haben ein klassisches Theme. Dann ist Headless kein Weg, Open Source zu behalten, sondern ein zusätzliches Projekt mit eigenem Betrieb. Hydrogen ist offen und gut gemacht, aber ein eigenes Frontend braucht dauerhaft Entwicklerinnen und Entwickler, die es pflegen. Wann sich das lohnt, haben wir in Headless Commerce: Welche Vorteile bei einem Shopify-Wechsel wirklich zählen durchgerechnet. Für die meisten Umsteiger ist ein Liquid-Theme der bessere Start, und ein Wechsel zu Hydrogen bleibt später möglich, weil die Daten im selben Backend liegen.
Wann Open Source die bessere Antwort bleibt
Es gibt Fälle, in denen wir vom Umstieg abraten oder ihn zumindest nicht wegen des Lizenzmodells empfehlen.
Ihr Unterschied zum Wettbewerb liegt in der vierten Ebene. Wenn eine Preisberechnung, ein Bestellprozess oder eine Lagerlogik im Kern Ihres Shops steckt und genau das Ihr Geschäft ausmacht, verlieren Sie mit dem Wechsel mehr als Komfort. Dann ist die bessere Frage, ob sich diese Logik als eigener Dienst aus dem Shop herauslösen lässt, unabhängig davon, wohin der Shop später geht.
Ihre Daten müssen an einem bestimmten Ort liegen. Shopify betreibt den Shop in der eigenen Infrastruktur. Den Ort, an dem Ihre Daten verarbeitet werden, wählen Sie nicht selbst. Wer vertraglich an ein bestimmtes Rechenzentrum gebunden ist, kann das mit Shopify nicht erfüllen.
Sie haben ein eigenes Entwicklungsteam, das den Shop als Produkt führt. Dann gehören Updates ohnehin zum Alltag, und die Freiheit des offenen Codes kostet Sie weniger zusätzlich, als die Grafik oben vermuten lässt.
Sie sind klein, und Ihre Bedingungen sind gut. Ein Shopware-Shop unter der Umsatzgrenze mit wenigen Plugins und einer gepflegten Version hat keinen Lizenzgrund zu wechseln. Wenn er wechselt, dann wegen Betrieb, Funktionen oder Wachstum, und diese Gründe sollten dann auch die Rechnung tragen.
Checkliste
Lizenz und Kern vor dem Wechsel: zehn Punkte
Die ersten vier Punkte klären, wo Sie heute stehen. Die übrigen sechs gehören in die Entscheidung. Ihre Häkchen bleiben in diesem Browser gespeichert.
0 von 10 erledigt
Was für Ihre Ausgangslage sinnvoll ist
| Ihre Situation | Empfehlung |
|---|---|
| Shopware 6 Community Edition unter 1 Mio. € Bruttowarenwert | Kein Zeitdruck aus der Lizenz. Nach Betriebskosten, Funktionen und Wachstumsplänen entscheiden |
| Shopware 6 Community Edition über 1 Mio. € | Den nötigen Tarif ab Rise und Shopify mit Apps als Jahreskosten nebeneinanderstellen, jeweils mit Betrieb und Updates |
| Shopware 5 | Seit Juli 2024 ohne Herstellerupdates. Ein Umzug steht ohnehin an, ob auf Shopware 6 oder zu Shopify |
| Magento Open Source 2.4.6 oder älter | Ohne Sicherheitspatches. Das Upgrade auf 2.4.8 oder 2.4.9 und den Umstieg als zwei echte Optionen nebeneinander rechnen |
| Magento mit vielen preference-Einträgen | Jeden Eintrag einzeln bewerten, bevor über die Plattform entschieden wird. Diese Liste bestimmt den Aufwand, nicht die Zahl der Module |
| WooCommerce mit vielen Marketplace-Erweiterungen | Die Jahresabos summieren und den Apps bei Shopify gegenüberstellen. Geänderte Plugin-Dateien mit verify-checksums finden |
| OXID eShop Community Edition im Verkauf | Klären, unter welcher Lizenz Ihre Version steht. Steht ohnehin ein Versionswechsel an, Shopify als Ziel mitprüfen |
| Bestehendes Headless-Frontend mit Vue, Nuxt oder Next.js | Komponenten und Design behalten, Datenschicht, Warenkorb und Konten gegen die Storefront API neu bauen. Der Checkout läuft bei Shopify |
| Kern-Eingriffe, die das Geschäftsmodell tragen | Beim offenen System bleiben oder die Logik zuerst als eigenen Dienst herauslösen. Erst danach über die Plattform entscheiden |
Was Sie aus diesem Artikel mitnehmen sollten
Der Satz „Unser Shop ist Open Source“ ist richtig. Er beantwortet nur nicht die Frage, die beim Wechsel zählt.
Open Source schützt den Code, nicht die Bedingungen. Umsatzgrenzen, Supportfenster, Jahresabos und Lizenzwechsel kommen auch bei offenen Systemen vom Hersteller. Die Abhängigkeit gibt es auf beiden Seiten. Vergleichen Sie, welche Sie tragen wollen.
Was Sie aufgeben, steht in der vierten Ebene. Einstellungen, Theme und Plugins haben bei Shopify ein Gegenstück. Eingriffe in den Kern nicht. Wer diese Liste kennt und jeden Eintrag einordnet, weiß, was der Wechsel kostet.
Die Update-Pflicht wird kleiner, aber Shopify bestimmt den Kalender. Aus rund 30 Versionen im Jahr, wie zuletzt bei Shopware und WooCommerce, wird eine API-Version, die Ihr eigener Code einmal im Jahr nachziehen muss. Dafür entscheidet Shopify, wann eine Umstellung kommt.
Wenn Sie wissen wollen, wie lang Ihre Liste aus der vierten Ebene ist und was aus jedem Eintrag bei Shopify wird: Lassen Sie uns sprechen. Wie wir Migrationen angehen, steht auf Shopsystem-Migration. Die systemspezifischen Fälle finden Sie auf Shopware zu Shopify, Magento zu Shopify, WooCommerce zu Shopify, OXID zu Shopify und JTL-Shop zu Shopify.
