Der falsche Next-Cart Migration Service wird selten gewählt, weil die Servicenamen unklar wären. Häufiger wird die Entscheidung schlicht zu früh getroffen. Shopgröße, Preis, Zeitdruck oder der allgemeine Wunsch nach Unterstützung treten an die Stelle konkreter Nachweise über Daten, Zieldarstellung, Ausführungsaufwand und Abnahmestandard.
Eine belastbare Entscheidung folgt einer anderen Reihenfolge. Zuerst wird festgelegt, was die Migration erhalten muss. Danach wird geprüft, ob die Anforderung innerhalb unterstützten Verhaltens liegt, ob ein klar begrenztes Add-on ausreicht und wer die Ausführung verantwortungsvoll koordinieren kann. Der Preis wird erst dann wirklich aussagekräftig, wenn diese Fragen eine glaubwürdige Servicerichtung ergeben haben.
Diese Reihenfolge ist wichtig, weil die drei Next-Cart Migration Services unterschiedliche Probleme lösen. Standard Service unterstützt kundengeführte Ausführung innerhalb unterstützten Umfangs. Managed Service umfasst expertengestützte Ausführung innerhalb unterstützten Umfangs. Custom Service adressiert angepasste Anforderungen und kann kundengeführt sein oder Expert Handle enthalten.
Definieren Sie das gewünschte Ergebnis, bevor Sie Services vergleichen
Die Serviceeignung beginnt mit dem Geschäftsergebnis, nicht mit dem Servicenamen. Das Projekt sollte festlegen, welche Ergebnisse nach der Migration weiterhin gelten müssen, zum Beispiel:
- Products bleiben verständlich und kaufbar;
- Customer-Identität und Segmentierung bleiben nutzbar;
- Order-Historie unterstützt Service- und Reportinganforderungen;
- Content und URLs behalten ihren vorgesehenen Wert;
- kritische Beziehungen bleiben verbunden;
- externe Kennungen unterstützen weiterhin abhängige Systeme;
- der Zielshop kann anhand vereinbarter Nachweise validiert werden.
Diese Ergebnisse zeigen, was in den Quelldaten untersucht werden muss. Auch ein unterstützter Migrationspfad kann benutzerdefinierte Tabellen, von Anwendungen verwaltete Datensätze oder Zielplattformgrenzen enthalten, die die erforderliche Darstellung verändern. Ohne Ergebnisdefinition werden solche Unterschiede möglicherweise erst entdeckt, nachdem die Serviceentscheidung bereits Erwartungen gesetzt hat.
Die Entscheidung sollte migrierte Daten außerdem von der Implementierung auf der Zielplattform trennen. Eine Kennung zu übertragen ist eine Migrationsfrage. Die Integration zu implementieren und zu betreiben, die diese Kennung später verwendet, ist Implementierungsarbeit, sofern sie nicht ausdrücklich enthalten ist. Werden beide Ebenen vermischt, kann jedes Projekt unnötig individuell erscheinen oder ein unvollständiger Custom-Umfang entstehen.
Kapazität aus der Serviceeignungsentscheidung heraushalten
Entity Points beantworten die Frage, wie viel gezählte Kapazität für Products, Customers, Orders und Blog Posts benötigt wird. Sie messen nicht:
- strukturelle Komplexität;
- individuelle Logik;
- Drittanbieterabhängigkeiten;
- interne Ausführungskapazität;
- Implementierungsaufwand auf der Zielplattform;
- Validierungsaufwand.
Ein Shop mit 200,000 vorhersehbaren Datensätzen kann zu Standard Service passen, wenn das Team die Ausführung selbst führen kann. Ein Shop mit 500 Datensätzen kann Custom Service benötigen, wenn eine kleine Datengruppe proprietäre Preis- oder Auftragsabwicklungslogik trägt. Kapazität und Serviceeignung sollten getrennt berechnet und erst in der endgültigen Kaufentscheidung zusammengeführt werden.
Diese Trennung verhindert außerdem, dass der Preis den Umfang bestimmt. Ein kleinerer Kapazitätsplan reduziert den Preis nur dann sinnvoll, wenn der gezählte Bedarf tatsächlich hineinpasst. Er beseitigt keine individuelle Datenabhängigkeit und ändert nicht, wer für die Ausführung vorbereitet ist.
Prüfen Sie, ob die Anforderung unterstützt wird
Die erste Frage zur Serviceeignung lautet, ob das verfügbare Migrationsverhalten das gewünschte Ergebnis erzeugen kann.
Eine Anforderung bleibt eher im unterstützten Umfang, wenn:
- der Migrationspfad unterstützt wird;
- wichtige Datensätze vorhersehbare Plattformstrukturen verwenden;
- die Quellenbedeutung über verfügbare Zielfelder und Beziehungen abgebildet werden kann;
- Standardkonfiguration und Attribute Mapping die erforderliche Zuordnung abdecken;
- zusätzliche Filterung, Werttransformation oder Feldumleitung innerhalb eines Standard Add-on liegt;
- Abnahmenachweise ohne maßgeschneiderte Migrationslogik definiert werden können.
Custom Service sollte geprüft werden, wenn das erwartete Ergebnis von Folgendem abhängt:
- einer Custom Platform;
- benutzerdefinierten Feldern, Tabellen oder Datenbankstrukturen, deren erforderliche Behandlung über unterstützte Migration oder Standard Add-on hinausgeht;
- Daten, die Anwendungen, Plugins, Module oder Erweiterungen besitzen;
- Drittanbieterdatensätzen oder Kennungen externer Systeme;
- maßgeschneiderter Transformation, Umstrukturierung oder Beziehungslogik;
- einem Standard Add-on, das verändert werden muss;
- einem neuen projektspezifischen Add-on;
- einer Zieldarstellung, die individuell entworfen und vereinbart werden muss.
Die stärksten Nachweise sind konkret. „Der Shop hat individuelle Daten“ ist zu vage. „Vertragspreise liegen in einer benutzerdefinierten Tabelle, die über Customer-Gruppe und Product-SKU verknüpft ist, und der Zielshop muss diese kommerzielle Beziehung erhalten“ benennt Daten, Eigentum, Beziehung und gewünschtes Ergebnis.
Entscheiden Sie, ob ein Standard Add-on ausreicht
Ein Add-on kann ein unterstütztes Projekt innerhalb von Standard oder Managed Service halten, wenn das Problem klar begrenzt ist und die verfügbare Funktion passt.
| Benötigte Steuerung | Richtung des Standard Add-on | Zu prüfende Grenze |
|---|---|---|
| Festlegen, welche Datensätze einer Datenkategorie über feldbasierte Bedingungen migriert werden | Data Filter | Datenkategorie, Quellfeld, Bedingung sowie Include-/Exclude-Regel werden unterstützt |
| Ein unterstütztes Quellfeld einem kompatiblen Zielfeld neu zuordnen | Advanced Data Mapping | Quell- und Ziel-Datentypen, Beziehungen und nachgelagerte Nutzung bleiben gültig; Tax ist ausgeschlossen |
| Unterstützte Felder oder zugrunde liegende Datenbankspalten kompatiblen Zielfeldern oder Zielspalten zuordnen | Advanced Database Mapping | Quellplattform und Zielplattform sind beide Open-Source und Anforderungen an Feld/Spalte, Datentyp, Beziehung und nachgelagerte Nutzung bleiben unterstützt; Tax ist ausgeschlossen |
| Ausgewählte Zielfeldwerte während der Migration transformieren | Data Transformation | Ausdruck, Eingabewerte und zielkompatible Ergebnisse sind definiert |
Beim Add-on-Test sollte gefragt werden, ob das erwartete Ergebnis mit der verfügbaren Funktion klar beschrieben und erzeugt werden kann. Wenn die Funktion selbst verändert werden muss, wird daraus ein Tailored Add-on unter Custom Service. Wenn kein Standard Add-on die Anforderung abdeckt, kann ein Custom Add-on oder ein umfassenderer Custom-Umfang erforderlich sein.
Die Nutzung eines Add-on ist kein Beweis dafür, dass ein Projekt Custom ist. Der stärkere Custom-Hinweis liegt darin, dass das Add-on verändert werden muss, nicht unterstützte Daten interpretiert werden müssen oder projektspezifisches Verhalten entwickelt werden soll. Mehrere Standard Add-ons können kombiniert werden, wenn ein Ergebnis mehrere unterstützte Verarbeitungsschritte benötigt. Die Kombination allein macht den Migration Service nicht Custom.
Bewerten Sie den tatsächlichen Ausführungsaufwand
Sobald unterstützt oder angepasst geklärt ist, kann das Projekt entscheiden, wer die vereinbarten Migrationsaktionen ausführen soll.
Kundengeführte Ausführung erfordert mehr als die Fähigkeit, eine Aktion zu starten. Das Team muss in der Lage sein:
- erforderliche Zugänge und Quelleninformationen vorzubereiten;
- Konfigurationsentscheidungen zu verstehen;
- repräsentative Demo-Nachweise auszuwählen;
- das Migrationsfenster zu koordinieren;
- auf Fehlschläge oder unerwartete Ergebnisse zu reagieren;
- Business-, SEO-, technische und operative Prüfer einzubeziehen;
- die abschließende Abnahme zu dokumentieren.
Wenn die Migration unterstützt bleibt und das interne Team diese Arbeit leisten kann, kann Standard Service passen. Wenn der unterstützte Umfang weiterhin passt, aber die Ausführung enthalten sein soll, kann Managed Service geeigneter sein.
Wenn angepasste Arbeit erforderlich ist, gilt Custom Service unabhängig davon, wer ausführt. Das Projekt kann kundengeführt bleiben oder Expert Handle enthalten. Expert Handle sollte gewählt werden, weil die Ausführungsverantwortung enthalten sein muss, nicht weil der Begriff „custom“ automatisch als vollständig gemanagt verstanden wird.
Nutzen Sie Demo Migration, um Annahmen zu prüfen
Demo Migration ist besonders wertvoll, wenn sie die Annahmen testet, die die Serviceentscheidung verändern würden. Eine Stichprobe nur aus einfachen Products und gewöhnlichen Orders kann grundlegendes Übertragungsverhalten bestätigen und zugleich das eigentliche Risiko unberührt lassen.
Repräsentative Nachweise können enthalten:
- ein Product mit komplexen Varianten oder benutzerdefinierten Attributen;
- einen Customer, dessen Gruppe Preis oder Sichtbarkeit beeinflusst;
- eine Order mit Erstattungen, ungewöhnlicher Statushistorie oder externen Referenzen;
- Content mit wichtigem URL- oder SEO-Wert;
- Datensätze, die wahrscheinlich Filter-, Transformations- oder Mapping-Bedarf sichtbar machen;
- ein benutzerdefiniertes Feld oder einen Drittanbieterdatensatz, dessen erforderliche Behandlung gegen unterstützte Mapping- oder angepasste Umfangsgrenzen geprüft werden muss.
Demo Migration kann konfigurierte Add-ons oder Customization nicht validieren, weil diese Funktionen in der Demo nicht verfügbar sind. Sie kann die Anforderung dennoch sichtbar machen und zeigen, wo weitere Nachweise benötigt werden.
Die Interpretation sollte diszipliniert erfolgen:
- ein vorhersehbares unterstütztes Ergebnis stärkt Standard oder Managed Service;
- ein unterstütztes Ergebnis bei unzureichender interner Ausführungskapazität stärkt Managed Service;
- nicht unterstützte Struktur, maßgeschneiderte Transformation oder ungeklärte Beziehungslogik stärkt Custom Service;
- eine nicht repräsentative Stichprobe stützt keine belastbare Serviceentscheidung.
Vergleichen Sie die Services erst nach Aufbau der Nachweise
Erst wenn Umfang und Ausführung untersucht wurden, wird eine Vergleichstabelle wirklich nützlich.
| Nachweismuster | Wahrscheinliche Richtung | Begründung |
|---|---|---|
| Unterstützter Pfad und unterstützte Strukturen; Standard Add-ons reichen aus; Team kann ausführen und validieren | Standard Service | Kundengeführte unterstützte Migration ist glaubwürdig |
| Unterstützter Pfad und unterstützte Strukturen; Standard Add-ons reichen aus; expertengestützte Ausführung ist erforderlich | Managed Service | Die fehlende Komponente ist Ausführungsverantwortung |
| Angepasste oder nicht standardmäßige Behandlung ist erforderlich; Team kann ausführen und validieren | Kundengeführter Custom Service | Custom-Funktion wird benötigt, aber nicht Expert Handle |
| Angepasste oder nicht standardmäßige Behandlung ist erforderlich; expertengestützte Ausführung wird ebenfalls benötigt | Custom Service with Expert Handle | Custom-Umfang und Ausführungsverantwortung müssen enthalten sein |
Dies ist ein Entscheidungsrahmen und kein automatisches Scoring-System. Eine einzige kritische Custom-Abhängigkeit kann viele standardmäßige Datensätze überwiegen. Ein starkes internes Team kann Standard Service für eine große unterstützte Migration passend machen. Die Qualität der Nachweise ist wichtiger als die Anzahl der Merkmale, die scheinbar für eine Option sprechen.
Prüfen Sie den Preis erst nach der Serviceeignung
Der Preis setzt sich aus Entity-Points-Kapazität, Migration Service, gekauften Add-ons und individuell vereinbarter Arbeit zusammen. Wer angezeigte Beträge vergleicht, bevor die Serviceeignung geklärt ist, kann eine falsche Sparlogik erzeugen.
Eine sinnvolle Reihenfolge ist:
- realistische Entity-Points-Kapazität berechnen;
- feststellen, ob das gewünschte Ergebnis unterstützt oder individuell ist;
- Ausführungsverantwortung zuweisen;
- Standard, Tailored oder Custom Add-ons identifizieren;
- den passenden Planpreis und gegebenenfalls das Custom-Angebot prüfen.
Custom Service zeigt den Standard-Service-Preis des ausgewählten Entity Points Plan als Ausgangsbasis. Der Endbetrag hängt von der vereinbarten Custom-Arbeit, gekauften Add-ons, sofern relevant, Expert Handle, wenn enthalten, und weiteren vereinbarten umfangsspezifischen Kosten ab. Der Startbetrag sollte nicht mit einem festen Standard- oder Managed-Preis verglichen werden, als würden alle drei Zahlen denselben Leistungsumfang beschreiben.
Auch der Upgrade-Pfad sollte die Entscheidung unterstützen, aber Nachweise nicht ersetzen. Standard kann später zu Managed oder Custom wechseln, Managed später zu Custom. Ein gekaufter Migration Service kann nicht herabgestuft werden. Ein zulässiges Upgrade wird Teil derselben Migration und nur die zusätzliche Differenz wird berechnet. Der feste Pfad und die ursprüngliche einjährige Dauer ändern sich dadurch nicht.
Dokumentieren Sie, warum die Entscheidung belastbar ist
Eine Serviceentscheidung sollte auch später nachvollziehbar bleiben. Die Begründung sollte festhalten:
- die erforderlichen Geschäftsergebnisse;
- warum Migrationspfad und wichtige Strukturen als unterstützt oder individuell eingestuft werden;
- welche klar begrenzten Anforderungen in Standard Add-ons passen;
- welche Anforderungen angepasste Arbeit benötigen;
- wer die Migrationsaktionen ausführt;
- was Demo Migration bewiesen hat und was nicht;
- welche Implementierung auf der Zielplattform separat bleibt;
- welche Nachweise die abschließende Abnahme tragen.
Diese Dokumentation wird wertvoll, wenn sich das Projekt verändert. Werden neue individuelle Daten entdeckt oder verliert das interne Team Ausführungskapazität, kann der Service anhand der ursprünglichen Begründung neu bewertet werden. Die Entscheidung ändert sich dann, weil sich die Nachweise geändert haben, nicht weil das Projekt zufällig in Richtung eines anderen Labels driftet.
Fazit
Der richtige Next-Cart Migration Service ist das Ergebnis von Nachweisen, nicht eine Abkürzung anhand von Shopgröße, Preis oder wahrgenommener Servicestufe. Definieren Sie das gewünschte Ergebnis, trennen Sie Kapazität von Komplexität, prüfen Sie den unterstützten Umfang, entscheiden Sie, ob ein Standard Add-on ausreicht, und weisen Sie die Ausführungsverantwortung zu.
Wählen Sie Standard Service für kundengeführte Ausführung innerhalb unterstützten Umfangs. Wählen Sie Managed Service, wenn der unterstützte Umfang weiterhin passt und expertengestützte Ausführung erforderlich ist. Wählen Sie Custom Service, wenn das erwartete Ergebnis eine angepasste Behandlung benötigt, und nehmen Sie Expert Handle nur auf, wenn die Ausführungsverantwortung ebenfalls Teil des akzeptierten Custom-Umfangs sein muss.
Häufige Fragen
Kann ein großer Shop Standard Service nutzen?
Ja. Ein großer Shop kann zu Standard Service passen, wenn Pfad und Anforderungen unterstützt bleiben und der Kunde Ausführung und Validierung koordinieren kann.
Wann ist Managed Service geeigneter als Standard Service?
Managed Service ist geeigneter, wenn die Migration innerhalb unterstützten Umfangs bleibt, aber die vereinbarten Migrationsaktionen expertengestützt ausgeführt werden sollen.
Was ist das stärkste Signal für Custom Service?
Das stärkste Signal ist ein erforderliches Ergebnis, das mit unterstütztem Migrationsverhalten und verfügbaren Standard Add-ons nicht erzeugt werden kann, etwa maßgeschneiderte Logik, nicht unterstützte Daten oder eine projektspezifische Zieldarstellung.
Können Add-ons Custom Service ersetzen?
Nur wenn die klar begrenzte Anforderung in den verfügbaren Standard-Add-on-Umfang passt. Mehrere Standard Add-ons können gemeinsam ohne Custom Service eingesetzt werden, wenn jede Operation unterstützt bleibt. Veränderte Add-ons, neues Add-on-Verhalten, nicht unterstützte Datensätze und maßgeschneiderte Beziehungen benötigen eine Custom-Service-Prüfung.
Bestimmen Entity Points den Migration Service?
Nein. Entity Points bestimmen gezählte Kapazität. Der Migration Service hängt von unterstütztem Umfang, Ausführungsverantwortung, Add-on-Bedarf, angepassten Anforderungen und Abnahmenachweisen ab.
Sollte der Preis vor Demo Migration verglichen werden?
Der Preis kann früher geschätzt werden, sollte die Serviceentscheidung aber nicht bestimmen, bevor repräsentative Nachweise die Annahmen zu unterstütztem Umfang und Ausführungsverantwortung geprüft haben.
Kann der Migration Service nach dem Kauf geändert werden?
Nur nach oben. Standard kann zu Managed oder Custom wechseln, Managed zu Custom. Der Kunde zahlt die zusätzliche Differenz, während Pfad und ursprüngliche Servicedauer unverändert bleiben.