Doppelte SKUs und nahezu doppelte Produkte finden und auflösen
Exportieren Sie Ihre vollständige Produktliste und prüfen Sie zunächst auf exakte SKU-Duplikate - meist ein Erfassungs- oder Importfehler und einfach zu bereinigen, sobald gefunden. Suchen Sie danach nach Beinahe-Duplikaten: dasselbe Produkt, erneut unter einer anderen SKU angelegt, oft Ergebnis eines erneut importierten Lieferanten-Feeds, der nicht mit bestehenden Datensätzen abgeglichen wurde, oder eines Produkts, das nach einer Systemänderung manuell neu angelegt statt bearbeitet wurde.
Entscheiden Sie für jedes Duplikat-Paar, welcher Datensatz der "echte" ist - meist derjenige mit vollständigeren Daten, mehr Bestellhistorie oder besseren SEO-Signalen wie Backlinks oder Bewertungen - und führen Sie den anderen zusammen oder leiten Sie ihn dorthin um, statt beide zu migrieren und es später auf der neuen Plattform zu klären.
Verwaiste Bilder und Medien aufspüren
Verwaiste Medien - Bilder und Dateien in Ihrer Mediathek, auf die kein Produkt, keine Kategorie und keine Inhaltsseite mehr verweist - sammeln sich über Jahre von Produktaktualisierungen, saisonalen Kampagnen und Plattformänderungen ganz natürlich an. Sie bringen auf der neuen Plattform keinen Mehrwert und erhöhen nur Migrationszeit und Speicherbedarf, daher lohnt es sich, sie zu identifizieren und auszuschließen.
Achten Sie auch auf den umgekehrten Fall: Bilder, die referenziert, aber defekt sind (fehlende Datei, tote externe URL), sollten Sie jetzt erfassen, da ein defektes Bild auf einer Produktseite ein kleines, aber echtes Vertrauensproblem ist, das sich gegen Ihre aktuellen, vertrauten Daten deutlich leichter beheben lässt als nach dem Umzug.
Kategorien und Attribute vereinheitlichen
Jahre ad hoc vorgenommener Ergänzungen führen tendenziell zu uneinheitlichen Kategorien und Attributen: dasselbe Konzept produktübergreifend unterschiedlich geschrieben oder groß-/kleingeschrieben, Kategorien, die sich überschneiden oder duplizieren, Attribute, die in einer Produktlinie einen Zweck erfüllen und in einer anderen einen völlig anderen. Diese Uneinheitlichkeit verursacht auf der alten Plattform meist keine sichtbaren Probleme, da Mitarbeiter gelernt haben, damit umzugehen - sie wird aber zu einem echten Risiko, sobald sie mechanisch auf das Datenmodell einer neuen Plattform gemappt wird.
Bauen Sie vor der Migration eine saubere, abgestimmte Taxonomie auf (oder bestätigen Sie eine bestehende) - einen definierten Kategoriebaum und eine definierte Attributliste mit konsistenter Benennung - und gleichen Sie Ihre tatsächlichen Daten damit ab. Das ist auch der richtige Zeitpunkt zu fragen, welche Attribute für Kunden oder interne Abläufe noch relevant sind und welche nur existieren, weil sie nie entfernt wurden.
Konflikte in der Variantenstruktur bereinigen
Variantenstrukturen (Größe, Farbe, Material und wie sie sich zu konkret verkäuflichen SKUs kombinieren) werden plattformübergreifend unterschiedlich gehandhabt, und uneinheitliche Quelldaten verschärfen das. Suchen Sie nach Produkten, bei denen Variantenoptionen keinem einheitlichen Muster folgen - manche Größenvarianten heißen "S/M/L", andere für dieselbe Produktlinie "Klein/Mittel/Groß", oder Produkte, bei denen eine Variantenkombination im System existiert, aber ohne gültigen Preis oder Lagerbestand dahinter.
Legen Sie Ihr Ziel-Variantenmodell vor der Migration fest, nicht währenddessen. Zu wissen, ob die neue Plattform Variantenkombinationen genauso handhabt wie die alte - und wo nicht -, entscheidet, ob sich Ihre bestehenden Variantendaten direkt mappen lassen oder erst umstrukturiert werden müssen.
Entscheiden, was tatsächlich mitziehen muss
Nicht alles in Ihrem aktuellen Katalog verdient einen Platz auf der neuen Plattform. Eingestellte Produkte ohne verbleibenden Lagerbestand, Test- oder Platzhaltereinträge und Altfelder, deren ursprünglicher Zweck niemand mehr erklären kann, sind allesamt Kandidaten, um zurückgelassen zu werden - mit einer dokumentierten Entscheidung, nicht einem stillen Wegfall. Bewusst weniger zu migrieren, ist oft besser, als alles zu migrieren und es später auf einem unvertrauten neuen System zu klären.
Bei allem, das Sie nicht migrieren, aber noch eine indexierte URL hat, stellen Sie sicher, dass es in Ihrem Weiterleitungsplan berücksichtigt ist (siehe den Leitfaden zum Weiterleitungs-Mapping), statt versehentlich in einem 404 zu enden.
Häufig gestellte Fragen
Wie viel Zeit sollten wir für die Datenbereinigung vor einer Migration einplanen?
Das hängt stark von der Kataloggröße und dem tatsächlichen Zustand der Daten ab - ein kleiner, gut gepflegter Katalog braucht weit weniger Zeit als einer mit zehntausenden SKUs und Jahren an Lieferanten-Feed-Importen. Erst ein Audit der Daten zeigt den tatsächlichen Umfang; das Audit zu überspringen und zu raten, ist der Grund, warum die Bereinigungszeit unterschätzt wird.
Sollten wir Daten vor oder während des Migrationsprojekts bereinigen?
Davor, oder mindestens als eigene, frühe Phase mit eigenem Prüfschritt - nicht vermischt mit der technischen Datenübertragung. Bereinigungsentscheidungen (was ist ein Duplikat, was kann gefahrlos entfallen, wofür ein mysteriöses individuelles Feld gedacht war) benötigen meist den Input von jemandem, der die Geschichte des Katalogs kennt, und das ist eine andere Art von Arbeit als das technische Mapping und die Übertragung selbst.
Was, wenn wir nicht sicher sind, ob ein Duplikat wirklich eines ist?
Markieren Sie es, statt in die eine oder andere Richtung zu raten. Ein Beinahe-Duplikat mit unterschiedlicher Preisgestaltung, unterschiedlichen Variantenoptionen oder unterschiedlicher Bestellhistorie kann ein eigenständiges, legitimes Produkt sein, das nur ähnlich aussieht. Im Zweifel behalten Sie beide und entscheiden nach Abschluss des Audits, statt auf Verdacht zusammenzuführen.
Kann die Datenbereinigung stattfinden, während der alte Shop noch live ist und Bestellungen entgegennimmt?
Ja, für den größten Teil der Audit- und Planungsarbeit - das Prüfen von Exporten, das Entscheiden über Zusammenführungen und der Aufbau der Ziel-Taxonomie erfordern kein Eingreifen in den Live-Shop. Die tatsächliche Umsetzung der Änderungen (Datensätze zusammenführen, verwaiste Medien löschen) ist meist sicherer an einer Kopie oder einem Export durchzuführen, um dann die bereinigten Daten in die Migration einzubringen, statt den Live-Katalog mitten im Audit zu bearbeiten.