Innerhalb der Next-Cart Migration Services unterstützen Additional Migration Options Projekte, die nach dem ersten umfassenderen Ergebnis weiterlaufen. Der Quellshop kann aktiv bleiben, während der Zielshop geprüft wird. Neue Orders und Customers können hinzukommen. Die Validierung kann zeigen, dass ein Mapping oder Filter geändert werden sollte. Ein Testergebnis kann vor dem Go-live ersetzt werden müssen.
Diese Situationen wirken ähnlich, weil jede zusätzliche Migrationsaktivität erfordert. Die beabsichtigten Ergebnisse unterscheiden sich jedoch. Eine Situation erhält die Kontinuität mit einer bewährten Konfiguration. Eine andere setzt das Projekt fort, ändert aber die Konfiguration. Eine dritte erzeugt ein eigenständiges frisches Migrationsergebnis.
Next-Cart Additional Migration Options sollten deshalb nach dem beabsichtigten Ergebnis ausgewählt werden und nicht nach Bequemlichkeit. Die falsche Wahl kann Annahmen wiederverwenden, die nicht mehr gelten, ein Ergebnis ersetzen, das erhalten bleiben sollte, oder falsche Erwartungen dazu erzeugen, welche Quelldatensätze gelesen werden.
Definieren Sie das nächste Ergebnis, bevor Sie die Aktion wählen
Die erste Frage lautet nicht „Welche Option ist verfügbar?“, sondern „Was soll nach der nächsten Migrationsaktivität weiterhin gelten?“
Drei Absichten sollten unterschieden werden:
- Kontinuität: Das vorherige Ergebnis bleibt nützlich und dieselbe Konfiguration soll fortgeführt werden.
- Kontrollierte Änderung: Das vorherige Ergebnis bleibt nützlich, aber Filter, Mappings, ausgewählte Datenkategorien, Add-ons oder andere Konfigurationen sollen sich ändern.
- Frisches Ergebnis: Das frühere Migrationsergebnis soll nicht länger die Grundlage des Projekts sein.
Diesen Absichten entsprechen drei exakte Aktionen:
| Beabsichtigtes Ergebnis | Migrationsaktion | Zentrale Bedeutung |
|---|---|---|
| Mit einer bewährten Konfiguration fortfahren | Continue the Migration with the Last Used Configuration | Die gespeicherte Konfiguration wird wiederverwendet |
| Fortfahren und die Konfiguration ändern | Continue the Migration with a New Configuration | Die Konfiguration wird vor der Ausführung geprüft oder überarbeitet |
| Ein eigenständiges frisches Ergebnis erzeugen | Perform a New Migration | Frühere Migrationsaktivität wird nicht als Grundlage des neuen Ergebnisses behandelt |
Bei einer ersten Migration gibt es keine gespeicherte Konfiguration, die wiederverwendet werden kann. Die Verfügbarkeit späterer Aktionen hängt von der relevanten Migrationshistorie und einer aktiven Servicedauer ab. Wenn die einjährige Dauer abgelaufen ist, muss die Migration verlängert werden, bevor eine zulässige spätere Aktion ausgeführt werden kann.
Verwenden Sie die letzte Konfiguration nur wieder, wenn ihre Annahmen noch gelten
Continue the Migration with the Last Used Configuration ist geeignet, wenn die frühere Konfiguration weiterhin gültig und das vorherige Ergebnis im Zielshop weiterhin nützlich ist.
Die Aktion kann wiederholte Entscheidungsarbeit reduzieren, ihre Effizienz hängt aber von einer wesentlichen Annahme ab: Die letzte Konfiguration repräsentiert weiterhin das beabsichtigte Ergebnis.
Vor der Wiederverwendung sollte bestätigt werden, dass:
- die ausgewählten Datenkategorien weiterhin passen;
- Mapping-Entscheidungen weiterhin zur Zielstruktur passen;
- Filterregeln weiterhin den beabsichtigten Datensatzumfang beschreiben;
- die Add-on-Konfiguration weiterhin geeignet ist;
- sich Quell- und Zielstrukturen nicht wesentlich verändert haben;
- die vorherige Validierung keinen ungelösten Konfigurationsfehler aufgedeckt hat;
- das beabsichtigte Zeitfenster der Quelldatensätze weiterhin richtig ist.
Eine Konfiguration nur deshalb wiederzuverwenden, weil sie einmal funktioniert hat, reicht nicht aus. Der Projektkontext kann sich geändert haben. Ein neues Quellfeld, eine überarbeitete Zielstruktur oder ein anderer Go-live-Umfang kann die frühere Konfiguration ungeeignet machen, obwohl der Migrationspfad unverändert ist.
Die Validierung nach dieser Aktion sollte sowohl Kontinuität als auch Änderung bestätigen. Das bestehende Ergebnis im Zielshop sollte nutzbar bleiben und neu verarbeitete Datensätze sollten denselben akzeptierten Regeln folgen.
Mit neuer Konfiguration fortfahren, wenn sich das Ziel verändert hat
Continue the Migration with a New Configuration passt, wenn frühere Migrationsaktivität weiterhin nützlich ist, die nächste Ausführung aber andere unterstützte Einstellungen benötigt.
Typische Gründe sind:
- Filterung soll eine andere Datensatzgruppe ein- oder ausschließen;
- Standard-Mappings müssen überarbeitet werden;
- ausgewählte Datenkategorien haben sich geändert;
- ein Add-on soll andere Einstellungen verwenden;
- die Validierung hat ein Konfigurationsproblem gezeigt;
- die nächste Projektphase hat einen anderen Umfang;
- Zielerwartungen haben sich verändert, ohne dass ein vollständig frisches Ergebnis erforderlich ist.
Der zentrale Vorteil ist kontrollierte Anpassung. Das Projekt kann nützliche frühere Arbeit erhalten und zugleich die Entscheidungen ändern, die die nächste Aktivität steuern.
Das Risiko besteht in unbeabsichtigter Koexistenz. Datensätze, die mit der früheren Konfiguration erzeugt wurden, können neben Datensätzen bestehen bleiben, die mit der neuen Konfiguration erzeugt werden. Die Validierung sollte deshalb prüfen, ob beide Konfigurationen Duplikate, widersprüchliche Mappings, inkonsistente Feldnutzung oder unterschiedliche geschäftliche Bedeutung erzeugen.
Wenn beispielsweise ein Mapping für Customer-Gruppen geändert wird, sollten Customers geprüft werden, die unter beiden Konfigurationen migriert wurden. Die Frage ist nicht nur, ob das neue Mapping funktioniert. Entscheidend ist, ob der kombinierte Zielshop weiterhin konsistent bleibt.
Perform a New Migration verwenden, wenn das frühere Ergebnis nicht fortgeführt werden soll
Perform a New Migration ist geeignet, wenn das Projekt ein eigenständiges frisches Migrationsergebnis benötigt, statt frühere Arbeit fortzusetzen.
Das kann gerechtfertigt sein, wenn:
- das frühere Migrationsergebnis nur für Tests erstellt wurde;
- die vorherige Konfiguration den beabsichtigten Umfang nicht mehr widerspiegelt;
- die Validierung zusammenhängende Fehler gefunden hat, die eine Fortsetzung unzuverlässig machen;
- die Vorbereitung des Zielshops eine saubere Migrationsbasis benötigt;
- das Projekt Umfang und Konfiguration von Beginn an neu bewerten möchte.
Eine neue Migration sollte gewählt werden, weil das Ergebnis frisch sein muss, nicht nur weil eine weitere Ausführung möglich ist.
Entscheidungen zu Ersetzung und Bereinigung müssen sorgfältig getroffen werden. Die Aktion kann Datensätze betreffen, die zuvor innerhalb des ausgewählten Umfangs durch Migration erstellt wurden, autorisiert aber nicht automatisch das Entfernen sämtlicher Datensätze im Zielshop. Manuell erstellte Datensätze, von Anwendungen erzeugte Datensätze, Testdaten und operative Daten sollten vor jeder Bereinigungs- oder Ersetzungsentscheidung identifiziert werden.
Der Validierungsstandard sollte umfassender sein als bei einer Fortsetzung. Das Projekt sollte die frische Konfiguration, den resultierenden Datenbestand, die Behandlung früher migrierter Datensätze und den Schutz von Datensätzen außerhalb des freigegebenen Ersetzungsumfangs bestätigen.
Trennen Sie die Migrationsaktion vom Quelldaten-Zeitfenster
Die drei Aktionen bestimmen die Beziehung zur früheren Konfiguration und zum früheren Ergebnis. Sie bestimmen nicht unabhängig davon, welche Quelldatensätze gelesen werden.
Das Leseverhalten der Quelle beantwortet eine andere Frage:
- Soll eine unterbrochene Verarbeitung an der bereits erreichten Stelle fortgesetzt werden?
- Sollen nur Datensätze gelesen werden, die seit der letzten erfolgreichen Migration neu hinzugekommen sind?
- Soll der ausgewählte Quellumfang unter der gewählten Konfiguration erneut gelesen werden?
Diese Trennung verhindert ein häufiges Missverständnis. Mit der letzten Konfiguration fortzufahren bedeutet nicht automatisch, dass nur neu hinzugefügte Datensätze verarbeitet werden. Perform a New Migrationlegt ebenfalls nicht automatisch fest, wie das Quelldaten-Zeitfenster ausgewählt wird.
Ein bereits vorhandener Datensatz, der nach der vorherigen Aktivität verändert wurde, ist zudem etwas anderes als ein neu hinzugefügter Datensatz. Wenn geänderte bestehende Datensätze erneut berücksichtigt werden sollen, müssen Leseverhalten und Konfigurationsentscheidung diese Anforderung ausdrücklich festhalten.
Aktion und Quelldaten-Zeitfenster sollten gemeinsam geplant, aber nicht als eine einzige Einstellung behandelt werden.
Entity Points nach Datensatzstatus anwenden
Zusätzliche Migrationsaktivität verbraucht nicht allein deshalb Entity Points, weil eine weitere Aktion stattfindet. Der Verbrauch hängt von den gezählten Datensätzen ab.
| Situation eines gezählten Datensatzes | Auswirkung auf Entity Points |
|---|---|
| Product-, Customer-, Order- oder Blog-Posts-Datensatz wird erstmals erfolgreich migriert | Punkte werden mit dem jeweils festgelegten Gewicht verbraucht |
| Derselbe gezählte Datensatz wurde innerhalb der gekauften Migration und des festen Pfads bereits gezählt | Er verbraucht nicht erneut Punkte, nur weil eine weitere Aktion ihn verarbeitet |
| Ein neuer berechtigter Datensatz wird hinzugefügt und später migriert | Punkte werden verbraucht, wenn er erstmals erfolgreich migriert wird |
| Eine neue Migration enthält bereits zuvor gezählte berechtigte Datensätze | Diese Datensätze verbrauchen nicht erneut Punkte |
Diese Regel gilt für alle drei Aktionen. Perform a New Migration zählt nicht automatisch jeden früher registrierten Product-, Customer-, Order- und Blog-Posts-Datensatz erneut.
Die Kapazitätsplanung sollte sich auf tatsächlich neue gezählte Daten konzentrieren. Wenn der Quellshop aktiv bleibt, sollte das erwartete Wachstum von Products, Customers, Orders und Blog Posts vor der nächsten Aktion mit der verbleibenden Entity-Points-Kapazität verglichen werden.
Migrationsaktionen von kommerziellen Änderungen trennen
Eine Additional Migration Option bestimmt, wie sich die nächste Migrationsaktivität zum früheren Ergebnis verhält. Ein Upgrade verändert das gekaufte Paket, eine Extension stellt eine abgelaufene Migration wieder her. Diese Entscheidungen hängen zusammen, sind aber nicht austauschbar.
Mehr Entity Points zu kaufen erhöht beispielsweise die Kapazität, entscheidet aber nicht darüber, ob die nächste Aktivität die letzte Konfiguration wiederverwendet, eine neue Konfiguration nutzt oder ein frisches Ergebnis erzeugt. Ein Upgrade von Standard zu Managed verändert die Ausführungsverantwortung, wählt aber nicht die Migrationsaktion. Eine Extension einer abgelaufenen Migration stellt den Service aus dem zuletzt erhaltenen Paket wieder her. Danach hängt die passende Aktion weiterhin vom beabsichtigten Ergebnis ab.
Diese Trennung verhindert, dass eine kommerzielle Order mit einer Migrationsanweisung verwechselt wird. Gleichzeitig bleibt der feste Migrationspfad erhalten: Upgrades und Extensions verändern dieselbe gekaufte Migration und erzeugen keine andere Richtung von Quellplattform zu Zielplattform.
Die Verantwortung des Migration Service sichtbar halten
Eine Additional Migration Option ersetzt nicht den gekauften Migration Service.
Bei kundengeführter Ausführung führt der Kunde die ausgewählte Aktion aus und validiert das Ergebnis. Bei expertengestützter Ausführung wird die vereinbarte Aktion innerhalb des akzeptierten Serviceumfangs ausgeführt, während der Kunde die erforderlichen Informationen liefert und das Ergebnis freigibt.
Wenn spätere Aktivitäten angepasste Anforderungen einführen, muss sich gegebenenfalls auch der Serviceumfang ändern. Ein neues benutzerdefiniertes Feld, ein verändertes Add-on oder eine maßgeschneiderte Transformation darf nicht in einer Fortsetzungsaktion verborgen werden, nur weil der Migrationspfad bereits existiert.
Das Projekt sollte daher zwei Fragen getrennt prüfen:
- Welche Aktion entspricht der beabsichtigten Beziehung zum früheren Ergebnis?
- Deckt der bestehende Migration Service den erforderlichen Umfang und die Ausführungsverantwortung weiterhin ab?
Validierung an den Zweck der Aktion anpassen
Jede Aktion benötigt Validierung, aber die Nachweise sollten zu ihrer Absicht passen.
| Aktion | Primärer Validierungsfokus |
|---|---|
| Continue the Migration with the Last Used Configuration | Die Konfiguration blieb gültig, das beabsichtigte Quelldaten-Zeitfenster wurde verarbeitet und die Kontinuität blieb erhalten |
| Continue the Migration with a New Configuration | Die überarbeiteten Einstellungen erzeugten das beabsichtigte Ergebnis, ohne Inkonsistenzen mit früher migrierten Datensätzen zu verursachen |
| Perform a New Migration | Das frische Ergebnis entspricht dem freigegebenen Umfang, früher migrierte Daten wurden richtig behandelt und geschützte Datensätze im Zielshop blieben intakt |
Repräsentative Prüfungen sollten geschäftskritische Products, Customers, Orders, Blog Posts, CMS Pages, Reviews, Coupons, URLs, gefilterte Datensätze, gemappte Werte, Add-on-Ergebnisse und Daten im Custom-Umfang umfassen, sofern relevant.
Eine ausgewählte Aktion ist erst dann erfolgreich, wenn der Zielshop den vorgesehenen nächsten Geschäftsschritt unterstützt. Der Abschluss einer Aktion ist keine Abnahme.
Fehler bei der Wahl der Absicht vermeiden
Konfiguration wiederverwenden, obwohl sich die Anforderung geändert hat
Die letzte Konfiguration kann vertraut, aber nicht mehr gültig sein. Wiederverwendung sollte nur erfolgen, wenn Nachweise zeigen, dass Mappings, Filter, Add-ons und Zielerwartungen weiterhin passen.
Neue Migration wählen, obwohl eine Konfigurationsanpassung reicht
Ein frisches Ergebnis kann unnötige Ersetzungsrisiken erzeugen. Wenn frühere Arbeit weiterhin nützlich ist und nur unterstützte Einstellungen geändert werden müssen, kann die Fortsetzung mit einer neuen Konfiguration präziser sein.
Annehmen, dass eine Fortsetzung nur neue Datensätze liest
Aktion und Quelldaten-Zeitfenster sind getrennt. Das Leseverhalten der Quelle muss ausdrücklich geplant werden.
Eine neue Migration als Erlaubnis verstehen, jeden Zielshop-Datensatz zu löschen
Ersetzung muss innerhalb des freigegebenen Umfangs bleiben. Manuell oder durch Anwendungen erstellte und andere geschützte Datensätze brauchen separate Schutz- und Eigentumsentscheidungen.
Validierung überspringen, weil das frühere Ergebnis bestanden hat
Neue Quelldatensätze, geänderte Konfiguration und ein frisches Ergebnis erzeugen jeweils neue Nachweisanforderungen. Eine frühere Abnahme kann nicht automatisch übertragen werden.
Fazit
Next-Cart Additional Migration Options stehen für drei unterschiedliche Projektabsichten. Continue the Migration with the Last Used Configuration erhält Kontinuität, wenn die frühere Konfiguration weiterhin gültig ist. Continue the Migration with a New Configurationerhält nützliche frühere Arbeit und ermöglicht zugleich kontrollierte Änderungen. Perform a New Migration erzeugt ein eigenständiges frisches Ergebnis, wenn die frühere Migration nicht länger die Grundlage des Projekts sein soll.
Die Aktion sollte mit Auswahl der Quelldatensätze, Entity-Points-Kapazität, Verantwortung des Migration Service, Ersetzungsgrenzen und zweckbezogener Validierung abgestimmt werden. Wer vom beabsichtigten Ergebnis ausgeht, hält spätere Migrationsaktivität kontrolliert und verhindert, dass eine verfügbare Aktion zur Ersatzentscheidung für die Projektplanung wird.
Häufige Fragen
Wann sollte die zuletzt verwendete Konfiguration wiederverwendet werden?
Verwenden Sie sie wieder, wenn die vorherige Konfiguration, die beabsichtigte Quelldatenauswahl, Add-ons, Mappings und Zielerwartungen weiterhin gültig sind.
Wann ist eine neue Konfiguration geeigneter?
Nutzen Sie eine neue Konfiguration, wenn frühere Migrationsarbeit weiterhin nützlich ist, aber Filter, Mappings, ausgewählte Datenkategorien, Add-ons oder andere unterstützte Einstellungen geändert werden müssen.
Wann sollte eine neue Migration durchgeführt werden?
Verwenden Sie Perform a New Migration, wenn das Projekt ein eigenständiges frisches Ergebnis benötigt und das frühere Migrationsergebnis nicht mehr die Grundlage des Projekts sein soll.
Lesen Fortsetzungsaktionen automatisch nur neu hinzugefügte Datensätze?
Nein. Migrationsaktion und Quelldaten-Zeitfenster sind separate Entscheidungen.
Verbrauchen bereits gezählte Datensätze erneut Entity Points?
Nein. Gezählt Datensätze, die innerhalb der gekauften Migration und des festen Pfads bereits erfasst wurden, verbrauchen nicht erneut Punkte, nur weil eine weitere Aktion sie verarbeitet.
Löscht Perform a New Migration jeden Datensatz im Zielshop?
Nein. Bereinigung und Ersetzung müssen dem freigegebenen Umfang folgen. Manuell erstellte, von Anwendungen erzeugte und andere geschützte Datensätze müssen separat identifiziert werden.
Ändert eine Additional Migration Option den Migration Service?
Nein. Ein Upgrade des Migration Service ist eine separate kommerzielle Änderung. Es kann Umfang oder Ausführungsverantwortung verändern, entscheidet aber nicht, welche Additional Migration Option zum nächsten Ergebnis passt.
Was muss nach einer späteren Aktion validiert werden?
Die Validierung sollte das beabsichtigte Quelldaten-Zeitfenster, das Konfigurationsverhalten, die Auswirkung auf Entity Points, die Behandlung früherer Ergebnisse, geschützte Datensätze und die geschäftliche Nutzbarkeit des Zielshops bestätigen.