„Gibt es dafür nicht ein Plugin?" — diese Frage hören wir in fast jedem Shopware-Projekt irgendwann. Die Antwort ist meist ja. Ob das Plugin aber wirklich das richtige Werkzeug ist, eine andere Frage. Der Shopware Store listet über 3.500 Erweiterungen, und trotzdem landen viele Projekte früher oder später bei individueller Entwicklung. Nicht weil Standard-Plugins schlecht wären, sondern weil die falschen Annahmen darüber getroffen wurden, was sie leisten können.

Dieser Beitrag erklärt, welche Erweiterungstypen Shopware 6 kennt, wann Custom-Entwicklung wirklich Sinn ergibt — und welche Stolperfallen sich dabei immer wiederholen.

Plugin, App oder Symfony Bundle? Die drei Wege zur Erweiterung

Shopware 6 unterscheidet drei grundlegend verschiedene Erweiterungskonzepte, die in der Praxis oft durcheinandergeworfen werden.

Plugins sind tief in die Shopware-Installation integriert. Sie können PHP-Klassen überschreiben, neue Services registrieren, Datenbank-Migrationen ausführen und in den Checkout-Prozess eingreifen. Plugins sind das richtige Mittel, wenn komplexe Geschäftslogik direkt im Shop laufen soll — etwa individuelle Preisberechnungen, ERP-Anbindungen oder eigene Checkout-Schritte.

Apps lagern die Business-Logik nach außen aus. Statt direkt in den Shopware-Kern einzugreifen, kommuniziert eine App über Webhooks und APIs mit einem externen System. Das ist technisch aufwändiger aufzusetzen, hat aber klare Vorteile: Die App läuft unabhängig von Shopware-Updates, lässt sich eigenständig deployen und ist leichter testbar. Für größere Systeme mit eigenem Backend — etwa PIM-Integrationen oder komplexe B2B-Workflows — ist der App-Weg oft der nachhaltigere.

Kurzgefasst: Plugin für verteilungsfähige Erweiterungen, App für externe Business-Logik.

Wann ein Standard-Plugin reicht — und wann nicht

Die 3.500 Extensions im Shopware Store lösen einen Großteil der Standardanforderungen: Produktkonfiguratoren, Zahlungsanbieter, SEO-Tools, Bewertungssysteme. Wenn eine Anforderung generisch genug ist, dass viele andere Shops sie haben, existiert dafür sehr wahrscheinlich ein gepflegtes Plugin.

Die Grenze ist erreicht, wenn eines dieser Szenarien zutrifft:

- Spezifische Preislogik: Staffelpreise nach Kundengruppen, Projektnummern im Checkout, Sonderkonditionen für Vertragspartner — sobald die Logik mehr als zwei Dimensionen hat, reicht kein Konfigurations-Plugin mehr.

- Legacy-System-Integration: Viele Mittelständler haben gewachsene ERP-Systeme mit proprietären Schnittstellen. Ein Standard-Plugin existiert dafür nicht und wäre auch nicht sinnvoll — die Anforderungen sind zu individuell.

- Modifizierter Kaufprozess: Mehrschrittiger Checkout, Freigabe-Workflows im B2B, Konfigurierbare Produkte mit komplexen Abhängigkeiten — das sind Fälle, wo Standard-Extensions an ihre Grenzen stoßen.

Der entscheidende Test: Kann eine Anforderung in einem Standard-Plugin über Konfiguration abgebildet werden, oder würde sie ein Eingriff in den Code des Plugins erfordern? Letzteres ist ein sicheres Zeichen dafür, dass Custom-Entwicklung die bessere Wahl ist.

Der Entscheidungsprozess aus der Praxis

Bevor Shopware-Projekte in die Entwicklung gehen, lohnt sich ein strukturierter Discovery-Prozess. Die Fragen, die dabei beantwortet werden müssen:

1. Welches konkrete Problem soll die Erweiterung lösen?

2. Welche Drittsysteme müssen angebunden werden?

3. Welche User-Rollen sind betroffen — Shopadmin, Sachbearbeiter, Endkunde?

4. Wie oft und durch wen wird die Funktion genutzt?

5. Was passiert bei einem Shopware-Update — muss die Erweiterung mitgepflegt werden?

Diese Fragen klingen selbstverständlich, werden in der Praxis aber oft übersprungen. Das Ergebnis: Entwicklungsaufwände, die im Nachhinein niemand eingeplant hat, weil die Anforderungen erst während der Implementierung vollständig wurden.

Typische Stolperfallen

Update-Kompatibilität unterschätzen: Shopware 6 wird aktiv weiterentwickelt. Plugins, die Core-Klassen oder Storefront-Templates überschreiben, müssen bei größeren Shopware-Updates überprüft und angepasst werden. Je tiefer ein Plugin eingreift, desto höher der Wartungsaufwand. Dieser Aufwand wird in Projektkalkulationen systematisch unterschätzt.

Plugin-Konflikte: Mehrere Plugins, die dieselben Template-Blöcke oder denselben Event überschreiben, können unvorhersehbare Effekte produzieren. Das passiert vor allem dann, wenn mehrere Standard-Plugins kombiniert werden, die nicht aufeinander abgestimmt sind.

Budget-Überraschungen durch späte Anforderungen: „Eigentlich sollte das Plugin auch noch X können" — dieser Satz kostet in jedem Projekt Geld. Eine saubere Anforderungsdefinition vor der Entwicklung ist kein Nice-to-have, sondern Budget-Schutz.

Aktivierungs-Overhead bei Plugins: Plugins müssen im Shopware-Backend installiert und aktiviert werden. In automatisierten Deployments ist das ein zusätzlicher Schritt, der vergessen werden kann.

Fazit

Individuelle Erweiterungen für Shopware 6 machen dann Sinn, wenn Standard-Extensions die Anforderungen nicht vollständig abdecken können — und sie machen nur dann Sinn, wenn die Anforderungen vorher sauber definiert wurden. Die Wahl zwischen Plugin und App ist keine technische Geschmacksfrage, sondern hängt vom Einsatzkontext ab.

Das größte Missverständnis in Shopware-Projekten: Custom-Entwicklung ist nicht dann erfolgreich, wenn ein Feature fertiggestellt ist, sondern wenn es langfristig wartbar ist. Wer das von Anfang an im Blick hat, trifft bessere Architekturentscheidungen — und hat weniger Überraschungen beim nächsten Shopware-Update.

---

Quellen: [Shopware Plugin Entwicklung — Einblicke](https://www.shopware.com/de/news/einblick-in-die-shopware-6-plugin-entwicklung/), [You don't need a plugin to customize Shopware 6 (shyim.me)](https://shyim.me/blog/you-dont-need-a-plugin-to-customize-shopware-6/), [Differences: Plugins and Apps vs Themes (Shopware Docs)](https://developer.shopware.com/docs/guides/plugins/themes/differences-plugins-and-apps-vs-themes.html), [Shopware App Development](https://www.shopware.com/de/app-development/)