Shopware 6 ist das Shopsystem. Das ERP ist das Rückgrat. Systeme wie PlentyONE, Xentral oder SAP liefern die Produktdaten, Bestände und Bestellinformationen – Shopware macht sie für den Kunden sichtbar. Zwischen beiden fließen Produktdaten, Bestände, Bestellungen und Versandinformationen – im besten Fall in Echtzeit, fehlerfrei und in beide Richtungen. In der Praxis ist genau diese Verbindung oft der kritischste Punkt im gesamten E-Commerce-Setup.
Die gute Nachricht: Shopware 6 wurde von Grund auf API-first gebaut. Das bedeutet, jede Funktion des Systems ist über eine sauber dokumentierte REST-API erreichbar. Die schlechte Nachricht: API-first bedeutet nicht, dass die Integration automatisch einfach ist. Die Architekturentscheidung, die ihr am Anfang trefft, bestimmt, wie viel technische Schulden ihr in zwei Jahren mit euch tragt.
Dieser Artikel zeigt euch die drei Integrationsansätze im direkten Vergleich – und warum wir beim Thomas-Philipps-Projekt einen Weg gegangen sind, den es vorher so nicht gab.
ERP-Integration in Shopware 6
:quality(75))
Architektur, Optionen und was in der Praxis wirklich funktioniert.
Warum ERP-Integrationen so oft scheitern
Die meisten ERP-Integrationsprojekte scheitern nicht an der Technik. Sie scheitern an falschen Annahmen in der Planungsphase. Die drei häufigsten:
"Das ERP kann alles exportieren, was wir brauchen."
"Wir synchronisieren einmal täglich, das reicht."
"Die Connector-App aus dem App Store löst das."
Die drei Integrationsansätze im Vergleich – am Beispiel PlentyONE & Shopware 6
Native Shopware 6 REST API
Shopware 6 stellt eine vollständige REST API zur Verfügung – für Produkte, Kategorien, Bestellungen, Kunden, Lagerbestände und mehr. Euer ERP-System kommuniziert direkt mit dieser API, ohne Zwischenschicht.
Das funktioniert gut, wenn euer ERP-System selbst eine ausgereifte API-Schnittstelle mitbringt und euer Entwicklungsteam beide Systeme kennt. Der Vorteil: volle Kontrolle, keine App-Lizenzkosten, maximale Flexibilität bei der Datenmapping-Logik. Der Nachteil: Der initiale Entwicklungsaufwand ist hoch, und jedes Shopware-Major-Update muss auf API-Änderungen geprüft werden.
Connector-App aus dem Shopware App Store
Für gängige ERP-Systeme wie Xentral, Sage, Lexware oder DATEV gibt es fertige Connector-Apps im Shopware App Store. Setup in Stunden statt Wochen, monatliche Lizenzkosten statt hohem Entwicklungsbudget.
PlentyONE ist als Connector-Lösung besonders stark, wenn ihr Multichannel-Handel plant: Die native Anbindung synchronisiert nicht nur Shopware, sondern gleichzeitig Amazon, eBay, Zalando und weitere Kanäle über eine zentrale Warenwirtschaft. Das ist der Sweet Spot für Händler, die ihren Shopware-Shop als einen von mehreren Vertriebskanälen betreiben.
Die Grenzen zeigen sich, sobald die Geschäftslogik vom Standard abweicht: kundenspezifische B2B-Preisstrukturen, individuelle Kataloge pro Kundengruppe, oder – wie im folgenden Praxisbeispiel – die gleichzeitige Anbindung mehrerer ERP-Systeme. Dann reicht ein Connector nicht mehr aus.
Individuelle Middleware
Eine Middleware ist eine eigenständige Software-Schicht zwischen Shopware 6 und dem ERP. Sie übernimmt Datentransformation, Fehlerbehandlung, Logging und Retry-Logik. Sie ist nicht Teil von Shopware und nicht Teil des ERPs – sie ist der Übersetzer zwischen beiden.
Dieser Ansatz ist aufwendiger in der Entwicklung und erfordert langfristige Wartung. Er ist aber der einzige, der zuverlässig funktioniert, wenn mehrere ERP-Systeme gleichzeitig angebunden werden müssen, wenn die Datenlogiken zwischen den Systemen fundamental unterschiedlich sind, oder wenn das Unternehmen in den nächsten Jahren weitere Systeme integrieren will.
:quality(75))
Aus der Praxis: Thomas Philipps – zwei ERP-Systeme, eine Middleware, ein Shop
Thomas Philipps ist eines der bekanntesten Einzelhandelsunternehmen im deutschsprachigen Raum – mit Tausenden von Artikeln und einer komplexen Systemlandschaft, die über Jahrzehnte gewachsen ist. Als das Unternehmen den Online-Shop auf Shopware 6 relaunchen wollte, standen wir vor einer Herausforderung, für die es keine fertige Lösung im App Store gab.
Die Ausgangslage: Xentral sollte als ERP-System für die digitale Sparte eingesetzt werden – musste aber gleichzeitig mit dem Legacy-ERP-System des Mutterkonzerns synchronisiert bleiben. Zwei ERP-Systeme mit unterschiedlichen Datenmodellen, unterschiedlichen Update-Zyklen und unterschiedlichen Verantwortlichkeiten. Dazwischen: Shopware 6 als Frontend, das beide als Datenquelle nutzen musste.
Unser Ansatz: Wir haben eine individuelle Middleware entwickelt, die als einzige Wahrheitsquelle zwischen allen drei Systemen fungiert. Die Middleware übernimmt die Datentransformation, priorisiert bei Konflikten zwischen den beiden ERP-Systemen, und stellt sicher, dass Shopware 6 immer einen konsistenten Zustand sieht – unabhängig davon, welches der beiden ERPs gerade einen Update-Prozess durchläuft.
Von ONEDOT sind viele Dinge proaktiv vorgeschlagen worden, sodass wir als Firma von der Expertise lernen und die Dinge gemeinsam umsetzen konnten. Für Themen, die technisch nicht im Standard abbildbar waren, wurden schnell gute und kostentechnisch akzeptable Lösungen gefunden.
Lena Rahe
Projektleiterin E-Commerce, Thomas Philipps
:quality(75))
Das Ergebnis: Zeitgesteuerte Sonderangebote, intelligente Upselling-Regeln und Erlebniswelten im Frontend – realisiert auf einer technischen Basis, die beide ERP-Systeme in Echtzeit synchron hält. Was hinter den Kulissen komplex ist, ist im Frontend unsichtbar: Die User erleben einen schnellen, konsistenten Shop.
Design & Technik als Einheit
Ein oft übersehener Aspekt bei ERP-Integrationen: Die Datenqualität aus dem ERP ist direkt sichtbar im Frontend. Fehlende Produktbilder, inkonsistente Attributnamen, lückenhafte Beschreibungen – all das kommt aus dem ERP und landet ungefiltert im Shop. Beim Thomas-Philipps-Projekt haben wir deshalb parallel zur Middleware-Entwicklung ein komponentenbasiertes Design-System in Figma aufgebaut, dessen Komponenten explizit mit den ERP-Datenfeldern verknüpft sind. Jede UI-Komponente weiß, welche Daten sie braucht – und zeigt einen definierten Fallback, wenn diese Daten fehlen. Das ist der Unterschied zwischen einem Shop, der aussieht wie zufällig zusammengestellt, und einem Shop, der konsequent wirkt.
Worauf es bei der Architektur wirklich ankommt
Unabhängig davon, welchen Integrationsansatz ihr wählt – diese vier Prinzipien bestimmen, ob die Integration langfristig stabil bleibt:
Echtzeit vs. Batch – bewusst entscheiden: Nicht jeder Datenpunkt braucht Echtzeit-Synchronisation. Produktbeschreibungen können einmal täglich synchronisiert werden. Lagerbestände nicht. Definiert explizit für jeden Datentyp, welche Latenz akzeptabel ist.
Fehlerbehandlung von Tag 1: Jede Integration wird irgendwann in einen Fehlerfall laufen – ein ERP-Update ändert ein Datenformat, ein Timeout unterbricht eine Synchronisation. Baut Retry-Logik, Alerting und ein Logging-Dashboard ein, bevor ihr live geht.
Staging-Umgebung ist Pflicht: ERP-Updates müssen in einer Staging-Umgebung getestet werden können, bevor sie die Produktiv-Integration berühren. Das klingt selbstverständlich, wird aber in der Praxis regelmäßig übersprungen.
Dokumentation als Lieferbestandteil: Die Integration ist so gut wie ihre Dokumentation. Wenn das Entwicklungsteam wechselt, muss ein neues Team die Architektur in zwei Stunden verstehen können. Das gilt besonders für individuelle Middleware-Lösungen.
Saubere Daten, konsistentes Design: Warum beides zusammengehört
Ein funktionierendes Design-System in Shopware 6 basiert auf einem Prinzip, das direkt aus der Komponentenarchitektur kommt: Jede UI-Komponente wird einmal definiert – mit Farbvariablen als Design-Token, Typografie-Skalen und Spacing-Regeln – und dann im gesamten Shop wiederverwendet. In Figma werden diese Tokens als Variables definiert und direkt in SCSS-Variablen des Shopware-Themes übersetzt.
Was das mit eurer ERP-Integration zu tun hat: Wenn die Produktdaten aus dem ERP unvollständig oder inkonsistent sind, bricht die Designsystem-Logik an genau diesen Stellen. Ein Produkt ohne Hauptbild, ein Artikel ohne Kurzbeschreibung, eine Kategorie ohne Metadaten – das sind keine Design-Probleme, das sind Daten-Probleme. Die ERP-Integration und das Design-System müssen daher von Anfang an gemeinsam gedacht werden.
:quality(75))
Wann macht es Sinn, eine Agentur einzubinden?
Nicht jede ERP-Integration braucht externe Unterstützung. Wenn euer ERP ein Standardsystem ist, eure Prozesse weitgehend unveränderlich sind und ein Connector-App im App Store euren Use Case abdeckt – setzt die App auf, konfiguriert sie und seid live.
Eine Agentur macht dann Sinn, wenn mindestens einer dieser Faktoren zutrifft:
Ihr habt mehr als ein ERP-System oder plant eine Migration zwischen Systemen.
Eure Preislogiken sind komplex – kundenspezifische Preise, Staffelpreise, B2B-Konditionen.
Ihr plant eine internationale Expansion mit mehreren Shopware-Verkaufskanälen.
Die Integration soll mit einem Shop-Relaunch oder einer Plattform-Migration kombiniert werden.
Euer Entwicklungsteam kennt Shopware 6, aber nicht die API-Architektur des ERPs – oder umgekehrt.
FAQ: ERP-Integration in Shopware 6
:quality(75))
Ihr plant eine ERP-Integration in Shopware 6?
Wir analysieren eure Systemlandschaft und zeigen euch in einem kostenlosen 30-Min-Call, welche Architektur zu eurem Setup passt – ohne Vendor-Bias.
Insights. Themen die uns um- und antreiben.
Alle Beiträge ansehen
:quality(75))
:quality(75))