1. Beginnen Sie mit Bestandsaufnahme und Audit, nicht mit einem Tool-Vergleich
Bevor Sie Zielplattformen vergleichen, prüfen Sie, was Sie auf der aktuellen tatsächlich haben: wie viele Produkte und Varianten, wie viele Kundenkonten und wie viel Bestellhistorie, welche individuellen Felder aktiv genutzt werden und welche verwaiste Altlasten sind, von welchen Apps oder Integrationen der Storefront abhängt, und welche URLs aktuell nennenswerten Traffic bekommen. Dieses Audit macht aus "wir migrieren" ein abgegrenztes Projekt mit einer echten Liste dessen, was mitziehen muss.
Seien Sie an dieser Stelle ehrlich zur Datenqualität. Hat Ihr Katalog bekannte Duplikate, verwaiste Kategorien oder uneinheitliche Attribute, halten Sie das jetzt fest - die Bereinigung ist vor dem Umzug günstiger als danach, und das Audit zu überspringen ist der Weg, wie Teams diese Probleme mitten in der Migration statt vorher entdecken.
2. Mappen Sie Ihr Datenmodell, bevor Sie ein einziges Feld mappen
Jede Plattform strukturiert Produkte, Varianten, Kategorien und Kundendaten leicht unterschiedlich. Bevor Sie irgendwelche Daten verschieben, bauen Sie ein explizites Mapping: welches Quellfeld in welches Zielfeld geht, welche Quellkonzepte (ein individuelles Attribut, ein Tag, ein Bundle-Typ) keine direkte Zielentsprechung haben und eine Entscheidung brauchen, und welche Felder sich gefahrlos ganz weglassen lassen, weil nichts mehr davon abhängt.
Dokumentieren Sie dieses Mapping dauerhaft - eine Tabelle oder ein geteiltes Dokument, nicht das Gedächtnis einer Person. Es wird zur Referenz, gegen die während der QA alle prüfen, und es ist das Erste, das Sie brauchen, wenn nach dem Launch etwas nicht stimmt.
3. Planen Sie Weiterleitungen und URL-Struktur frühzeitig
Die URL-Struktur ist einer der häufigsten Punkte, an denen eine Migration still SEO schädigt und Lesezeichen bricht. Erstellen Sie eine vollständige Liste Ihrer aktuellen URLs - Produktseiten, Kategorie- und Sammlungsseiten, Blog- oder Inhaltsseiten sowie individuelle Landingpages - und legen Sie für jede die neue URL fest, bevor Sie irgendetwas starten. Seiten ohne saubere Entsprechung auf der neuen Plattform brauchen eine explizite Entscheidung (meist eine Weiterleitung zur nächstpassenden Kategorie- oder Hub-Seite), keinen stillen 404.
Diese Planung erfolgt deutlich vor dem Umzug, idealerweise parallel zur Datenmapping-Arbeit, da beides zusammenhängt: Wie Sie Kategorien und Produkte mappen, bestimmt oft, wie die neuen URLs aussehen. Den vollständigen Prozess finden Sie im eigenständigen Leitfaden zum Weiterleitungs-Mapping, der unten verlinkt ist.
4. Bauen Sie eine Staging-Umgebung auf und führen Sie echte QA durch
Behandeln Sie einen ersten Import nie als finalen Import. Laden Sie Ihre gemappten Daten auf eine Staging- oder Testinstanz der Zielplattform und nutzen Sie den Shop tatsächlich: Kategorien durchsuchen, Produktseiten ansehen, Variantenauswahl und Preise prüfen, Warenkorb und Checkout testen, und bestätigen, dass Kundenkonten und Bestellhistorie korrekt angezeigt werden. Binden Sie jemanden außerhalb des Migrationsteams ein - ein frischer Blick entdeckt Dinge, die den Personen, die das Mapping gebaut haben, nicht mehr auffallen.
Behandeln Sie diese Phase als iterativ. Es ist normal, beim ersten Durchgang Mapping-Probleme zu finden; das Ziel ist, sie hier auf Staging zu entdecken und zu beheben, wo ein Fehler einen erneuten Import kostet - nicht einen Ausfall im Live-Betrieb oder einen kundenseitigen Fehler.
5. Planen Sie das Umzugsfenster wie einen Einsatz, nicht wie einen Schalterdruck
Legen Sie schriftlich fest, was während des Umzugs passiert: wie neue Bestellungen auf der alten Plattform behandelt werden, falls die Migration Zeit braucht (ein vorübergehender Bestellstopp, eine Wartungsseite oder Weiterbetrieb bis zu einem definierten finalen Abgleich), wer den finalen Datenabgleich durchführt, wer DNS und SSL auf der neuen Plattform prüft, und wer befugt ist, im Zweifel zurückzurollen oder zu pausieren.
Geben Sie dem Team für den eigentlichen Tag eine gemeinsame Checkliste, nicht nur einen Plan im Kopf einer einzelnen Person. Ein überstürzter oder unklarer Umzug ist der Punkt, an dem sonst gut vorbereitete Migrationen Daten verlieren - etwa eine Handvoll Bestellungen, die in der Lücke zwischen finalem Abgleich und Livegang eingehen -, planen Sie diese Lücke also explizit ein, statt zu hoffen, dass sie nicht ins Gewicht fällt.
6. Beobachten Sie nach dem Launch weiter - die Migration ist mit dem Livegang nicht fertig
In den Tagen und Wochen nach dem Umzug tauchen Probleme auf, die Staging nicht abgefangen hat: ein für Live-Traffic falsch konfiguriertes Zahlungsgateway, eine Steuer- oder Versandregel, die sich bei echten Bestellungen anders verhielt, Weiterleitungen, die für getestete Seiten funktionieren, aber nicht für Randfälle, oder ein Tracking-Pixel, das still aufgehört hat zu feuern. Legen Sie eine bewusste Monitoring-Routine fest, statt anzunehmen, dass Stille Erfolg bedeutet.
Unsere Post-Launch-QA-Checkliste (unten verlinkt) behandelt diese Phase im Detail - Checkout- und Zahlungsprüfung, stichprobenartige Weiterleitungskontrolle, Analytics-Kontinuität und Search-Console-Monitoring -, da sie einen eigenen, dedizierten Prozess verdient, statt eine überstürzte Nachbetrachtung, wenn die Aufmerksamkeit des Teams schon woanders ist.
Häufig gestellte Fragen
Wie lange dauert ein Replatforming-Projekt?
Das hängt stark von der Kataloggröße, der Datenkomplexität und der Anzahl beteiligter individueller Integrationen ab. Ein kleiner, sauberer Katalog zieht meist schneller um als einer mit zehntausenden SKUs, jahrelang angesammelten individuellen Feldern und mehreren verbundenen Apps. Eine realistische Schätzung erhalten Sie nach einem Audit Ihres konkreten Shops, nicht durch Vertrauen auf einen allgemeinen Zeitplan.
Sollten wir alles auf einmal migrieren oder in Phasen?
Beide Ansätze funktionieren je nach Shop. Ein einzelner Umzug ist einfacher zu überblicken und vermeidet den parallelen Betrieb zweier Plattformen, konzentriert das Risiko aber auf ein Zeitfenster. Ein phasenweiser Ansatz (zum Beispiel zuerst Inhalte und Design, dann Katalog, dann Transaktionsdaten) verteilt das Risiko, erfordert aber sorgfältigere Koordination, was in welcher Phase wo "live" ist. Die richtige Wahl hängt von Ihrer Kataloggröße, Ihrer Toleranz für ein Wartungsfenster und der Integrationstiefe Ihrer Systeme ab.
Was ist die häufigste Ursache für Migrationsprobleme?
Das Überspringen oder Überstürzen der Audit- und Mapping-Phasen. Teams, die direkt mit dem Verschieben von Daten beginnen, ohne vorher zu verstehen, was sie tatsächlich haben - doppelte Produkte, undokumentierte individuelle Felder, URLs, an die niemand gedacht hat -, entdecken diese Probleme tendenziell live nach dem Umzug statt im Staging, wo sie günstig zu beheben sind.
Müssen wir den alten Shop während der Migration einfrieren?
Nicht zwangsläufig für das gesamte Projekt, aber Sie brauchen einen klaren Plan für das finale Umzugsfenster - meist einen kurzen Einfrierzeitraum oder einen definierten finalen Abgleichspunkt -, damit keine Bestellungen oder Kundenänderungen zwischen dem letzten Datenabruf und dem Livegang des neuen Shops verloren gehen. Wie lang dieses Fenster sein muss, hängt von Ihrem Bestellvolumen und der Handhabung des finalen Abgleichs ab.