Der Next-Cart Migrationsprozess sollte mehr leisten, als Datensätze von einem Shop in einen anderen zu übertragen. Er sollte Unsicherheit schrittweise reduzieren. Frühe Annahmen zu Zugriff, Umfang, Mapping und Darstellung auf der Zielplattform müssen zu überprüfbaren Entscheidungen werden. Die Ausführung erzeugt anschließend ein breiteres Ergebnis, und die Validierung entscheidet, ob dieses Ergebnis für das Unternehmen tatsächlich nutzbar ist.
Diese Sichtweise verändert die Steuerung des Prozesses. Eine Verbindung ist nicht nur ein technischer Handshake. Konfiguration ist keine nebensächliche Einrichtung. Demo Migration ist kein abschließender Nachweis. Eine abgeschlossene Full Migration ist keine automatische Go-live-Freigabe. Jede Phase liefert eine andere Art von Nachweis, und die Qualität der finalen Entscheidung hängt davon ab, wie diese Übergaben verstanden werden.
Innerhalb der Next-Cart Migration Services ist der gekaufte Ablauf um Verbindung, Konfiguration und Migration organisiert. Zum vollständigen Projekt gehören außerdem die Vorbereitung vor diesen Phasen, die Validierung danach sowie spätere Migrationsentscheidungen, wenn sich der Quellshop weiter verändert.
Definieren Sie das gewünschte Ergebnis, bevor Daten übertragen werden
Der Prozess beginnt mit einem festen Migrationspfad von einer Quellplattform zu einer Zielplattform. Dieser Pfad bestimmt die Plattformstrukturen, Zugriffsanforderungen und Zielgrenzen, die berücksichtigt werden müssen.
Anschließend sollte das Projekt definieren, was ein nutzbares Ergebnis bedeutet. Reine Datensatzmengen reichen dafür selten aus. Products müssen eventuell kaufbare Varianten behalten. Customers müssen möglicherweise weiterhin anhand ihrer Gruppe erkennbar sein. Orders können historischen Status und Kontext der Positionen benötigen. Content muss gegebenenfalls wichtige URLs erhalten. Externe Kennungen müssen möglicherweise weiterhin mit einem anderen System verbunden bleiben.
Diese Ergebnisse werden zu Abnahmekriterien. Sie steuern, welche Datensätze als Stichprobe ausgewählt werden, welche Konfigurationsentscheidungen eine genauere Prüfung verdienen und welche Ergebnisse im Zielshop als Pass, Watch oder Block eingestuft werden sollten.
Die Vorbereitung sollte außerdem Folgendes identifizieren:
- wichtige Datenkategorien und Beziehungen;
- Quelldatensätze, die von Anwendungen, Plugins, Modulen oder Erweiterungen verwaltet werden;
- benutzerdefinierte Felder, Tabellen oder Kennungen externer Systeme;
- Content und URLs mit kommerziellem oder SEO-Wert;
- erwartete Aktivität im Quellshop während des Migrationsfensters;
- Implementierung auf der Zielplattform, die weiterhin getrennt von der Datenmigration behandelt werden muss;
- Verantwortliche für Konfiguration, Ausführung und abschließende Validierung.
Der Prozess wird instabil, wenn diese Punkte erst entdeckt werden, nachdem eine umfassendere Migration bereits als verbindliches Ergebnis behandelt wurde.
Die Verbindung prüft die Erreichbarkeit
Unterstützte Verbindungsanforderungen hängen von der gewählten Quell- und Zielplattform ab. Der praktische Zweck der Verbindung besteht darin, festzustellen, ob die Migration die Datensätze und Medien erreichen kann, die für den freigegebenen Umfang benötigt werden.
Eine KitConnect- oder API-Verbindung kann für Quellshop und Zielshop unabhängig getestet werden. Diese Trennung ist für die Fehlerdiagnose wichtig. Ein erfolgreicher Test des Quellshops bestätigt nur dessen Erreichbarkeit, ein erfolgreicher Test des Zielshops nur dessen Erreichbarkeit. Wenn eine Seite erfolgreich ist und die andere nicht, kann das Projekt gezielt Zugriff, Zugangsdaten, Endpunkt oder Installationsbedingungen des betroffenen Shops prüfen, statt den gesamten Pfad als ein einziges unspezifisches Verbindungsproblem zu behandeln.
Eine erfolgreiche Verbindung beweist nicht, dass jeder geschäftlich relevante Datensatz verfügbar ist. Manche Daten können in benutzerdefinierten Tabellen, von Anwendungen verwalteten Strukturen, exportierten Dateien oder externen Systemen liegen. Die Vorbereitung der Verbindung sollte die erreichbaren Daten deshalb mit dem Umfangsinventar vergleichen.
Dieser Vergleich kann früh zu einer klaren Entscheidung führen:
| Feststellung | Bedeutung für die Migration |
|---|---|
| Erforderliche Datensätze sind über unterstützten Zugriff erreichbar | Die Konfiguration kann mit höherer Sicherheit über den Umfang fortgesetzt werden |
| Wichtige Datensätze liegen außerhalb unterstützter Plattformstrukturen | Eine Prüfung durch Custom Service oder separate Implementierungsplanung kann erforderlich sein |
| Medien- oder Content-Abhängigkeiten sind unvollständig | Die Vorbereitung muss korrigiert werden, bevor repräsentative Nachweise belastbar sind |
| Zielzugriff besteht, aber die erforderliche Darstellung auf der Zielplattform ist unklar | Mapping und Implementierungsverantwortung müssen vor der Ausführung geklärt werden |
Der Wert dieser Phase liegt nicht nur darin, dass zwei Shops kommunizieren können. Entscheidend ist, dass das Projekt bestätigen kann, ob die verfügbaren Daten dem Migrationsversprechen entsprechen.
Konfiguration macht den Umfang zu einer überprüfbaren Annahme
Die Konfiguration übersetzt den Migrationsplan in konkrete Behandlungsentscheidungen. Sie legt fest, welche unterstützten Datenkategorien enthalten sind, wie Standardattribute zugeordnet werden, welche Einstellungen gelten und ob gekaufte Add-ons benötigt werden.
Das Projekt formuliert an diesem Punkt praktisch eine Hypothese:
Wenn diese Datensätze ausgewählt, diese Mappings verwendet und diese Konfigurationsentscheidungen angewendet werden, sollte der Zielshop die beabsichtigte geschäftliche Bedeutung erhalten.
Diese Annahme sollte geprüft werden, bevor sie eine umfangreiche Ausführung steuert. Wichtige Fragen sind:
- Tragen Quell- und Zielfelder dieselbe Bedeutung?
- Bleiben Product-Optionen und Varianten kaufbar?
- Sind Customer-Gruppen und Order-Status sinnvoll abgestimmt?
- Werden Werte für Sprache, Standort, Bestand, Zahlung oder Auftragsabwicklung korrekt zugeordnet?
- Sollen alle gescannten Datensätze migriert werden oder ist eine Filterung erforderlich?
- Muss ein unterstützter Wert transformiert werden?
- Muss ein unterstütztes Quellfeld einem anderen kompatiblen Zielfeld zugeordnet werden?
- Überschreitet eine Anforderung die verfügbaren Add-on-Funktionen?
Die beim Kauf eingegebenen Datenmengen unterstützen die Schätzung der Entity Points und die Preisbestimmung. Sie sind keine Migrationsfilter. Standardmäßig werden alle gescannten Datensätze innerhalb der ausgewählten unterstützten Datenkategorien migriert, sofern keine Filterung konfiguriert ist. Ein selektiver Umfang sollte deshalb mit Data Filter über feldbasierte Bedingungen für die jeweils relevante Datenkategorie ausgedrückt werden oder als individuelle Filteranforderung geprüft werden, wenn die verfügbaren Funktionen nicht ausreichen.
Die Qualität der Konfiguration ist wichtig, weil ein Datensatz vorhanden und trotzdem unbrauchbar sein kann. Ein Product mit falscher Optionsbeziehung, eine Order mit bedeutungslosem Status oder ein Customer in der falschen Gruppe kann die Anzahl erhöhen und gleichzeitig die Qualität des Migrationsergebnisses verschlechtern.
Demo Migration liefert frühe, aber begrenzte Nachweise
Demo Migration ist eine separate optionale Quelle für frühe Nachweise. Am wertvollsten ist sie, wenn repräsentative Datensätze gezielt ausgewählt werden, um die Konfigurationsannahme zu testen.
Einfache Datensätze können grundlegendes Übertragungsverhalten zeigen. Schwierige Datensätze zeigen eher, ob die Bedeutung der Quelle erhalten bleibt. Sinnvolle Stichproben umfassen häufig Products mit Varianten, Customers mit relevanter Gruppenlogik, Orders mit ungewöhnlicher Historie, Content mit wichtigen URLs sowie Datensätze, die wahrscheinlich Anforderungen an Filterung, Mapping oder individuelle Daten sichtbar machen.
Demo Migration hat definierte Daten- und Mengenlimits. Add-ons und Customization stehen darin nicht zur Verfügung. Das Ergebnis kann zeigen, dass solche Funktionen erforderlich sein könnten, es kann aber deren konfigurierte Funktionsweise nicht validieren.
Die Entscheidung nach Demo Migration sollte nicht lauten: „Datensätze sind sichtbar, also ist das Projekt bereit.“ Stattdessen sollte geklärt werden:
- welche Annahmen durch die Ergebnisse gestützt wurden;
- welche Beziehungen oder Werte weiterhin unklar sind;
- welche Anforderung ein Add-on oder eine Prüfung durch Custom Service benötigt;
- welche Stichproben während der bezahlten Migration erneut getestet werden sollten;
- ob der ausgewählte Migration Service weiterhin zu den Erkenntnissen passt.
Demo Migration behandelt diese Entscheidungen zu Nachweisen und Stichprobenauswahl im Detail.
Full Migration erzeugt das umfassendere Ergebnis
Full Migration wendet die akzeptierte Konfiguration auf den ausgewählten unterstützten Umfang an. Hier werden Planung und frühe Nachweise zu einem umfassenderen Ergebnis im Zielshop.
Shopdaten werden in einer festen Reihenfolge der Datenkategorien verarbeitet:
Taxes -> Manufacturers -> Categories -> Products -> Customers -> Orders -> Reviews -> Coupons -> CMS Pages -> Blog Posts
Innerhalb jeder Datenkategorie werden Datensätze gemäß der Quelldatenbank vom ältesten zum neuesten verarbeitet. Die Reihenfolge bildet Datenabhängigkeiten innerhalb der Migration ab. Categories werden beispielsweise vor Products verarbeitet, weil die Product-Zuordnung von der Katalogstruktur abhängt.
Diese Verarbeitungsreihenfolge darf nicht mit dem Verbrauch von Entity Points verwechselt werden. Entity Points gelten nur für die Kapazität von Products, Customers, Orders und Blog Posts. Taxes, Manufacturers, Categories, Reviews, Coupons und CMS Pages können Teil der Migration sein, ohne eigenständig Entity Points zu verbrauchen.
Auch die Ausführung kann Failed- oder Skipped-Datensätze, Mapping-Unterschiede oder Zielplattformfunktionen erzeugen, die interpretiert werden müssen. Ein abgeschlossener Lauf bedeutet, dass die Verarbeitung ihr Ende erreicht hat. Er beweist nicht, dass jedes beabsichtigte Ergebnis bestanden hat.
Validierung macht aus dem Output eine Abnahmegrundlage
Die Validierung sollte den Zielshop mit den Abnahmekriterien vergleichen, die vor der Ausführung definiert wurden. Die Frage ist nicht nur, ob Daten vorhanden sind, sondern ob sie den beabsichtigten nächsten Geschäftsschritt unterstützen.
Priorisierte Bereiche sind häufig:
- Product-Identität, Optionen, Varianten, Attribute, Preise, Bilder und Kaufverhalten;
- Category- und Navigationsbeziehungen;
- Customer-Identität, Gruppen, Adressen und Kontoerwartungen;
- Order-Positionen, Summen, Status, Erstattungen und Servicekontext;
- Reviews, Coupons, CMS Pages und Blog Posts, sofern relevant;
- URLs, Weiterleitungen, Metadaten und Content-Kontinuität;
- Ergebnisse, die von Filterung, Mapping, Werttransformation oder Custom Service beeinflusst wurden;
- externe Kennungen und Beziehungen, die verbundene Systeme benötigen.
Repräsentative Nachweise sind nützlicher als wahllose Vollkontrollen. Hochwertige, strukturell anspruchsvolle und geschäftskritische Beispiele sollten von den Personen geprüft werden, die ihre beabsichtigte Bedeutung verstehen.
Die Verantwortung für die abschließende Verifikation bleibt bei jeder Migration Service Variante beim Kunden. Die Ausführung kann kundengeführt oder expertengestützt sein, aber die geschäftliche Abnahme bleibt eine separate Entscheidung.
Spätere Aktionen berücksichtigen einen sich verändernden Quellshop
Viele Migrationsprojekte enden nicht mit einer einzigen Ausführung. Der Quellshop kann während Vorbereitung und Validierung des Zielshops weiterhin neue Products, Customers, Orders oder Content erhalten.
Spätere Aktivitäten sollten mit dem beabsichtigten Ergebnis beginnen:
- Kontinuität erhalten, indem eine weiterhin gültige Konfiguration wiederverwendet wird;
- fortsetzen und dabei die Konfiguration ändern;
- ein eigenständiges neues Migrationsergebnis erzeugen.
Diesen Absichten entsprechen:
- Continue the Migration with the Last Used Configuration
- Continue the Migration with a New Configuration
- Perform a New Migration
Die gewählte Aktion bestimmt nicht automatisch, welche Quelldatensätze gelesen werden. Das Leseverhalten der Quelle, beispielsweise das Fortsetzen einer unterbrochenen Verarbeitung oder die Migration nur neu hinzugefügter Datensätze, ist eine separate Konfigurationsentscheidung, sofern diese Option unterstützt wird und anwendbar ist.
Jede spätere Aktion braucht eine Validierung, die zu ihrem Zweck passt. Bei Wiederverwendung einer Konfiguration muss bestätigt werden, dass die früheren Annahmen weiterhin gelten. Bei geänderter Konfiguration muss das überarbeitete Verhalten geprüft werden. Eine neue Migration muss zeigen, dass das frische Ergebnis nur das ersetzt, was der freigegebene Umfang vorsieht.
Die Verantwortung verändert die Übergabe, nicht den Nachweisstandard
Derselbe Prozess kann kundengeführt sein oder expertengestützte Ausführung enthalten. Was sich ändert, ist, wer die vereinbarten Schritte vorbereitet und ausführt. Die Nachweise, die für ein belastbares Ergebnis erforderlich sind, bleiben bestehen.
| Verantwortungsmodell | Zentrale Prozessverantwortung | Erforderliche Kundenrolle |
|---|---|---|
| Kundengeführte Ausführung | Zugänge und Konfiguration vorbereiten, Aktionen ausführen, Ergebnisse koordinieren | Zielshop validieren und Ergebnis freigeben |
| Expertengestützte Ausführung | Vereinbarte Migrationsaktionen innerhalb des akzeptierten Umfangs ausführen | Korrekte Anforderungen liefern, Nachweise prüfen und Ergebnis freigeben |
Klare Übergaben verhindern zwei gegensätzliche Fehler. Der erste ist die Annahme, expertengestützte Ausführung übertrage auch die geschäftliche Abnahme. Der zweite ist die Annahme, Kundenvalidierung mache den Wert expertengestützter Ausführung überflüssig. Es handelt sich um unterschiedliche Verantwortlichkeiten, und beide sind notwendig.
Fazit
Der Next-Cart Migrationsprozess führt von Unsicherheit zu Nachweisen. Die Vorbereitung definiert das gewünschte Ergebnis. Die Verbindung prüft, ob die benötigten Daten erreichbar sind. Die Konfiguration macht aus dem Umfang eine überprüfbare Annahme. Demo Migration kann diese Annahme mit repräsentativen Nachweisen testen. Full Migration erzeugt das umfassendere Ergebnis. Die Validierung entscheidet, ob der Zielshop nutzbar ist, und spätere Aktionen halten das Ergebnis passend, wenn sich Projektbedingungen verändern.
Wenn jede Phase als Nachweispunkt verstanden wird, wird ein abgeschlossener Lauf nicht mit einem abgeschlossenen Migrationsergebnis verwechselt. Gleichzeitig lassen sich Fehler leichter diagnostizieren, weil das Projekt erkennen kann, ob die Schwäche bei Umfang, Zugriff, Konfiguration, Ausführung oder Validierung entstanden ist.
Häufige Fragen
Was sind die wichtigsten Bestandteile des Migrationsprozesses?
Der gekaufte Ablauf konzentriert sich auf Verbindung, Konfiguration und Migration. Das vollständige Projekt umfasst außerdem Ergebnisdefinition, Vorbereitung, repräsentative Nachweise, Validierung und spätere Migrationsentscheidungen.
Begrenzen die beim Kauf eingegebenen Datenmengen, was migriert wird?
Nein. Sie unterstützen die Schätzung der Entity Points und die Auswahl des Plans. Standardmäßig werden alle gescannten Datensätze innerhalb der ausgewählten unterstützten Datenkategorien migriert, sofern keine Filterung konfiguriert wurde.
Wie lautet die feste Verarbeitungsreihenfolge der Datenkategorien?
Die Reihenfolge lautet Taxes, Manufacturers, Categories, Products, Customers, Orders, Reviews, Coupons, CMS Pages und Blog Posts.
Ist die Verarbeitungsreihenfolge der Datenkategorien dasselbe wie der Verbrauch von Entity Points?
Nein. Die Reihenfolge beschreibt, in welcher Reihenfolge unterstützte Daten verarbeitet werden. Entity Points gelten nur für die gezählte Kapazität von Products, Customers, Orders und Blog Posts.
Bedeutet eine abgeschlossene Full Migration, dass der Zielshop bereit ist?
Nein. Abschluss bedeutet, dass die Verarbeitung beendet ist. Die Validierung muss weiterhin bestätigen, dass Datensätze, Beziehungen, Content und Geschäftsergebnisse die Abnahmekriterien erfüllen.
Warum werden spätere Migrationsaktionen vom Leseverhalten der Quelle getrennt?
Die Aktion bestimmt, ob die Konfiguration wiederverwendet, geändert oder durch ein frisches Ergebnis ersetzt wird. Das Leseverhalten der Quelle bestimmt, welche Datensätze gelesen werden, beispielsweise neu hinzugefügte Datensätze oder die Fortsetzung einer unterbrochenen Verarbeitung, sofern diese Optionen unterstützt werden.