Shopware Plugin-Entwicklung 2026: Warum 80 % der Plugins Ihre Updates blockieren

Ihr Shopware-Shop läuft seit Jahren. 18, vielleicht 24 Plugins sind installiert - jedes davon hat damals ein konkretes Problem gelöst. Heute steht das nächste Major-Update an, und plötzlich kostet allein die Frage „können wir auf 6.7 hoch?" mehrere Tausend Euro Vorbereitungszeit. Und niemand kann zusagen, dass der Shop danach noch alles kann, was er heute kann.

Das ist keine Ausnahme - das ist der Normalfall. Und in den allermeisten Fällen liegt es nicht an Shopware, sondern an den Plugins.

Was ein Plugin bei der Installation mitbringt

Jedes Plugin verspricht Ihnen ein Feature in fünf Minuten Installation. Im Hintergrund schließt es dafür einen unsichtbaren Vertrag mit Ihrem Shop: Es greift in den Bestellprozess ein, dekoriert Services, überschreibt Templates, patcht den Core - manche davon sogar direkt im vendor-Verzeichnis. Jeder dieser Eingriffe ist ein Punkt, an dem ein Shopware-Update brechen kann.

In einem typischen gewachsenen Shopware-6-Shop, den wir uns ansehen, sind drei Muster wiederkehrend - und vermutlich erkennen Sie Ihren Shop direkt darin:

1. Marketplace-Plugins, die seit zwei Jahren nicht mehr aktualisiert wurden. Der Hersteller existiert vielleicht noch, der Code aber friert auf Shopware 6.4 ein. Beim Sprung auf 6.7 fehlt nicht nur die Kompatibilität, sondern auch jemand, der sie liefern kann.

2. „Eigene" Plugins, die niemand mehr versteht. Vor drei Jahren hat eine Agentur eine Funktion gebaut, die Ihr Pricing-Modell abbildet. Heute ist die Agentur weg, der Code ist nicht dokumentiert, und das Plugin überschreibt drei Core-Services - inklusive einer Stelle, die in Shopware 6.7 gar nicht mehr existiert.

3. Plugins, die Sie nicht mehr brauchen. Drei oder vier Stück, die mal für eine Kampagne gebaut wurden oder eine Funktion ersetzten, die Shopware inzwischen selbst kann. Sie laden trotzdem bei jedem Request mit.

Das Ergebnis ist immer dasselbe: ein Shop, der funktioniert, solange ihn niemand anfasst. Sobald der nächste Sicherheits-Patch oder das nächste Feature aus Shopware kommt, wird aus einem Routine-Update ein Projekt.

Was ein Plugin 2026 wirklich „upgrade-fest" macht

Ein gut gebautes Plugin erkennt man daran, wie wenig es beim nächsten Shopware-Update zu tun gibt - der Funktionsumfang sagt darüber nichts aus. Vier technische Eigenschaften entscheiden darüber:

• Keine Core-Patches, keine vendor-Eingriffe. Ein Plugin, das Shopware-Dateien direkt verändert, gibt es im Maintenance-Vertrag nicht für umsonst. Beim nächsten Update sind die Patches weg - oder schlimmer, sie kollidieren still.

• Dependency Injection und Decorator-Pattern. Wer Shopware-Services dekoriert, statt sie zu überschreiben, bricht beim Update nicht - solange die Schnittstelle stabil bleibt. Shopware kommuniziert Breaking Changes Major-Versionen im Voraus.

• Tests, die beim CI/CD-Lauf grün sein müssen. Ein Plugin ohne Tests ist eine Annahme. Erst Unit-Tests für die Business-Logik plus ein paar Integrationstests gegen die Shopware-API machen aus „läuft" ein „läuft nachweisbar". Beim Update wissen Sie in Minuten, was bricht - nicht erst, wenn ein Kunde anruft.

• Kompatibilitäts-Range statt fixer Version. Ein Plugin, das `"shopware/core": "~6.6.0"` verlangt, blockiert Sie sofort beim 6.7-Update. `"^6.6"` ist meist die ehrlichere Variante - kombiniert mit einer Test-Pipeline, die das auch wirklich beweist.

Wenn Sie ein Marketplace-Plugin bewerten, können Sie die ersten drei Punkte oft schon aus dem öffentlichen GitHub-Repo oder dem composer.json ablesen - bevor Sie einen Cent investieren.

Marketplace, fertig kaufen oder selbst bauen?

Die Entscheidung ist selten ideologisch. Sie hängt an drei nüchternen Fragen:

Ist die Funktion Standard? Ein DHL-Versandlabel oder ein Klarna-Checkout ist Standard. Ein Marketplace-Plugin mit aktivem Hersteller ist hier fast immer die richtige Antwort - selbst wenn es 49 € pro Monat kostet. Selber zu bauen bedeutet hier, denselben Wartungsaufwand wie der Hersteller zu tragen, ohne dessen Skaleneffekte.

Ist die Funktion Ihr Geschäftsmodell? Wenn Ihr Pricing, Ihre Konfiguratoren, Ihre B2B-Workflows oder Ihre ERP-Anbindung das sind, was Sie von Wettbewerbern unterscheidet - dann gehört dieser Code Ihnen. Nicht einem Plugin-Hersteller, den Sie nicht kontrollieren. Custom-Entwicklung ist teurer, aber sie sichert genau den Bereich, der Ihr Geschäft trägt.

Was kostet das Plugin in 24 Monaten? Nicht heute. Ein Marketplace-Plugin für 29 € pro Monat ist über zwei Jahre 700 € - plus Update-Kompatibilität, plus Lock-in, falls der Hersteller die Richtung wechselt. Bei einer Custom-Lösung steht der Aufwand am Anfang, aber der Code gehört Ihnen und altert kontrolliert.

Eine pragmatische Faustregel: Standard-Funktionen kaufen Sie, geschäftskritische Logik bauen Sie - und beides muss denselben technischen Qualitätsmaßstab erfüllen. Für den Teil, den Sie bauen lassen, stehen Ihnen unsere Shopware Plugin Entwickler gern zur Seite.

Wo KI in der Plugin-Entwicklung 2026 wirklich hilft

KI-Tools haben in der Plugin-Entwicklung im letzten Jahr die Rolle gewechselt. Sie ersetzen keine Entwickler, aber sie verändern, wo deren Zeit hingeht.

Plugin-Audits werden in Stunden machbar, nicht Tagen. Mit Coding-Agents wie Claude Code lässt sich der gesamte Plugin-Code eines Shops automatisiert daraufhin prüfen, ob er Core-Patches setzt, deprecated APIs benutzt oder gegen Shopware-Konventionen verstößt. Was früher ein Senior-Entwickler manuell durchgegangen ist, läuft heute als Pre-Check für ein Update durch - und liefert eine konkrete Liste statt eines Bauchgefühls.

Migrations-Patches werden generierbar. Wenn Shopware in 6.7 eine API umbenennt oder einen Service umstrukturiert, kann ein KI-Tool die nötigen Anpassungen in einem Plugin in vielen Fällen als Pull Request vorbereiten. Reviewen muss das Team, schreiben muss niemand mehr.

Tests werden zur Selbstverständlichkeit. Das größte Hemmnis für Tests war historisch der Aufwand. Mit KI-gestützter Test-Generierung kostet ein erstes Test-Set für ein bestehendes Plugin Stunden statt Tage. Damit fällt eine der Hauptausreden weg, warum „unsere Plugins keine Tests haben".

Den menschlichen Review Ihres Plugins ersetzt KI damit nicht. Sie verschiebt aber die Wirtschaftlichkeit: 2026 ist es günstiger, ein Plugin mit Tests und ohne Core-Patches zu bauen, als nochmal mit dem Argument „Tests sind zu teuer" zu starten.

Womit Sie diese Woche anfangen können

Sie brauchen keinen großen Plugin-Strategie-Workshop, um in eine bessere Ausgangslage zu kommen. Drei Schritte reichen für den Anfang:

1. Macht eine ehrliche Plugin-Inventur. Welche Plugins haben Sie aktiviert? Wer hat sie gebaut? Wann wurden sie zuletzt aktualisiert? Welche brauchen Sie heute noch wirklich? Allein das Deaktivieren von zwei oder drei toten Plugins macht jedes Update spürbar leichter.

2. Klären Sie die Eigentumsfrage pro Plugin. Bei eigenen Plugins: Haben Sie den Code? Haben Sie ihn dokumentiert? Bei Marketplace-Plugins: Wissen Sie, was passiert, wenn der Hersteller morgen die Lichter ausmacht? Ein einseitiges Notfall-Dokument pro Plugin spart Ihnen im Ernstfall Wochen.

3. Definiert Qualitätsmaßstäbe für neue Plugins. Bevor das nächste Plugin in Ihren Shop kommt - egal ob gekauft oder gebaut: keine Core-Patches, Tests vorhanden, Kompatibilität dokumentiert, klare Eigentumsverhältnisse. Vier Häkchen vor der Installation ersparen Ihnen beim übernächsten Update viel Analyseaufwand.

Worauf es beim nächsten Plugin ankommt

Teuer werden Plugins, die niemand mehr versteht oder pflegt. Wer 2026 Shopware-Plugins entwickelt oder einkauft, kauft mit dem Feature auch die Wartbarkeit der nächsten zwei, drei Major-Updates ein.

Der Zustand Ihres Plugin-Stacks lässt sich mit einer Inventur und einem automatisierten Audit belastbar feststellen. Meist reichen danach ein paar gezielte Eingriffe - deaktivieren, ersetzen, nachdokumentieren -, um das nächste Update aus dem Projektstatus zu holen. Ein Shop-Neubau ist dafür nicht nötig.