Shopware Nexus oder eigene Middleware? Eine Entscheidungshilfe für ERP-Anbindungen

Seit Nexus im Early Access ist, taucht in jedem zweiten Projektgespräch dieselbe Frage auf: Brauchen wir die individuelle ERP-Anbindung überhaupt noch?

Die Antwort hängt an zwei Dingen: daran, wie eine Schnittstelle geschnitten ist, und daran, wer den Betrieb übernimmt.

Was Nexus ist

Shopware beschreibt Nexus als natives iPaaS, das in die Plattform eingebaut ist. Praktisch ist es ein Cloud-Dienst mit visuellem Workflow-Editor, erreichbar unter nexus.shopware.com und mit dem Shop über den Nexus Event-Ingestion Service verknüpft.

Ein Workflow besteht aus einem Trigger, einer Kette von Schritten und Aktionen nach außen. Die Dokumentation nennt zwei Trigger-Typen: Shopware-Events wie order.placed und zeitgesteuerte Läufe im Cron-Stil. Dazwischen liegen bedingte Verzweigungen und Datentransformationen.

Die Dokumentation nennt fünf Action-Nodes: Business Central Connector, Shopware-API-Aufrufe, Slack-Benachrichtigungen, Shopware-Mailversand und generische API-Requests. Dazu kommt ein Output-Node, der Daten in S3-kompatiblen Object Storage schreibt. Weitere Connectors führt die Produktseite als in Prüfung, darunter Pimcore, NetSuite und Akeneo.

Was daran neu ist, und was nicht

Eventgetriebene Workflows mit visuellem Editor und Connectors gibt es seit über einem Jahrzehnt. Zapier, Make, Workato, Talend, Apache Camel, Node-RED, n8n. Die Bauform ist etabliert, und Nexus folgt ihr.

Der Wert eines solchen Werkzeugs steckt nicht im Editor, sondern in den Connectors. Ein fertiger Connector nimmt für ein bestimmtes Zielsystem die Authentifizierung ab, die Paginierung, das Verhalten bei Rate Limits, das Mapping auf dessen Entitäten und die Frage, was eine Fehlermeldung dieses Systems eigentlich bedeutet. Dieser Teil frisst in einer Eigenentwicklung die Tage, nicht der Transport.

Damit hängt der Nutzen an einer einzigen Frage: Steht das eigene Zielsystem im Katalog?

Der Katalog ist im Early Access entsprechend jung. Von den dokumentierten Nodes schreibt genau einer in ein Fachsystem: der Business Central Connector. Slack-Nachricht und Shopware-Mail sind Benachrichtigungen, der Rest ist generischer Transport: HTTP-Request, Aufruf gegen die eigene Shopware-API, Ablage in S3. In Prüfung sind mit Pimcore, NetSuite und Akeneo genau die Kandidaten, die den Unterschied machen würden.

Für alle anderen Systeme bleibt der generische API-Request. Dann schreibt man Mapping, Authentifizierung und Fehlerbehandlung wieder selbst, nur eben in einem fremden Dienst statt im eigenen Code.

Ob Nexus Arbeit abnimmt, entscheidet der Connector-Katalog. Steht das eigene ERP nicht darin, bleibt ein Workflow-Editor mit HTTP-Aufruf.

Die Event-Anbindung wird daneben leicht überschätzt. Nexus liefert Shopware-Events ohne eigenes Zutun, das tut aber auch ein Plugin mit einem EventSubscriber, und das sind ein paar Dutzend Zeilen. Wer den Empfänger außerhalb des Shops betreiben will, nimmt das App-System mit <webhooks> im Manifest. Bequem ist der native Trigger, ein Alleinstellungsmerkmal ist er nicht.

Shopware wirbt mit zwei Zahlen: Die Integrationskosten sollen um bis zu 40 Prozent sinken, und 52 Prozent des Projektaufwands sollen im Schnitt durch individuelle Middleware verloren gehen. Beide Zahlen tragen auf der Produktseite eine Fußnotenmarke, eine Herleitung ist dort nicht hinterlegt. Ohne Bezugsgröße bleibt offen, was als Projektaufwand zählt und woran die Ersparnis gemessen wurde.

Unstrittig ist, wo der Aufwand liegt: zwischen den Systemen und nicht im Shop. Ein passender Connector deckt davon den Standardteil ab. Der größere Teil steckt erfahrungsgemäß in den Sonderfällen, und dafür braucht es weiterhin eine eigene Lösung.

Eine Abgrenzung noch, weil Nexus und der Flow Builder regelmäßig verwechselt werden. Der Flow Builder automatisiert Logik innerhalb des Shops, etwa Statuswechsel oder Mailversand. Nexus verbindet den Shop mit Systemen außerhalb. Beide existieren nebeneinander.

Die Granularität entscheidet über die Kosten

Die technische Dokumentation nennt keine Preise, die Preisseite schon. Shopware führt Nexus dort als Add-on: bis zum 1. September 2026 eine kostenlose Einführungsphase, danach rund 10 Euro pro 1.000 Ausführungen, ausgewiesen als Richtpreis in der Beta.

Abgerechnet wird also nach Ausführungen, und genau das verändert die Art, wie man eine Schnittstelle schneidet.

Als Beispiel ein Shop mit 5.000 Artikeln und 200 Bestellungen pro Tag, angebunden an ein ERP.

Bestellstrecke, eventgetrieben:

Pro Bestellung fallen vier Ausführungen an. Auftrag ins ERP, Kundenabgleich, Statusrückmeldung, Trackingnummer zurück in den Shop.

200 Bestellungen × 4 Schritte × 30 Tage = 24.000 Ausführungen/Monat
24.000 / 1.000 × 10 € = 240 €/Monat

Das ist unauffällig und für die gelieferte Leistung günstig.

Bestandsabgleich, eine Ausführung pro Artikel:

5.000 Artikel × 24 Läufe/Tag × 30 Tage = 3.600.000 Ausführungen/Monat
3.600.000 / 1.000 × 10 € = 36.000 €/Monat

Derselbe Bestandsabgleich als Batch, eine Ausführung pro Lauf:

24 Läufe/Tag × 30 Tage = 720 Ausführungen/Monat
720 / 1.000 × 10 € = 7,20 €/Monat

Gleiche Funktion, gleiche Datenmenge, aber ein Preisunterschied von Faktor 5.000. Der Faktor bleibt derselbe, egal welchen Preis pro Ausführung man einsetzt.

Bei einer eigenen Middleware ist die Granularität eine Frage von Laufzeit und Lesbarkeit. Bei Nexus ist sie die Kostenfrage. Wer pro Datensatz triggert statt pro Lauf, zahlt das Tausendfache.

Das ist kein Argument gegen Nexus. Es ist ein Argument dafür, die Workflows von Anfang an batchorientiert zu schneiden, überall dort, wo keine Echtzeit gefordert ist. Bestellungen gehören einzeln verarbeitet, Bestände und Preise gehören gebündelt.

Wo Nexus trägt

In einer ganzen Reihe von Projekten ist eine eigene Middleware überdimensioniert.

• Standardstrecken zwischen Shopware und einem System, für das ein Connector existiert
• Feld-Mappings ohne Sonderlogik, bei denen ein Auftrag ein Auftrag bleibt
• Überschaubare Volumina, bei denen die Kosten pro Ausführung nicht ins Gewicht fallen
• Benachrichtigungen an Slack oder per Mail, wo ohnehin keine Fachlogik nötig ist
• Projekte ohne eigenes Betriebsteam, in denen jede zusätzliche Komponente ein Risiko ist

In diesen Fällen ist eine eigene Middleware ein Kostentreiber ohne Gegenwert. Wer eine Business-Central-Anbindung mit Standardfeldern braucht, sollte Nexus nehmen.

Wo die Grenzen liegen

Ein Teil der folgenden Punkte ist dem Early Access geschuldet und dürfte sich mit der Zeit erledigen. Für eine Entscheidung heute zählt trotzdem der aktuelle Stand.

At-least-once-Delivery. Shopware dokumentiert das als bekannte Einschränkung. Ein Event kann mehrfach ankommen. Ohne Idempotenz auf der Empfängerseite können daraus Doppelbuchungen im ERP entstehen.

Kein Testmodus, keine Undo-Funktion, begrenzte Fehlerdetails. Auch das steht so in der Dokumentation. Wer einen Workflow ändert, ändert ihn produktiv. Als Ausweg empfiehlt die Doku Staging-Shops, also eine zweite Umgebung, die man selbst pflegt. Für die Fehlersuche stehen weniger Details zur Verfügung, als man aus einer eigenen Middleware gewohnt ist.

Fehlerbehandlung mit Checkpoints. Was passiert, wenn das ERP mitten in einem Batch von 3.000 Artikeln nicht mehr antwortet? Eine eigene Middleware hat einen Zustand, läuft ab dem letzten bestätigten Datensatz weiter und meldet den Abbruch ans Monitoring. Eine entsprechende Funktion nennt die Nexus-Dokumentation nicht.

Eigene Datenmodelle. Sobald Artikelstämme über mehrere Entitäten verteilt sind, Konfiguratoren im Spiel sind oder Preise nach Kundengruppe, Staffel und Aktionslogik berechnet werden, reichen Feld-Mappings nicht mehr.

Systeme ohne Connector. SAP, Oracle, Salesforce und praktisch jedes Warenwirtschaftssystem aus dem deutschen Mittelstand laufen über den generischen API-Request. Der Aufwand für Mapping und Fehlerbehandlung bleibt beim Projekt. Der Vorteil gegenüber einem anderen Workflow-Tool beschränkt sich dann auf den Event-Trigger.

Betrieb außerhalb der Cloud. Die Dokumentation beschreibt Nexus als Cloud-Dienst. Eine Variante zum Selbstbetreiben ist nicht dokumentiert. Wer aus regulatorischen Gründen oder wegen hoher Ausfallkosten Kontrolle über die Laufzeitumgebung braucht, findet sie hier nicht.

Der Dreijahresvergleich

Die folgende Rechnung nutzt den von Shopware genannten Preis pro Ausführung und ein mittleres Szenario: eine Anbindung an ein System mit vorhandenem Connector, Standardfelder, 24.000 Ausführungen pro Monat. Tagessatz (1.000 Euro) und Personentage sind Annahmen aus unserer Projektpraxis. Wer eigene Werte hat, setzt sie ein, die Struktur der Rechnung bleibt.

Für dieses Szenario ist Nexus etwa viermal günstiger. Wer trotzdem selbst baut, sollte gute Gründe nennen können.

Bei hohen Volumina kippt die Rechnung, weil die Nutzungskosten linear mitwachsen, während die Kosten einer eigenen Middleware weitgehend fix bleiben. Sie kippt bei Sonderlogik, weil der Initialaufwand auf der Nexus-Seite dann nicht mehr bei 6 Personentagen liegt. Und sie kippt bei Systemen ohne Connector, weil dort beide Seiten dasselbe Mapping bauen, nur dass eine davon zusätzlich pro Ausführung abrechnet.

Ein Posten fehlt in der Tabelle, weil er sich schlecht beziffern lässt.

Lock-in bei kritischen Prozessen

Die Rechnung oben bewertet den Aufwand, aber nicht, wie schwer sich die Entscheidung später zurücknehmen lässt. Bei einer Slack-Benachrichtigung spielt das keine Rolle, bei der Bestellstrecke schon.

Die Abhängigkeit hat vier Ebenen:

Die letzte Zeile wiegt in der Praxis am schwersten.

Eine eigene Middleware ist genau der Teil, der ein Replatforming bezahlbar macht. Sie kennt das ERP, die Mappings und die Sonderfälle aus Jahren im laufenden Betrieb. Beim Wechsel des Shopsystems tauscht man den Shop-Adapter und behält den Rest.

Wer die ERP-Anbindung vollständig in Nexus abbildet, macht aus einem Shopwechsel zusätzlich ein Integrationsprojekt. In der Praxis entscheidet genau diese Rechnung oft darüber, ob ein Replatforming überhaupt angegangen wird.

Woran die Bindung an den Account hängt

Verbrauchsabhängige Preise sind planbar, solange das Modell stabil bleibt. Ein Vorgang aus dem vergangenen Jahr zeigt, was die Bindung an einen Shopware Account praktisch bedeutet.

Zum 24. März 2025 hat Shopware eine Fair Usage Policy eingeführt. Seither ist die Community Edition bis 1 Mio. Euro GMV im Jahr uneingeschränkt nutzbar. Wer darüber liegt, wechselt auf einen kostenpflichtigen Plan. Zur Meldung des GMV sind alle Nutzer der Community Edition verpflichtet, unabhängig von der Höhe, mit erster Frist zum 30. Juni 2025.

Was ein Wechsel bedeutet, steht auf der Preisseite: Rise beginnt bei 600 Euro im Monat zuzüglich Steuern, Evolve bei 2.400 Euro, Beyond auf Anfrage.

Für die Planung ist weniger die Schwelle interessant als die Stelle, an der die Policy greift. Der Code der Community Edition ist weiterhin MIT-lizenziert, daran hat die Policy nichts geändert. Sie regelt den Zugang zu Shopware Account und Store. Wer über der Schwelle liegt und nicht wechselt, riskiert die Sperrung von Shopware Account und Store samt Kündigung gemieteter Extensions. Der Shop selbst läuft weiter: Die Community Edition lässt sich laut Shopware auch ohne Account und Store weiter nutzen.

Nexus setzt einen aktiven Shopware Account voraus und hängt damit an derselben Ebene. Anders als beim Shop gibt es hier keinen MIT-lizenzierten Teil, der ohne den Dienst weiterläuft.

Das ist kein Vorwurf. Jeder Anbieter darf sein Modell weiterentwickeln, und für diesen Schritt gab es nachvollziehbare Gründe. Für die eigene Planung heißt das nur: Je mehr Geschäftsprozess an einem Dienst hängt, desto weniger Spielraum bleibt, wenn der Anbieter das nächste Mal nachjustiert.

Dasselbe gilt für Produktentscheidungen. OpenAI hat Instant Checkout nach rund fünf Monaten zurückgezogen, und vor solchen Kurskorrekturen ist kein Anbieter gefeit. Für eine Slack-Benachrichtigung ist das verkraftbar, für eine Auftragsstrecke weniger.

Lock-in reduzieren, ohne auf Nexus zu verzichten

Der Ausweg liegt in der Aufteilung der Schnittstelle: Nexus übernimmt Trigger und Transport, die Fachlogik bleibt im eigenen Code. Der Workflow bildet also keine Bedingungen, Mappings oder Fehlerbehandlung mehr ab. Er ruft einen eigenen Endpunkt auf und übergibt die Rohdaten. Alles ab diesem Punkt liegt im Repository, ist versioniert, testbar und unabhängig von Nexus.

Diese Aufteilung lohnt sich nur bei kritischen Strecken. Eine Slack-Nachricht bei jeder Bestellung über 5.000 Euro gehört komplett ins Canvas, also in den visuellen Workflow-Editor von Nexus. Ein eigener Endpunkt dafür wäre Overhead.

Für die kritischen Strecken bleibt eine berechtigte Frage: Wenn die Fachlogik ohnehin im eigenen Code liegt, warum das Event überhaupt durch Nexus schicken? Dafür gibt es zwei Gründe, und mindestens einer sollte zutreffen:

• Auf der Zielseite steht ein fertiger Connector. Der eigene Endpunkt bereitet die Daten auf und gibt sie zurück, den Schreibzugriff ins Zielsystem übernimmt der Connector. Damit spart man sich dessen Authentifizierung und Fehlerbehandlung und behält trotzdem die Fachlogik im Repository.
• Dasselbe Event geht an mehrere Empfänger, und diese Liste ändert sich. Ein zusätzlicher Empfänger ist im Workflow eine Konfiguration, im eigenen Code ein Release.

Trifft keiner von beiden zu, hat Nexus in dieser Strecke keine Aufgabe mehr. Das Event läuft dann durch einen kostenpflichtigen Dienst, nur um bei einem Endpunkt zu landen, der alles selbst erledigt. Ein Plugin mit EventSubscriber bringt es direkt dorthin.

Der folgende Endpunkt zeigt die Empfängerseite. Die Idempotenz darin ist Pflicht, keine Vorsichtsmaßnahme: Shopware dokumentiert At-least-once-Delivery, dasselbe Event kann also mehrfach ankommen.

<?php

declare(strict_types=1);

namespace App\Controller;

use App\Message\ProcessOrderMessage;
use Psr\Log\LoggerInterface;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Messenger\MessageBusInterface;
use Symfony\Contracts\Cache\CacheInterface;
use Symfony\Contracts\Cache\ItemInterface;

final class OrderWebhookController
{
    public function __construct(
        private readonly MessageBusInterface $bus,
        private readonly CacheInterface $idempotencyStore,
        private readonly LoggerInterface $logger,
        private readonly string $webhookSecret,
    ) {
    }

    #[Route('/hooks/order-placed', methods: ['POST'])]
    public function __invoke(Request $request): Response
    {
        $payload = $request->getContent();

        // 1. Signatur prüfen. Der Endpunkt ist öffentlich erreichbar,
        //    die Authentizität hängt allein am HMAC.
        if (!$this->isSignatureValid($payload, (string) $request->headers->get('X-Signature'))) {
            return new JsonResponse(['error' => 'invalid signature'], Response::HTTP_UNAUTHORIZED);
        }

        $data = json_decode($payload, true, 512, JSON_THROW_ON_ERROR);
        $orderNumber = (string) ($data['orderNumber'] ?? '');

        if ($orderNumber === '') {
            return new JsonResponse(['error' => 'orderNumber missing'], Response::HTTP_BAD_REQUEST);
        }

        // 2. Idempotenz. Bei At-least-once-Delivery kommt dasselbe Event
        //    mehrfach an. Der Schutz gehört auf die eigene Seite.
        $isDuplicate = true;
        $this->idempotencyStore->get(
            'order_hook_' . $orderNumber,
            function (ItemInterface $item) use (&$isDuplicate): bool {
                $item->expiresAfter(86400);
                $isDuplicate = false;

                return true;
            }
        );

        if ($isDuplicate) {
            $this->logger->info('Doppelter Aufruf verworfen', ['orderNumber' => $orderNumber]);

            return new JsonResponse(['status' => 'duplicate'], Response::HTTP_OK);
        }

        // 3. Annehmen und asynchron verarbeiten. Der Aufrufer bekommt sofort
        //    eine Antwort, die eigentliche Arbeit läuft im eigenen Worker.
        $this->bus->dispatch(new ProcessOrderMessage($orderNumber, $data));

        return new JsonResponse(['status' => 'accepted'], Response::HTTP_ACCEPTED);
    }

    private function isSignatureValid(string $payload, string $received): bool
    {
        $expected = hash_hmac('sha256', $payload, $this->webhookSecret);

        return $received !== '' && hash_equals($expected, $received);
    }
}

Fällt Nexus weg, ersetzt man den Trigger durch einen EventSubscriber im eigenen Plugin, einen Cronjob oder einen Queue-Consumer. Der Endpunkt, die Verarbeitung, die Fehlerbehandlung und die Mappings bleiben unverändert. Der Wechsel kostet Tage statt Monate.

Für den Alltag reichen drei Regeln:

• Jede Strecke bekommt vorab eine Antwort auf die Frage, was passiert, wenn sie zwei Tage nicht läuft. Ist der Ausfall verkraftbar, darf alles ins Canvas.
• Wird der Ausfall teuer, gehören die Geschäftsregeln in Code, nicht ins Canvas.
• Wenn dabei vom Workflow nur noch ein Aufruf übrig bleibt, gehört die Strecke nicht in Nexus, sondern an einen eigenen EventSubscriber.

Die dritte Option: eine eigene Workflow-Engine

Workflow-Engines dieser Bauform gibt es auch zum Selbstbetreiben. Mit n8n läuft dieselbe Art von Workflow auf eigener Infrastruktur, ohne Abrechnung pro Ausführung.

Für Shopware existieren Community-Nodes, etwa von solution25 und codeblick. Wo kein Node passt, bleibt der HTTP-Node. Für Aufrufe gegen die Shopware Admin API ist das kein praktischer Nachteil.

Der Kern des Vergleichs steht in zwei Zeilen: Nexus liefert die Events frei Haus und nimmt den Betrieb ab, n8n liefert Kontrolle und Nachvollziehbarkeit. Der Betriebsaufwand ist der Preis dafür: n8n im Produktivbetrieb heißt Main-Instanz, Worker, Redis und Postgres, dazu Backups, Updates und Monitoring.

Zwei Punkte, die man bei n8n kennen sollte

Die Lizenz ist nicht OSI-konform. n8n steht seit dem 17. März 2022 unter der Sustainable Use License, davor unter Apache 2.0 mit Commons Clause. Für den eigenen Shop ist das unkritisch: Die Nutzung für interne Geschäftszwecke ist ausdrücklich erlaubt, und genau darum geht es, wenn ein Händler seine eigenen Systeme verbindet. Untersagt ist, n8n selbst als Dienst weiterzuverkaufen.

Praktisch relevanter ist ein zweiter Punkt: Dateien mit .ee. im Pfad stehen nicht unter der Sustainable Use License, sondern verlangen eine Enterprise-Lizenz. Betroffen sind Funktionen, die n8n als Enterprise-Features führt, darunter SSO. Wer sie braucht, zahlt auch bei n8n.

Das Canvas-Problem bleibt. Auch bei n8n liegt die Logik in einem grafischen Editor. Der Unterschied ist, dass sich Workflows als JSON exportieren und ins Repository legen lassen. Richtig reviewen lassen sich diese JSON-Diffs trotzdem kaum.

n8n nimmt den Vendor-Lock-in und die Abrechnung pro Ausführung aus der Rechnung. Am Grundproblem ändert es nichts: Geschäftslogik in einem Canvas lässt sich schlechter prüfen als Code.

Die Empfehlung aus dem vorigen Abschnitt bleibt damit bestehen. Ob Nexus oder n8n: Trigger und Transport gehören in die Engine, die Fachlogik in einen eigenen Endpunkt.

Wer ohnehin kein Canvas braucht, fährt mit Temporal oder einer schlichten Kombination aus Symfony Messenger und Cron oft schlanker. Kestra, Windmill und Node-RED gehen in dieselbe Richtung wie n8n und lohnen einen Blick, wenn eine bestimmte Anforderung dort besser passt.

Der hybride Weg

In den meisten mittelständischen Projekten ist die Entscheidung keine Entweder-oder-Frage.

Ein praktikabler Schnitt:

• Eine Workflow-Engine übernimmt Standardstrecken, Benachrichtigungen und alles, was eventgetrieben und niedrigvolumig ist. Ob Nexus oder n8n, hängt davon ab, ob ein Betriebsteam vorhanden ist
• Eigene Middleware übernimmt die kritischen Strecken mit Zustand, Checkpoints und Sonderlogik, typischerweise Artikelstamm, Preise und Auftragsverarbeitung

Damit sinkt der Umfang der Eigenentwicklung deutlich, ohne dass die Teile, die im Fehlerfall Geld kosten, an einem fremden Dienst hängen. Die Middleware bleibt außerdem erhalten und übersteht einen Plattformwechsel.

Der Preis dieses Wegs ist, dass zwei Systeme betrieben und dokumentiert werden müssen. Das lohnt sich ab dem Punkt, an dem mindestens eine Strecke die Grenzen von Nexus erreicht.

Entscheidungsmatrix

Wer in der Spalte Nexus überall zustimmt, aber ein Betriebsteam hat und die Abrechnung pro Ausführung vermeiden will, landet bei einem selbst betriebenen n8n. Die fachliche Bewertung bleibt dieselbe, es verschiebt sich nur, wer den Betrieb trägt.

Fazit

Technisch ist Nexus ein Cloud-iPaaS in einer etablierten Produktkategorie. Ob es trägt, entscheidet der Connector-Katalog: Steht das eigene Zielsystem darin, nimmt es echte Arbeit ab. Für diese Fälle ist die eigene Middleware vom Tisch. Das offen zu sagen fällt einer Agentur schwer, die von genau diesen Projekten lebt. Es ändert nichts daran, dass es stimmt.

Was bleibt, sind die Strecken mit Zustand, Sonderlogik oder Volumen. Dort ist Nexus im aktuellen Stand kein Ersatz, sondern eine Ergänzung für die einfachen Strecken daneben. Die Gründe nennt die Dokumentation selbst: kein Testmodus, begrenzte Fehlerdetails, At-least-once-Delivery. Ein Teil davon dürfte sich mit den kommenden Releases erledigen.

Die Kostenrechnung allein trägt die Entscheidung nicht. Bei den Strecken, die den Betrieb tragen, wiegt die Abhängigkeit schwerer als der Aufwand. Wer die ERP-Anbindung vollständig in eine Plattform legt, die zum Shopsystem gehört, muss beim Plattformwechsel beides gleichzeitig ersetzen.

Unabhängig von der Wahl gilt dieselbe Regel: Fachlogik ins eigene Repository, Trigger und Transport in die Engine. Damit bleibt der Nutzen erhalten und der Wechsel eine Frage von Tagen.

👉 Wenn du wissen willst, welche deiner Schnittstellen in Nexus gehören und welche nicht:

Quellen

• Shopware Docs: Shopware Nexus für Voraussetzungen, Aktivierung, Trigger und Aktionen
• Shopware Developer Docs: Nexus, Getting Started für die bekannten Einschränkungen im Early Access
• Shopware Developer Docs: Listening to events für den Plugin-Weg über EventSubscriber
• Shopware Developer Docs: App-System, Webhooks für Manifest, Registrierung und Signaturprüfung
• Shopware: Produktseite Nexus für die Angaben zu Integrationskosten und Projektaufwand
• Shopware: Pricing für die Editionspreise und die Abrechnung von Nexus
• Shopware: Fair Usage Policy für die Community Edition für Schwelle, Meldepflicht und Fristen
• n8n: Sustainable Use License und LICENSE.md
• n8n Docs: Queue Mode

Stand der Angaben: Juli 2026. Nexus befindet sich im Early Access, Funktionsumfang und Konditionen können sich ändern.