Migration von Shopware zu Shopify Plus: Kosten, Zeitplan und was neu abgebildet werden muss
Von Robin Laseur
Der sichtbare Teil einer Migration von Shopware zu Shopify Plus ist ein neuer Storefront. Der schwierige Teil liegt darunter: vererbte Produktbeziehungen, Bedingungen im Rule Builder, Einkaufswelten, die Konfiguration der Verkaufskanäle, Plugins, B2B-Abläufe und Anbindungen an die Systeme, die den gesamten Betrieb tragen.
Eine Migration von Shopware zu Shopify Plus überträgt die Commerce-Daten, die das Unternehmen noch braucht, bildet Shopware-spezifische Regeln und Strukturen neu ab, baut den Storefront neu und bindet wesentliche Systeme wieder an. Ein vollständiges Programm umfasst Discovery, Zielarchitektur, Daten, Funktionen, Integrationen, SEO, Tests, Umstellung und Stabilisierung nach dem Go-live, statt das Projekt als Katalogimport zu behandeln.
Shopware Funktion für Funktion nachzubauen, ist selten das stärkste Ziel. Damit tragen Sie historische Umsetzungsentscheidungen auf eine Plattform mit einem anderen Betriebsmodell. Das bessere Ziel ist Geschäftskontinuität mit weniger vermeidbarer Komplexität: Erhalten Sie die Funktionen, die Kunden und interne Teams unterstützen, und geben Sie jeder die einfachste zuverlässige Verantwortung in der Shopify-Architektur.
Wie verändert die Quellversion eine Shopware-Migration?
Shopware 5 und Shopware 6 erfordern unterschiedliche Migrationsbewertungen. Shopware 5 ist eine abgekündigte Legacy-Plattform mit anderer technischer Grundlage, während Shopware 6 als Community Edition, mit kommerziellem Plan, selbst gehostet, als PaaS oder als SaaS laufen kann. Quellversion, Deployment-Modell und Funktionsumfang bestimmen, welche Daten, welcher Code und welche operative Verantwortung sich ändern müssen.
Shopware hat den offiziellen Sicherheitssupport für Shopware 5 im Juli 2024 eingestellt. Die eigenen Hinweise zur Migration von Shopware 5 machen deutlich, dass Shopware 6 ein anderes Ziel ist und kein gewöhnliches Versions-Update. Für ein Unternehmen, das noch auf Shopware 5 läuft, ist die Entscheidung daher breiter als die Frage nach einer Modernisierung. Es geht darum, ob Sie auf Shopware 6 neu bauen oder den ohnehin nötigen Plattformwechsel nutzen, um zu Shopify Plus zu wechseln.
Prüfen Sie bei Shopware 6, ob die Umgebung die Community Edition oder einen Rise-, Evolve- oder Beyond-Plan nutzt und ob sie selbst gehostet, als PaaS oder als SaaS betrieben wird. Diese Entscheidungen verändern, welche kommerziellen Funktionen, welcher individuelle Code und welche Infrastrukturverantwortung zum Umfang gehören.
Klären Sie diese Punkte, bevor Sie das Projekt schätzen:
Haupt- und Nebenversion von Shopware
Community Edition oder aktueller kommerzieller Plan
Deployment: selbst gehostet, PaaS oder SaaS
Anzahl und Zweck der Verkaufskanäle
Architektur von Storefront, Headless oder eigenem Frontend
Aktive Plugins, Apps und individuelle Erweiterungen
Nutzung von Rule Builder und Flow Builder
Einkaufswelten, CMS-Erweiterungen und eigene Content-Blöcke
B2B Suite, B2B Components oder eigene Großhandelsfunktionen
Anbindungen an ERP, PIM, WMS, POS, Marktplätze und Marketing
Wann ist der Wechsel von Shopware zu Shopify Plus sinnvoll?
Der Wechsel von Shopware zu Shopify Plus ist sinnvoll, wenn Infrastruktur, Upgrades, Plugins und spezialisierte Entwicklung Kapazität binden, die das Unternehmen in die Verbesserung des Commerce stecken will. Der Business Case wird stärker, wenn Shopify das benötigte B2C-, B2B- und Multi-Market-Modell mit weniger plattformspezifischen Abhängigkeiten und geringerer Betriebslast über drei Jahre tragen kann.
Shopware bleibt eine ernsthafte Option für europäischen Commerce im Mittelstand und im Enterprise-Segment. Es kann zu Organisationen passen, die Kontrolle über Deployment und Anwendungsarchitektur schätzen, die Regel- und Content-Funktionen intensiv nutzen und das Engineering-Modell haben, diese Flexibilität gut zu betreiben. Eine Migration sollte nicht mit der Annahme beginnen, Shopify Plus sei automatisch ein Upgrade.
Signale, die eine formale Bewertung eines Plattformwechsels rechtfertigen:
Wartung verdrängt immer wieder kaufmännische Arbeit: Ein erheblicher Teil der Entwicklungskapazität fließt in Hosting, Upgrades, Kompatibilität und Fehlerbehebung.
Routineänderungen hängen an knappen Spezialisten: Verbesserungen bei Merchandising, Inhalten oder Checkout erreichen nicht das Tempo, das E-Commerce-Teams erwarten.
Die Verantwortung für Plugins ist unklar: Mehrere Erweiterungen überschneiden sich, enthalten geschäftskritische Logik oder haben keine benannte interne Verantwortung.
Verkaufskanäle sind in der Konfiguration auseinandergedriftet: Unterschiede bei Markt, Sprache, Währung, Preisen und Navigation lassen sich nur schwer einheitlich steuern.
Das B2B- und D2C-Betriebsmodell hat sich verändert: Das aktuelle Setup spiegelt nicht mehr wider, wie Kunden, Vertriebsteams und Backoffice-Systeme arbeiten.
Die TCO über drei Jahre passt nicht mehr zum gelieferten Wert: Plattform, Hosting, Entwicklung, Plugins und interne Zeit kosten mehr als die Kontrolle, die sie bieten.
Flatlines Vergleich von Shopware und Shopify behandelt die grundsätzliche Plattformentscheidung. Sobald der Migrationsweg abgegrenzt wird, lautet die nützlichere Frage, ob das Ziel-Betriebsmodell genug Verantwortung und Abhängigkeit abbaut, um die Wechselkosten zu rechtfertigen.
Wann das Bleiben bei Shopware die bessere Entscheidung sein kann
Bleiben kann die stärkere Wahl sein, wenn die aktuelle Implementierung gesund ist, das interne Team die Flexibilität von Shopware produktiv nutzt und die Roadmap von Kontrolle abhängt, die rund um Shopify umfangreiche individuelle Dienste erfordern würde. Eine stabile Shopware-6-Umgebung sollte nicht ersetzt werden, nur weil Shopify eine einfachere Funktionsgeschichte erzählt.
Was sollte übertragen, neu abgebildet, neu gebaut oder abgeschaltet werden?
Jedes Element aus Shopware sollte eine von vier Zielentscheidungen erhalten. Übertragen Sie Datensätze, die bereits zum Modell von Shopify passen. Bilden Sie Strukturen oder Regeln neu ab, deren geschäftliche Bedeutung bleibt, deren Umsetzung sich aber ändert. Bauen Sie Funktionen neu, die eine neue Verantwortung innerhalb von Shopify brauchen. Schalten Sie Daten, Plugins und Abläufe ab, die Migration und laufenden Support nicht mehr rechtfertigen.
Diese Einteilung macht aus einem technischen Inventar einen Umfang mit klaren Verantwortlichkeiten. Eine Tabelle mit dem Etikett „Migrationsdaten“ unterscheidet nicht zwischen einer aktiven kaufmännischen Regel und einer ruhenden oder zwischen einer Funktion, die Kunden sehen, und einer Erweiterung, die vor Jahren installiert wurde und nicht mehr genutzt wird.
Jede Entscheidung braucht eine fachliche Verantwortung. E-Commerce gibt das Merchandising-Verhalten frei, Finance die Preis- und Steuerlogik, Operations die Bestell- und Fulfillment-Abläufe und Marketing den Umgang mit Einwilligungen und Kunden-Events. So trennen Sie auch den für den Go-live kritischen Umfang von Verbesserungen, die später folgen können.
Wie sollten Shopware-Produkte und Katalogdaten auf Shopify abgebildet werden?
Shopware-Produkte sollten nach verkaufbarem Verhalten und den Anforderungen nachgelagerter Systeme auf Shopify abgebildet werden. Eltern-Kind-Varianten, Eigenschaften, Optionen, Kategorien, Zusatzfelder, Medien und die Verfügbarkeit je Kanal haben keine automatischen Eins-zu-eins-Entsprechungen. Das Migrationsmodell muss erhalten, was Kunden auswählen können und was Bestands-, Bestell- und Fulfillment-Systeme erhalten müssen.
Das Produktmodell von Shopware unterscheidet Hauptprodukte und verkaufbare Varianten, mit Vererbung zwischen ihnen. Die Produktdokumentation trennt außerdem Eigenschaften, die ein Produkt beschreiben, von Optionen, die Varianten festlegen. Produkte können mehreren hierarchischen Kategorien angehören und über ausgewählte Verkaufskanäle angeboten werden.
Shopify arbeitet mit Produkten, Varianten, Kollektionen, Metafields und Metaobjects. Ein Standardprodukt mit Größe und Farbe lässt sich womöglich sauber abbilden. Komplexere Beziehungen können ein anderes Modell erfordern, besonders wenn ein Konfigurator, ein Bundle, eine Einheitenumrechnung, ein Staffelpreis oder eine ERP-Nachricht von der Quellstruktur abhängt.
Den Zielkatalog festlegen, bevor der Export umgewandelt wird
Dokumentieren Sie aktive Produkte, Varianten, Eigenschaften, Kategorien, Medien, Zusatzfelder und die Verfügbarkeit je Markt. Legen Sie dann die Verantwortung nach dem Go-live fest. Das PIM kann die Anreicherung verantworten, das ERP Preis und Bestand und Shopify das digitale Sortiment.
Die Zahl der Produkte misst nicht die Schwierigkeit des Mappings. Ein großer Katalog mit konsistenten Kennungen kann einfacher sein als ein kleinerer Katalog, dessen Variantenoptionen, Zusatzfelder und ERP-Verweise ohne Governance gewachsen sind.
Repräsentative Testdaten sollten enthalten:
Ein einfaches Produkt und eine Variantenfamilie mit maximaler Komplexität
Produkte mit vererbten und überschriebenen Werten
Produkte, die mehreren Kategorien oder Verkaufskanälen zugeordnet sind
Beispiele für Sichtbarkeit und Preise je Markt
Bundles, Sets, Konfiguratoren oder digitale Produkte, sofern genutzt
Auslaufprodukte, übersetzte Inhalte und Medien
Die Ausgabe für Bestellpositionen und Fulfillment, die angebundene Systeme erwarten
Validieren Sie das Ergebnis für Kunden und den operativen Datensatz gemeinsam. Eine Produktseite kann korrekt aussehen, während SKU, Steuerklasse, Bestandseinheit oder Zusammensetzung der Bestandteile, die im ERP ankommen, falsch sind.
Zusatzfelder als Geschäftsdaten behandeln, nicht als allgemeine Metadaten
Shopware erlaubt Zusatzfelder für Produkte, Kunden, Bestellungen und andere Entitäten. Erfassen Sie jedes Feld mit Typ, Quelle, Nutzern und nachgelagertem Zweck. Ein Feld, das nur ein abgeschaltetes Plugin nutzt, braucht womöglich kein Ziel. Ein Feld, das Filter, Feeds oder Fulfillment steuert, braucht ein ausdrückliches Mapping auf ein Shopify-Metafield, ein Metaobject oder ein externes System.
Wie lassen sich Rule Builder, Aktionen und Automatisierung auf Shopify abbilden?
Logik aus dem Shopware Rule Builder sollte in Bedingungen, Wirkungen und Zuordnungspunkte zerlegt werden, bevor sie auf Shopify abgebildet wird. Eine Regel kann Versand, Zahlung, Aktionen, erweiterte Preise, Flows oder die Sichtbarkeit von Inhalten beeinflussen. Das Ziel kann je nach Anforderung Shopify-Konfiguration, Rabatte, Functions, Markets, Flow, eine App oder einen externen Dienst nutzen.
Das Zuordnungsmodell des Rule Builders von Shopware zeigt, warum ein Export der Regelnamen nicht ausreicht. Regeln können die Verfügbarkeit von Zahlungs- und Versandarten beeinflussen, Versandkosten, Aktionen, Rabatte, erweiterte Preise, Flows und die Sichtbarkeit von Inhalten. Eine mehrfach genutzte Bedingung zu ändern, kann daher mehrere Kunden- oder Betriebsabläufe verändern.
Legen Sie ein Regelregister mit diesen Feldern an:
Wandeln Sie nicht jede Shopware-Regel standardmäßig in eine eigene Shopify Function um. Manche Bedingungen gehören in Markets, Kataloge, Versandprofile, Zahlungskonfiguration oder Standardrabatte. Andere sind im ERP oder in der Middleware klarer aufgehoben, wenn dieses System die zugrunde liegende kaufmännische Vorgabe bereits verantwortet.
Das stärkste Ziel ist die kleinste Menge an Regeln, die die nötigen Ergebnisse liefert. Das ist auch eine Gelegenheit, Widersprüche zu beseitigen. Können zwei Shopware-Regeln über unterschiedliche Zuordnungen denselben Warenkorb beeinflussen, sollte die Discovery die Rangfolge festlegen, bevor im Ziel irgendetwas gebaut wird.
Aktionen brauchen eine Prüfung ihres Verhaltens: Berechtigung, Kombinierbarkeit, Gutscheine, Zeiträume, ausgeschlossene Produkte, Auswirkungen auf den Versand, Brutto- oder Nettoberechnung und Reporting. Der im Browser sichtbare Rabatt ist nur ein Ergebnis. Finance, Analyse und Kundenservice brauchen nach dem Go-live dieselbe Interpretation.
Wie sollten Shopware-Verkaufskanäle auf Shopify Markets und Shops abgebildet werden?
Shopware-Verkaufskanäle sollten nach Zielgruppe, Transaktionen und Governance-Anforderungen abgebildet werden, statt sie in dieselbe Zahl von Shopify-Shops zu kopieren. Ein Verkaufskanal kann Sprache, Währung, Steuern, Zahlung, Versand, Domains und Navigation steuern. Shopify Markets, Kataloge, Kanäle und Expansion Stores verteilen diese Aufgaben anders, daher braucht jeder Quellkanal eine Bewertung nach seinem Zweck.
Shopware definiert Verkaufskanäle als den Weg, auf dem ein Katalog eine bestimmte Zielgruppe erreicht, darunter Storefronts, Headless-Clients, Feeds oder Anwendungen. Jeder Kanal kann Standardwerte für Sprache, Währung, Steuern, Zahlung, Versand, Domains und Navigation haben.
Mit Shopify Markets lassen sich Produktverfügbarkeit, Preise, Währung, Sprache, Domains, Theme-Inhalte und das steuerliche Erlebnis je Region oder Kundengruppe variieren. Andere Kanaltypen, Feeds und separate Shops können Anforderungen abdecken, die nicht in eine einzige Marktstruktur gehören.
Halten Sie für jeden Shopware-Verkaufskanal fest:
Zielgruppe, Länder, Marke und Domain
Gesellschaft und Zahlungsabwicklung
Sprache, Währung, Steuern und Zölle
Verantwortung für Katalog, Preise und Bestand
Zahlung, Versand und Fulfillment
Navigation, Inhalte und operative Verantwortung
Mehrere Storefront-Kanäle aus Shopware können in einem Shopify-Shop mit Markets aufgehen. Ein Kanal für einen Marktplatz-Feed kann statt eines Shops zu einer App- oder Feed-Anbindung werden. Getrennte Gesellschaften, Marken oder stark unterschiedliche Abläufe können weiterhin getrennte Shopify-Shops rechtfertigen.
Das Mapping sollte Duplizierung verringern, ohne Anforderungen zu zentralisieren, die eine eigene Verantwortung brauchen. Ein Architekturdiagramm hilft, doch die Entscheidung folgt aus den Details von Transaktionen und Governance, nicht aus einem optisch aufgeräumten Bild.
Was passiert mit Einkaufswelten, Themes und Headless-Storefronts?
Einkaufswelten, Themes und Headless-Frontend-Code aus Shopware wandern nicht direkt zu Shopify. Wiederverwendbare Inhalte und Design-Assets lassen sich migrieren, doch Layouts, CMS-Blöcke, Twig-Templates, Anbindungen an die Store API und eigene Rendering-Logik brauchen eine neue Umsetzung. Wählen Sie Liquid oder Headless-Shopify nach den aktuellen Anforderungen, nicht nach der Quellarchitektur.
Die Einkaufswelten von Shopware ordnen Landingpages, Shopseiten und Kategorielayouts über Sektionen, Blöcke und Elemente. Eigene CMS-Elemente oder Erweiterungen können geschäftsspezifische redaktionelle Funktionen ergänzen. Die Inhalte darin können wertvoll bleiben, doch Struktur und Rendering sind an Shopware gebunden.
Erstellen Sie ein Inventar der Content-Komponenten, statt Screenshots zu machen und Seiten einzeln nachzubauen. Halten Sie für jeden Block Inhaltsfelder, Platzierungen, Unterschiede je Markt, Zeitplanung, dynamische Daten, Personalisierung, SEO-Rolle und Nutzungshäufigkeit fest. Entscheiden Sie dann, ob er wird:
Eine Section, ein Block oder eine native Seite in einem Shopify-Theme
Eine Komponente, die über Metafields oder Metaobjects gesteuert wird
Ein externes CMS, eine App oder eine eigene Storefront-Funktion
Abgeschaltete oder zusammengeführte Inhalte
Dieser Ansatz erhält das redaktionelle System, nicht nur das veröffentlichte Erscheinungsbild. Marketing-Teams sollten nach dem Go-live die nächste Kampagne erstellen können, ohne Entwickler zu bitten, eine fest programmierte Seite zu kopieren.
Liquid oder Headless ist eine neue Entscheidung
Ein individueller oder Headless-Storefront auf Shopware macht Headless-Shopify nicht zur Pflicht. Ein Theme-basierter Shopify Online Store kann weiterhin ein eigenständiges Design, ein wiederverwendbares Content-System und starke Performance tragen, mit weniger Verantwortung für Infrastruktur und Integrationen.
Headless bleibt gerechtfertigt, wenn geprüfte Anforderungen an Erlebnis, Kanäle oder Organisation über das Theme-Modell hinausgehen. Beispiele sind ein Commerce-Erlebnis, das über mehrere Anwendungen geteilt wird, ein Frontend, das als eigenständiges Produkt gesteuert wird, oder komplexe Content-Orchestrierung. Wählen Sie es, weil das Unternehmen im Zielzustand es braucht, nicht weil das Quellteam bereits in ein entkoppeltes Frontend investiert hat.
Auch die Wiederverwendung von Frontend-Komponenten erfordert Vorsicht. Eine Komponente kann in einem portablen JavaScript-Framework geschrieben sein und trotzdem von Schemas der Shopware Store API, Sitzungskontext, Routing und Plugin-Verhalten abhängen. Die Wiederverwendung von Code sollte auf eine Prüfung der Abhängigkeiten folgen, nicht auf einen optischen Vergleich.
Wie sollten Plugins und Integrationen bewertet werden?
Shopware-Plugins und -Integrationen sollten nach der Geschäftsfunktion bewertet werden, die sie liefern, nach den Daten, die sie austauschen, und nach den Folgen eines Ausfalls. Plugins werden nicht eins zu eins zu Shopify-Apps. Manche Anforderungen werden native Shopify-Konfiguration, manche brauchen eine App oder individuelle Integration, und andere sollten in das System wandern, das den Prozess bereits verantwortet.
Legen Sie getrennte Inventare für Storefront-Plugins und Systemintegrationen an, auch wenn dieselbe Erweiterung in beiden vorkommt. Ein Bewertungs-Widget und ein ERP-Konnektor haben unterschiedliche operative Folgen, Testbedarfe und Verantwortungsmodelle.
Halten Sie für jedes Plugin fest:
Geschäftlicher Zweck und benannte Verantwortung
Supportstatus, gelesene und geschriebene Daten und Belege für aktive Nutzung
Auswirkung auf Storefront, Checkout, Administration oder geplante Jobs
Abhängigkeiten, Vertrag und Exit-Anforderungen
Zielentscheidung und Abnahmekriterien
Integrationen bestimmen meist den kritischen Pfad
Anbindungen an ERP, PIM, WMS, OMS, CRM, POS, Suche, Steuern, Zahlungen, Marktplätze und Lifecycle-Marketing brauchen Verträge statt Etiketten. „Das ERP anbinden“ sagt nicht, welches System für Produkt-, Bestands-, Preis-, Kunden- oder Bestelldaten verantwortlich ist.
Dokumentieren Sie für jeden Fluss Richtung, Häufigkeit, Volumen, Umwandlungen, Kennungen, Fehlerbehandlung, Abgleich und erwartete Service-Level. Gestalten Sie dann den Shopify-Vertrag rund um die Datenverantwortlichen im Zielzustand. Eine Migration kann Punkt-zu-Punkt-Verbindungen entfernen, die Middleware duplizieren, sollte aber keine Logik in Shopify zentralisieren, nur weil die Commerce-Plattform neu ist.
Führen Sie End-to-End-Tests mit realistischen Ausnahmen durch: Teilbestand, stornierte Bestellungen, Preisänderungen, Retouren, fehlgeschlagene Nachrichten, doppelte Kunden und nicht erreichbare nachgelagerte Systeme. Tests des Idealfalls zeigen nicht, ob sich der Betrieb erholen kann, wenn eine Verbindung ausfällt.
Wie sollte Shopware B2B auf Shopify Plus abgebildet werden?
Shopware B2B sollte als vollständige Einkaufsabläufe abgebildet werden statt als Funktionsliste. Firmenstrukturen, Rollen, Freigaben, Bestelllisten, eigene Bestellnummern, Budgets, kundenspezifische Kataloge, Preise und vertriebsgestützte Prozesse können aus der B2B Suite, den B2B Components, Plugins oder individuellem Code stammen. Jeder Ablauf braucht eine geprüfte Verantwortung in Shopify und im Backoffice.
Die aktuellen B2B Components von Shopware unterstützen Firmenrollen und Kontakte, Bestellfreigaben, Bestelllisten und eigene Bestellnummern. Ältere Umgebungen nutzen womöglich die B2B Suite, die laut Shopware zugunsten der B2B Components nicht mehr weiterentwickelt wird, oder eine eigene Kombination aus Kundengruppen und Erweiterungen.
Shopify unterstützt Firmen und Firmenstandorte, Kataloge, Zahlungsbedingungen, Mengenregeln und Staffelpreise. Shopify Plus ergänzt die direkte Zuordnung von Katalogen zu Firmen und erweiterte Zahlungsfunktionen, die in niedrigeren Tarifen nicht in derselben Form verfügbar sind. Diese Funktionen bilden eine starke Grundlage, belegen aber keine Parität mit jeder B2B-Umsetzung in Shopware.
Bilden Sie den gesamten Einkaufsweg ab:
Konto und Identität: Wer legt die Firma an, lädt Kontakte ein und steuert den Zugang?
Berechtigung: Welche Produkte, Inhalte und Preise sieht jeder Firmenstandort?
Einkaufskontrollen: Sind Mindestmengen, Staffelschritte, Budgets, Freigaben oder Bestellnummern nötig?
Checkout und Zahlung: Welche Bedingungen, Anzahlungen, Steuerregeln und Zahlungsarten gelten?
Beteiligung des Vertriebs: Können Vertriebsmitarbeiter im Namen eines Einkäufers Warenkörbe, Angebote oder Bestellungen vorbereiten?
Bestellabläufe: Wie gelangen Änderungen, Rückstände, Retouren, Gutschriften und Fulfillment ins ERP?
Shopify sollte nur die Funktionen verantworten, die zu seiner Rolle in der Zielarchitektur passen. Vertragspreise können im ERP bleiben, während Shopify-Kataloge die Darstellung steuern. Freigabelogik braucht womöglich eine App oder Workflow-Ebene. Der Kundenservice kann im CRM bleiben. Ein sauberer B2B-Storefront kann weiterhin von mehreren Systemen abhängen, doch jede Abhängigkeit sollte bewusst gewählt sein.
Wie lange dauert eine Migration von Shopware zu Shopify Plus?
Eine Migration von Shopware zu Shopify Plus für einen etablierten Betrieb sollte meist in Monaten geplant werden. Ein abgegrenztes B2C-Projekt passt womöglich in 12 bis 16 Wochen, während Programme mit mehreren Märkten, B2B, Headless oder vielen Integrationen oft 18 bis 28 Wochen oder länger brauchen. Die Discovery sollte die Spanne festlegen, sobald die Komplexität der Quelle und die Entscheidungskapazität bekannt sind.
Shopifys Hinweise zur Enterprise-Migration aus dem Jahr 2026 nennen 12 bis 16 Wochen für Migrationen mit komplexen Integrationen, während die breiteren Hinweise zur Modernisierung manche Enterprise-Replatformings bei sechs bis zwölf Monaten ansetzen. Beides kann zutreffen, weil sich die Projektgrenzen unterscheiden.
Nutzen Sie diese Spannen für die erste Planung, nicht als Lieferzusage:
Eine praktische Reihenfolge umfasst:
Die Umgebung prüfen: Version, Deployment, Produkte, Regeln, Inhalte, Plugins, Integrationen, SEO und Abläufe.
Das Zielmodell freigeben: Entscheidungen zu Shopify-Tarif, Markets, Datenverantwortung, B2B, Storefront und Apps.
Schwierige Mappings belegen: Repräsentative Produkte, Preise, Kunden, Bestellungen und Integrations-Events testen.
Die Arbeitspakete umsetzen: Storefront, Daten, Integrationen, Inhalte und SEO anhand gemeinsamer Abnahmekriterien vorantreiben.
End-to-End validieren: Konten, Checkout, Zahlung, Steuern, Bestellungen, Fulfillment, Service und Analyse testen.
Die Umstellung proben: Letzte Synchronisierung, Weiterleitungen, DNS, Go-live-Kriterien und Rollback-Befugnis bestätigen.
Stabilisieren: Daten abgleichen und Commerce-, Such- und Servicesignale überwachen, bevor optimiert wird.
Was kostet eine Migration von Shopware zu Shopify Plus?
Die Kosten einer Migration von Shopware zu Shopify Plus setzen sich aus Discovery, Datenumwandlung, Storefront-Entwicklung, Ersatz von Regeln und Plugins, Integrationen, SEO, Tests, Umstellung und Stabilisierung zusammen. Etablierte Projekte erfordern in der Regel ein fünfstelliges Umsetzungsbudget, während Programme mit mehreren Märkten, B2B oder vielen Integrationen sechsstellig werden können. Ein Umfang nach Arbeitspaketen ist verlässlicher als eine Schätzung pro Produkt.
Das sind richtungsweisende Planungsspannen, kein Angebot von Flatline. Die Zahl der Produkte beeinflusst den Migrationsaufwand, doch eigene Regeln, Content-Komponenten, Kanalstruktur, B2B und Integrationsverträge haben meist größeren Einfluss auf den Gesamtumfang.
Die Plattformgebühren von Shopify Plus sind eine Position im Zielbudget. Shopify Plus beginnt derzeit bei 2.100 € pro Monat für Standard-Setups bei drei Jahren Laufzeit oder 2.250 € pro Monat bei einem Jahr Laufzeit, mit variablen Preisen für komplexere Unternehmen oder höhere Volumen. Bestätigen Sie die aktuellen kaufmännischen Bedingungen vor der Freigabe.
Bauen Sie das Migrationsbudget aus diesen Arbeitspaketen auf:
Discovery und Architektur: Audit des Ist-Zustands, Anforderungen, Verantwortung im Zielzustand, Migrationsspezifikation, Risikoregister und Umsetzungsplan.
Storefront und Konfiguration: Design, Theme- oder Headless-Umsetzung, Markets, Checkout, Suche, Navigation und Merchandising.
Daten: Extraktion, Bereinigung, Umwandlung, Testladungen, Abgleich und letzte Synchronisierung.
Regeln und Funktionen: Ersatz von Aktionen, Preisen, Versand, Zahlung, Automatisierung, Inhalten und individuellen Funktionen.
Integrationen: ERP, PIM, WMS, OMS, CRM, POS, Steuern, Zahlungen, Marketing und Analyse.
Absicherung des Go-lives: SEO, Barrierefreiheit, Performance, QA, Abnahmetests, Generalproben der Umstellung und Monitoring.
Operative Veränderung: Vorbereitung von Inhalten, Schulung, Kundenkommunikation, Kosten für parallel laufende Plattformen und Support nach dem Go-live.
Vergleichen Sie die einmalige Investition mit mindestens drei Jahren aktueller und künftiger Betriebskosten. Berücksichtigen Sie Shopware-Plan oder -Lizenz, Hosting, Plattform-Upgrades, Entwicklungssupport, Plugins, Shopify-Apps, interne Zeit und die kaufmännischen Kosten eines langsamen Release-Modells. Flatlines TCO-Rahmen für E-Commerce kann diese umfassendere Rechnung unterstützen.
Wie schützen Sie SEO und Betrieb während der Umstellung?
SEO und Betrieb zu schützen, erfordert einen einzigen Umstellungsplan für URLs, Inhalte, Daten, Kundenzugang, Bestellungen, Bestand, Integrationen und Analyse. Crawlen Sie die Shopware-Umgebung, bevor Sie die Architektur ändern, proben Sie die letzte Synchronisierung und kritische Transaktionen, validieren Sie Weiterleitungen in großem Umfang, legen Sie die Befugnis für Go-live und Rollback fest und überwachen Sie Such- und Betriebssignale direkt nach dem Wechsel des Traffics.
Shopware kann SEO-URLs je Verkaufskanal, Domain und Sprache erzeugen. Derselbe Inhalt kann daher mehrere regionale Pfade, eigene Routenmuster oder historische Aliasse haben. Bauen Sie ein URL-Inventar aus Crawls, Sitemaps, Analyse, Google Search Console und Backlink-Daten auf, statt sich allein auf einen Datenbankexport zu verlassen.
Geben Sie jeder wertvollen indexierbaren URL eine Zielentscheidung:
Eine gleichwertige Seite und Suchintention erhalten
In ein stärkeres Ziel zusammenführen
Auf den nächstliegenden relevanten Ersatz weiterleiten
Nur abschalten, wenn es kein nützliches Ziel gibt
Shopify unterstützt den Massenimport von URL-Weiterleitungen. Das Migrationsteam muss trotzdem Ketten und Schleifen vermeiden, die Absicht je Locale erhalten, interne Links aktualisieren und Statuscodes validieren. Vergleichen Sie außerdem Canonicals, hreflang, Metadaten, strukturierte Daten, Paginierung, facettierte Navigation, Sitemaps und Robots-Anweisungen zwischen den Plattformen.
Das operative Runbook sollte umfassen:
Freeze-Zeiträume für Inhalte und Konfiguration
Letzte und Delta-Synchronisierung von Produkten, Kunden und Bestellungen
Maßgebliches System für Preise und Bestand während der Umstellung
Zugang zu Kundenkonten und Kommunikation
Tests von Zahlung, Steuern, Versand und Aktionen
Nachrichten an ERP, PIM, Fulfillment und Service
Einwilligung, Analyse und Marketing-Events
Ausrollen der Weiterleitungen, DNS- und Domain-Änderungen
Go-live-Kriterien, Eskalationswege und Rollback-Befugnis
Abgleich und Monitoring während der Stabilisierung
Kundenpasswörter erfordern einen bewussten Übergang. Shopify erklärt, dass sich verschlüsselte Passwörter von einer anderen Plattform nicht über eine Kunden-CSV importieren lassen, daher muss das Team Kontoeinladungen, passwortlose Kundenkonten oder einen anderen freigegebenen Identitätsansatz planen. Der Kundenservice sollte den Weg kennen, bevor Kunden ihm begegnen.
Eine Website, die eine Seite erfolgreich ausliefert, ist noch kein Beleg für Geschäftskontinuität. Bestellungen, Bestandsupdates, Kunden-Events oder regionale Weiterleitungen können hinter einem funktionierenden Storefront scheitern. Die Freigabe des Go-lives sollte von Belegen aus vollständigen Kunden- und Betriebsabläufen abhängen.
Wenn Sie Shopware 5 betreiben und ohnehin upgraden müssen, sollten Sie zuerst zwischen Plattformwechsel, Neuaufbau und Bleiben entscheiden, denn auch ein Umstieg auf Shopware 6 ist ein Neuaufbau. Liegt Shopify Plus vorn, bildet unsere Shopify-Migration Rule-Builder-Logik, Verkaufskanäle und Go-live aus diesem Leitfaden ab.
Häufig gestellte Fragen
Unterscheidet sich die Migration von Shopware 5 von der Migration von Shopware 6?
Ja. Shopware 5 hat das Ende seines Lebenszyklus erreicht und nutzt eine andere technische Grundlage, daher umfasst das Projekt oft eine Bewertung von Altlasten und Supportrisiken. Der Umfang bei Shopware 6 hängt von Edition, Deployment-Modell, Verkaufskanälen, Regeln, Plugins, Einkaufswelten, B2B-Funktionen und Integrationen ab. Beide erfordern einen Plattformwechsel statt einer direkten Code-Übertragung.
Lassen sich Passwörter von Shopware-Kunden zu Shopify migrieren?
Kundendatensätze lassen sich übertragen, verschlüsselte Passwörter aber in der Regel nicht in Shopify importieren. Planen Sie einen Weg zur Kontoaktivierung oder zur Anmeldung ohne Passwort, prüfen Sie gegebenenfalls externe Identitätsanforderungen und bereiten Sie Skripte für den Kundenservice vor. Testen Sie doppelte Profile, gespeicherte Adressen, Einwilligungen und Kommunikation vor dem Go-live.
Lässt sich Logik aus dem Shopware Rule Builder in Shopify kopieren?
Nicht direkt. Exportieren oder dokumentieren Sie für jede Regel Bedingungen, Zuordnungen, Prioritäten und Wirkungen und bilden Sie dann das geschäftliche Ergebnis auf Shopify Markets, Kataloge, Rabatte, Functions, Flow, Versand- oder Zahlungskonfiguration, eine App oder ein externes System ab. Gemeinsam genutzte und widersprüchliche Regeln brauchen ausdrückliche Testfälle.
Lassen sich Shopware-Einkaufswelten zu Shopify migrieren?
Inhalte und Medien lassen sich migrieren, doch Sektionen, Blöcke, Elemente und eigene CMS-Logik aus Shopware brauchen eine neue Umsetzung. Bilden Sie wiederverwendbare Komponenten auf Sections und Blocks in einem Shopify-Theme, Metafields, Metaobjects, ein externes CMS oder eigene Storefront-Komponenten ab, damit Redakteure praktisch weiter veröffentlichen können.
Können Shopware B2B Components zu Shopify Plus umziehen?
Viele Anforderungen lassen sich auf Firmen, Firmenstandorte, Kataloge, Zahlungsbedingungen, Mengenregeln und Staffelpreise in Shopify abbilden. Rollen, Freigaben, Budgets, Angebote, eigene Bestellnummern, Vertragspreise und ERP-Prozesse erfordern weiterhin eine Bewertung auf Ablaufebene. Manche Funktionen brauchen womöglich eine App, eine Integration oder ein anderes verantwortliches System.
Sollte jeder Shopware-Verkaufskanal zu einem Shopify-Shop werden?
Nein. Erfassen Sie zuerst für jeden Kanal Zielgruppe, Katalog, Währung, Steuern, Domain, Gesellschaft und Betrieb. Mehrere regionale Storefronts können über Shopify Markets zusammengeführt werden, während getrennte Marken oder rechtliche und operative Modelle zusätzliche Shops rechtfertigen können. Feeds und Anwendungen können zu Kanälen oder Integrationen werden statt zu Shops.
Lassen sich historische Shopware-Bestellungen in Shopify importieren?
Der Umfang historischer Bestellungen sollte der operativen Nutzung folgen. Kundenservice, Retouren, Finance, Treueprogramme und Reporting brauchen womöglich unterschiedlich viel Historie. Manche Bestellungen gehören in Shopify, während ältere Datensätze über ein ERP, CRM, Data Warehouse oder rechtskonformes Archiv zugänglich bleiben können.
Ist Shopify Plus immer der richtige Ersatz für Shopware?
Nein. Shopify Plus passt zu Unternehmen, die einen verwalteten Commerce-Kern wollen und ihre differenzierenden Anforderungen innerhalb des Erweiterungsmodells erfüllen können. Shopware kann stärker bleiben, wenn Kontrolle über das Deployment, tiefe Plattformanpassung oder aktuelle kommerzielle Funktionen genug Wert schaffen, um die operative Verantwortung zu rechtfertigen.
Das Wichtigste in Kürze
Shopware 5 und Shopware 6 erfordern unterschiedliche Bewertungen der Quelle. Version, Plan und Deployment-Modell gehören in die Discovery, bevor der Aufwand geschätzt wird.
Nutzen Sie vier Entscheidungen zum Umfang: übertragen, neu abbilden, neu bauen und abschalten. Wenden Sie sie auf Daten, Regeln, Inhalte, Plugins und Integrationen an.
Produktvarianten, Eigenschaften, Zusatzfelder und Kategorien erfordern ein Mapping nach Verhalten, nicht nur einen Feldabgleich.
Der Rule Builder kann Preise, Aktionen, Versand, Zahlung, Automatisierung und Sichtbarkeit beeinflussen. Bilden Sie Zuordnungen ebenso ab wie Regeldefinitionen.
Shopware-Verkaufskanäle werden nicht automatisch zu Shopify-Shops. Gestalten Sie Markets und Shopstruktur rund um Zielgruppe, Transaktionen und Governance.
Einkaufswelten und Storefront-Code brauchen eine neue Umsetzung, während wertvolle Inhalte und redaktionelle Anforderungen erhalten bleiben können.
B2B sollte als vollständige Einkaufs- und Backoffice-Abläufe bewertet werden, nicht als Funktions-Checkliste.
Ein Planungshorizont von 12 bis 28 Wochen passt zu vielen etablierten Projekten; komplexe Programme können länger dauern.
Kosten werden belastbar, wenn Daten, Storefront, Regeln, Integrationen, SEO und organisatorische Veränderung getrennt abgegrenzt werden.
SEO und operative Kontinuität gehören in denselben Umstellungsplan, weil der Storefront live wirken kann, während Such- oder Backoffice-Abläufe gestört sind.
Die Entscheidung, Shopware zu verlassen, wird erst dann nützlich, wenn das Unternehmen benennen kann, was die neue Architektur vereinfacht. Eine strukturierte Migration erhält die kaufmännischen und operativen Funktionen, die noch zählen, gibt jeder eine klare Verantwortung und lässt nicht mehr unterstützte oder unnötige Komplexität zurück.
Sie sind unsicher, wie sich Ihre Shopware-Regeln, Plugins, Verkaufskanäle und Integrationen auf Shopify Plus abbilden lassen? Flatline ist Shopify Platinum Partner mit praktischer Erfahrung in E-Commerce-Architektur, individueller Entwicklung, ERP-Integrationen und SEO. Nehmen Sie Kontakt auf, dann gehen wir den Umfang der Migration gemeinsam mit Ihnen durch.
Verwandte Artikel
