OXID zu Shopware Migration: Kein offizielles Tool, aber ein klarer Weg

Die OXID zu Shopware Migration ist für viele Händler 2026 das richtige Projekt, und es gibt gute Gründe dafür. Seit dem 15. August 2022 steht die OXID eShop Community Edition nicht mehr unter GPL3; der kommerzielle Einsatz ist gebührenpflichtig. Die 6er-Versionen haben End of Life erreicht, OXID 7 setzt auf Twig statt Smarty und erzwingt damit ohnehin ein Migrationsprojekt. Viele Agenturen haben die OXID-Entwicklung seit 2022 zurückgefahren.

Dieser Artikel zeigt dir die drei Migrationswege, das Datenmapping, das OXID-Shops besonders macht, und was das Projekt kostet. Die allgemeine Methodik steht im Artikel zur Shopware 5 auf 6 Migration und im Replatforming-Leitfaden.

OXID zu Shopware Migration: Das Wichtigste im Überblick

• Warum OXID-Händler 2026 wechseln, und warum OXID 7 kein kleinerer Schritt ist

• Drei Wege ohne offizielles Profil: SaaS-Tool, API-Import, eigenes Migrationsprofil

• Das Mapping: Varianten, Preisgruppen A/B/C, Kundengruppen, Multishop

• Was neu entsteht und was es kostet

Warum OXID-Händler wechseln

OXID eShop war über Jahre das Shopsystem des deutschen Mittelstands, besonders im B2B. Drei Entwicklungen haben das verändert.

Die Lizenzwende 2022. OXID hat die GPL3-Lizenz der Community Edition durch eigene Bedingungen ersetzt; kommerzielle Nutzung kostet seitdem eine Nutzungsgebühr. Für kleinere Shops, die genau wegen der kostenfreien CE bei OXID waren, fiel damit der Hauptgrund weg.

End of Life der 6er-Linie. OXID 6.x ist laut Herstellerdokumentation EOL. Wer darauf läuft, ist in derselben Lage wie Shopware-5-Betreiber: ohne Patches.

OXID 7 als Neuanfang. Seit 7.0 ist Twig die Template-Engine, ab 7.1 ist Smarty entfernt, aktuell ist 7.5. Themes und Module müssen für OXID 7 umgebaut werden. Das ist ein Migrationsprojekt innerhalb von OXID, und damit der Moment, in dem die Alternative Shopware auf den Tisch gehört. Der Leitfaden, Abschnitt 2.3, beschreibt, wie man diese Entscheidung sauber trifft.

Drei Wege ohne offizielles Profil

Weg 1: SaaS-Migrationsdienste. Anbieter wie Cart2Cart oder Next-Cart übertragen Produkte, Kategorien, Kunden, Bestellungen und Bilder aus OXID 4.x bis 7.x nach Shopware 6, bepreist nach Datenmenge. Schnell und günstig für Standarddaten. Grenzen: kein Mapping individueller Felder, keine Module, teilweise Einschränkungen beim Erhalt von IDs. Für einen kleinen Shop ohne Sonderlogik ausreichend, für gewachsene Systeme nicht.

Weg 2: API-Import. Export aus der OXID-Datenbank, Transformation nach eigenen Mapping-Regeln, Import über die Shopware Admin API oder den Sync-Endpoint. Volle Kontrolle über jedes Feld, wiederholbar für Delta-Läufe, aber Entwicklungsaufwand. In der Praxis der Standardweg für mittlere und große OXID-Shops.

Weg 3: Eigenes Profil für den Migration Assistant. Shopware hat den Assistant so gebaut, dass Agenturen eigene Quellsystem-Profile schreiben können. Der Vorteil: Du nutzt Shopwares Migrationslogik, Fortschrittsanzeige und Nachmigration. Der Nachteil: Höherer Initialaufwand, der sich erst lohnt, wenn das Profil mehrfach eingesetzt wird.

Unsere Empfehlung: Weg 2 für Einzelprojekte, Weg 3 nur, wenn eine Agentur mehrere OXID-Migrationen plant.

Das Mapping, das OXID besonders macht

Wer die Migration ohne Erfahrung angeht, unterschätzt besonders das Daten-Mapping. Eine spezialisierte Shopware-Agentur kennt die typischen Stolperfallen aus eigener Projekterfahrung.

Varianten. OXID führt Varianten als eigene Artikel mit Parent-Referenz und Variantenbezeichnung als Freitext ("Größe | Farbe"). Shopware braucht Eigenschaften mit Optionen. Der Freitext muss in strukturierte Werte zerlegt werden; bei inkonsistenter Pflege ist das Handarbeit mit Regeln.

Preisgruppen A/B/C. OXIDs drei Preisgruppen je Artikel werden zu Kundengruppen mit erweiterten Preisen oder zu Rule-Builder-Regeln. Wer in OXID zusätzlich Staffelpreise und Kundenrabatte kombiniert hat, braucht ein Entscheidungsraster, welche Logik wohin wandert.

Kunden und Gruppen. oxuser und oxgroups lassen sich sauber auf Kunden und Kundengruppen abbilden. Passwörter werden nicht übernommen; plane einen Passwort-Reset-Prozess zum Go-live.

Bestellungen. Für die Historie im Kundenkonto übertragbar. Für Buchhaltungszwecke aus Shopware heraus meist nicht sinnvoll; das ERP bleibt die führende Quelle.

SEO-URLs. OXIDs oxseo-Tabelle liefert das vollständige URL-Inventar für das 301-Mapping. Das ist ein Vorteil gegenüber anderen Quellsystemen: Die Daten sind da, man muss sie nur nutzen.

Multishop (Enterprise Edition). Mandanten und Subshops werden zu Sales Channels. Die Zuordnung von Artikeln, Preisen und Kunden je Mandant muss vor der Migration entschieden sein.

Was bei der OXID zu Shopware Migration neu entsteht

Theme. Flow, Wave oder ein individuelles Smarty- bzw. Twig-Theme wird nicht konvertiert. Das Shopware-Frontend ist ein Neubau.

Module. Hier liegt der größte Aufwand gewachsener OXID-Shops. Inventur aller Module, Klassifizierung in Store-Äquivalent, Kern-Abdeckung (Rule Builder, Flow Builder, Shopping Experiences) und Individualentwicklung. Individuelle Datenbankerweiterungen in OXID sind ein Warnsignal: Sie bedeuten Logik, die niemand dokumentiert hat.

Integrationen. ERP-, Payment- und Versandanbindungen werden neu gebaut. Das Integrationskonzept aus dem Leitfaden hilft, die Reihenfolge festzulegen.

Kosten und Ablauf der OXID zu Shopware Migration

Der Ablauf folgt den sechs Phasen aus dem Artikel zur Shopware 5 auf 6 Migration. Die OXID-Besonderheit liegt in Phase 3: Die Testmigration ist bei Weg 2 die erste Bewährungsprobe der eigenen Mapping-Regeln und sollte früher und öfter laufen als bei Systemen mit offiziellem Importer.

Kosten: Rechne mit 20 bis 50 Prozent Mehraufwand gegenüber einer Shopware-internen Migration (Marktschätzung), bei OXID vor allem durch die Mapping-Entwicklung und die Modulinventur. Vier bis acht Monate sind für einen mittleren OXID-Shop realistisch; Enterprise-Multishops länger.

Handlungsempfehlungen

1. Prüfe zuerst, ob OXID 7 oder Shopware das Ziel ist; beides ist ein Migrationsprojekt.

2. Wähle den Migrationsweg nach Datenkomplexität: SaaS-Tool für Standardshops, API-Import für gewachsene Systeme.

3. Zerlege Variantenbezeichnungen und Preisgruppen vor dem Import in Regeln, nicht danach.

4. Exportiere oxseo früh und baue das 301-Mapping daraus.

5. Plane den Passwort-Reset als Kommunikationsmaßnahme zum Go-live.

Fazit

Die OXID zu Shopware Migration kommt ohne offizielles Werkzeug aus, aber nicht ohne Methode. Der API-Import mit eigenen Mapping-Regeln ist für die meisten OXID-Shops der verlässliche Weg; SaaS-Tools reichen für Standardfälle.

Für Entscheider heißt das: Der Zeitpunkt ist jetzt, weil OXID 7 ohnehin einen Umbau erzwingt. Wer migrieren muss, sollte entscheiden, wohin.

Shopware bietet mit Rule Builder, B2B Components und einem großen Partnernetz im DACH-Raum das, wofür Mittelständler einst OXID gewählt haben. Der Wechsel ist Aufwand, aber einer mit Perspektive.

Wenn du vor der Entscheidung stehst, machen wir mit dir die Modulinventur und bewerten den Migrationsweg. Als Shopware-Agentur haben wir Mittelständler aus mehreren Altsystemen auf Shopware 6 gebracht.

FAQ

Gibt es ein offizielles Migrationstool von OXID zu Shopware 6?

Nein. Der Shopware Migration Assistant bietet Profile für Shopware 5 und Magento, nicht für OXID. Für OXID gibt es SaaS-Dienste wie Cart2Cart oder Next-Cart, den Import über die Shopware Admin API oder ein individuell entwickeltes Profil.

Welche Daten lassen sich von OXID zu Shopware übertragen?

Produkte, Varianten, Kategorien, Hersteller, Kunden, Kundengruppen, Bestellungen, Bilder und SEO-URLs. Nicht übertragbar sind Themes, Module, Passwörter und Konfigurationen.

Muss ich für die OXID Community Edition seit 2022 zahlen?

Für kommerziellen Einsatz von Code, der nach dem 15. August 2022 veröffentlicht wurde, ja. OXID hat die GPL3 durch eigene Lizenzbedingungen mit Nutzungsgebühr ersetzt. Nicht-kommerzielle Nutzung bleibt frei.

Können OXID-Module in Shopware weiterverwendet werden?

Nein. Die Architekturen sind grundlegend verschieden. Module müssen durch Store-Erweiterungen, Kernfunktionen oder Individualentwicklung ersetzt werden.

Wie lange dauert eine OXID-zu-Shopware-Migration?

Für einen mittleren Shop vier bis acht Monate, abhängig von Modulanzahl und Datenqualität. Enterprise-Multishops brauchen länger.