Zum Hauptinhalt springen Zur Suche springen Zur Hauptnavigation springen
Shopware Plugin-Migration · Datenübernahme · individuelle Ersatzentwicklung · Shopware 5 & 6

Shopware-Plugins ablösen und laufende Kosten gezielt reduzieren

Ihr Shop hängt von teuren Miet-Plugins ab oder eine Erweiterung wird nicht mehr gepflegt? borban prüft, welche Funktionen und Daten tatsächlich benötigt werden und ob eine eigene Ersatzlösung wirtschaftlich sinnvoll ist. Vor einer Umstellung klären wir Abhängigkeiten, Aufwand und mögliche Risiken.

Was wir bei einer Plugin-Ablösung prüfen

Zuerst klären wir, welche Funktionen das bisherige Plugin erfüllt, welche Daten davon abhängen und was nach einer Ablösung weiterhin funktionieren muss. Erst danach lässt sich eine Ersatzlösung seriös bewerten.

Migration
Bestehende Funktion analysierenStorefront, Administration, Events, Datenhaltung, Konfiguration und Seitentypen werden technisch eingeordnet.
Datenbestand identifizierenTabellen, Attribute, Custom Fields, Medien, Zuordnungen, Konfigurationen und Übersetzungen werden berücksichtigt.
Eigenständige Lösung entwickelnBenötigte Funktionen werden sauber neu umgesetzt – ohne unnötige Abhängigkeit vom bisherigen Drittanbieter-Plugin.
Parallel prüfen & sicher ablösenAlt- und Neulösung werden kontrolliert verglichen. Erst nach erfolgreicher Prüfung wird das bisherige Plugin entfernt.
Shopware 5Shopware 6Plugin-Ablösung Datenmigrationindividuelle EntwicklungAdmin & Storefront Medien & ZuordnungenMietkosten reduzieren
Wichtig: Wir kopieren keinen fremden Quellcode und erstellen keinen bloßen 1:1-Klon. Entscheidend sind die benötigte Funktion, die vorhandenen Daten und das gewünschte Ergebnis. Darauf aufbauend entsteht eine eigenständige technische Lösung.

Welche Daten können übernommen werden?

Die konkrete Datenlage hängt vom Plugin ab. Vor der Ablösung wird geprüft, wo der relevante Bestand tatsächlich liegt.

Daten
  • Eigene Plugin-Tabellen: Datensätze, Zuordnungen und Historien.
  • Artikel- & Variantendaten: Attribute, Custom Fields, Zusatzinformationen.
  • Medien: Bilder, Icons, SVGs, Dokumente oder weitere Plugin-Dateien.
  • Konfiguration: Einstellungen, Regeln, Status und Mapping-Logik.
  • Beziehungen: Artikel ↔ Daten, Varianten ↔ Daten, Kategorien, Hersteller oder Kunden.
  • Übersetzungen: sofern sie technisch im vorhandenen System zugänglich und migrierbar sind.
Grundsatz: Erst Datenmodell verstehen, dann migrieren. Eine Plugin-Deinstallation vor der Bestandsprüfung kann je nach Erweiterung Tabellen, Attribute oder Medien löschen.

Welche Funktionen können neu entwickelt werden?

Die Ersatzlösung wird auf den tatsächlich benötigten Scope begrenzt – nicht auf den kompletten Funktionskatalog des Altplugins.

Funktion
  • Storefront-Ausgabe: Produktseite, Listing, Checkout, CMS oder Kundenkonto.
  • Administration: eigene Masken, Tabs, Listen, Konfiguration und Pflegeoberflächen.
  • Import & Export: CSV, strukturierte Daten oder wiederholbare Migrationsläufe.
  • Automatisierung: Events, Regeln, Prüfungen und wiederkehrende Prozesse.
  • Schnittstellen: interne oder externe Systeme, sofern technisch sinnvoll.
  • Performance: nur benötigte Assets und Logik statt unnötigem Overhead.

Was bedeutet „eigenständig“?

Eine saubere Ablösung ist erst erreicht, wenn die neue Lösung nach Entfernung des bisherigen Plugins selbstständig funktioniert.

Unabhängig
  • Eigene Datenstruktur: kein dauerhafter Zugriff auf Tabellen des Altplugins.
  • Eigene Medien: benötigte Dateien bleiben nach der Deinstallation verfügbar.
  • Eigene Controller & Services: keine versteckte Laufzeitabhängigkeit.
  • Eigene Konfiguration: Einstellungen können unabhängig weitergepflegt werden.
  • Definierte Deinstallation: das eigene Plugin löscht nur den eigenen Bestand.

Nur die Funktionen entwickeln, die Ihr Shop wirklich braucht

Ein Ersatz muss nicht jede Option des bisherigen Plugins nachbauen. Wir konzentrieren uns auf die benötigten Abläufe und prüfen, wie sie sich ohne unnötige Abhängigkeiten integrieren lassen.

Bedarf statt Ballast
Kein 1:1-Plugin-Klon Wir kopieren oder klonen keine Drittanbieter-Plugins. Wir analysieren die tatsächlich benötigten Funktionen und entwickeln dafür eine eigenständige Lösung mit eigener Codebasis.
Weniger ungenutzte Funktionen Funktionen, Einstellungen oder Integrationen, die im Shop nicht benötigt werden, müssen nicht Teil der neuen Lösung sein. Das hält Scope und Bedienung überschaubar.
Weniger technische Komplexität Eine gezielte Lösung kann mit weniger Komponenten, Abhängigkeiten und Sonderlogik auskommen als eine universelle Erweiterung, die zahlreiche unterschiedliche Einsatzfälle bedienen muss.
Einfacher zu warten und zu testen Je klarer der benötigte Funktionsumfang abgegrenzt ist, desto leichter lassen sich Änderungen, Shopware-Updates, Datenmigrationen und Funktionstests nachvollziehen.
Unser Ansatz: Nicht „Wie bauen wir das alte Plugin vollständig nach?“, sondern „Welche Funktion braucht der Shop tatsächlich – welche Daten müssen erhalten bleiben und wie lässt sich genau dieser Bedarf sauber eigenständig lösen?“
Plugin prüfen lassen Eigenständige Entwicklung statt unnötigem Funktionsballast.

Laufende Kosten senken, wichtige Funktionen behalten

Monatliche Plugin-Gebühren können sich über mehrere Jahre summieren. Eine eigene Lösung lohnt sich aber nur, wenn Entwicklung, Wartung und mögliche Folgekosten in einem sinnvollen Verhältnis stehen.

Kosten
29 € / Monatentsprechen 348 € pro Jahr bzw. 1.740 € in fünf Jahren – für ein einzelnes Plugin, wenn der Preis unverändert bleibt.
10 Plugins × 29 € / Monatentsprechen rechnerisch 3.480 € pro Jahr bzw. 17.400 € in fünf Jahren – noch ohne Preisänderungen.
Praxis bei einzelnen KundenDurch die Ablösung und Konsolidierung mehrerer Erweiterungen konnten laufende Plugin-Kosten bereits um mehrere hundert Euro pro Monat reduziert werden.
Wirtschaftlichkeit zuerstEine Eigenentwicklung lohnt sich nur, wenn Entwicklungs-, Pflege- und Folgekosten gegenüber der bestehenden Lösung sinnvoll sind.
Kein Einsparversprechen: Die tatsächliche Ersparnis hängt von Plugin-Anzahl, Mietpreisen, benötigtem Funktionsumfang, Entwicklungsaufwand und zukünftiger Pflege ab. Die genannten Einsparungen sind Erfahrungswerte aus einzelnen Projekten und keine Garantie für andere Shops.

So läuft eine sichere Plugin-Ablösung ab

Das bisherige Plugin bleibt zunächst unverändert. Wir erfassen Daten und Funktionen, planen die Übernahme und prüfen den neuen Ablauf, bevor das alte System außer Betrieb genommen wird.

6 Schritte
1
BestandsaufnahmePlugin, Shopware-Version, Funktionen, Abhängigkeiten, Datenquellen und betroffene Bereiche werden geprüft.
2
Datenmodell sichernTabellen, Attribute, Custom Fields, Medien, Zuordnungen und Konfiguration werden identifiziert – bevor etwas deinstalliert wird.
3
Eigenständige Ersatzlösung entwickelnNur der benötigte Funktionsumfang wird sauber und nachvollziehbar neu umgesetzt.
4
Daten migrierenVorhandene Daten werden in die neue Struktur übernommen. Wiederholbare, nicht destruktive Migrationsläufe sind je nach Projekt sinnvoll.
5
Parallel testenBestandszahlen, Backend, Storefront, Varianten, Medien und Speichervorgänge werden mit der Alt-Lösung verglichen.
6
Altplugin kontrolliert entfernenErst nach erfolgreicher Prüfung wird das alte Plugin deaktiviert, erneut getestet und anschließend vollständig entfernt.
Sicherheitsprinzip: Nicht zuerst kündigen und löschen, sondern zuerst unabhängig werden. So bleibt der Rückweg während der Migration möglichst lange offen.

Bei der Ablösung wichtige Daten und Verknüpfungen erhalten

Je nach Plugin liegen wichtige Informationen in eigenen Tabellen, Konfigurationen, Kundenfeldern oder Bestellungen. Eine sichere Ablösung muss alle relevanten Verknüpfungen berücksichtigen.

Praxis
Mehrere SpeicherorteEigene Plugin-Tabellen können parallel zu Artikelattributen, Custom Fields oder Shopware-eigenen Übersetzungen verwendet werden.
Medien gehören zum DatenbestandIcons, SVGs oder andere Dateien müssen gegebenenfalls kopiert und unabhängig referenziert werden, bevor das Altplugin entfernt wird.
Deinstaller können Daten löschenManche Erweiterungen entfernen bei der Deinstallation eigene Tabellen, Attribute oder angelegte Medien. Das muss vorab bekannt sein.
Frontend allein reicht nichtAuch Backend-Editor, Varianten, Speichern, Import/Export, Cache und Administrationsmodule müssen ohne Altplugin funktionieren.
Erfahrung statt Schnellschuss: Eine erfolgreiche Migration ist erst dann abgeschlossen, wenn die neue Lösung nach vollständiger Entfernung des bisherigen Plugins mit dem übernommenen Bestand weiterarbeitet.

So prüfen wir eine Ersatzlösung

Eine neue Lösung ist nicht deshalb erfolgreich, weil sie sich installieren lässt. Entscheidend sind Datenintegrität, nachvollziehbare Architektur, saubere Trennung und ein überprüfbarer Übergang.

Qualität
Datenintegrität
Bestand vor und nach Migration prüfbar
Unabhängigkeit
keine versteckte Altplugin-Laufzeitabhängigkeit
Scope
benötigte Funktion statt unnötiger Nachbau
Wiederholbarkeit
Migration soweit sinnvoll idempotent
Testbarkeit
Backend, Frontend, Varianten, Medien
Rückweg
Altplugin erst spät endgültig entfernen

Shopware Plugin prüfen lassen

Teilen Sie uns mit, welches Plugin Sie ersetzen möchten, was es heute macht und warum Sie es ablösen wollen. Wir prüfen zunächst, ob eine eigene Lösung technisch und wirtschaftlich sinnvoll erscheint.

Anfrage
Hinweis: Bitte im ersten Schritt keine Passwörter, Admin-Zugänge, Lizenzschlüssel oder API-Keys senden. Falls für eine technische Prüfung später ein Zugang erforderlich ist, wird das separat abgestimmt.

Häufige Fragen zur Plugin-Ablösung

Antworten zu Datenübernahme, Mietplugins, Eigenentwicklung, Shopware 5 & 6, Kosten und sicherer Ablösung.

8 Fragen
Was ist eine Shopware Plugin-Migration?
Eine Plugin-Migration überführt benötigte Funktionen und vorhandene Daten aus einer bestehenden Erweiterung in eine neue, eigenständige Lösung. Vor der Ablösung werden Datenhaltung, Abhängigkeiten und tatsächlicher Funktionsumfang geprüft.
Können bestehende Plugin-Daten erhalten bleiben?
Häufig ja. Ob und wie Daten übernommen werden können, hängt vom jeweiligen Plugin ab. Relevant können eigene Datenbanktabellen, Artikelattribute, Custom Fields, Medien, Zuordnungen, Konfigurationen und Übersetzungen sein. Deshalb wird der Bestand vor einer Deinstallation analysiert.
Kann ein kostenpflichtiges oder gemietetes Plugin danach gekündigt werden?
Wenn die neue Lösung vollständig unabhängig arbeitet, die benötigten Daten übernommen wurden und die Abschlussprüfung erfolgreich ist, kann das bisherige Plugin technisch entbehrlich sein. Vertragliche Kündigungsfristen und Lizenzbedingungen des jeweiligen Anbieters sind separat zu beachten.
Kopiert borban dabei den Quellcode des bisherigen Plugins?
Nein. Ziel ist eine eigenständige Entwicklung auf Basis der benötigten Funktionen, Daten und Schnittstellen. Fremder Quellcode wird nicht einfach als eigene Lösung übernommen.
Ist die Leistung für Shopware 5 und Shopware 6 möglich?
Ja, eine technische Prüfung ist für Shopware 5 und Shopware 6 möglich. Architektur, Plugin-System, Datenmodell und Migrationsweg unterscheiden sich jedoch deutlich und werden versionsbezogen geplant.
Wie viel lassen sich bei Plugin-Kosten sparen?
Das lässt sich nicht pauschal versprechen. Bei einzelnen Kunden konnten laufende Plugin-Kosten bereits um mehrere hundert Euro pro Monat reduziert werden. Entscheidend sind die vorhandenen Mietkosten, die Zahl der Erweiterungen, der benötigte Funktionsumfang sowie Entwicklungs- und Pflegeaufwand der Ersatzlösungen.
Wann lohnt sich eine eigene Ersatzlösung nicht?
Wenn ein bestehendes Plugin günstig, zuverlässig, gut gepflegt und funktional passend ist, kann die weitere Nutzung wirtschaftlicher sein. Eine individuelle Entwicklung sollte einen nachvollziehbaren technischen oder wirtschaftlichen Vorteil haben.
Wie verhindert borban Datenverlust bei der Ablösung?
Der bisherige Datenbestand wird vor der endgültigen Entfernung identifiziert und kontrolliert migriert. Alt- und Neulösung werden verglichen, relevante Backend- und Frontend-Funktionen getestet und das Altplugin erst entfernt, wenn die neue Lösung unabhängig arbeitet.
Transparenz-Hinweis: Technische Machbarkeit, Datenmigration, Einsparpotenzial, Entwicklungsaufwand und endgültige Ablösbarkeit hängen vom jeweiligen Plugin, der Shopware-Version, dem Datenbestand, weiteren Erweiterungen und dem konkreten Shop-Setup ab. Eine Prüfung des Einzelfalls ist deshalb Bestandteil einer seriösen Einschätzung.