Mehrere Altsysteme, ein neuer Shopware-6-Core.

Bei einer Commerce-Modernisierung existiert selten nur ein Altsystem. Produktinformationen liegen in einer Warenwirtschaft und in mehreren Spezialdatenbanken, Kunden wurden über Jahre in unterschiedlichen Shops angelegt, Preise kommen aus einem ERP und die Bestellhistorie verteilt sich auf verschiedene Plattformen.

Der Wunsch, all diese Systeme „in Shopware 6 zusammenzuführen", klingt zunächst eindeutig. Technisch lassen sich Daten importieren. Fachlich treffen jedoch unterschiedliche Modelle, Identitäten und Verantwortlichkeiten aufeinander.

Die zentrale Aufgabe besteht deshalb nicht darin, möglichst viele Datensätze in Shopware zu laden. Sie besteht darin, eine neue, kontrollierte Commerce-Architektur zu schaffen, in der klar ist, welches System welche Wahrheit liefert, wie Konflikte behandelt werden und welche Informationen Shopware tatsächlich besitzen soll.

Zuerst die Rollen der Systeme klären

„Altsystem" bedeutet nicht automatisch, dass das System ersetzt werden muss. Ein älteres ERP kann weiterhin die verlässlichste Quelle für Preise, Bestände und Auftragsstatus sein. Ein spezialisiertes PIM kann auch nach der Shopmigration die Produktpflege übernehmen.

Deshalb werden die beteiligten Systeme zunächst nach ihrer künftigen Rolle eingeordnet:

• bleibt führend: Das System behält die fachliche Verantwortung.
• bleibt als Quelle: Daten werden übernommen, aber die Pflege verlagert sich perspektivisch.
• wird read-only: Historische Informationen bleiben zugänglich, neue Änderungen erfolgen nicht mehr.
• wird vollständig abgelöst: Daten und Prozesse wechseln in ein neues System.
• wird durch eine Integrationsschicht entkoppelt: Verbraucher greifen nicht mehr direkt auf das System zu.

Diese Einordnung verhindert, dass Shopware versehentlich zum zentralen Stammdatensystem für Informationen wird, die dort langfristig nicht sinnvoll gepflegt werden können.

Eine Source-of-Truth-Matrix statt eines pauschalen „Master Systems"

In komplexen Landschaften gibt es selten ein einziges führendes System für alles. Verantwortung wird pro Entität und teilweise pro Attribut verteilt.

Beispiel:

Wichtig ist nicht nur, wo ein Wert herkommt. Geklärt werden muss auch:

• Wer darf ihn ändern?
• Wie schnell muss eine Änderung sichtbar sein?
• Was passiert, wenn die Quelle nicht erreichbar ist?
• Wie werden Konflikte erkannt?
• Welche Version wurde für eine Bestellung verwendet?

Ein kanonisches Datenmodell als gemeinsame Sprache

Wenn mehrere Altsysteme dieselben fachlichen Objekte unterschiedlich beschreiben, ist eine direkte Punkt-zu-Punkt-Integration kaum stabil.

Ein System nennt beispielsweise jede verkaufbare Ausprägung „Artikel", ein anderes unterscheidet Produkt, Variante und Verpackungseinheit. Kundengruppen besitzen unterschiedliche Codes, Adressfelder werden anders strukturiert und Statuswerte sind nicht deckungsgleich.

Eine Integrationsschicht sollte deshalb ein kanonisches Modell definieren: eine gemeinsame fachliche Repräsentation, in die Daten aus den Quellen übersetzt und aus der sie für Shopware bereitgestellt werden.

Das kanonische Modell muss nicht jedes Detail aller Systeme enthalten. Es bildet genau die Informationen ab, die für die definierten Commerce-Prozesse benötigt werden.

Beispiele:

Legacy-Artikel A4711
Legacy-Variante B-12
ERP-Material 009812
        ↓ Identitäts- und Mappinglogik
Kanonisches Produkt P-10023
        ↓
Shopware Produkt + Varianten

Der Vorteil liegt in der Entkopplung: Ändert sich ein Quellsystem, muss nicht jede nachgelagerte Shopfunktion neu entwickelt werden.

Identität ist schwieriger als Datenübertragung

Beim Zusammenführen mehrerer Systeme ist die zentrale Frage, welche Datensätze dasselbe fachliche Objekt beschreiben.

Mögliche Schlüssel sind:

• Artikelnummer,
• EAN oder GTIN,
• Herstellerkennung,
• Kundennummer,
• E-Mail-Adresse,
• externe System-ID,
• Kombination mehrerer Merkmale.

Keiner dieser Schlüssel ist automatisch zuverlässig. Artikelnummern können mehrfach vergeben sein, E-Mail-Adressen ändern sich und Kundennummern unterscheiden sich je Mandant.

Deshalb benötigt die Migration explizite Mappingtabellen und Regeln. Kritische Zuordnungen sollten nicht bei jedem Import neu geraten werden. Wurde festgestellt, dass Kunde 1820 aus System A und Kunde K-991 aus System B dieselbe Organisation sind, wird diese Beziehung dauerhaft gespeichert und nachvollziehbar gehalten.

Shopware als Commerce Core – nicht als Datensammelstelle

Shopware benötigt alle Daten, die für Suche, Darstellung, Checkout, Kundenkonto und Commerce-Prozesse erforderlich sind. Es muss aber nicht zwangsläufig jede historische oder interne Information vollständig speichern.

Ein sinnvoller Commerce Core enthält beispielsweise:

• verkaufsfähige Produkt- und Variantendaten,
• commerce-relevante Preise und Regeln,
• verfügbare Bestände oder Verfügbarkeitsinformationen,
• Kunden- und Berechtigungsinformationen für den Verkauf,
• Bestell- und Transaktionsdaten,
• Content und Shopnavigation.

Detaillierte Fertigungsinformationen, vollständige CRM-Kommunikation oder jahrzehntealte Buchhaltungsdaten können außerhalb bleiben und bei Bedarf über APIs oder Archive erreichbar sein.

Dadurch bleibt Shopware fachlich fokussiert und technisch besser betreibbar.

Schreiben ist riskanter als Lesen

Viele Integrationen beginnen als Datenübernahme in den Shop. Sobald Benutzer jedoch Daten ändern, Bestellungen auslösen oder Konten verwalten, entstehen Rückkanäle.

Für jeden Rückkanal muss geklärt sein:

• Ist Shopware berechtigt, die Information zu ändern?
• Wird die Änderung direkt oder asynchron übertragen?
• Was passiert bei einem Fehler?
• Darf der Nutzer weiterarbeiten, wenn das Zielsystem nicht erreichbar ist?
• Wie werden doppelte Übertragungen verhindert?
• Welche System-ID wird nach erfolgreicher Anlage zurückgegeben?

Besonders riskant sind unkontrollierte bidirektionale Synchronisationen. Wenn dasselbe Feld in mehreren Systemen geändert werden darf, entsteht schnell eine Schleife oder ein „Last write wins"-Verhalten, das fachlich nicht vertretbar ist.

Besser ist eine klare Schreibhoheit und ein ereignisbasierter Rückkanal mit nachvollziehbaren Zuständen.

Migration und laufende Synchronisation trennen

Die initiale Übernahme großer Datenmengen ist eine andere Aufgabe als der spätere operative Datenaustausch.

Initiale Migration

• hohe Datenmengen,
• wiederholbare vollständige Läufe,
• Bereinigung historischer Fehler,
• Zuordnung alter und neuer IDs,
• Vergleich und fachliche Abnahme.

Laufender Betrieb

• kleine inkrementelle Änderungen,
• zeitnahe oder ereignisbasierte Übertragung,
• Retry- und Fehlerlogik,
• Monitoring,
• klare fachliche Zustände.

Wer beides in denselben provisorischen Import packt, erhält häufig eine Lösung, die für den Go-live ausreicht, aber im Dauerbetrieb unzuverlässig wird.

Observability für die gesamte Kette

Eine erfolgreiche HTTP-Antwort sagt wenig darüber aus, ob die Commerce-Daten fachlich korrekt angekommen sind.

Für die Integrationskette sollten mindestens sichtbar sein:

• Zeitpunkt des letzten erfolgreichen Imports,
• Anzahl gelesener, verarbeiteter und abgelehnter Datensätze,
• unbekannte Mappings,
• Validierungsfehler,
• ungewöhnliche Mengenänderungen,
• Verzögerungen zwischen Quelle und Shop,
• nicht übertragene Bestellungen,
• fehlende Rückmeldungen aus dem ERP,
• Anzahl wiederholter oder dauerhaft fehlgeschlagener Vorgänge.

Diese Informationen müssen nicht alle in einem technischen Log gesucht werden. Für geschäftskritische Prozesse sind fachlich verständliche Statusansichten und Alerts sinnvoll.