Shopware Plugin-Migration · Datenübernahme · individuelle Ersatzentwicklung · Shopware 5 & 6

Shopware Plugins migrieren, Mietkosten reduzieren & eigene Lösungen entwickeln

borban unterstützt Shopbetreiber dabei, bestehende Shopware-Plugins technisch zu prüfen, vorhandene Daten sicher zu übernehmen und bei Bedarf durch eine eigenständige, individuell entwickelte Lösung zu ersetzen. Dabei wird nicht der komplette Funktionsumfang eines Drittanbieter-Plugins künstlich nachgebaut: Entwickelt werden die Funktionen, die der jeweilige Shop tatsächlich benötigt. Ziel ist, unnötige Abhängigkeiten, laufende Plugin-Kosten und technische Komplexität dort zu reduzieren, wo eine Ablösung sinnvoll ist.

Was bedeutet Shopware Plugin-Migration?

Bei einer Plugin-Migration wird nicht einfach eine Erweiterung abgeschaltet. Zuerst wird geprüft, welche Funktionen das bestehende Plugin tatsächlich übernimmt, wo seine Daten gespeichert sind und welche Abhängigkeiten im Shop bestehen. Danach kann eine eigenständige Ersatzlösung entwickelt und der vorhandene Datenbestand kontrolliert übernommen werden.

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

Standardplugins müssen möglichst viele Shops, Themes, Prozesse und Sonderfälle abdecken. Deshalb enthalten sie häufig Funktionen, Einstellungen, Integrationen oder Verwaltungsbereiche, die im konkreten Shop gar nicht genutzt werden. Bei einer individuellen Ersatzlösung muss dieser komplette Funktionsumfang nicht künstlich nachgebaut werden.

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.

Typische Beispiele

Welche Teile überflüssig sind, lässt sich erst nach Analyse des konkreten Plugins und Shops beurteilen.

Scope

nicht genutzte Integrationen oder Schnittstellen
zusätzliche Frontend-Ausgaben, die deaktiviert bleiben
Konfigurationsoptionen für fremde Anwendungsfälle
Import-/Export-Wege, die im Shop nie verwendet werden
Admin-Funktionen ohne praktischen Nutzen im eigenen Workflow
Kompatibilitätslogik für Systeme oder Themes, die nicht eingesetzt werden

Wichtig: Weniger Funktionen sind nicht automatisch besser. Entfernt wird nur, was für den vereinbarten Anwendungsfall tatsächlich nicht benötigt wird.

Laufende Plugin-Kosten reduzieren – ohne benötigte Funktionen aufzugeben

Einzelne Mietplugins wirken monatlich oft überschaubar. In Shops mit vielen Erweiterungen können sich die laufenden Kosten jedoch über Jahre deutlich summieren. Eine gezielte Konsolidierung kann deshalb nicht nur technisch, sondern auch wirtschaftlich interessant sein.

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

Der kritische Punkt ist nicht das neue Plugin allein, sondern der kontrollierte Übergang. Das bisherige System bleibt so lange verfügbar, bis Datenbestand und Funktion der neuen Lösung verifiziert sind.

6 Schritte

BestandsaufnahmePlugin, Shopware-Version, Funktionen, Abhängigkeiten, Datenquellen und betroffene Bereiche werden geprüft.

Datenmodell sichernTabellen, Attribute, Custom Fields, Medien, Zuordnungen und Konfiguration werden identifiziert – bevor etwas deinstalliert wird.

Eigenständige Ersatzlösung entwickelnNur der benötigte Funktionsumfang wird sauber und nachvollziehbar neu umgesetzt.

Daten migrierenVorhandene Daten werden in die neue Struktur übernommen. Wiederholbare, nicht destruktive Migrationsläufe sind je nach Projekt sinnvoll.

Parallel testenBestandszahlen, Backend, Storefront, Varianten, Medien und Speichervorgänge werden mit der Alt-Lösung verglichen.

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.

Praxiswissen: Warum „Daten behalten“ mehr bedeutet als eine Datenbankkopie

Bei realen Plugin-Ablösungen liegen relevante Informationen häufig an mehreren Stellen gleichzeitig. Eine vollständige Migration kann deshalb deutlich mehr umfassen als das Kopieren einer einzelnen Tabelle.

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.

Qualitätskriterien für Migration & Ersatzentwicklung

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

Für eine erste technische Einschätzung reichen Shopware-Version, Name bzw. Funktion des bestehenden Plugins, eine kurze Beschreibung der verwendeten Bereiche und das Ziel der Ablösung. Sensible Zugangsdaten sind dafür nicht nötig.

Anfrage

Plugin-Migration anfragen E-Mail senden Systemlösungen ansehen Shopware 6 Plugins Shopware 5 Plugins

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.

Passende nächste Schritte rund um Shopware Plugins

Eine Plugin-Migration ist nur eine mögliche Route. Je nach Ausgangslage kann ein fertiges Plugin, eine individuelle Systemlösung oder eine spezialisierte Shopware-Funktion sinnvoller sein. Diese Seiten helfen bei der weiteren Einordnung.

Weiterführend

Shopware Plugins Zentraler Plugin-Hub für fertige Erweiterungen, Shopware 5, Shopware 6 und technische Shopware-Themen. Plugin-Hub öffnen Shopware 6 Plugins Fertige Erweiterungen für moderne Shopware-6-Shops und klar abgegrenzte technische Anforderungen. Shopware 6 ansehen Shopware 5 Plugins Erweiterungen für aktive Shopware-5-Bestandssysteme und gewachsene Legacy-Projekte. Shopware 5 ansehen Codebasierte Systemlösungen Wenn mehrere Datenflüsse, Prozesse oder Integrationen zusammenspielen und ein einzelnes Plugin nicht ausreicht. Systemlösungen ansehen Altersverifikation & AVS Beispiel für eine eigenständig entwickelte Borban-Systemlösung mit Shopware-5-/6-Integration und internationaler Dokumentprüfung. Verify Pro ansehen Projekt einordnen lassen Plugin, Shopware-Version, vorhandene Daten und Ziel nennen – wir prüfen die technisch sinnvolle Route. Kontakt aufnehmen

FAQ zur Shopware Plugin-Migration

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.