Ein Next-Cart Migration Service wird leicht unterschätzt, wenn er nur als eine Zahlung und eine Datenübertragung betrachtet wird. Der Kunde erwirbt eine Migration, die als zentrale Serviceeinheit bestehen bleibt. Ihr fester Migrationspfad, die einjährige Servicelaufzeit, die gezählte Kapazität, die Verantwortung für die Ausführung, unterstützte Erweiterungen und gegebenenfalls individuell vereinbarte Anforderungen bestimmen gemeinsam das Ergebnis.
Diese Entscheidungen hängen zusammen, sind aber nicht austauschbar. Ein großer Shop kann vorhersehbare Daten besitzen und gut zu einer vom Kunden ausgeführten Migration passen. Ein kleinerer Shop kann dagegen von benutzerdefinierten Feldern oder Datensätzen aus Drittsystemen abhängen, deren erforderliche Behandlung außerhalb des unterstützten Migrationsumfangs oder der Standard-Add-on-Funktionen liegt. Ein Add-on kann eine klar abgegrenzte Zuordnungsanforderung lösen, ohne den gesamten Migration Service zu verändern. Entity Points können das gezählte Datenvolumen abdecken, ohne zu beweisen, dass die Darstellung auf der Zielplattform tatsächlich nutzbar sein wird.
Der sinnvollste Überblick über die Next-Cart Migration Services betrachtet die erworbene Migration daher als Zusammenspiel mehrerer aufeinander abgestimmter Ebenen. Jede Ebene beantwortet eine andere Projektfrage. Spätere Upgrades werden Teil derselben Migration, statt voneinander unabhängige Services zu erzeugen. Die Migration bleibt damit der stabile Bezugspunkt für Planung, Ausführung und Validierung.
Beginnen Sie mit dem angestrebten Migrationsergebnis
Der Migrationspfad definiert eine feste Einbahnrichtung von einer Quellplattform zu einer Zielplattform. Diese Richtung ist mehr als ein technisches Routing-Detail. Sie bestimmt, welche Plattformstrukturen interpretiert werden müssen, welche Verbindungsanforderungen vorzubereiten sind und welche Einschränkungen der Zielplattform das Ergebnis beeinflussen können.
Bevor Kapazität oder Preis betrachtet werden, sollte das angestrebte Ergebnis eindeutig sein. Das Projekt kann beispielsweise verlangen, dass Products weiterhin kaufbar bleiben, Customer-Historien nutzbar sind, Orders ihren Servicekontext behalten, Inhalte ihren SEO-Wert bewahren oder externe Kennungen mit einem anderen System verbunden bleiben. Diese Ziele bestimmen, was die Migration erhalten muss und welche Nachweise später erforderlich sind.
Eine erworbene Migration umfasst genau einen Pfad von der Quellplattform zur Zielplattform. Dieser Pfad kann nach dem Kauf nicht geändert werden. Der Service bleibt ab dem Zeitpunkt des ursprünglichen Kaufs ein Jahr verfügbar, vorbehaltlich der gewählten Kapazität, des Migration Service, erworbener Add-ons, des vereinbarten individuellen Umfangs und der Validierungsverantwortung.
Das Upgrade einer Komponente erzeugt keinen neuen Pfad und startet die einjährige Laufzeit nicht neu. Das Upgrade verändert die bestehende Migration, während der ursprüngliche Kaufzeitpunkt weiterhin die Servicelaufzeit bestimmt. Eine abgelaufene Migration muss verlängert werden, bevor weitere zulässige Aktivitäten fortgesetzt werden können.
Trennen Sie die Entscheidungen innerhalb einer erworbenen Migration
Eine erworbene Migration verbindet in der Regel mehrere Planungsentscheidungen. Die folgende Tabelle ist besonders hilfreich, nachdem Ziel und Migrationspfad geklärt sind, weil sie zeigt, welche Frage die jeweilige Komponente beantworten soll.
| Komponente | Welche Projektfrage beantwortet sie? | Was entscheidet sie nicht? |
|---|---|---|
| Migrationspfad | Welche feste Richtung von der Quellplattform zur Zielplattform ist abgedeckt? | Ob das Datenmodell einfach ist oder das Ergebnis akzeptabel sein wird |
| Servicelaufzeit | Wie lange bleibt die erworbene Migration ab dem Erstkauf aktiv? | Ob ein Upgrade den Pfad ändert oder die Laufzeit neu startet |
| Entity Points Plan | Wie viel gezählte Kapazität für Product-, Customer-, Order- und Blog-Posts-Daten ist verfügbar? | Ob das Projekt Managed Service oder Custom Service benötigt |
| Migration Service | Wer ist für die Ausführung verantwortlich, und bleibt die Anforderung im unterstützten Rahmen oder benötigt sie individuelle Behandlung? | Wie viel gezählte Kapazität erforderlich ist |
| Add-ons | Kann eine klar abgegrenzte Anforderung an Filterung, Feld- oder Datenbankzuordnung oder Transformation von Zielwerten durch eine unterstützte Erweiterung abgedeckt werden? | Ob umfassendere nicht unterstützte oder maßgeschneiderte Arbeiten enthalten sind |
| Vereinbarter individueller Umfang | Welche nicht standardmäßigen Daten, Regeln, Beziehungen oder Ergebnisse benötigen individuelle Arbeit? | Die Implementierung der Zielplattform, sofern sie nicht ausdrücklich vereinbart wurde |
Verwirrung entsteht meist dann, wenn eine Zeile zur Beantwortung der Frage einer anderen verwendet wird. Die Shopgröße ersetzt die Bewertung der Service-Eignung. Eine geringe Entity-Points-Schätzung gilt fälschlich als Beweis für Einfachheit. Von einem Add-on wird erwartet, ein individuelles Datenmodell zu lösen. Managed Service wird so verstanden, als umfasse er jede nicht standardmäßige Anforderung. Keine dieser Schlussfolgerungen folgt aus der jeweiligen Komponente selbst.
Kapazität beschreibt Volumen, nicht Komplexität
Entity Points übersetzen vier gezählte Datenkategorien in gewichtete Kapazität:
- Product;
- Customer;
- Order;
- Blog Posts.
Der gewählte Entity Points Plan muss genügend Kapazität für den realistisch zu erwartenden gezählten Bedarf bereitstellen. Das ist eine Volumenentscheidung. Komplexität kann trotzdem durch Products mit ungewöhnlichen Optionsstrukturen, von Anwendungen verwaltete Datensätze, benutzerdefinierte Customer-Attribute, externe Order-Kennungen, mehrsprachige Beziehungen oder Einschränkungen der Zielplattform entstehen.
Betrachten Sie zwei Shops mit derselben Entity-Points-Schätzung. Der erste verwendet Standarddatensätze der Plattform und vorhersehbare Beziehungen. Der zweite speichert Vertragspreise in benutzerdefinierten Tabellen und nutzt eine externe Kennung, um Orders mit einem ERP zu verbinden. Die gezählte Kapazität kann identisch sein, die Migrationsanforderungen sind es nicht. Kapazitätsplanung sollte daher parallel zur Strukturanalyse erfolgen und diese nicht ersetzen.
Die ausführlichen Regeln zur Gewichtung und zum Verbrauch finden Sie in Entity Points. Plankapazitäten sowie Preise für Upgrades und Verlängerungen werden in Entity Points Plan and Migration Pricingerläutert.
Verantwortung und Umfang sind zwei verschiedene Achsen
Bei der Auswahl des Migration Service müssen zwei voneinander unabhängige Fragen beantwortet werden:
- Bleibt das erwartete Ergebnis innerhalb der unterstützten Migrationsfunktionen oder erfordert es individuelle Arbeit?
- Wer soll die vereinbarten Migrationsaktionen ausführen?
Standard Service und Managed Service decken beide unterstützte Migrationsanforderungen ab. Der wesentliche Unterschied liegt in der Ausführungsverantwortung. Standard Service folgt einem kundengeführten Ansatz. Managed Service umfasst die fachkundige Ausführung der vereinbarten Migrationsaktionen innerhalb des unterstützten Umfangs.
Custom Service ist für individuelle oder nicht standardmäßige Anforderungen vorgesehen. Er kann weiterhin kundengeführt sein oder Expert Handle enthalten, wenn auch die Ausführung der vereinbarten Aktionen Teil des individuellen Umfangs sein soll.
Diese Unterscheidung verhindert einen häufigen Fehler: Managed Service als Lösung für nicht unterstützte Daten zu betrachten. Fachkundige Ausführung macht eine individuelle Struktur nicht zu einer Standardstruktur. Umgekehrt bedeutet eine individuelle Anforderung nicht automatisch, dass eine fachkundige Ausführung benötigt wird.
Standard, Managed, and Custom Migration Services erläutert diese Definitionen im Detail. Choose the Right Migration Service zeigt, wie die Entscheidung aus den Projektinformationen abgeleitet wird.
Behandeln Sie die Migration als den Service-Datensatz
Die erworbene Migration und die damit verbundenen Zahlungen beantworten unterschiedliche Fragen. Die Migration bildet den aktuellen Servicestatus ab: ihren festen Pfad, den gewählten Migration Service, den Entity Points Plan, Add-ons, akzeptierte individuelle Arbeiten, die Servicelaufzeit und die Migrationshistorie. Orders dokumentieren dagegen geschäftlich, wie dieser Status gekauft, erweitert oder verlängert wurde.
Der Erstkauf erstellt die Migration. Ein späteres Upgrade des Plans, Service, Add-on oder individueller Arbeit wird nach dem Kauf Teil derselben Migration. Diese Trennung erklärt, warum eine Migration mehrere zugehörige Orders haben kann, ohne zu mehreren unabhängigen Migrationsservices zu werden.
Sie erklärt auch die spätere Preisbildung. Ein Upgrade wird mit dem bereits für die Migration bezahlten Wert verrechnet, sodass der Kunde nur die zusätzliche Differenz bezahlt, statt das vollständige Paket erneut zu erwerben. Die Verlängerung einer abgelaufenen Migration ist etwas anderes: Sie stellt den Service aus dem zuletzt erhaltenen Migrationsstand wieder her, einschließlich der bereits integrierten anwendbaren Komponenten.
Für die Serviceplanung ist diese Trennung wichtig, weil die Kontinuität der Migration der erworbenen Migration folgt, während jede Zahlung weiterhin eindeutig der geschäftlichen Änderung zugeordnet werden kann, die sie dokumentiert.
Nutzen Sie Add-ons für klar abgegrenzte Anforderungen
Add-ons sind besonders sinnvoll, wenn der Migrationspfad unterstützt wird, aber ein klar definierter Teil des Ergebnisses zusätzliche Steuerung benötigt. Die vier Standard Add-ons adressieren unterschiedliche, abgegrenzte Anforderungen:
- Data Filter bestimmt anhand feldbasierter Bedingungen je Datenkategorie, welche Datensätze migriert werden.
- Advanced Data Mapping ordnet unterstützte Quellfelder kompatiblen Zielfeldern neu zu.
- Advanced Database Mapping ordnet unterstützte Felder und zugrunde liegende Datenbankspalten kompatiblen Zielfeldern oder Zielspalten zu, einschließlich plattformspezifischer und benutzerdefinierter Felder. Es ist nur verfügbar, wenn sowohl Quellplattform als auch Zielplattform Open-Source sind.
- Data Transformation transformiert ausgewählte Werte in Zielfeldern, während Datensätze vom Quellshop in den Zielshop migriert werden.
Die Grenze ist entscheidend. Standard Add-ons sind mit allen drei Migration Services kompatibel, wenn ein verfügbares Add-on die Anforderung bereits erfüllt. Muss das Add-on selbst angepasst werden, wird die Anforderung als Tailored Add-on unter Custom Service behandelt. Passt kein Standard Add-on, kann ein Custom Add-on oder eine umfassendere Prüfung im Rahmen von Custom Service erforderlich sein.
Die Entscheidung sollte mit dem benötigten Ergebnis beginnen, nicht mit dem Namen des Add-ons. „Nur Orders nach einem freigegebenen Datum migrieren“ beschreibt ein filterbares Ergebnis. „Eine proprietäre Preis-Engine erhalten“ beschreibt dagegen ein umfassenderes individuelles Problem, dessen Bedeutung, Beziehungen und Zielverhalten zunächst definiert werden müssen.
Nutzen Sie frühe Ergebnisse als Entscheidungsgrundlage
Demo Migration kann vor einer umfassenderen Migration repräsentative frühe Ergebnisse liefern. Ihr Wert hängt weniger davon ab, ob Datensätze sichtbar werden, sondern davon, ob die gewählten Samples bedeutende Unterschiede aufdecken.
Ein aussagekräftiges Sample kann beispielsweise ein Product mit Varianten und besonderen Attributen, eine Order mit ungewöhnlicher Statushistorie, einen Customer aus einem realen Segmentierungsablauf oder Inhalte mit wichtigem URL-Wert enthalten. Einfache Datensätze können zeigen, dass ein grundlegender Pfad funktioniert. Schwierige Datensätze zeigen, ob die Annahmen für die Migration belastbar genug sind.
Demo Migration hat definierte Grenzen. Add-ons und Customization stehen innerhalb von Demo Migration nicht zur Verfügung. Das Ergebnis kann einen wahrscheinlichen Bedarf an einer unterstützten Erweiterung oder individueller Arbeit sichtbar machen, beweist aber nicht, wie diese spätere Konfiguration funktionieren wird. Demo Migration erläutert die Auswahl geeigneter Nachweise und die Grenzen ihrer Interpretation.
Trennen Sie Ausführung und Abnahme
Die Ausführung erzeugt ein Migrationsergebnis. Die Validierung stellt fest, ob dieses Ergebnis für das Unternehmen nutzbar ist.
Die Abschlussprüfung sollte mehr als das Vorhandensein von Datensätzen betrachten. Sie sollte bestätigen, dass wichtige Products ihre Kaufbedeutung behalten, Customers und Orders nutzbar bleiben, Inhalte und URLs die vorgesehene Nutzerreise unterstützen, Beziehungen weiterhin die richtigen Datensätze verbinden und jedes Add-on- oder individuelle Ergebnis dem akzeptierten Umfang entspricht.
Der Kunde bleibt bei jedem Migration Service für die abschließende Prüfung verantwortlich. Das bedeutet nicht, dass die Ausführungsverantwortung wieder auf den Kunden übertragen wird. Es handelt sich um eine andere Art der Verantwortung: Nur das Unternehmen selbst kann bestätigen, dass der Zielshop die vorgesehenen geschäftlichen, operativen, SEO- und Compliance-Ergebnisse unterstützt.
Konfiguration der Zielplattform, Theme-Arbeiten, Installation von Anwendungen, Bereitstellung von Integrationen und andere Implementierungsarbeiten sollten getrennt betrachtet werden, sofern sie nicht ausdrücklich im vereinbarten Umfang enthalten sind. Ein korrekt migrierter Datensatz konfiguriert nicht automatisch das System, das ihn anschließend verwendet.
Nutzen Sie den Bereich als Entscheidungssystem
Die Serviceartikel beantworten unterschiedliche Fragen:
| Zu klärende Entscheidung | Artikel |
|---|---|
| Wie gelangt die Migration von der Vorbereitung zu einem validierten Ergebnis? | How the Migration Process Works |
| Was können repräsentative frühe Ergebnisse tatsächlich belegen? | Demo Migration |
| Wie wird gezählte Kapazität berechnet und verbraucht? | Entity Points |
| Welcher Plan und welcher Preis gelten? | Entity Points Plan and Migration Pricing |
| Kann eine klar abgegrenzte unterstützte Anforderung durch ein Add-on gelöst werden? | Add-ons |
| Wie unterscheiden sich die drei Migration Services? | Standard, Managed, and Custom Migration Services |
| Welche individuellen Anforderungen gehören in Custom Service? | What Custom Service Handles |
| Welcher Migration Service passt zu den Projektnachweisen? | Choose the Right Migration Service |
| Welche spätere Aktion passt zu Kontinuität, geänderter Konfiguration oder einem neuen Ergebnis? | Additional Migration Options |
Diese Lesereihenfolge ist nicht verpflichtend. Sie hilft dabei, die jeweils noch offene Entscheidung isoliert zu betrachten, ohne Kapazität, Serviceverantwortung, individuellen Umfang und Validierung in einer einzigen Frage zu vermischen.
Fazit
Eine Next-Cart-Migration lässt sich am besten als dauerhafter erworbener Service verstehen und nicht als einmalige Übertragung oder Zahlung. Der feste Migrationspfad und die einjährige Laufzeit definieren den Rahmen. Entity Points stellen gezählte Kapazität bereit. Der Migration Service bestimmt unterstützten oder individuellen Umfang und die Ausführungsverantwortung. Add-ons lösen klar abgegrenzte unterstützte Anforderungen. Custom Service deckt nicht standardmäßige Bedürfnisse ab. Zugehörige Orders dokumentieren Käufe, Upgrades und Verlängerungen, ohne die Migration selbst aufzuteilen. Die Validierung entscheidet, ob das Ergebnis geschäftlich nutzbar ist.
Wer diese Ebenen getrennt hält, erhält klarere Schätzungen, besser begründbare Serviceentscheidungen und aussagekräftigere Abnahmenachweise. Gleichzeitig wird ein häufiger Planungsfehler vermieden: anzunehmen, eine einzelne Komponente wie Shopgröße, Preis oder ein Add-on könne die gesamte Migration erklären.
Häufige Fragen
Was definiert der Migrationspfad?
Er definiert die feste Einbahnrichtung von der Quellplattform zur Zielplattform, die von der erworbenen Migration abgedeckt ist.
Erzeugt ein Upgrade eine neue Migration oder startet es die Servicelaufzeit neu?
Nein. Ein erworbenes Upgrade wird in dieselbe Migration integriert. Der feste Pfad bleibt unverändert, und die einjährige Laufzeit läuft ab dem ursprünglichen Kaufzeitpunkt weiter.
Warum kann eine Migration mehrere zugehörige Orders haben?
Die erste Order erstellt die Migration. Spätere Orders können Upgrades oder eine Verlängerung dokumentieren, während die Migration der verwaltete Service bleibt.
Erfordert ein größerer Entity Points Plan Managed Service oder Custom Service?
Nein. Entity Points bestimmen die gezählte Kapazität. Die Auswahl des Migration Service hängt vom unterstützten Umfang, der Ausführungsverantwortung, dem Bedarf an Add-ons und individuellen Anforderungen ab.
Kann ein Add-on mit Standard Service verwendet werden?
Ja. Ein Standard Add-on kann Standard, Managed oder Custom Service ergänzen, wenn seine verfügbare Funktionsweise die klar abgegrenzte Anforderung erfüllt.
Enthält Custom Service immer Expert Handle?
Nein. Custom Service kann weiterhin kundengeführt sein. Expert Handle ist nur enthalten, wenn die fachkundige Ausführung der vereinbarten Migrationsaktionen Teil des akzeptierten individuellen Umfangs ist.
Warum ist nach fachkundiger Ausführung weiterhin eine Validierung durch den Kunden erforderlich?
Die Ausführung bestätigt, dass die Migrationsaktivitäten innerhalb des vereinbarten Umfangs durchgeführt wurden. Die Validierung durch den Kunden bestätigt, dass die daraus resultierenden Products, Customers, Orders, Inhalte, Beziehungen und geschäftlichen Ergebnisse für den Zielshop akzeptabel sind.