Magento zu Shopify migrieren: Was mit Daten, Funktionen und Rankings passiert

Eine Magento-zu-Shopify-Migration überträgt nicht einfach denselben Shop in eine andere technische Hülle. Magento beziehungsweise Adobe Commerce und Shopify organisieren Produkte, Kategorien, Kunden, Bestellungen, Inhalte und Erweiterungen nach unterschiedlichen Regeln. Selbst wenn beide Systeme am Ende dieselben Artikel verkaufen, gibt es deshalb keine verlässliche Eins-zu-eins-Kopie. Die Aufgabe besteht darin, das bestehende Geschäft vollständig zu verstehen und es anschließend innerhalb der Shopify-Logik neu abzubilden.

Der sichtbare Shop ist dabei nur eine Ebene. Unter der Oberfläche liegen Produktattribute, Kundengruppen, Preisregeln, Gutscheine, Zahlungsabläufe, Versandlogik, Suchfunktionen, Tracking und angebundene Systeme. Manche Funktionen gehören zum Magento-Kern, andere stammen aus Modulen oder eigenem Code. Shopify stellt für einen Teil davon native Funktionen bereit. Für andere Aufgaben braucht es Apps, Shopify Functions, Theme-Komponenten oder eine eigene Integration. Wieder andere Alt-Funktionen sollten bewusst entfallen, weil sie nicht mehr genutzt werden.

Der Wechsel beginnt mit einer fachlichen Übersetzung

Eine belastbare Migration fragt deshalb nicht zuerst, welches Importwerkzeug verfügbar ist. Sie fragt, welche Aufgabe eine Magento-Funktion für Kunden oder Mitarbeitende erfüllt. Erst wenn der Zweck verstanden ist, lässt sich entscheiden, ob Shopify denselben Ablauf nativ trägt, ob er anders gestaltet werden sollte oder ob eine individuelle Erweiterung nötig bleibt. Die neue Lösung muss nicht technisch gleich aussehen. Sie muss dieselbe geschäftliche Aufgabe mindestens ebenso verlässlich erfüllen.

Das gilt besonders für gewachsene Shops. Ein Magento-Modul kann offiziell noch installiert sein, obwohl nur ein kleiner Teil davon verwendet wird. Umgekehrt kann eine scheinbar nebensächliche Anpassung im Checkout für Buchhaltung oder Logistik unverzichtbar sein. Wer ausschließlich installierte Erweiterungen zählt, bewertet beide Fälle falsch. Entscheidend sind reale Abläufe, Daten und Verantwortlichkeiten.

Die Systementscheidung ist bereits gefallen

Dieser Leitfaden setzt voraus, dass Shopify als Zielplattform grundsätzlich gewählt wurde oder ernsthaft vorbereitet wird. Die Frage, ob Magento oder Shopify allgemein besser passt, gehört in den vorhandenen Systemvergleich. Hier geht es um die nächste Stufe: Welche Bestandteile müssen mit, wie werden sie geprüft und wie bleibt der laufende Verkauf während des Wechsels kontrollierbar?

Der wichtigste Perspektivwechsel lautet daher: Nicht Magento wird nach Shopify kopiert. Das Geschäftsmodell wird aus einem gewachsenen Magento-System herausgelöst, bereinigt und in Shopify neu zusammengesetzt. Genau diese Trennung schützt vor einem Projekt, das zwar Daten importiert, aber zentrale Prozesse erst nach dem Start entdeckt.

Zur fachlichen Übersetzung gehört eine klare Entscheidungsstruktur. Produktmanagement kann beurteilen, welche Eigenschaften und Sortimentsregeln gebraucht werden, während Logistik und Buchhaltung andere Folgen derselben Entscheidung sehen. Das Projekt sollte deshalb für jedes offene Thema festhalten, wer den Sachverhalt erklärt, wer eine Lösung entwirft und wer das Ergebnis freigibt. Ohne diese Rollen entscheiden Entwickler zwangsläufig über Geschäftsregeln, die sie nur aus Datenbankfeldern oder alten Tickets kennen. Mit einer sichtbaren Verantwortung lassen sich widersprüchliche Wünsche früh auflösen, bevor sie in Importcode oder Theme-Komponenten festgeschrieben sind.

Ebenso wichtig ist ein gemeinsamer Stichtag für die Bestandsaufnahme. Ein Magento-Shop verändert sich während eines Projekts weiter: neue Attribute entstehen, Module werden aktualisiert und Kampagnen bringen zusätzliche Inhalte. Das Inventar braucht deshalb einen dokumentierten Stand und einen Prozess für spätere Änderungen. Jede neue Anforderung wird darauf geprüft, ob sie noch in die erste Migration gehört oder bewusst nach dem Start folgt. Diese einfache Regel schützt den Cutover davor, durch ständig nachrückende Sonderfälle unkontrollierbar zu werden.

Vor der ersten Testmigration braucht der bestehende Magento-Shop ein Inventar. Dabei sollten nicht nur Datenbanktabellen oder Modulnamen erfasst werden. Ein brauchbares Inventar verbindet technische Bestandteile mit ihrem fachlichen Zweck, ihrer Nutzung und ihrer Verantwortlichkeit. So wird sichtbar, was wirklich migriert werden muss und welche Altlasten nicht in Shopify nachgebaut werden sollten.

Beginne mit den Datenobjekten: Produkte, Varianten, Kategorien, Attribute, Medien, Kunden, Adressen, Bestellungen, Gutscheine, Bewertungen, CMS-Seiten, Blogbeiträge und Weiterleitungen. Ergänze zu jedem Objekt Umfang, Pflichtfelder, Datenqualität, Quelle und Ziel. Ein Feld, das in Magento vorhanden ist, muss nicht automatisch in Shopify landen. Es braucht einen belegbaren Zweck im Verkauf, in der Suche, im Kundenservice oder in einem nachgelagerten System.

Funktionen werden entlang echter Abläufe geprüft

Danach folgen die Geschäftsfunktionen. Gehe einen realen Kauf vom Einstieg bis zur Rückerstattung durch und notiere, welche Regel an welcher Stelle wirkt. Dazu gehören Kundengruppen, individuelle Preise, Staffelungen, Bundle-Logik, Produktkonfiguration, Gutscheine, Zahlarten, Versandmethoden, Steuerregeln, E-Mails, Retouren und Serviceprozesse. Wiederhole dieselbe Prüfung aus Sicht von Einkauf, Lager, Buchhaltung, Marketing und Kundenservice. Auf diese Weise werden Funktionen sichtbar, die im Frontend kaum auffallen, intern aber täglich Arbeit steuern.

Ein eigenes Verzeichnis gilt den Erweiterungen. Notiere nicht nur Hersteller und Version, sondern auch, ob das Modul Daten speichert, den Checkout verändert, Cronjobs ausführt, externe Dienste aufruft oder Dateien erzeugt. Prüfe anschließend anhand realer Nutzung, welche Teile davon noch benötigt werden. Eine Erweiterung mit zwanzig Funktionen kann im Alltag nur für einen einzigen Export zuständig sein. Dann wird nicht das gesamte Modul ersetzt, sondern nur dieser Exportprozess.

Schnittstellen bilden ein eigenes Inventar

ERP, PIM, Warenwirtschaft, Zahlungsanbieter, Versand, Marktplätze, Newsletter, Bewertungen und Analysewerkzeuge dürfen nicht als Randnotiz erscheinen. Für jede Verbindung braucht es Datenrichtung, Auslöser, Häufigkeit, Identifikatoren, Fehlerweg und verantwortliches Team. Besonders wichtig ist die Frage, welches System für Bestand, Preis, Produkttext, Kundendaten und Auftragsstatus führend ist. Ohne diese Datenhoheit entstehen beim späteren Parallelbetrieb widersprüchliche Änderungen.

Ergänze zuletzt URLs und Traffic. Exportiere alle indexierbaren Adressen, ihre Seitentypen, Statuscodes, Canonicals und relevante Leistungsdaten aus Search Console oder Webanalyse. Diese Liste wird später zur Grundlage der Ziel-URL-Matrix. Sie darf nicht erst kurz vor dem Domainwechsel entstehen.

Produktdaten wirken auf den ersten Blick wie der einfachste Teil der Migration. Beide Systeme kennen schließlich Produkte, Varianten, Bilder, Preise und Bestände. Die Schwierigkeit liegt in der Struktur dahinter. Magento arbeitet häufig mit umfangreichen Attributsets, konfigurierbaren Produkten, Kategorien und individuellen Erweiterungsfeldern. Shopify verwendet Produkte und Varianten, Collections, Metafelder und Metaobjekte innerhalb eines anderen, stärker vorgegebenen Rahmens. Ein CSV-Import kann Werte übertragen, aber diese Modellentscheidung nicht übernehmen.

Für jedes Sortiment braucht es deshalb ein Mapping. Ein Magento-Attribut kann in Shopify eine Variantenoption, ein Produkt-Metafeld, ein Metaobjekt, ein Tag oder reine redaktionelle Information werden. Die richtige Wahl hängt davon ab, was mit dem Wert geschieht. Eine sichtbare Produkteigenschaft für Filter und Vergleich braucht eine andere Struktur als eine interne Versandkennzeichnung. Wer alle Attribute pauschal als Tags importiert, schafft schnell ein unkontrolliertes Hilfssystem, das später Suche, Theme und Integrationen erschwert.

Varianten und konfigurierbare Produkte brauchen echte Testfälle

Besonders sorgfältig müssen konfigurierbare Produkte geprüft werden. Erstelle für jede relevante Produktfamilie einen echten Musterfall mit ihren Optionen, abhängigen Werten, Preisen, Bildern, Verfügbarkeiten und Artikelnummern. Prüfe daran, ob Shopifys Variantenmodell ausreicht oder ob ergänzende Logik notwendig ist. Entscheidend ist nicht die größtmögliche theoretische Kombination, sondern das reale Sortiment einschließlich seiner schwierigsten Ausnahmen.

Kategorien werden ebenfalls nicht blind übernommen. Magento-Kategoriestrukturen können technische oder organisatorische Ebenen enthalten, die Kunden nie sehen. Shopify Collections sollten die Navigation, Suche, Kampagnen und interne Pflege sinnvoll unterstützen. Eine Migration ist eine gute Gelegenheit, doppelte Pfade, leere Kategorien und historisch gewachsene Namen zu bereinigen. Dabei muss die spätere URL-Weiterleitung trotzdem jeden relevanten Altpfad berücksichtigen.

Medien und Texte brauchen Zuordnung statt bloßer Übertragung

Produktbilder müssen in richtiger Reihenfolge, Qualität und Zuordnung ankommen. Prüfe Variantenbilder, Alt-Texte, zusätzliche Dokumente und eingebettete Medien gesondert. Beschreibungen enthalten in Magento häufig HTML, Widgets oder Layoutbausteine, die im Shopify-Theme nicht sinnvoll weiterverwendet werden können. Solche Inhalte sollten in ein sauberes Zielmodell überführt werden, statt alten Markup-Code dauerhaft mitzunehmen.

Führe das Mapping zuerst mit einer kleinen, repräsentativen Produktmenge aus. Dazu gehören ein einfaches Produkt, ein komplexer Variantenartikel, ein reduzierter Artikel, ein nicht verfügbarer Artikel und ein Produkt mit allen relevanten Sonderfeldern. Erst wenn diese Fälle fachlich abgenommen sind, lohnt sich der vollständige Import.

Die Abnahme sollte dabei nicht nur in der Shopify-Administration stattfinden. Prüfe dasselbe Produkt in Collection, Suche, Produktseite, Warenkorb, Bestellbestätigung und angebundenem ERP. Ein Materialwert kann im Backend korrekt vorhanden sein und trotzdem im Filter fehlen, im Theme falsch beschriftet oder bei der Übergabe an ein Drittsystem abgeschnitten werden. Erst der vollständige Weg zeigt, ob das neue Datenmodell tatsächlich alle Verbraucher versorgt.

Lege zusätzlich fest, wie spätere Korrekturen einfließen. Wird ein Attribut nach der ersten Testmigration neu zugeordnet, muss die Transformationsregel geändert und der Import reproduzierbar erneut ausgeführt werden. Manuelle Korrekturen direkt im Zielshop verschleiern dagegen, dass derselbe Fehler beim nächsten Lauf wiederkehrt. Die Regel ist das Produkt der Migration; der einzelne erfolgreich reparierte Datensatz ist nur ein kurzfristiger Zustand.

Kundendaten lassen sich grundsätzlich nach Shopify übertragen, doch ein Kundenkonto besteht aus mehr als Name und E-Mail-Adresse. Adressen, Einwilligungen, Tags, Kundengruppen, B2B-Zuordnungen, Steuermerkmale und individuelle Felder müssen jeweils fachlich eingeordnet werden. Gleichzeitig ist zu klären, welche Daten überhaupt noch benötigt und rechtmäßig weiterverarbeitet werden. Eine Migration ist kein Anlass, jeden historischen Datensatz ungeprüft zu vervielfältigen.

Besonders wichtig ist die Kommunikation zu Passwörtern. Passwort-Hashes aus Magento lassen sich nicht wie gewöhnliche Felder exportieren und in Shopify als nutzbare Passwörter einsetzen. Kunden müssen je nach gewähltem Shopify-Kontenmodell ihr Konto aktivieren oder einen neuen Zugang verwenden. Dieser Schritt gehört in den Migrationsplan, in die E-Mail-Kommunikation und in die Vorbereitung des Kundenservice. Ein stiller Wechsel mit der Erwartung, alte Zugangsdaten funktionierten unverändert weiter, erzeugt vermeidbare Supportfälle.

Alte und neue Kontenmodelle unterscheiden

Shopify stellt unterschiedliche Kundenkonto-Modelle bereit. Deshalb muss vor dem Import feststehen, welche Anmeldung und welche Kontofunktionen der neue Shop nutzt. Davon hängen Aktivierungsstrecke, Theme-Verknüpfung, Self-Service und mögliche Erweiterungen ab. Prüfe außerdem, welche Magento-Funktionen Kunden bisher im Konto verwenden: Bestellhistorie, Adressverwaltung, Downloads, Retourenanfragen, Angebotslisten oder besondere Preisansichten. Nicht jede Funktion entsteht allein dadurch, dass ein Kunde importiert wurde.

Kundengruppen verdienen eine eigene Übersetzung. In Magento können sie Preise, Steuern, Inhalte oder Versand beeinflussen. In Shopify werden ähnliche Anforderungen je nach Fall über B2B-Funktionen, Kataloge, Tags, Segmente, Apps oder individuelle Logik gelöst. Eine Kundengruppe ohne dokumentierten Zweck sollte nicht einfach als Tag weiterleben. Ihre Wirkung muss nachvollziehbar neu modelliert und getestet werden.

Einwilligungen und Datenqualität werden getrennt geprüft

Marketing-Einwilligungen dürfen nicht aus einer allgemeinen Kundenexistenz abgeleitet werden. Übertrage nur Zustände, deren Herkunft und Bedeutung belegt sind. Dokumentiere außerdem, wie Dubletten, unvollständige Adressen, abweichende Schreibweisen und veraltete Konten behandelt werden. Eine technische Validierung zählt Datensätze; eine fachliche Validierung prüft, ob ein Kunde mit seinen richtigen Adressen, Berechtigungen und Kommunikationspräferenzen ankommt.

Plane vor dem Start eine verständliche Nachricht: Was ändert sich, wann ist das alte Konto nicht mehr erreichbar und wie funktioniert der erste Zugang im neuen Shop? Stelle dem Service eine kurze Fehlerdiagnose und einen sicheren Weg zur Identitätsprüfung bereit. So wird die unvermeidbare Kontoänderung nicht zu einer überraschenden Störung.

Historische Bestellungen sind für Kundenservice, Buchhaltung, Analysen und Kundenkonten wertvoll. Trotzdem muss nicht jede alte Bestellung vollständig in Shopify nachgebaut werden. Shopify nennt für historische Bestellungen Migrations-Apps sowie Order- und Transaction-APIs als mögliche Wege. Welcher davon passt, hängt davon ab, was nach dem Wechsel mit der Historie geschehen soll. Ein lesbares Archiv hat andere Anforderungen als Daten, auf denen Rückerstattungen oder Automationen weiterlaufen sollen.

Teile den Bestand deshalb nach Nutzung. Offene Bestellungen, laufende Rücksendungen, nicht eingelöste Gutscheine, aktive Abonnements und ungeklärte Zahlungen benötigen eine operative Übergabe. Abgeschlossene Altbestellungen können möglicherweise als Referenz importiert oder in einem gesicherten Altsystem-Archiv zugänglich bleiben. Entscheidend ist, dass Mitarbeitende und Kunden wissen, wo sie welchen Zeitraum finden.

Zahlungsobjekte lassen sich nicht beliebig neu erzeugen

Eine Bestellung ist mit Zahlung, Transaktion, Steuer, Versand und Rückerstattung verknüpft. Diese Beziehungen unterscheiden sich zwischen Plattformen und Zahlungsanbietern. Ein importierter Auftrag ist nicht automatisch eine fortsetzbare Originaltransaktion. Prüfe deshalb für offene Fälle, in welchem System eine Rückerstattung ausgelöst wird, wie Zahlungsreferenzen erhalten bleiben und welche Belege die Buchhaltung benötigt. Solche Regeln gehören in den Cutover-Plan, nicht in einen allgemeinen Datenimport.

Gutscheine und Guthaben sind ähnlich sensibel. Erfasse aktive Codes, Restwerte, Gültigkeiten und Nutzungsbedingungen. Lege fest, ob bestehende Codes übernommen, ersetzt oder vor dem Wechsel abgeschlossen werden. Ein nominell identischer Gutschein ist für den Kunden nur dann derselbe, wenn Wert und Einlösbarkeit korrekt fortbestehen.

Abonnements brauchen einen eigenen Migrationspfad

Wiederkehrende Zahlungen hängen häufig an externen Diensten, gespeicherten Zahlungsvereinbarungen und konkreten App-Modellen. Sie dürfen nicht als normale Bestellungen behandelt werden. Prüfe gemeinsam mit dem bisherigen und künftigen Anbieter, welche Verträge und Zahlungsmandate übertragbar sind, welche Zustimmung erforderlich ist und wie ein paralleler Übergang funktioniert. Wenn eine direkte Übertragung nicht möglich ist, braucht es eine ehrliche Kundenstrecke statt einer stillen Neuanlage.

Validiere Bestellungen nicht nur über Gesamtzahlen. Ziehe Stichproben aus verschiedenen Jahren, Ländern, Zahlarten, Steuersätzen und Statuskombinationen. Vergleiche Positionen, Rabatte, Versand, Steuer, Gesamtbetrag, Kundenzuordnung und Zeitstempel. Erst wenn diese Beziehungen stimmen, ist die Historie fachlich brauchbar.

Die Modulliste eines Magento-Shops ist keine Einkaufsliste für Shopify-Apps. Beide Ökosysteme schneiden Funktionen unterschiedlich zu. Eine Magento-Erweiterung kann mehrere Abläufe verbinden, während Shopify dafür native Einstellungen, eine App und eine kleine Theme-Anpassung kombiniert. Umgekehrt kann eine scheinbar einfache Magento-Sonderlogik in Shopify eine eigene App oder Function erfordern. Der Vergleich muss deshalb bei der fachlichen Wirkung beginnen.

Lege für jede benötigte Funktion vier mögliche Zielwege fest: Shopify-Standard, vorhandene App, gezielte Eigenentwicklung oder bewusster Verzicht. Diese Reihenfolge verhindert, dass der neue Shop sofort wieder dieselbe Komplexität aufbaut. Standardfunktionen sind meist am leichtesten updatefähig. Apps beschleunigen bewährte Aufgaben, bringen aber laufende Abhängigkeiten mit. Eigene Entwicklung lohnt sich, wenn eine geschäftskritische Regel nicht sauber anders abgebildet werden kann.

Der Checkout besitzt andere Erweiterungsgrenzen

Magento erlaubt tiefe Eingriffe in den Anwendungskern und Checkout. Shopify schützt zentrale Teile stärker und stellt dafür definierte Erweiterungspunkte bereit. Prüfe jede bestehende Checkout-Anpassung deshalb früh: Welches Problem löst sie, für welche Kunden gilt sie und kann es innerhalb der verfügbaren Checkout-, Functions- oder App-Mechanismen umgesetzt werden? Eine kritische Regel erst am Ende zu entdecken, gefährdet den gesamten Zieltermin.

Dasselbe gilt für Produktkonfiguratoren, Angebotsfunktionen, komplexe Preislogik und B2B-Prozesse. Baue für schwierige Anforderungen einen kleinen technischen Prototyp, bevor das vollständige Theme entsteht. Ein Prototyp beantwortet nicht nur, ob etwas grundsätzlich möglich ist. Er zeigt auch, wie redaktionelle Pflege, Fehlermeldungen, Performance und Betrieb aussehen.

Weniger Apps sind kein Selbstzweck

Ein App-Verzeichnis sollte Verantwortlichkeit schaffen, nicht nur zählen. Für jede App braucht es Zweck, Datenzugriff, Ansprechpartner, Vertragskonto, Testfall und Rückbauweg. Eine einzige geschäftskritische App ohne Monitoring kann riskanter sein als mehrere klar abgegrenzte Erweiterungen. Gleichzeitig sollte keine App installiert werden, nur um einen einmaligen Migrationsschritt zu erleichtern, wenn sie danach unnötig im Shop verbleibt.

Dokumentiere am Ende nicht nur die gewählte Lösung, sondern auch bewusst verworfene Alternativen. Das verhindert, dass dieselbe Diskussion wenige Monate später ohne Kontext erneut beginnt. Vor allem zeigt es, an welchen Stellen der neue Shopify-Shop absichtlich anders arbeitet als Magento.

In vielen Magento-Projekten ist der Shop nicht das führende System. Produkte kommen aus einem PIM oder ERP, Bestände aus der Warenwirtschaft, Versandstatus aus der Logistik und Kundendaten aus CRM oder Service. Die Migration kann deshalb nicht abgeschlossen sein, bevor diese Datenflüsse in Shopify funktionieren. Ein schöner Testshop mit manuellen Beispieldaten beweist noch keinen belastbaren Betrieb.

Für jeden Datenfluss wird zuerst die Hoheit festgelegt. Welches System erzeugt eine Artikelnummer? Wo wird der verfügbare Bestand berechnet? Wer darf Preise ändern? Welches System setzt den Auftragsstatus? Ohne diese Entscheidungen kann eine neue Integration technisch Daten übertragen und trotzdem falsche Zustände erzeugen. Besonders während des Parallelbetriebs muss klar sein, ob Magento, Shopify oder ein Drittsystem Änderungen annimmt.

Identifikatoren müssen über beide Welten stabil bleiben

Magento- und Shopify-IDs sind nicht identisch und dürfen nicht als austauschbar behandelt werden. Nutze stabile fachliche Schlüssel wie SKU oder eine dokumentierte externe ID, sofern sie wirklich eindeutig sind. Pflege eine Zuordnung zwischen Alt- und Neuobjekten, damit Fehler, Nachimporte und spätere Rückfragen nachvollziehbar bleiben. Dasselbe gilt für Kunden, Bestellungen, Varianten und Gutscheine.

Die Integration braucht außerdem einen Fehlerweg. Was passiert, wenn das ERP nicht erreichbar ist, eine Variante fehlt oder ein Preisformat abgelehnt wird? Ein Datensatz darf nicht still verschwinden. Protokollierung, Wiederholungen, Alarmierung und ein manueller Reparaturweg gehören zur Definition der Schnittstelle. Für den Start sollte das Team wissen, welche Ansicht oder Meldung einen Handlungsbedarf zeigt.

Der Delta-Lauf schließt die Lücke

Zwischen vollständiger Testmigration und endgültigem Wechsel entstehen neue Produkte, Kunden und Bestellungen. Deshalb braucht es einen Delta-Prozess, der nur die seit dem Stichtag hinzugekommenen oder geänderten Daten überträgt. Dieser Lauf muss wiederholbar sein, ohne Objekte doppelt anzulegen. Ein vorheriger Probelauf mit denselben Regeln zeigt, ob Zeitstempel, externe IDs und Statusfilter zuverlässig funktionieren.

Teste die vollständige Kette mit realen Geschäftsfällen: Produktänderung im führenden System, Bestellung in Shopify, Übergabe an ERP, Versandmeldung zurück, Kundeninformation und gegebenenfalls Storno oder Retoure. Erst diese Ende-zu-Ende-Prüfung belegt, dass der Shop in seiner Systemlandschaft arbeitsfähig ist.

Berücksichtige dabei auch Reihenfolge und Last. Ein vollständiger Produktimport, tausende Bestandsänderungen und laufende Bestellungen dürfen sich nicht gegenseitig überholen. Die Integrationsarchitektur sollte erkennen, ob ein Ereignis veraltet ist, ob ein Zielsystem Anfragen begrenzt und wie große Datenmengen portioniert werden. Sonst kann ein technisch erfolgreicher älterer Lauf einen neueren Bestand überschreiben. Für den Cutover werden deshalb nicht nur Funktionsfälle, sondern auch erwartete Datenmengen und Wiederanlauf nach einer Unterbrechung getestet.

Schließlich braucht der Parallelbetrieb eine eindeutige Schreibsperre. Wenn Magento und Shopify gleichzeitig Aufträge oder Produktänderungen an dasselbe ERP senden, müssen Nummernkreise und Herkunft unterscheidbar bleiben. Oft ist es sinnvoller, den neuen Shop bis zur Freigabe nur lesend mit bestimmten Produktdaten zu versorgen und operative Rückkanäle erst im festgelegten Umschaltfenster zu aktivieren. Welche Variante passt, hängt von der Systemlandschaft ab; unkontrolliertes gleichzeitiges Schreiben ist jedoch keine neutrale Übergangslösung.

Beim Plattformwechsel ändern sich häufig URL-Strukturen. Shopify weist in der eigenen Migrationsdokumentation ausdrücklich darauf hin, dass alte Einzelseiten wegen anderer Pfade sonst nicht mehr erreichbar sind, und empfiehlt, Weiterleitungen vor dem Domainwechsel einzurichten. Die Aufgabe besteht jedoch nicht darin, jede alte Adresse pauschal auf die Startseite zu schicken. Jede indexierte und extern verlinkte URL braucht das fachlich passendste neue Ziel.

Erstelle eine URL-Matrix aus mehreren Quellen: Magento-Sitemap, Crawling, Search Console, Webanalyse, Backlinkdaten und gegebenenfalls Serverlogs. Ergänze Seitentyp, bisherigen Statuscode, Canonical, Klicks und neues Ziel. So werden auch Adressen sichtbar, die nicht mehr in der Navigation stehen, aber noch Suchtraffic oder externe Links besitzen. Doppelte Parameter- und Filterpfade werden getrennt von echten Inhaltsseiten bewertet.

Kategorien und Content brauchen eine inhaltliche Entsprechung

Eine alte Kategorie sollte auf eine neue Collection führen, wenn Sortiment und Suchabsicht übereinstimmen. Wurde sie zusammengelegt, führt sie auf die passende gemeinsame Collection. Gibt es keinen Ersatz und keinen relevanten Inhalt mehr, kann ein sauberer entfernter Status richtiger sein als eine irreführende Weiterleitung. Dieselbe Prüfung gilt für Ratgeber, Marken-, Hersteller- und Kampagnenseiten.

Produkt-URLs benötigen Regeln für aktive, dauerhaft entfernte und zusammengeführte Artikel. Bei Varianten ist zu prüfen, ob Magento eigene erreichbare Adressen erzeugt hat und wie Shopify die neue Auswahl abbildet. Weiterleitungen werden anschließend automatisiert auf Status, Ziel und mögliche Ketten geprüft. Eine Weiterleitung über mehrere Zwischenstationen erschwert Diagnose und sollte auf ein direktes Ziel verkürzt werden.

Metadaten sind nur ein Teil des Transfers

Title, Description, Überschriften, strukturierte Daten, interne Links und Canonicals werden je Seitentyp geprüft. Übernimm sie nicht blind, wenn sich Inhalt oder Suchabsicht geändert haben. Gleichzeitig sollte ein Relaunch nicht ohne Grund alle Texte, Navigation und Plattform zugleich neu erfinden. Je mehr Variablen gleichzeitig wechseln, desto schwieriger wird die Ursachenanalyse nach dem Start.

Erfasse vor dem Cutover eine SEO-Baseline mit indexierten Seiten, wichtigen Suchanfragen, Klicks, Rankings und organischen Einstiegsseiten. Nach dem Wechsel werden Weiterleitungen, Canonicals, Sitemap, robots-Regeln und tatsächliche Erreichbarkeit kontrolliert. Schwankungen lassen sich nicht garantiefrei ausschließen, aber technische Verluste und unbemerkte 404-Seiten sehr wohl systematisch verhindern.

Eine Testmigration ist nur dann aussagekräftig, wenn sie denselben Ablauf wie der spätere Wechsel verwendet. Einzelne CSV-Dateien manuell zu korrigieren und anschließend einen völlig anderen Produktionslauf zu starten, schafft keine Sicherheit. Extraktion, Transformation, Import und Validierung sollten reproduzierbar sein. Fehler werden in den Regeln behoben und der Lauf wird erneut ausgeführt, statt nur einzelne Datensätze im Ziel zu reparieren.

Beginne mit einer kleinen Stichprobe, gehe danach auf den vollständigen Bestand und führe schließlich einen zweiten Lauf gegen denselben Zielstand aus. Dieser Wiederholungstest zeigt, ob der Prozess idempotent arbeitet oder Produkte, Kunden und Bestellungen dupliziert. Dokumentiere Laufzeit, Fehlermengen und manuelle Schritte. Nur so lässt sich der tatsächliche Zeitbedarf am Cutover-Tag einschätzen.

Abnahme bedeutet mehr als Datensatzanzahl

Automatisierte Prüfungen vergleichen Mengen, Pflichtfelder, Summen, externe IDs und Beziehungen. Fachliche Abnahmen prüfen konkrete Produkte, Kundenkonten, Bestellungen, Preise, Steuern, Suchergebnisse und interne Abläufe. Verwende dafür fest definierte Testfälle und erwartete Ergebnisse. Ein zufälliger Rundgang im Shop findet vor allem sichtbare Fehler, aber selten stille Abweichungen in Daten oder Schnittstellen.

Der Cutover-Plan legt fest, wann Inhalte und Daten eingefroren werden, welcher Delta-Lauf folgt, wann Zahlungen und Integrationen umgeschaltet werden und wer den Start freigibt. Für jeden Schritt braucht es einen Verantwortlichen, einen Nachweis und ein Stop-Kriterium. DNS oder Domain werden erst umgestellt, wenn Daten, Checkout, E-Mails, Weiterleitungen und Kernintegrationen grün sind.

Ein Rückweg wird vor dem Start definiert

Rollback bedeutet nicht zwangsläufig, die gesamte Migration rückgängig zu machen. Es kann heißen, die Domain vorübergehend auf Magento zu belassen, den neuen Checkout nicht freizugeben oder einen Datenfluss anzuhalten. Entscheidend ist, bis zu welchem Punkt ein Rückweg möglich ist und wie Bestellungen behandelt werden, die während eines Umschaltfensters entstehen. Diese Entscheidung darf nicht erst unter Zeitdruck fallen.

Nach dem Start folgt eine überwachte Phase. Prüfe echte Bestellungen, Zahlungen, Steuer, Versand, E-Mails, ERP-Übergabe, Retouren, Weiterleitungen und Fehlerprotokolle. Halte ein Team bereit, das Befunde priorisiert und dokumentiert, statt unkoordiniert direkt im Produktivsystem zu ändern.

Definiere für diese Phase außerdem, wann ein Befund nur beobachtet und wann sofort eingegriffen wird. Eine einzelne ungewöhnliche Suchanfrage besitzt eine andere Dringlichkeit als fehlende Bestellungen im ERP oder eine falsch berechnete Steuer. Ein gemeinsames Lageprotokoll sammelt Zeitpunkt, Auswirkung, Ursache, Maßnahme und Ergebnis. Dadurch arbeiten Entwicklung, Fachteam und Support mit demselben Stand. Nach der stabilen Anlaufphase wird aus diesem Protokoll die Betriebsdokumentation: wiederkehrende Kontrollen, bekannte Besonderheiten und Zuständigkeiten bleiben erhalten, statt mit dem Projektteam zu verschwinden.

Ein belastbares Angebot für eine Magento-zu-Shopify-Migration kann erst entstehen, wenn Bestand und Zielbild ausreichend klar sind. Die Anfrage sollte deshalb nicht nur Shop-URL, Produktanzahl und gewünschten Termin enthalten. Sie beschreibt die wichtigsten Produktmodelle, Kundengruppen, offenen Bestellungen, Erweiterungen, Integrationen, Märkte und internen Verantwortlichen. Unbekannte Bereiche werden als offene Prüfung benannt, nicht mit einer pauschalen Annahme verdeckt.

Fordere eine Vorgehensweise, die Analyse, Zielmodell, Prototyp, Testmigration, Abnahme, Cutover und Nachbetreuung voneinander trennt. Damit wird sichtbar, welche Entscheidungen vor der Umsetzung fallen und an welchen Stellen du Ergebnisse prüfen kannst. Ein Festversprechen ohne Inventar ist weniger belastbar als ein Angebot, das Unsicherheiten offenlegt und sie in einer frühen Phase gezielt auflöst.

Ergebnisse und Verantwortung gehören ins Angebot

Kläre, wer Mappingregeln dokumentiert, Testdaten bereitstellt, fachlich abnimmt und Fehler priorisiert. Lege fest, wem Shopify-Organisation, Domain, Quellcode, App-Konten und technische Dokumentation gehören. Produktivzugänge sollten auf Unternehmensaccounts liegen; externe Partner erhalten benötigte Rollen, aber nicht die alleinige Kontrolle über geschäftskritische Konten.

Das Angebot sollte außerdem benennen, welche Daten und Funktionen ausdrücklich nicht enthalten sind. Historische Bestellungen, Abonnements, Bewertungen, Gutscheine oder besondere Magento-Module dürfen nicht stillschweigend vorausgesetzt werden. Dasselbe gilt für Content-Überarbeitung, Übersetzungen und SEO-Mapping. Klare Leistungsgrenzen machen Angebote vergleichbar und schützen beide Seiten vor überraschenden Nachträgen.

Der erste sinnvolle Schritt ist eine Bestandsaufnahme

Wenn noch kein vollständiges Inventar existiert, ist eine vorgeschaltete Analyse kein Umweg. Sie liefert das fachliche Mapping, schwierige Testfälle und eine realistische Umsetzungsarchitektur. Auf dieser Grundlage kann die eigentliche Migration präziser beauftragt werden. Das Ergebnis sollte übergabefähig sein, selbst wenn anschließend ein anderes Team umsetzt.

Wenn du den Wechsel nicht allein strukturieren möchtest, kann ein Team deinen Magento-Bestand analysieren, das Shopify-Zielmodell entwickeln und die Migration bis zum kontrollierten Go-live umsetzen. Entscheidend bleibt, dass Annahmen, Datenregeln und Abnahmen für dein Unternehmen nachvollziehbar dokumentiert sind.

Der richtige nächste Schritt ist daher kein vorschneller Vollimport. Wähle zwei oder drei schwierige Produkte, einen realen Kundenfall, eine Bestellung und die wichtigste Schnittstelle. Wenn diese Fälle im Zielmodell schlüssig gelöst sind, besitzt das Projekt eine belastbare Grundlage für Umfang und Angebot.

Halte die Ergebnisse dieses Durchstichs in einer kurzen Entscheidungsakte fest. Sie verbindet Ausgangsdaten, gewählte Zielstruktur, offene Grenze, Testnachweis und zuständige Person. So kann jedes spätere Arbeitspaket auf derselben geprüften Grundlage aufbauen, ohne die entscheidenden Annahmen erneut zu erraten.