Shopware Open Source: ein Core, drei Deployment-Modelle und was das für Ihren Shop heißt

Shopware hat am 27.08.2026 erklärt, warum Open Source Teil seiner Commerce-Strategie ist und dass alle Bereitstellungsvarianten (SaaS, PaaS, self-hosted) auf demselben Core laufen. Für Shopbetreiber, Architekten und Entwickler heißt das: Plugins und Integrationen sollen kompatibel bleiben. Sie erfahren hier, wo das gilt, wo Grenzen liegen und wie Sie einen Wechsel planen.

Ein typisches Szenario: Ein technischer Leiter vergleicht zwei Hosting-Angebote, SaaS und self-hosted. Die zentrale Frage ist, ob Plugins, Integrationen und Betriebsprozesse zwischen den Varianten kompatibel bleiben. Shopware beschreibt seine Plattformarchitektur als „one core, three deployment models“. Ein gemeinsamer Core soll Kompatibilität sichern und Migrationspfade planbar machen. Die Quelle finden Sie im Beitrag von Shopware zur Open-Source-Strategie.

Was bedeutet „one core, three deployment models“ konkret für Shopbetreiber?

Die Kurzantwort: Alle drei Bereitstellungsvarianten (SaaS, PaaS, self-hosted) basieren auf demselben Shopware-Core, Kernfunktionen und APIs sollen also konsistent sein. Plugins und Integrationen sind damit grundsätzlich portierbar, Migrationspfade lassen sich besser planen.

Technisch heißt das: Shopware will zentrale Logik, Datenmodelle und öffentliche APIs nicht verändern, wenn ein Shop vom eigenen Hosting zu einem SaaS-Angebot von Shopware oder zu einem PaaS wechselt. Für Sie als Shopbetreiber hat das drei praktische Folgen. Erstens können Sie leichter einschätzen, ob ein Drittanbieter-Plugin in allen Modellen funktioniert. Zweitens werden Migrationstests vorhersehbarer, weil sich die APIs nicht grundlegend ändern sollen. Drittens können Sie Hosting-Optionen später wechseln, ohne zwangsläufig alle Integrationen neu schreiben zu müssen.

Kompatibilität heißt aber nicht automatisch vollständige Interoperabilität. Systemabhängige Konfigurationen, infrastrukturabhängige Dienste (z. B. bestimmte Cloud-Dienste) und proprietäre SaaS-Erweiterungen können weiterhin Unterschiede erzeugen. Prüfen Sie vor einer Migration die Versions- und Kompatibilitätslisten der eingesetzten Plugins und dokumentieren Sie Abhängigkeiten von der Infrastruktur.

Welche Auswirkungen hat die gemeinsame Codebasis auf Entwickler, Plugins und CI/CD?

Die gemeinsame Codebasis verringert den Abstimmungsaufwand für Entwickler. API-Verhalten und Kernfunktionen sind besser planbar, deshalb lassen sich Plugin-Architekturen, Tests und CI/CD-Pipelines an einem erwartbaren Grundgerüst ausrichten.

Konkret lassen sich Testumgebungen so aufsetzen, dass sie das Verhalten des Core verlässlich abbilden. Ein Plugin, das sich strikt an öffentliche Schnittstellen hält und Feature-Toggles nutzt, lässt sich eher zwischen SaaS, PaaS und self-hosted übertragen. CI/CD-Prozesse sollten eigene Stages für Contract-Tests gegen die Core-API, Integrationstests gegen externe Dienste und die Validierung von Infrastructure as Code enthalten. So finden Sie Abweichungen früh.

Manche Integrationen hängen allerdings an der Infrastruktur. Eine Suche, die auf einem Managed Service eines bestimmten Hosters beruht, muss in einem anderen Modell womöglich anders betrieben werden. Wir empfehlen daher, Plugins in Schichten aufzubauen: eine Core-kompatible Schicht, eine Adapter-Schicht für die Infrastruktur und eine Konfigurationsschicht. Dann bleibt der größte Teil des Codes unverändert, und nur die Adapter werden getauscht.

Welche Risiken und Grenzen bestehen beim Wechsel zwischen SaaS, PaaS und self-hosted?

Ein einheitlicher Core senkt Risiken, beseitigt sie aber nicht. Einschränkungen entstehen durch Infrastrukturabhängigkeiten, proprietäre SaaS-Funktionen und betriebsspezifische Konfigurationen. Migrationsaufwand bleibt möglich, vor allem bei Integrationen und Betriebsabläufen.

Konkrete Risiken sind unter anderem unterschiedliche Betriebsfunktionen (Monitoring, Backup, Wartungsfenster), abweichende Zusatzdienste (z. B. CDN, Managed Search) und Performance-Optimierungen, die an bestimmte Cloud-Anbieter gebunden sind. Auch rechtliche oder datenschutzbezogene Anforderungen können den Wechsel erschweren, wenn ein SaaS-Angebot keine passende Datenlokalisierung bietet.

Vor einer Migration empfiehlt sich eine Gap-Analyse: Erfassen Sie die eingesetzten Plugins, dokumentieren Sie externe Dienste und prüfen Sie, welche Betriebsprozesse (CI, Rollbacks, Skripte zur Datenmigration) an die Infrastruktur geknüpft sind. Testen Sie Migrationen in Staging-Umgebungen, die das Zielmodell möglichst realistisch abbilden. Nutzerrechte, API-Quoten oder SLA-Vereinbarungen können bei SaaS-Partnern anders aussehen als im eigenen Rechenzentrum.

Wie beeinflusst die Open-Source-Strategie Fragen zu Vendor-Lock-in und Community-Beiträgen?

Open Source als Teil der Strategie verringert den klassischen Vendor-Lock-in, weil Quellcode und Kernlogik offen bleiben. Eine praktische Bindung an Plattformdienste ist trotzdem möglich, wenn Sie proprietäre Erweiterungen nutzen. Community-Beiträge nennt Shopware ausdrücklich als Teil der Strategie.

Für Shopbetreiber bedeutet das: Sie können den Code grundsätzlich einsehen, anpassen und selbst betreiben, was Ihre Verhandlungsposition gegenüber Dienstleistern stärkt. In der Praxis entsteht Lock-in weniger durch den Codezugang als durch genutzte Dienste aus dem Ökosystem (z. B. proprietäre Backups, bestimmte Cloud-Integrationen) und durch den Grad der Anpassung. Shopware spricht in der Mitteilung auch Community-Beiträge an: Ein gemeinsamer Core sorgt dafür, dass Verbesserungen und Bugfixes möglichst vielen Nutzern zugutekommen.

Wenn Ihre Strategie auf möglichst große Unabhängigkeit setzt, planen Sie die Architektur entsprechend. Verwenden Sie Adapter für externe Dienste, halten Sie Anpassungen in eigenen, sauber vom Core getrennten Plugins und dokumentieren Sie Änderungsbedarf. So bleibt ein Wechsel möglich, ohne dass Sie auf Updates von Community oder Hersteller verzichten.

Wann ist welches Deployment-Modell für meinen Shop sinnvoll?

Die Wahl hängt von drei Kriterien ab: Betriebsaufwand, Anpassungsbedarf und Compliance-Anforderungen. SaaS passt bei geringem Betriebsaufwand, self-hosted bei maximaler Kontrolle, PaaS als Kompromiss zwischen Kontrolle und einfachem Betrieb.

Konkrete Entscheidungshilfen:

• Wenn Sie möglichst wenig Betriebsaufwand wollen und akzeptieren, dass der Anbieter einige Dienste verwaltet, ist SaaS meist sinnvoll. Achten Sie auf SLA- und Datenschutzbedingungen.
• Wenn Sie Anpassungen auf Infrastruktur- oder Betriebssystemebene brauchen (z. B. spezielle Speicher- oder Sicherheitsmodule), ist self-hosted vermutlich die einzige praktikable Option.
• Wenn Sie flexibel skalieren und gleichzeitig weniger operative Verantwortung tragen wollen, ist PaaS oft ein guter Kompromiss, vorausgesetzt der Anbieter unterstützt die benötigten Add-ons.

Entscheiden Sie anhand eines kurzen Kriterienkatalogs: Listen Sie die Pflichtanforderungen auf (Compliance, Performance, Integrationen), optimieren Sie danach die Infrastrukturkosten und schätzen Sie den langfristigen Wartungsaufwand. Prüfen Sie mit Migrationen auf Staging, ob sich die wichtigsten Plugins und Integrationen übertragen lassen.

Häufige Fragen

Ist wirklich der gesamte Shopware-Code in allen Modellen identisch?

Shopware schreibt, dass alle drei Modelle auf demselben Core basieren; Kernfunktionen und APIs sollen also konsistent sein. Infrastrukturabhängige Zusatzfunktionen oder proprietäre SaaS-Erweiterungen können trotzdem Unterschiede erzeugen. Prüfen Sie die Herstellerangaben zu den jeweiligen Funktionen.

Müssen Plugins für jedes Modell neu zertifiziert werden?

Nicht zwangsläufig. Wenn sich Plugins an die öffentlichen APIs halten, sind sie grundsätzlich portierbar. Zertifizierungen oder Tests können aber nötig sein, wenn Plugins infrastrukturabhängige Funktionen verwenden oder besondere Rechte benötigen.

Wie teste ich Migrationspfade praktisch?

Legen Sie eine Testmatrix an: Core-Version, Plugin-Versionen, externe Integrationen. Führen Sie automatisierte API-Contract-Tests, Integrationstests und Lasttests in einer Staging-Umgebung durch, die dem Zielmodell ähnelt. Dokumentieren Sie Abweichungen und bauen Sie Adapter, wo nötig.

Ändert die Open-Source-Strategie etwas an Compliance- oder Datenschutzpflichten?

Die Strategie betrifft vor allem Code und Architektur; Compliance hängt vom gewählten Betriebsmodell ab. Bei SaaS prüfen Sie Datenstandort und Auftragsverarbeitungsverträge. Bei self-hosted konfigurieren Sie Datenschutz und Datensicherung selbst.

Fazit

Nutzen Sie die Klarstellung von Shopware als Ausgangspunkt für eine technische Prüfung, nicht als alleinige Entscheidungsgrundlage. Prüfen Sie Plugins, dokumentieren Sie Abhängigkeiten von der Infrastruktur und testen Sie Migrationen auf Staging. Wenn Sie wenig Betriebsaufwand wollen, ist SaaS oft sinnvoll; bei strengen Compliance- oder Anpassungsanforderungen ist self-hosted häufig nötig.

Der nächste konkrete Schritt: Erstellen Sie eine Liste aller Plugins und externen Dienste, testen Sie deren Verhalten in einer Umgebung, die dem Zielmodell entspricht, und dokumentieren Sie die nötigen Adapter. Dann bleiben Sie beim Wechsel zwischen SaaS, PaaS und self-hosted handlungsfähig. Wie wir solche Umstellungen begleiten, lesen Sie unter Shopware-Migration und Relaunch.