KI-generiertes Beispielbild — kann von der Realität abweichen.
Ein technischer Leiter betrachtet zwei Hosting-Angebote nebeneinander: SaaS vs. self-hosted. Die zentrale Frage ist, ob Plugins, Integrationen und Betriebsprozesse zwischen den Varianten kompatibel bleiben. Shopware hat dazu eine Klarstellung veröffentlicht, die genau diese Kompatibilität thematisiert.
Shopware beschreibt in einer Mitteilung vom 27.08.2026, warum Open Source Teil der Commerce-Strategie ist und wie die Plattformarchitektur als »one core, three deployment models« organisiert ist. Für Shopbetreiber, Architekten und Entwickler bedeutet das vor allem: ein gemeinsamer Core soll Kompatibilität sichern und Migrationspfade planbar machen. Die Quelle findest Du hier.
Was bedeutet „one core, three deployment models“ konkret für Shopbetreiber?
Die Kurzantwort: Alle drei Bereitstellungsvarianten (SaaS, PaaS, self-hosted) basieren auf exakt demselben Shopware-Core, sodass Kernfunktionen und APIs konsistent sein sollen. Daraus folgt für Shopbetreiber, dass Plugins und Integrationen prinzipiell portierbar und Migrationspfade planbarer sind.
Technisch heißt das, dass Shopware zentrale Logik, Datenmodelle und öffentliche APIs nicht variieren will, wenn ein Shop von eigenem Hosting zu einem Shopware-SaaS-Angebot oder einem PaaS wechselt. Für Dich als Shopbetreiber ergeben sich drei praktische Konsequenzen: Erstens erleichtert eine einheitliche Basis die Einschätzung, ob ein Drittanbieter-Plugin in allen Modellen funktioniert. Zweitens werden Migrationstests vorhersehbarer, weil sich die API-Verläufe nicht grundlegend ändern sollen. Drittens erlaubt es langfristige Betriebsentscheidungen: Du kannst Hosting-Optionen wechseln, ohne zwangsläufig einen kompletten Rewrite von Integrationen zu planen.
Wichtig bleibt: Kompatibilität ist nicht automatisch vollständige Interoperabilität. Systemabhängige Konfigurationen, Infrastrukturabhängige Services (z. B. spezifische Cloud-Dienste) und proprietäre SaaS-Erweiterungen können weiterhin Unterschiede erzeugen. Prüfe vor Migrationen Versions- und Kompatibilitätslisten der eingesetzten Plugins und dokumentiere Infrastrukturabhängigkeiten.
Welche Auswirkungen hat die gemeinsame Codebasis auf Entwickler, Plugins und CI/CD?
Die gemeinsame Codebasis reduziert den Abstimmungsaufwand für Entwickler: API-Verhalten und Kernfunktionen sind stabiler planbar, weshalb Plugin-Architekturen, Tests und CI/CD-Pipelines an einem erwartbaren Grundgerüst ausgerichtet werden können.
Für Entwickler bedeutet das konkret: Testumgebungen lassen sich so aufsetzen, dass sie das Verhalten des Core verlässlich abbilden. Eine Plugin-Architektur, die sich strikt an öffentliche Schnittstellen hält und Feature-Toggles verwendet, ist eher zwischen SaaS, PaaS und self-hosted portierbar. CI/CD-Prozesse sollten separate Stages für Core-API-Contract-Tests, Integrations-Tests gegen externe Services und Infrastructure-as-Code-Validierung enthalten. Dadurch findest Du Abweichungen frühzeitig.
Beachte aber: Einige Integrationen sind infrastructurell bedingt. Beispielsweise kann eine Suche, die auf einem host-spezifischen Managed-Service beruht, in einem anderen Modell anders betrieben werden müssen. Daher ist als Richtlinie zu empfehlen, Plugins in Layers zu strukturieren, Core-kompatible Schicht, Adapter-Schicht für Infrastruktur und Konfigurations-Schicht, damit der größte Teil des Codes ohne Änderung bleibt und nur Adapter getauscht werden müssen.
Welche Risiken und Grenzen bestehen beim Wechsel zwischen SaaS, PaaS und self-hosted?
Einheitlicher Core vermindert Risiken, aber eliminiert sie nicht: Einschränkungen entstehen durch Infrastrukturabhängigkeiten, proprietäre SaaS-Features und betriebsspezifische Konfigurationen. Migrationsaufwand bleibt möglich, insbesondere bei Integrationen und Betriebsabläufen.
Konkrete Risiken sind unter anderem: unterschiedliche Betriebsfunktionen (Monitoring, Backup, Wartungsfenster), divergierende Zusatzdienste (z. B. CDN, Managed Search), sowie Performance-Optimierungen, die an spezielle Cloud-Provider gebunden sind. Auch rechtliche oder datenschutzbezogene Anforderungen können den Wechsel erschweren, wenn ein SaaS-Angebot keine geeignete Datenlokalisierung bietet.
Als pragmatische Prüfung vor einer Migration empfiehlt sich eine Gap-Analyse: Inventarisiere eingesetzte Plugins, dokumentiere externe Services und prüfe, welche Betriebsprozesse (CI, Rollbacks, Datenmigrationsskripte) an die Infrastruktur geknüpft sind. Teste Migrationen in Staging-Umgebungen, die das Zielmodell möglichst realistisch abbilden. Beachte zudem, dass Nutzerrechte, API-Quoten oder SLA-Vereinbarungen bei SaaS-Partnern anders aussehen können als im eigenen Rechenzentrum.
Wie beeinflusst die Open-Source-Strategie Fragen zu Vendor-Lock-in und Community-Beiträgen?
Open Source als strategisches Element reduziert klassischen Vendor-Lock-in, weil Quellcode und Kernlogik offen bleiben; gleichzeitig bleibt die praktische Bindung an Plattform-Services möglich, wenn proprietäre Erweiterungen genutzt werden. Community-Beiträge werden explizit als Teil der Strategie genannt.
Für Shopbetreiber bedeutet das: Du kannst theoretisch den Code auslesen, anpassen und selbst betreiben, was die Verhandlungsposition gegenüber Dienstleistern stärkt. Praktisch entsteht Lock-in weniger durch Codezugang als durch eingesetzte Ecosystem-Services (z. B. proprietäre Backups, spezifische Cloud-Integrationen) und durch den Grad der Anpassung an das Ökosystem. Die Mitteilung von Shopware adressiert auch Community-Beiträge: ein gemeinsamer Core erleichtert, dass Verbesserungen und Bugfixes für möglichst viele Nutzer relevant sind und zentral wirken.
Wenn Deine Strategie auf größtmögliche Unabhängigkeit setzt, plane Deine Architektur daraufhin: verwende Adapter für externe Services, halte Anpassungen möglichst in eigenen Plugins, die sauber vom Core getrennt sind, und dokumentiere Änderungsbedarf. So bleibt die Option auf Wechsel offen, ohne dass Du auf hilfreiche Community- oder Hersteller-Updates verzichten musst.
Wann ist welches Deployment-Modell für meinen Shop sinnvoll?
Die Wahl des Modells hängt von drei Kriterien ab: Betriebsaufwand, Anpassungsbedarf und Compliance-Anforderungen. SaaS eignet sich für geringeren Betriebsaufwand, self-hosted für maximale Kontrolle, PaaS für Kompromisse zwischen Kontrolle und einfachen Betriebsprozessen.
Konkrete Entscheidungsindikatoren:
- Wenn Du minimalen Betriebsaufwand willst und akzeptierst, dass einige Dienste vom Anbieter verwaltet werden, ist SaaS typischerweise sinnvoll. Beachte SLA- und Datenschutzbedingungen.
- Wenn Du Anpassungen auf Infrastruktur- oder OS-Ebene brauchst (z. B. spezielle Speicher- oder Sicherheitsmodule), ist self-hosted die vermutlich einzige praktikable Option.
- Wenn Du Flexibilität beim Skalieren und gleichzeitig weniger operative Verantwortung willst, ist PaaS oft ein guter Kompromiss, vorausgesetzt der PaaS-Anbieter unterstützt die benötigten Add-ons.
Entscheide anhand eines kurzen Kriterienkatalogs: Liste Pflichtanforderungen (Compliance, Performance, Integrationen), optimiere danach die Infrastrukturkosten und schätze langfristigen Wartungsaufwand. Nutze Staging-Migrationen, um die Portierbarkeit der wichtigsten Plugins und Integrationen zu überprüfen.
Häufige Fragen
Ist wirklich der gesamte Shopware-Code in allen Modellen identisch?
Shopware schreibt, dass alle drei Modelle auf demselben Core basieren; das bedeutet, Kernfunktionen und APIs sollen konsistent sein. Infrastrukturabhängige Zusatzfunktionen oder proprietäre SaaS-Erweiterungen können dennoch Varianten erzeugen—prüfe die Herstellerangaben zu den jeweiligen Features.
Müssen Plugins für jedes Modell neu zertifiziert werden?
Nicht zwangsläufig. Wenn Plugins sich an die öffentlichen APIs halten, sind sie prinzipiell portierbar. Zertifizierungen oder Tests können allerdings notwendig sein, wenn Plugins Infrastruktur-abhängige Features verwenden oder spezielle Rechte benötigen.
Wie teste ich Migrationspfade praktisch?
Lege eine Testmatrix an: Core-Version, Plugin-Versionen, externe Integrationen. Führe automatisierte API-Contract-Tests, Integrations-Tests und Lasttests in einer Ziel-ähnlichen Staging-Umgebung durch. Dokumentiere Abweichungen und erstelle Adapter, wo nötig.
Ändert die Open-Source-Strategie etwas an Compliance- oder Datenschutzpflichten?
Die Strategie betrifft primär Code und Architektur; Compliance bleibt eine Frage der Betriebswahl. Bei SaaS prüfe Datenlokation und Auftragsverarbeitungsvereinbarungen. Bei self-hosted konfigurierst Du Datenschutz und Datensicherung selbst.
Fazit
Empfehlung: Nutze die Klarstellung von Shopware als Ausgangspunkt für eine technische Due Diligence, nicht als alleinige Entscheidungsgrundlage. Prüfe Plugins, dokumentiere Infrastrukturabhängigkeiten und führe Migrationstests in einer Staging-Umgebung durch. Wenn Du geringe Betriebsaufwände willst, ist SaaS in vielen Fällen sinnvoll; bei strikten Compliance- oder Anpassungsbedarfen ist self-hosted oft notwendig.
Konkreter Schritt: Erstelle eine Inventarliste aller Plugins und externen Services, teste deren Verhalten in einer Umgebung, die dem Zielmodell entspricht, und dokumentiere die notwendigen Adapter. Damit bleibst Du beim Wechsel zwischen SaaS, PaaS und self-hosted handlungsfähig.
