Der Kern lässt sich in einem Satz zusammenfassen: Shopware 6 ist ein flexibles, API-first aufgebautes Shop-System, das B2C- und B2B-Geschäft unter einem Dach abbildet und besonders dort stark ist, wo Unternehmen ihren Onlineshop nicht von der Stange kaufen, sondern an die eigenen Prozesse, Sortimente und Preislogiken anpassen wollen. Während ein reines SaaS-Produkt seine Grenzen am Funktionskatalog des Anbieters findet, ist Shopware so angelegt, dass Agenturen und Entwicklerteams eigene Erweiterungen schreiben, eigene Storefronts bauen und das System tief in die bestehende Systemlandschaft einbinden können.
Für den deutschsprachigen Raum kommt ein kultureller und rechtlicher Faktor hinzu. Shopware versteht die Eigenheiten des DACH-Handels von Haus aus besser als viele internationale Plattformen: Kauf auf Rechnung, differenzierte Steuersätze, abmahnsichere Pflichttexte, ein deutschsprachiges Backend und ein dichtes Netz spezialisierter Agenturen und Hosting-Partner. Genau diese Kombination — moderne Architektur plus DACH-Verständnis plus Open-Source-Datenhoheit — erklärt, warum Shopware für viele mittelständische Händler und Hersteller die erste Wahl ist, sobald ein Projekt über den einfachsten Standardshop hinauswächst.
Shopware hat sich über die Jahre von einem klassischen monolithischen Shopsystem zu einer modernen, API-getriebenen Plattform entwickelt. Die heutige Generation trennt sauber zwischen der Geschäftslogik im Backend und der Darstellung im Frontend. Damit lässt sich Shopware sowohl klassisch mit der mitgelieferten Storefront betreiben als auch headless, also als reine Datenquelle hinter einem frei gewählten Frontend. Diese Wandelbarkeit ist der eigentliche Grund, warum das System sowohl den kleinen Markenshop als auch den komplexen B2B-Hersteller bedienen kann.
Im Kern basiert Shopware 6 auf Symfony, einem etablierten und weit verbreiteten PHP-Framework. Das ist mehr als eine technische Fußnote: Symfony bringt klare Strukturen, einen großen Pool an Entwicklerinnen und Entwicklern sowie ausgereifte Konzepte für Erweiterbarkeit mit. Für Unternehmen bedeutet das einen praktischen Vorteil bei der Fachkräftesuche — wer Symfony beherrscht, findet sich in Shopware deutlich schneller zurecht als in einem proprietären, geschlossenen System.
Der entscheidende Architekturgedanke ist API-first. Shopware stellt seine Funktionen über klar definierte Programmierschnittstellen bereit, allen voran die Store-API für alle kundenseitigen Vorgänge — Katalog, Warenkorb, Checkout, Kundenkonto — und die Admin-API für administrative Aufgaben wie Produktpflege, Bestellverwaltung und Konfiguration. Das klingt abstrakt, hat aber konkrete Folgen: Jede Information und jede Aktion, die im Shop sichtbar ist, lässt sich auch über die Schnittstelle abrufen oder auslösen. Damit wird Shopware zu einem Commerce-Backend, das nicht an seine eigene Oberfläche gebunden ist.
Aus dieser API-Zentrierung folgt die Headless-Fähigkeit. „Headless“ bedeutet, dass der Kopf — also das Frontend — vom Körper — der Geschäftslogik — entkoppelt ist. Ein Unternehmen kann die mitgelieferte Storefront verwenden oder sie weglassen und stattdessen ein eigenes Frontend bauen, etwa eine Progressive Web App, eine native Mobile-App oder ein mit modernen JavaScript-Frameworks erstelltes Schaufenster. Das Backend bleibt dasselbe; nur die Präsentationsschicht ändert sich.
Wer Shopware klassisch betreibt, nutzt die mitgelieferte Storefront. Sie wird serverseitig mit dem Template-System Twig gerendert und durch Vue sowie moderne Frontend-Bausteine im administrativen Bereich und in interaktiven Komponenten ergänzt. Diese Variante ist für die meisten mittelständischen Projekte der pragmatische Weg: Sie liefert ein vollständiges, suchmaschinenfreundliches Frontend, ohne dass ein separates Headless-Frontend von Grund auf entwickelt werden muss. Die Administrationsoberfläche selbst ist eine moderne Single-Page-Anwendung, die über die Admin-API mit dem Backend kommuniziert — Shopware „isst hier sein eigenes Hundefutter“ und nutzt dieselben Schnittstellen, die auch Dritten offenstehen.
Shopware unterscheidet bei Erweiterungen grob zwischen klassischen Plugins, die tief in den Code eingreifen und serverseitig laufen, und dem neueren App-System, bei dem Erweiterungen über Schnittstellen und Webhooks angebunden werden, ohne den Shopware-Kern direkt zu verändern. Das App-System ist besonders für Cloud-Betrieb relevant, weil es Erweiterungen ermöglicht, ohne dass eigener Code in die gehostete Umgebung eingreift. Für self-hosted Projekte bleiben Plugins der mächtigere, wenn auch wartungsintensivere Weg. Diese Zweigleisigkeit ist ein gutes Beispiel für die generelle Philosophie von Shopware: maximale Anpassbarkeit dort, wo sie gebraucht wird, kombiniert mit sichereren, gekapselten Wegen für den Cloud-Betrieb.
Die Erlebniswelten, international als Shopping Experiences bezeichnet, sind Shopwares Antwort auf die Frage, wie ein Shop nicht nur verkauft, sondern auch erzählt. Über einen Drag-and-drop-Editor lassen sich Start-, Kategorie- und Landingpages aus vorgefertigten Blöcken bauen. Eine Markenseite kann so ein großflächiges Bild, einen Markentext, eine kuratierte Produktauswahl und einen Erklärfilm kombinieren — alles gepflegt von der Redaktion, ohne dass für jede Anpassung ein Entwickler gebraucht wird. Für Hersteller und Marken ist das ein zentrales Argument: Sie können ihre Inszenierung selbst in der Hand behalten, statt jede Kampagnenseite extern beauftragen zu müssen.
Der Rule Builder ist eines der unterschätztesten Werkzeuge des Systems. Er erlaubt es, Bedingungen und Wirkungen grafisch zu verknüpfen, ohne eine Zeile Code zu schreiben. Praktisch heißt das: Eine bestimmte Zahlungsart erscheint nur für eine bestimmte Kundengruppe; ein Versandkostenrabatt greift ab einem definierten Warenkorbwert; eine Aktion gilt nur in einem bestimmten Land oder Zeitraum. Im B2B-Kontext wird der Rule Builder besonders wertvoll, weil sich damit kundenindividuelle Konditionen und komplexe Konstellationen abbilden lassen, die in einfacheren Systemen Sonderprogrammierung erfordern würden.
Der Flow Builder schließlich verlagert Prozesslogik aus E-Mail-Postfächern und manuellen Klicks in das System. Tritt ein Ereignis ein — etwa eine neue Bestellung, ein Zahlungseingang oder ein Statuswechsel —, lassen sich daran Aktionen knüpfen: Bestätigungsmails, interne Benachrichtigungen, Statusänderungen oder die Übergabe von Daten an angebundene Systeme. So entsteht ein automatisierter Faden durch die Bestellabwicklung, der manuelle Routinearbeit reduziert und Fehlerquellen verringert. Zusammen bilden Erlebniswelten, Rule Builder und Flow Builder das, was Shopware im Alltag so anpassungsfähig macht: ein großer Teil der typischen Anforderungen lässt sich konfigurieren, bevor überhaupt Programmierung ins Spiel kommt.
Wichtig ist, die Namen nicht mit festen Preisen zu verwechseln: Die kommerziellen Editionen werden nach Leistungsstufe und teils umsatz- oder funktionsabhängig vermarktet, und die konkreten Konditionen ändern sich. Maßgeblich für die Auswahl ist nicht der Stufenname, sondern die Frage, welche Funktionen, welcher Support und welches Betriebsmodell zum Vorhaben passen. Genau hier lohnt sich vor der Entscheidung ein Abgleich der aktuellen Leistungsbeschreibungen mit den eigenen Anforderungen.
Quer zu den Editionen liegt die Entscheidung über das Betriebsmodell. Beim Self-Hosting betreibt das Unternehmen — meist über einen spezialisierten Hosting-Partner — die Software auf eigener oder gemieteter Infrastruktur. Das bietet maximale Kontrolle: voller Zugriff auf den Code, freie Wahl von Plugins, individuelle Server-Konfiguration und vollständige Datenhoheit. Der Preis dafür ist Verantwortung: Updates, Sicherheit, Skalierung und Verfügbarkeit müssen aktiv gemanagt werden.
Bei der Cloud-Variante übernimmt der Anbieter Betrieb, Wartung und Skalierung. Das reduziert den Aufwand erheblich und senkt die technische Einstiegshürde, schränkt aber im Gegenzug die Tiefe der Anpassung ein, weil nicht beliebig in die gehostete Umgebung eingegriffen werden kann — hier kommt vor allem das gekapselte App-System zum Tragen. Die Faustregel: Wer maximale Individualisierung und Datenhoheit braucht, tendiert zum Self-Hosting; wer Komfort, planbaren Betrieb und geringere technische Last sucht, ist mit der Cloud gut bedient.
Shopify ist ein reines SaaS-Produkt: Der Anbieter betreibt alles, der Händler mietet sich ein. Das macht den Start denkbar einfach und nimmt nahezu alle technischen Sorgen ab. Der Preis dafür ist ein Verlust an Kontrolle. Anpassungen sind nur im Rahmen dessen möglich, was die Plattform vorsieht; die Daten liegen beim Anbieter; und tiefe Sonderlogik stößt schneller an Grenzen. Shopware dreht dieses Verhältnis um: mehr Aufwand und Verantwortung, dafür Datenhoheit und nahezu unbegrenzte Anpassbarkeit. Die Wahl zwischen beiden ist im Kern eine Wahl zwischen „schnell und gemanagt“ und „flexibel und souverän“.
WooCommerce ist ein E-Commerce-Plugin für WordPress und damit ebenfalls quelloffen und self-hosted. Es punktet bei kleinen bis mittleren Shops, die ohnehin in der WordPress-Welt zu Hause sind, und ist günstig im Einstieg. Sobald jedoch größere Sortimente, komplexe Preislogiken oder echte B2B-Anforderungen ins Spiel kommen, zeigt sich der Unterschied: Shopware ist von Grund auf als Commerce-Plattform konzipiert, während WooCommerce ein Shop-Aufsatz auf einem Content-Management-System ist. Was bei WooCommerce über eine wachsende Zahl von Zusatz-Plugins zusammengesetzt werden muss, bringt Shopware als zusammenhängendes System mit.
JTL ist im deutschsprachigen Raum besonders dort stark, wo der Warenwirtschafts- und ERP-Kontext im Vordergrund steht — JTL kommt aus der Logistik- und Warenwirtschaftswelt und denkt den Shop oft vom Lager und der Abwicklung her. Shopware ist dagegen primär als E-Commerce-Plattform gedacht, die sich an Warenwirtschaft und ERP anbinden lässt. Für Händler, die ihre Prozesse vollständig um eine integrierte Warenwirtschaft herum bauen wollen, kann JTL die naheliegende Wahl sein. Für Unternehmen, die maximale Freiheit beim Frontend, beim Content und bei der Anpassung suchen und die ERP-Integration als Schnittstelle behandeln, spielt Shopware seine Stärken aus.
Im B2B-Handel ist der „Preis“ selten eine einzelne Zahl. Verschiedene Kunden zahlen unterschiedliche Konditionen, abhängig von Vertrag, Abnahmemenge, Kundengruppe oder Region. Shopware bildet das über kundenindividuelle Preise und Preisstaffeln ab und kann diese Logik mit dem Rule Builder verbinden, sodass Konditionen regelbasiert greifen. Für Großhändler und Hersteller ist das ein zentrales Kriterium, weil sich damit gewachsene Preisstrukturen digital abbilden lassen, ohne für jeden Sonderfall programmieren zu müssen.
B2B-Kunden sind selten Einzelpersonen, sondern Unternehmen mit mehreren Bestellern, Budgets und Genehmigungswegen. Shopwares B2B-Funktionen erlauben die Abbildung von Kundenorganisationen mit Rollen und Rechten: Ein Mitarbeitender legt eine Bestellung an, eine vorgesetzte Person gibt sie frei, bestimmte Sortimente oder Budgetgrenzen gelten nur für bestimmte Rollen. Diese Freigabe- und Rollenlogik ist im professionellen Einkauf oft Pflicht — und ein Grund, warum reine B2C-Systeme im B2B-Einsatz schnell an ihre Grenzen stoßen.
Der B2B-Alltag kennt Abläufe, die im B2C kaum vorkommen: das Anfordern und Annehmen von individuellen Angeboten, die Schnellbestellung per Artikelnummer oder Liste sowie wiederkehrende Bestellungen aus gespeicherten Vorlagen. Shopware adressiert diese Muster mit eigenen B2B-Komponenten, die den Einkauf für professionelle Besteller effizient machen. Statt sich durch einen für Endkunden gedachten Shop zu klicken, kann ein Einkäufer hier mit Artikellisten arbeiten, frühere Bestellungen wiederholen und Angebote in Bestellungen überführen.
Eine belastbare Kalkulation betrachtet alle vier Blöcke gemeinsam. Die Lizenz- oder Abokosten sind der sichtbarste, aber oft kleinste Posten. Das Hosting ist bei self-hosted ein laufender Betrag, der bei steigendem Traffic mitwächst; in der Cloud ist er im Abo gebündelt. Der Agenturaufwand für die Umsetzung — Gestaltung, Entwicklung, Schnittstellen und Datenmigration — ist in den meisten Projekten der größte einzelne Block und schwankt enorm mit dem gewünschten Individualisierungsgrad. Und schließlich die laufende Pflege: Updates, Sicherheitsaktualisierungen, Plugin-Wartung und kontinuierliche Weiterentwicklung, die nach dem Go-Live nicht enden, sondern erst richtig beginnen.
Die quelloffene Community Edition spart die Lizenzgebühr — aber sie verlagert Verantwortung zum Betreiber. Updates, Sicherheit, Performance und Betrieb müssen selbst oder über Dienstleister gestemmt werden. In der Praxis entstehen die realen Kosten daher nicht durch die Software, sondern durch Menschen: durch Entwicklung, Hosting und Pflege. Wer das früh einkalkuliert, trifft eine fundierte Entscheidung; wer nur auf die Null bei der Lizenz schaut, erlebt später unangenehme Überraschungen. Aus diesem Grund kann eine kommerzielle Edition oder die Cloud unter dem Strich sogar wirtschaftlicher sein, wenn sie Betriebsaufwand und Risiko reduziert.
Der erste Vorteil ist grundlegend: Mit Shopware lässt sich der Shop in Deutschland oder der EU betreiben, sei es im Self-Hosting bei einem EU-Hoster oder über EU-Cloud-Regionen. Damit liegt eine zentrale DSGVO-Anforderung — die Datenverarbeitung möglichst im europäischen Rechtsraum — von vornherein in greifbarer Nähe, ohne komplizierte Konstruktionen um Drittlandtransfers herum. Für Unternehmen, die Datenhoheit und Datenschutz ernst nehmen, ist diese Wahlfreiheit beim Hosting-Standort ein echtes Argument.
Im laufenden Betrieb sind mehrere DSGVO-Bausteine relevant: ein sauberes Einwilligungsmanagement für Cookies und Tracking, Mechanismen für Auskunfts- und Löschanfragen betroffener Personen, ein Auftragsverarbeitungsvertrag mit Hostern und eingebundenen Dienstleistern sowie eine durchdachte Aufbewahrung und Pflege von Kunden- und Bestelldaten. Shopware bietet die Grundlagen, um diese Anforderungen abzubilden; die rechtssichere Ausgestaltung — etwa welche Tools eingebunden werden und wie Einwilligungen konkret eingeholt werden — bleibt jedoch eine Aufgabe, die mit fachkundiger Beratung gelöst werden sollte.
Über die DSGVO hinaus kennt der DACH-Handel zahlreiche Pflichten: Impressum, Widerrufsbelehrung, AGB, Preisangaben inklusive Grundpreis, korrekte Steuerausweisung und Versandinformationen. Shopware ist mit dem deutschen Markt vertraut und kann diese Anforderungen abbilden — etwa differenzierte Steuersätze, Pflichttextfelder und die im DACH-Raum so wichtige Zahlart Kauf auf Rechnung, die in vielen Branchen erfolgsentscheidend ist. Dass das System aus Deutschland stammt, zeigt sich gerade in diesen Details: Sie sind nicht nachträglich aufgesetzt, sondern Teil des Selbstverständnisses.
Die Wahl der richtigen Agentur ist die folgenreichste Entscheidung des gesamten Projekts. Entscheidend sind nicht Hochglanz-Präsentationen, sondern nachweisbare Shopware-Erfahrung, Referenzen in vergleichbarer Größe und Branche, Erfahrung mit den benötigten Schnittstellen und ein ehrlicher Umgang mit Aufwänden. Ein gutes Zeichen ist, wenn eine Agentur frühzeitig über Pflege, Updates und laufende Kosten spricht — und nicht nur über den glänzenden Launch. Die Zusammenarbeit ist langfristig; entsprechend wichtig sind Vertrauen, klare Kommunikation und ein gemeinsames Verständnis von Verantwortlichkeiten.
Die Datenmigration ist der unspektakulärste und zugleich riskanteste Teil. Alte Daten sind selten so sauber, wie man hofft; Kategorien, Varianten und Kundenkonten müssen strukturiert übertragen werden. Wer hier sorgfältig arbeitet und ausreichend testet, vermeidet die häufigsten Probleme nach dem Start. Beim Go-Live selbst sind Suchmaschinen-Weiterleitungen vom Altsystem, ein wachsames Monitoring und ein Rückfallplan entscheidend. Und danach beginnt der eigentliche Dauerlauf: Ein Shop, der nicht gepflegt wird, verliert über die Zeit an Sicherheit, Geschwindigkeit und Aktualität.
