Shopware zu Shopify Migration: Was beim Wechsel mit Produkten, Kundendaten und SEO passiert

Bei einer Shopware zu Shopify Migration wechseln nicht nur Produkte und Kundendaten den Speicherort. Shopware und Shopify ordnen Katalog, Varianten, Preise, Inhalte, Kundenkonten und Erweiterungen unterschiedlich. Deshalb besteht eine belastbare Migration aus drei Aufgaben: den Shopware-Bestand vollständig erfassen, jedes relevante Element in ein Shopify-Zielmodell übersetzen und den laufenden Verkauf kontrolliert auf das neue System umschalten.

Ein bloßer CSV-Export deckt davon nur einen Ausschnitt ab. Shopify unterstützt den Import bestimmter Daten per CSV, nennt für Migrationen aber ebenso Apps und eigene API-Lösungen. Historische Bestellungen werden nach offizieller Shopify-Dokumentation nicht über den normalen Admin-CSV-Import übernommen, sondern über eine Migrations-App oder Schnittstellen. Schon daran zeigt sich: Die passende Methode wird pro Datenart entschieden.

Die Entscheidung für Shopify ist bereits gefallen

Dieser Leitfaden vergleicht nicht, ob Shopware oder Shopify grundsätzlich besser ist. Er setzt voraus, dass das Zielsystem feststeht, und beantwortet die anschließende operative Frage: Wie wird ein produktiver Shop übertragen, ohne Produkte, Kundenbeziehungen, Integrationen oder organische Einstiegsseiten stillschweigend zu verlieren?

Damit bleibt das Projekt prüfbar. Anforderungen werden nicht als allgemeine Wunschliste formuliert, sondern auf den vorhandenen Shopware-Bestand bezogen. Jede aktive Funktion erhält ein Ziel: nativ in Shopify, über eine App, über eine eigene Integration, bewusst verändert oder begründet eingestellt.

Der sichtbare Shop ist nur eine Schicht

Produktseiten, Navigation und Checkout sind für Besucher sichtbar. Dahinter arbeiten jedoch weitere Systeme: Warenwirtschaft, PIM, Zahlungsanbieter, Versand, Suche, Marketing-Feeds, Tracking, E-Mail-Automationen und gegebenenfalls B2B-Regeln. Eine Funktion kann im neuen Theme gut aussehen und trotzdem falsche Bestände, unvollständige Preise oder doppelte Aufträge erzeugen, wenn diese Verbindungen fehlen.

Die Migration beginnt deshalb mit Geschäftsabläufen und Datenflüssen. Welche Anwendung besitzt den führenden Bestand? Wo entstehen Produkttexte? Welches System vergibt Auftragsnummern? Welche Rückmeldung erwartet die Logistik? Diese Fragen entscheiden, was Shopify speichern soll und welche Daten nur durch den Shop hindurchlaufen.

Alt- und Neushop laufen zeitweise parallel

Während der neue Shop aufgebaut und getestet wird, nimmt Shopware meist weiterhin Bestellungen an. Produktdaten, Kunden und Bestände verändern sich also nach dem ersten Export. Ein einmaliger Import kann am späteren Go-live nicht mehr aktuell sein. Deshalb braucht das Projekt einen wiederholbaren Migrationslauf und einen Delta-Sync für alle Änderungen seit dem letzten Stichtag.

Der eigentliche Cutover ist dann kein großer erstmaliger Import. Er ist ein kontrollierter letzter Abgleich auf Grundlage bereits erprobter Abläufe. Das reduziert die Zahl unbekannter Schritte genau in dem Moment, in dem der Verkauf nicht unterbrochen werden soll.

Das Ergebnis wird fachlich und technisch abgenommen

Datensätze werden nicht nur gezählt. Produkte müssen richtige Varianten, Medien, Preise und Bestände tragen. Kundenprofile müssen den passenden Adressen und Einwilligungsständen zugeordnet sein. Alte URLs müssen zu inhaltlich passenden neuen Zielen führen. Testbestellungen müssen durch Zahlung, Versand und Rückmeldung an verbundene Systeme laufen.

Erst diese Abnahme zeigt, ob der neue Shop dieselben geschäftlichen Aufgaben erfüllt. Ein fehlerfreier Importbericht allein beweist das nicht.

Der Shopware-Admin zeigt nicht automatisch, welche Funktionen für den täglichen Betrieb unverzichtbar sind. Ein Teil steckt in Erweiterungen, Regeln, individuellen Feldern, Verkaufskanälen oder externen Diensten. Andere Abläufe haben sich im Team etabliert, ohne dokumentiert zu sein. Bevor Daten zugeordnet werden, entsteht deshalb ein Inventar aus Funktionen, Datenquellen und Verantwortlichkeiten.

Die Leitfrage lautet nicht „Welche Plugins sind installiert?“, sondern „Welche geschäftliche Aufgabe wird damit heute erfüllt?“ Eine ungenutzte Erweiterung muss nicht nachgebaut werden. Eine scheinbar kleine Regel für Versand, Preise oder Kundengruppen kann dagegen den korrekten Verkauf bestimmen.

Vom Kundenweg bis zur Nachbearbeitung

Erfasse den Ablauf vom Einstieg in den Shop bis zur abgeschlossenen Bestellung und darüber hinaus. Dazu gehören Suche, Filter, Variantenwahl, Rabattlogik, Zahlarten, Versandberechnung, Kundenkonto, Bestellmails, Retouren und Statusänderungen. Prüfe für jeden Schritt Sonderfälle wie unterschiedliche Länder, Kundengruppen, Mindestmengen oder Produkte mit besonderer Konfiguration.

Anschließend folgt die interne Bearbeitung: Werden Bestellungen automatisch an eine Warenwirtschaft übertragen? Wo entstehen Versandlabels? Wie gelangen Trackingnummern zurück? Welche Daten benötigt der Kundenservice? Ein Wechsel darf den Kauf ermöglichen und gleichzeitig die Auftragsbearbeitung blockieren.

Erweiterungen werden nach Aufgabe gruppiert

Liste aktive Shopware-Erweiterungen und ordne sie einer Funktion zu. Manche Aufgaben deckt Shopify nativ ab, andere benötigen eine App oder eine eigene Anbindung. Bei Funktionen, die eingestellt werden sollen, wird festgehalten, welche Daten zuvor gesichert und welche Nutzerwege angepasst werden müssen.

Diese Gruppierung vermeidet einen verbreiteten Fehler: Für jedes alte Plugin wird vorschnell eine App gesucht. Das übernimmt die gewachsene technische Lösung, ohne zu prüfen, ob Shopify dieselbe Aufgabe einfacher oder anders löst. Entscheidend ist die fachliche Wirkung, nicht die Zahl installierter Erweiterungen.

Datenquellen und Feldhoheit werden sichtbar

Für Produktstammdaten, Bestände, Preise, Kunden und Bestellungen wird jeweils festgelegt, welches System führend ist. Shopware kann heute nur die sichtbare Ausgabe einer Information enthalten, während die eigentliche Pflege im ERP oder PIM stattfindet. Dann wird nicht der Shopware-Export zur neuen dauerhaften Quelle, sondern die bestehende Systemverbindung für Shopify neu geplant.

Zu jedem Datenfluss gehören Richtung, Rhythmus und Fehlerweg. Ein Bestand kann aus der Warenwirtschaft zu Shopify laufen, eine Bestellung in die Gegenrichtung und ein Versandstatus anschließend zurück. Ohne diese Richtungen bleibt eine Liste von Schnittstellen zu abstrakt für die Umsetzung.

Inhalte und SEO-Einstiege gehören ins Inventar

Kategorien, Landingpages, Ratgeber, Herstellerseiten, Metadaten und Medien werden separat erfasst. Nicht jeder Inhalt steckt in einem Standard-Export. Shopware-Erlebniswelten oder erweiterungsspezifische Inhaltsblöcke benötigen häufig eine bewusste Übertragung in Shopify-Themeabschnitte, Seiten oder Metaobjekte.

Zusätzlich wird festgehalten, welche URLs organische Einstiege, externe Verweise oder Kampagnenziele tragen. Diese Liste bildet später die Grundlage für Zielseiten und Redirects. Sie wird nicht erst aus der neuen Navigation abgeleitet, denn dort wären entfernte oder zusammengeführte Inhalte bereits unsichtbar.

Ein Datenmapping verbindet nicht nur zwei Spaltennamen. Es beschreibt, welche Bedeutung ein Wert in Shopware hat, wie Shopify dieselbe Information abbildet und welche Umwandlung dazwischen nötig ist. Ohne diese semantische Ebene können Daten technisch importiert werden und fachlich trotzdem falsch sein.

Die Mapping-Matrix wird pro Entität aufgebaut: Produkte, Varianten, Kategorien, Hersteller, Medien, Preise, Bestände, Kunden, Adressen, Bestellungen und Inhalte. Jedes Quellfeld erhält ein Ziel, eine Transformationsregel, einen Pflichtstatus und einen Abnahmetest. Felder ohne sinnvolles Ziel werden nicht stillschweigend verworfen, sondern ausdrücklich entschieden.

Shopware-IDs bleiben als Referenz erhalten

Shopware und Shopify vergeben eigene interne Kennungen. Für wiederholbare Läufe braucht die Migration deshalb eine Zuordnung zwischen Quell-ID und neuer Ziel-ID. Die Shopware-ID kann in einer separaten Mapping-Datei oder einem dafür vorgesehenen Metafeld dokumentiert werden. Sie wird nicht als sichtbare Produktinformation missbraucht.

Diese Referenz ist für Delta-Sync und Fehlerkorrektur entscheidend. Wenn ein Produkt erneut exportiert wird, muss die Pipeline denselben Shopify-Datensatz aktualisieren statt einen zweiten anzulegen. Das gilt ebenso für Kunden, Varianten und historische Bestellungen.

Kategorien werden zu einer Zielstruktur

Shopware-Kategorien und Shopify-Kollektionen folgen nicht zwangsläufig derselben Logik. Die Migration entscheidet, welche Kategorien als Navigation und Landingpage bestehen bleiben, welche zusammengeführt werden und nach welchen Regeln Produkte automatisch oder manuell zugeordnet werden. Die bisherige Baumstruktur wird nicht blind kopiert, wenn das Zielsystem eine andere Pflege vorsieht.

Dabei bleiben SEO-relevante Themen erhalten. Eine umbenannte Kollektion kann fachlich richtig sein, benötigt aber ein eindeutiges URL-Ziel und passende Inhalte. Datenmapping und URL-Mapping werden deshalb gemeinsam geplant.

Individuelle Felder brauchen ein bewusstes Shopify-Modell

Shopware-Custom-Fields können Produktdetails, interne Steuerung oder Erweiterungsdaten enthalten. In Shopify kommen je nach Zweck Metafelder, Metaobjekte, Tags, Variantenfelder oder externe Systeme infrage. Die Wahl richtet sich danach, wer den Wert pflegt, wo er ausgegeben wird und ob Apps oder Schnittstellen darauf zugreifen müssen.

Ein Feld wird nicht allein deshalb zum Tag, weil Tags schnell importierbar sind. Tags eignen sich für bestimmte Gruppierungen, aber nicht als universelle Datenbank für strukturierte Werte. Ein sauberer Typ erleichtert spätere Validierung, Filterung und Pflege.

Transformationen werden reproduzierbar beschrieben

Werte benötigen oft mehr als eine direkte Übernahme. Maßeinheiten werden vereinheitlicht, HTML wird bereinigt, Steuersätze werden einem Zielmodell zugeordnet, Sprachwerte getrennt und Statuswerte übersetzt. Jede Transformation wird als Regel mit einem Beispiel und einer Fehlerbehandlung dokumentiert.

Shopware beschreibt in seiner offiziellen Import-/Export-Dokumentation Profile und Feldzuordnungen als Grundlage des CSV-Austauschs. Für den Plattformwechsel reicht ein einzelnes Profil selten aus, doch das Prinzip bleibt: Quelle, Feldbedeutung und Ziel müssen vor dem Lauf eindeutig verbunden sein.

Der Produktkatalog ist meist der größte sichtbare Datenblock, aber nicht einfach eine Liste einzelner Artikel. Ein Shopware-Hauptprodukt kann Varianten, Eigenschaften, Staffel- oder Regelpreise, Hersteller, Kategorien, Medien, Übersetzungen und individuelle Felder verbinden. Shopify benötigt daraus Produkte mit konsistenten Optionen, Varianten, Medien, Preisen, Beständen und Zuordnungen.

Der sichere Weg beginnt mit einem repräsentativen Produktsatz: ein einfaches Produkt, ein Variantenprodukt, ein Artikel mit mehreren Bildern, ein Produkt mit individuellen Feldern und ein Sonderfall aus dem tatsächlichen Sortiment. An diesen Beispielen wird das Mapping geprüft, bevor der gesamte Katalog verarbeitet wird.

Hauptprodukt und Varianten brauchen stabile Schlüssel

Eine Variante wird nicht nur über ihre sichtbare Bezeichnung identifiziert. SKU, Shopware-ID, Elternbeziehung und Optionswerte müssen zusammenpassen. Fehlt die Elternbeziehung oder ändern sich Optionsnamen zwischen Läufen, kann Shopify neue Varianten anlegen, obwohl eigentlich ein bestehender Datensatz aktualisiert werden sollte.

Lege deshalb fest, welcher Schlüssel Produkte und Varianten dauerhaft verbindet. Sichtbare Titel sind dafür ungeeignet, weil Redaktion und Übersetzung sie ändern können. Produktnummern können passen, sofern sie eindeutig und stabil gepflegt sind. Die separate ID-Zuordnung bleibt trotzdem wichtig, sobald Schnittstellen mit internen Shopify-IDs arbeiten.

Optionswerte werden vor dem Import bereinigt

Variantenwerte wie „Blau“, „blau“ und „blau “ können in Shopware technisch getrennt vorliegen, obwohl sie für Kunden dasselbe bedeuten. Vor dem Import werden Schreibweise, Leerzeichen, Einheiten und Reihenfolge vereinheitlicht. Ebenso wird geprüft, ob Eigenschaften nur beschreibend sind oder eine kaufbare Variante erzeugen.

Eine Eigenschaft wie Material kann ein Filter- oder Inhaltsfeld sein, während Größe eine konkrete Variante bestimmt. Wird beides ohne Modellentscheidung in Produktoptionen gepresst, entsteht ein unnötig komplexer Variantenraum. Das Mapping trennt kaufentscheidende Optionen von ergänzenden Produktmerkmalen.

Medien benötigen erreichbare Quellen und eine feste Zuordnung

Shopify kann Produktbilder beim CSV-Import über öffentlich erreichbare Bild-URLs laden. Die offizielle Dokumentation weist darauf hin, dass diese Quellen während des Imports verfügbar sein müssen. Deshalb bleibt die Shopware-Medienquelle bis zum abgeschlossenen und geprüften Medienimport erreichbar. Bilder werden nicht erst am Umschalttag aus dem alten Shop abgerufen.

Pro Medium werden Produktbezug, Reihenfolge, Alternativtext und gegebenenfalls Variantenbezug übernommen. Videos, Dokumente oder erweiterungsspezifische Medienformate werden getrennt bewertet, weil nicht jede Datei über denselben Produkt-CSV-Weg läuft. Nach dem Import wird nicht nur die Dateizahl verglichen; Stichproben prüfen das richtige Titelbild, die Galerie und Variantenmedien im sichtbaren Shop.

Preise und Bestände folgen ihrer Datenhoheit

Wenn ERP oder PIM führend sind, dient der initiale Import nur zum Aufbau. Danach übernimmt die neue Shopify-Anbindung die laufende Pflege. Werden Preise dagegen ausschließlich in Shopware geführt, muss feststehen, wie Grundpreis, Vergleichspreis, Staffelung, Währung und Kundengruppenlogik im Ziel abgebildet werden.

Bestände werden pro Lager- oder Fulfillment-Modell betrachtet. Eine Gesamtsumme aus Shopware kann falsch sein, wenn Shopify künftig mehrere Standorte führt oder ein Dienstleister einzelne Varianten verwaltet. Vor dem Go-live werden daher nicht nur Mengen, sondern auch ihre Zuordnung und Aktualisierungsrichtung geprüft.

Der Produktimport läuft in überprüfbaren Paketen

Shopify empfiehlt bei umfangreicheren Migrationen ausdrücklich einen Test mit einem kleinen Datenausschnitt. Danach werden Katalogsegmente importiert, protokolliert und gegen die Quelle validiert. Fehlerhafte Datensätze landen in einer nachvollziehbaren Fehlerliste und werden nach Korrektur erneut verarbeitet.

So bleibt der Import wiederholbar. Manuelle Nachpflege direkt in Shopify wird bis zur Übergabe kontrolliert, damit ein erneuter Lauf keine undokumentierten Änderungen überschreibt.

Kundenprofile, Kundenkonten und Bestellhistorie sind drei verschiedene Dinge. Ein Profil enthält Kontakt- und Adressdaten. Ein Konto regelt die Anmeldung und den Zugriff des Kunden. Bestellungen verbinden Kunden, Produkte, Preise, Steuern, Zahlungen, Versand und Status zu historischen Geschäftsvorgängen. Wer diese Bereiche als eine CSV-Aufgabe behandelt, verliert Beziehungen oder erzeugt falsche Erwartungen.

Shopify empfiehlt für die Reihenfolge einer Migration: zuerst Produkte, dann Kunden und anschließend historische Bestellungen. Dadurch können Bestellpositionen und Kundenbezüge auf bereits vorhandene Zieldatensätze zeigen. Diese Reihenfolge wird in Probeimport und Cutover beibehalten.

Kundenprofile werden bereinigt und dedupliziert

Vor dem Import werden E-Mail-Adressen, Telefonnummern, Rechnungs- und Lieferadressen sowie individuelle Felder geprüft. Doppelte Profile können in Shopware durch Gastbestellungen, geänderte E-Mail-Adressen oder getrennte Verkaufskanäle entstanden sein. Shopify ordnet Profile anhand unterstützter Identifikatoren zu; unbereinigte Duplikate führen deshalb zu ausgelassenen oder mehrfach angelegten Datensätzen.

Marketing-Einwilligungen werden nicht aus dem bloßen Vorhandensein einer E-Mail-Adresse abgeleitet. Übernommen wird nur der belegte Zustand aus der Quelle. Welche rechtlichen Aufbewahrungs- und Informationspflichten für das konkrete Unternehmen gelten, wird separat mit Datenschutzverantwortlichen geklärt; die technische Migration ersetzt keine Rechtsberatung.

Passwörter lassen sich nicht wie Stammdaten importieren

Shopify erklärt in der offiziellen Hilfe, dass Kundenpasswörter aus einem anderen Shop nicht per CSV migriert werden können, weil sie außerhalb von Shopify verschlüsselt sind. Bei klassischen Konten benötigen Kunden daher einen Aktivierungs- oder neuen Anmeldeweg. Die aktuelle Shopify-Kontenlösung arbeitet standardmäßig mit einem per E-Mail gesendeten Einmalcode und benötigt kein migriertes Passwort.

Die Entscheidung für das Kontomodell fällt vor der Kundenkommunikation. Login-Links, Kontoanpassungen, Wunschlisten, Retourenfunktionen und Abonnements müssen zum gewählten Modell passen. Eine importierte Kundenzeile beweist noch nicht, dass der Kunde seine erwarteten Funktionen im neuen Konto findet.

Historische Bestellungen kommen nicht über die Kunden-CSV

Die Shopify-Dokumentation trennt den Kundenimport ausdrücklich von Bestellinformationen. Historische Bestellungen werden über eine geeignete Migrations-App oder die Shopify-APIs übertragen. Dabei müssen Produkte, Varianten und Kunden bereits zugeordnet sein oder über ein belastbares Ersatzmodell verbunden werden.

Vorab wird festgelegt, wie weit die Historie zurückreichen muss und wofür sie benötigt wird: Kundenservice, Kontoansicht, Auswertungen, Retouren oder gesetzliche Aufbewahrung. Nicht jeder historische Systemzustand muss als aktive Shopify-Bestellung nachgebaut werden. Manchmal bleibt ein revisionssicheres Archiv zusätzlich erforderlich.

Importierte Bestellungen dürfen keine operativen Prozesse auslösen

Eine historische Bestellung ist bereits erfüllt oder abgeschlossen. Beim Import darf sie nicht versehentlich neue Fulfillment-Aufträge, Lagerbewegungen, Kundenmails oder ERP-Buchungen auslösen. Shopify weist darauf hin, dass Benachrichtigungseinstellungen beim Import historischer Bestellungen berücksichtigt werden müssen.

Deshalb wird der vollständige Weg mit wenigen Testbestellungen geprüft: Status, Zahlungsdarstellung, Fulfillment, Steuern, Rabatte, Kunde und Positionen. Erst wenn die Historie fachlich richtig erscheint und keine unerwünschten Automationen startet, folgt der größere Lauf.

Shopware-Erweiterungen lassen sich nicht nach Shopify kopieren. Selbst wenn für eine Aufgabe eine Shopify-App existiert, übernimmt sie weder automatisch die alte Konfiguration noch deren Datenmodell. Jede Funktion wird deshalb im Ziel neu eingerichtet und mit den Datenquellen verbunden, die sie für den Betrieb benötigt.

Die Funktionsinventur aus Abschnitt 02 liefert dafür den Umfang. Nun wird pro Aufgabe die technische Zielentscheidung umgesetzt und getestet: Shopify-eigene Funktion, App, individuelle Integration oder bewusster Wegfall.

ERP, PIM und Logistik brauchen neue Verträge

Eine Schnittstelle besteht aus mehr als einer URL und Zugangsdaten. Sie überträgt konkrete Felder, Statuswerte und Ereignisse. Beim Plattformwechsel ändern sich IDs, Webhooks, Fehlermeldungen und teilweise die Reihenfolge der Prozesse. Die Shopify-Verbindung wird daher als eigener Datenvertrag beschrieben.

Für jede Richtung werden Auslöser, Nutzlast, Wiederholungsverhalten und Fehlerablage definiert. Eine Bestellung darf bei einem Timeout nicht doppelt im ERP angelegt werden. Ein fehlgeschlagener Bestandsabgleich muss sichtbar werden und erneut laufen können. Diese Eigenschaften werden mit Testdaten geprüft, bevor echte Aufträge fließen.

Rabatte, Regeln und Kundengruppen werden fachlich nachgebaut

Shopware-Regeln können Preise, Versand oder Aktionen abhängig von Kundengruppe, Warenkorb und Verkaufskanal steuern. Shopify bildet solche Aufgaben mit eigenen Funktionen, Apps oder individuellen Erweiterungen ab. Die alte Regel wird nicht wörtlich übersetzt, sondern anhand von Beispielen beschrieben: Eingabe, Bedingung, erwartetes Ergebnis und Ausschlüsse.

So wird erkennbar, ob das Ziel dieselbe Wirkung erreicht. Ein Rabattcode, der im Normalfall funktioniert, reicht als Test nicht aus, wenn kombinierte Rabatte, Mindestwerte oder bestimmte Kundengruppen ausgeschlossen sein sollen.

Zahlung, Versand und Abonnements benötigen End-to-End-Tests

Zahlarten und Versandoptionen werden im Ziel neu konfiguriert. Dabei zählen Länder, Währungen, Steuern, Gewicht, Warenkorbbedingungen und Rückmeldungen des Anbieters. Abonnements oder gespeicherte Zahlungsmittel sind besonders sensibel, weil Verträge und Zahlungsreferenzen nicht wie normale Produktdaten behandelt werden können.

Für solche Funktionen wird früh mit den beteiligten Anbietern geklärt, welche Daten übertragbar sind und welche Kundenaktion nötig wird. Eine Annahme im Migrationsskript ersetzt keine bestätigte Möglichkeit des Zahlungs- oder App-Anbieters.

Tracking und Feeds wechseln mit dem Verkaufssystem

Analytics, Werbeplattformen und Produktfeeds verwenden im neuen Shop andere Ereignisse, Produktkennungen oder Datenquellen. Prüfe, welche IDs in Kampagnen, Merchant-Feeds und Auswertungen verwendet werden. Bleiben SKUs stabil, können sie eine Brücke bilden; interne Shopware-IDs eignen sich nicht automatisch als dauerhafte externe Kennung.

Testbestellungen müssen deshalb nicht nur im Shopify-Admin erscheinen. Sie werden auch in den verbundenen Systemen verfolgt: Auftrag, Zahlung, Versand, Trackingereignis und gegebenenfalls Feed. Erst diese Kette belegt, dass der operative Shopwechsel vollständig vorbereitet ist.

Shopware- und Shopify-URLs folgen unterschiedlichen Strukturen. Produkt-, Kategorie-, Hersteller- und Inhaltsseiten erhalten im Ziel neue Adressen oder können wegen des Shopify-Pfadmodells nicht unverändert bestehen bleiben. Damit bestehende Suchsignale und externe Verweise nicht auf Fehlerseiten enden, wird jede relevante Quell-URL einem fachlich passenden Ziel zugeordnet.

Das URL-Mapping ist keine pauschale Regel wie „alles zur Startseite“. Es übersetzt die bisherige Informationsarchitektur. Ein vorhandenes Produkt führt zum entsprechenden Produkt, eine weiterbestehende Kategorie zur passenden Kollektion und ein zusammengeführter Inhalt zur nächstliegenden Seite mit derselben Suchaufgabe.

Das Inventar kommt aus mehreren Quellen

Ein Shopware-Sitemap-Export zeigt aktuelle indexierbare Seiten, aber nicht zwangsläufig alte URLs mit externen Links, Kampagnenzielen oder weiterhin vorhandenem Traffic. Ergänze deshalb technische Crawls um Search-Console-Daten, Analytics, Backlink-Daten und bekannte Feed- oder Kampagnenziele.

Jede Quell-URL erhält Seitentyp, Status, Ziel-URL und Begründung. So lässt sich prüfen, ob eine Kategorie bewusst zusammengeführt, ein Produkt ersetzt oder ein Inhalt vollständig entfernt wird. Ohne diese Begründung entstehen bei großen Listen schnell unpassende Massenredirects.

Handles und Zielpfade werden früh festgelegt

Shopify verwendet Handles für Produkte, Kollektionen, Seiten und Beiträge. Sie werden vor dem finalen Produkt- und Inhaltsimport festgelegt, weil sie sowohl interne Links als auch Redirectziele bestimmen. Eine spätere spontane Umbenennung vervielfacht die Mapping-Arbeit und kann Redirectketten erzeugen.

Produkt- und Kategoriestruktur werden mit dem Datenmapping abgestimmt. Wenn eine Shopware-Kategorie in zwei Shopify-Kollektionen aufgeteilt wird, braucht jede bisherige URL trotzdem genau ein sinnvolles Hauptziel. Die neue Navigation allein beantwortet diese historische Zuordnung nicht.

Shopify-Redirects werden importiert und getestet

Shopify unterstützt die Verwaltung sowie den Import von URL-Weiterleitungen. Die offizielle Hilfe beschreibt dafür einen CSV-Import im Bereich der Menüs. Bestimmte feste Shopify-Pfade und bereits funktionierende Zielpfade unterliegen Einschränkungen; deshalb wird die Redirectliste gegen das tatsächliche Zielsystem validiert, statt nur hochgeladen.

Nach dem Import werden Stichproben und automatisierte Tests ausgeführt. Sie prüfen Status, Ziel, Ketten und Schleifen. Besonders wichtig sind stark besuchte Produkt- und Kategorieseiten sowie URLs, die aus Merchant-Feeds, Anzeigen oder externen Verweisen kommen.

Metadaten und Inhalte werden nicht aus Redirects abgeleitet

Ein Redirect bringt Nutzer und Crawler zur neuen Adresse, ersetzt aber keine passende Zielseite. Titel, Beschreibung, H1, Kategorietext, Produktinhalt und interne Links werden im Shopify-Modell separat übertragen oder neu zugeordnet. Eine technisch korrekte Weiterleitung auf eine fachlich schwache Zielseite bewahrt die bisherige Suchaufgabe nicht automatisch.

Strukturierte Daten und Canonicals werden aus dem neuen Theme geprüft. Dabei zählt das gerenderte Ergebnis der wichtigsten Seitentypen. Das Projekt eröffnet hier keinen allgemeinen Relaunch-Audit, sondern kontrolliert die konkrete Parität zwischen jeder migrierten Shopware-Seite und ihrer Shopify-Zielfassung.

Interne Links zeigen direkt auf die finalen Ziele

Navigation, Inhalte und Produktverknüpfungen sollten nach der Migration nicht dauerhaft über Redirects laufen. Beim Import werden alte interne URLs auf die neuen Shopify-Ziele umgeschrieben. Dadurch bleibt die neue Architektur verständlich und Suchmaschinen müssen nicht jedem internen Klick über eine historische Umleitung folgen.

Ein abschließender Crawl vergleicht alte und neue URL-Menge: Welche Quellseiten haben ein Ziel, welche Zielseiten sind intern erreichbar und wo verweisen Inhalte noch auf Shopware-Pfade?

Zwischen erstem Export und Go-live verkauft der Shopware-Shop weiter. Neue Kunden registrieren sich, Bestellungen entstehen, Bestände ändern sich und Produktdaten werden gepflegt. Der Delta-Sync übernimmt genau diese Änderungen, ohne den vollständigen Zielbestand unkontrolliert neu aufzubauen.

Voraussetzung ist eine idempotente Pipeline: Derselbe Datensatz kann erneut verarbeitet werden, ohne Duplikate oder widersprüchliche Beziehungen zu erzeugen. Quell-IDs, Änderungszeitpunkte und Ziel-IDs werden dafür dauerhaft protokolliert.

Extract, Transform und Load bleiben getrennt

Der Extract-Schritt liest Shopware-Daten und speichert einen unveränderten Rohstand. Die Transformation übersetzt Felder, Statuswerte und Beziehungen in das vereinbarte Shopify-Modell. Erst der Load-Schritt schreibt Daten in Shopify. Diese Trennung ermöglicht es, eine fehlerhafte Regel zu korrigieren, ohne die Quelle erneut unter anderen Bedingungen auslesen zu müssen.

Jeder Lauf erhält einen Zeitstempel, eine Quellversion und einen Bericht über gelesene, übersetzte, geschriebene und abgewiesene Datensätze. Fehler werden nicht als allgemeine Warnung gesammelt, sondern einer Entität und Ursache zugeordnet.

Änderungen werden anhand stabiler Kriterien erkannt

Ein Änderungszeitpunkt kann helfen, reicht aber nicht immer aus. Erweiterungen oder externe Systeme aktualisieren möglicherweise Daten, ohne dieselben Zeitfelder zu pflegen. Für kritische Entitäten können deshalb zusätzlich Prüfsummen oder ein Vergleich ausgewählter Geschäftsfelder verwendet werden.

Die Delta-Regel legt auch Löschungen fest. Wird ein Produkt in Shopware deaktiviert, bedeutet das nicht zwingend, dass Shopify es löschen soll. Je nach Zielmodell wird es archiviert, aus Verkaufskanälen entfernt oder bewusst weitergeführt. Solche Zustände brauchen eine fachliche Übersetzung.

Bestellungen und Bestände erhalten eine Cutover-Grenze

Für Bestellungen muss eindeutig sein, welches System bis zu welchem Zeitpunkt führend ist. Während des Parallelbetriebs entstehen neue Aufträge nur in Shopware. Nach der Umschaltung nimmt Shopify neue Bestellungen an. Der letzte Delta-Lauf übernimmt die verbliebene Historie, ohne bereits im Ziel entstandene Aufträge zu überschreiben.

Bestände brauchen dieselbe Klarheit. Ist ein ERP führend, wird die endgültige Shopify-Anbindung vor dem Cutover aktiviert und gegen den erwarteten Bestand geprüft. Wird Shopware bisher als Bestandssystem genutzt, muss der letzte Abgleich zeitlich mit Bestellstopp und Umschaltung koordiniert werden.

Ein Rehearsal misst den echten Ablauf

Vor dem Go-live wird der vollständige Migrationslauf in einer Test- oder vorbereiteten Zielumgebung wiederholt. Dabei werden Laufzeit, Abhängigkeiten, Fehlerraten und manuelle Schritte protokolliert. Ein zweiter Lauf zeigt, ob Aktualisierungen korrekt funktionieren oder Duplikate entstehen.

Das Rehearsal endet mit fachlichen Vergleichen: Produkt- und Variantenmengen, Medienzuordnung, Kundenstichproben, Bestellbeziehungen, Redirects und Integrationen. Aus diesem Lauf entsteht das Cutover-Runbook mit Reihenfolge, Verantwortlichen und Stop-Kriterien.

Am Cutover-Tag sollte keine Migrationslogik zum ersten Mal ausgeführt werden. Datenläufe, Redirectimport, Integrationen und Testbestellungen wurden bereits im Rehearsal erprobt. Die Umschaltung wiederholt diese Schritte mit dem letzten aktuellen Stand und kontrolliert danach, ob der Verkauf vollständig über Shopify läuft.

Das Runbook nennt für jeden Schritt verantwortliche Person, erwartetes Ergebnis und Abbruchkriterium. Ein Zeitplan ohne Stop-Regeln reicht nicht: Das Team muss wissen, wann ein Fehler behoben werden kann und wann die Umschaltung zurückgestellt wird.

Die Abnahme umfasst reale Geschäftsfälle

Vor dem Cutover werden repräsentative Produkte, Kunden und Bestellungen geprüft. Dazu gehören einfache und variable Produkte, Rabatte, unterschiedliche Versandziele, Zahlarten, Gast- und Kundenbestellung sowie Rückmeldungen an ERP oder Fulfillment. Inhalte und Redirects erhalten eigene Stichproben.

Die Prüfung erfolgt nicht nur im Admin. Produktansicht, Warenkorb, Checkout, Bestellbestätigung und Kundenkonto werden aus Sicht eines Besuchers durchlaufen. Danach wird kontrolliert, ob Zahlung, Auftrag, Lagerbewegung, E-Mail und Tracking in den verbundenen Systemen angekommen sind.

Freeze und letzter Delta-Lauf werden koordiniert

Für den letzten Abgleich braucht das Projekt eine kurze Phase, in der klar ist, welche Daten noch verändert werden dürfen. Das kann ein Bestellstopp, ein Schreibstopp für ausgewählte Stammdaten oder eine genau definierte Übergangsregel sein. Umfang und Dauer hängen vom Datenmodell und der getesteten Laufzeit ab.

Der letzte Delta-Lauf verarbeitet alle Änderungen seit dem Rehearsal. Anschließend werden Kontrollsummen und definierte Stichproben geprüft. Erst wenn diese Gates grün sind, beginnt die Domainumschaltung.

Die Domain wechselt erst nach dem Smoke-Test

Der Shopify-Shop wird vor der öffentlichen Umschaltung unter einer kontrollierten Vorschau oder Zieladresse getestet. Nach dem Domainwechsel folgen sofort kurze Smoke-Tests: Startseite, wichtige Kategorien und Produkte, Warenkorb, Checkout, Konto, Redirects und zentrale Integrationen.

Der alte Shop bleibt während der Übergangsphase unverändert verfügbar und wird nicht vorschnell gelöscht. So können Daten verglichen und bei einem klar definierten Abbruch zurückgeführt werden. Neue Bestellungen dürfen dabei niemals unbemerkt in zwei Systemen entstehen; die Datenhoheit bleibt eindeutig.

Der erste echte Auftrag wird Ende zu Ende verfolgt

Ein erfolgreicher Checkout im Browser beweist nur den vorderen Teil. Der erste reale Shopify-Auftrag wird bis in Warenwirtschaft, Zahlung, Versand und Kundenkommunikation verfolgt. IDs und Status werden dokumentiert, damit spätere Abweichungen mit einem funktionierenden Referenzfall verglichen werden können.

Dasselbe gilt für Storno, Rückerstattung oder Retouren, sofern diese Prozesse zum unmittelbaren Betriebsumfang gehören. Der Go-live ist erst abgeschlossen, wenn das Team Aufträge nicht nur annehmen, sondern im vorgesehenen Zielprozess bearbeiten kann.

Nach der Umschaltung beginnt eine begrenzte Beobachtungsphase. Ihr Ziel ist nicht, den Shop allgemein neu zu optimieren, sondern Abweichungen aus der Migration schnell ihrer Ursache zuzuordnen. Dafür bleiben Migrationsprotokolle, Mappingtabellen und funktionierende Referenzfälle verfügbar.

Die Kontrollen folgen einem festen Rhythmus und klaren Zuständigkeiten. Kritische Kauf- und Integrationsfehler werden sofort behandelt, Datenabweichungen nach Wirkung priorisiert und redaktionelle Restarbeiten getrennt geführt.

Datenmengen und Beziehungen werden erneut abgeglichen

Vergleiche Produkt-, Varianten-, Kunden- und Bestellmengen mit dem letzten freigegebenen Quellstand. Reine Summen sind nur der Einstieg. Stichproben kontrollieren, ob Varianten am richtigen Produkt hängen, Medien in der vorgesehenen Reihenfolge erscheinen und historische Bestellungen dem passenden Kunden zugeordnet sind.

Fehlerkorrekturen laufen über die dokumentierte Pipeline. Manuelle Änderungen werden nur vorgenommen, wenn klar ist, wie sie bei einem erneuten Lauf erhalten bleiben. So entsteht kein zweiter, unbekannter Datenstand neben dem Mapping.

Redirects und organische Einstiege werden beobachtet

Server- und Plattformberichte zeigen aufgerufene Fehlerseiten, Redirectketten und alte Pfade ohne Ziel. Search Console hilft zu erkennen, welche neuen Shopify-URLs verarbeitet werden und ob wichtige Shopware-Einstiege auf unerwartete Ziele führen. Ein einzelner kurzfristiger Ausschlag wird von wiederkehrenden Mustern getrennt.

Neue 404-Funde werden auf Ursprung und passendes Ziel geprüft. Nicht jede unbekannte URL benötigt einen Redirect; relevante alte Produkt-, Kategorie- und Inhaltsadressen schon. Interne Links werden direkt korrigiert, damit sie nicht dauerhaft über Umleitungen laufen.

Integrationen werden mit echten Vorgängen geprüft

Bestandsabgleiche, Produktupdates, neue Bestellungen, Fulfillment und Rückmeldungen werden über mehrere reale Vorgänge beobachtet. Fehlerwarteschlangen und Webhook-Protokolle gehören zur Prüfung. Ein System, das nur beim ersten Auftrag funktioniert, aber Wiederholungen oder Statusänderungen verliert, ist noch nicht stabil.

Auch Tracking und Feeds werden auf die neuen Kennungen und Ziel-URLs geprüft. Abweichungen werden gegen den vorab dokumentierten Sollzustand bewertet, nicht durch spontane Änderungen an Kampagnen oder Produkten kaschiert.

Shopware bleibt vorübergehend als Referenz erhalten

Der alte Shop wird nach dem Cutover schreibgeschützt oder klar vom produktiven Auftragseingang getrennt und für die vereinbarte Nachlaufzeit zugänglich gehalten. Er dient zum Vergleich historischer Datensätze und als Quelle für Fälle, die im ersten Inventar nicht sichtbar waren. Gleichzeitig darf keine Mitarbeiterin und kein Mitarbeiter versehentlich weiter im alten System pflegen.

Wenn du den Plattformwechsel technisch planen und umsetzen lässt, sollten Datenmapping, Delta-Sync, Redirects und Cutover deshalb als eine zusammenhängende Kette verantwortet werden. Getrennte Einzellieferungen erschweren die Ursachenanalyse genau dann, wenn Quelle und Ziel kurzzeitig parallel bestehen.

Die Übergabe beendet die Migration nachvollziehbar

Zum Abschluss erhält das Betriebsteam eine Übersicht über Datenhoheit, aktive Apps, Integrationen, Fehlerwege, Redirectpflege und offene bewusste Abweichungen. Zugänge und Verantwortlichkeiten werden bestätigt. Der alte Shop wird erst abgeschaltet, wenn Aufbewahrung, Datenexport und verbleibende Abhängigkeiten geklärt sind.

Damit endet die Migration nicht mit einer optisch fertigen Startseite, sondern mit einem Shopify-Shop, dessen Daten und Abläufe im täglichen Betrieb nachvollziehbar betreut werden können.