Shopware-Plugins migrieren: ersetzen, neu bauen oder abschalten?

Ein älterer Shopware-Shop kann über Jahre eine große Plugin-Landschaft aufgebaut haben. Manche Erweiterungen sind offensichtlich geschäftskritisch, andere wurden für eine einzelne Kampagne installiert, wieder andere kompensieren Einschränkungen einer früheren Systemversion. Zusätzlich existieren oft individuelle Anpassungen, deren Funktion nur noch indirekt bekannt ist.

Für die Migration auf Shopware 6 ist es verlockend, für jedes alte Plugin ein gleichnamiges oder möglichst ähnliches neues Plugin zu suchen. Damit wird jedoch die historische technische Lösung zum Ausgangspunkt der neuen Architektur.

Sinnvoller ist eine Capability Review: Nicht das Plugin wird migriert, sondern die fachliche Fähigkeit, die es heute bereitstellt.

Schritt 1: Den tatsächlichen Einsatz ermitteln

Eine installierte Erweiterung wird nicht zwangsläufig noch genutzt. Umgekehrt kann eine unscheinbare Anpassung einen kritischen Prozess tragen.

Die Inventur sollte deshalb mehr enthalten als Name und Version:

• Welche Funktion stellt das Plugin bereit?
• Auf welchen Seiten oder Prozessen wird sie genutzt?
• Welche Konfigurationen sind aktiv?
• Welche Daten speichert das Plugin?
• Welche Schnittstellen oder Cronjobs verwendet es?
• Welche anderen Plugins hängen davon ab?
• Wer im Unternehmen kennt oder nutzt die Funktion?
• Was passiert, wenn das Plugin deaktiviert wird?
• Wie häufig wird die Funktion tatsächlich verwendet?

Technische Analyse und Gespräche mit Fachbereichen gehören zusammen. Manche Funktionen sind im Code vorhanden, aber operativ längst durch einen manuellen Workaround ersetzt worden.

Schritt 2: Vom Plugin zur fachlichen Capability

Die technische Bezeichnung eines Plugins kann die eigentliche Aufgabe verdecken.

Beispiele:

Diese Capability wird anschließend unabhängig vom alten Plugin beschrieben:

• Wer nutzt sie?
• Welcher Auslöser startet sie?
• Welche Daten werden benötigt?
• Welche Regeln gelten?
• Welche Ergebnisse entstehen?
• Welche Ausnahmen existieren?
• Welche Systeme sind beteiligt?

Damit wird sichtbar, ob die Aufgabe im Zielsystem weiterhin gleich gelöst werden sollte.

Schritt 3: Fünf mögliche Entscheidungen

1. Native Funktion verwenden

Shopware 6 oder eine bereits geplante Kernkomponente deckt die Capability ausreichend ab.

Vorteile:

• weniger Abhängigkeiten,
• geringerer Wartungsaufwand,
• bessere Integration in Standardprozesse.

Zu prüfen bleibt, ob die native Funktion tatsächlich die benötigte Fachlogik abbildet und nicht nur ähnlich aussieht.

2. Geeignete Standarderweiterung einsetzen

Eine etablierte Erweiterung deckt die Capability fachlich und betrieblich ab.

Bewertungskriterien:

• Funktionsumfang,
• Updatefähigkeit,
• Supportmodell,
• Code- und Datenqualität,
• Kompatibilität mit der Zielarchitektur,
• Export- und Migrationsmöglichkeiten,
• Abhängigkeit von externen Diensten,
• Lizenz- und Betriebskosten.

3. Individuell neu entwickeln

Die Capability ist differenzierend oder zu spezifisch für Standardlösungen.

Neu entwickeln bedeutet nicht, den alten Code zu portieren. Fachlogik, Datenmodell und Bedienung werden für die neue Architektur bewusst gestaltet.

4. In ein anderes System verlagern

Die Funktion gehört fachlich nicht in den Shop.

Beispiele:

• komplexe Preisfindung in ERP oder Pricing Service,
• Produktfreigabe im PIM,
• Dokumentenverwaltung in einem DMS,
• Vertriebsworkflow im CRM.

Shopware nutzt anschließend nur das Ergebnis oder stellt eine passende Oberfläche bereit.

5. Abschalten

Die Funktion wird nicht mehr benötigt, kaum verwendet oder erzeugt unverhältnismäßige Komplexität.

Das bewusste Entfernen ist ein wichtiger Teil der Modernisierung.

Plugin-Daten nicht vergessen

Selbst wenn eine Funktion abgeschaltet wird, können im Plugin relevante Daten gespeichert sein:

• kundenspezifische Einstellungen,
• Freigabestände,
• Zusatzattribute,
• historische Zuordnungen,
• Exportkonfigurationen,
• Protokolle,
• Einwilligungen.

Vor der Entscheidung muss geklärt werden:

• Werden diese Daten noch benötigt?
• Müssen sie in ein neues Modell überführt werden?
• Genügt ein Archiv?
• Können sie gelöscht werden?
• Welche IDs oder Beziehungen hängen davon ab?

Ein Plugin zu deinstallieren, ohne seine Datenfunktion zu verstehen, kann später zu schwer rekonstruierbaren Lücken führen.

Abhängigkeiten als Graph betrachten

Plugins arbeiten selten vollständig isoliert. Ein Checkout-Plugin kann Felder speichern, die ein Export-Plugin an das ERP überträgt. Ein Preisplugin kann die Darstellung, den Warenkorb und die Auftragsübergabe beeinflussen.

Eine Abhängigkeitskarte macht sichtbar:

Händlerregistrierung
      ↓
Rollenvergabe Kundengruppe
      ↓
Preislogik individueller Preis
      ↓
Checkout
ERP-Übergabe

Wenn nur ein Element ersetzt wird, müssen die angrenzenden Verträge und Datenflüsse geprüft werden.

Risiko und Differenzierung getrennt bewerten

Nicht jede komplexe Funktion ist strategisch wichtig. Und nicht jede wichtige Funktion ist technisch komplex.

Eine zweidimensionale Bewertung hilft:

Beispiele für hohes Risiko:

• Preis- und Steuerlogik,
• Zahlungsabwicklung,
• Berechtigungen,
• Bestellübergabe,
• personenbezogene Daten,
• Prozesse ohne manuellen Fallback.

Diese Funktionen benötigen intensivere Tests und einen klareren Betriebsplan als dekorative oder redaktionelle Erweiterungen.

Keine neue Plugin-Sammlung aufbauen

Auch in Shopware 6 kann schnell erneut eine große Zahl voneinander abhängiger Erweiterungen entstehen. Deshalb sollte die Zielarchitektur Regeln enthalten:

• Wann wird eine Erweiterung zugelassen?
• Wer bewertet Security und Wartbarkeit?
• Wie werden Updates getestet?
• Welche Funktionen dürfen nicht von einem einzelnen Plugin abhängig sein?
• Wie werden Daten exportierbar gehalten?
• Wer ist für den Betrieb verantwortlich?
• Wie wird eine spätere Ablösung möglich?

Ein Plugin ist kein Problem an sich. Unklare Verantwortlichkeit und unkontrollierte Abhängigkeit sind das Problem.

Capability-basierte Tests

Die Abnahme sollte nicht prüfen, ob das neue Plugin dieselben Menüpunkte besitzt. Sie prüft, ob die fachliche Fähigkeit Ende zu Ende funktioniert.

Beispiel Händlerregistrierung:

1. 1Interessent stellt Antrag.
2. 2Pflichtangaben und Nachweise werden erfasst.
3. 3Interne Prüfung erhält vollständigen Kontext.
4. 4Antrag wird freigegeben oder abgelehnt.
5. 5Kunde erhält richtige Rolle und Preise.
6. 6Entscheidung wird protokolliert.
7. 7ERP oder CRM erhält erforderliche Informationen.

Damit kann die neue Lösung anders aussehen und technisch anders aufgebaut sein, solange die Capability besser und verlässlicher erfüllt wird.