Nicht standardmäßige Migrationsanforderungen sind aus einem Grund schwierig, den reine Datensatzmengen nicht zeigen können: Die Daten tragen häufig eine Bedeutung, die sich aus dem Feldnamen allein nicht erkennen lässt. Ein benutzerdefinierter Product-Wert kann Suche, Preisbildung oder Auftragsabwicklung steuern. Eine externe Order-Kennung kann den Shop mit der Buchhaltung verbinden. Ein von einer Anwendung verwalteter Datensatz kann ein Abonnement, einen Loyalty-Saldo, einen Marketplace-Verkäufer oder einen operativen Ablauf darstellen.
Wird nur der Wert übertragen, ohne diese Rolle zu verstehen, kann ein Zielshop entstehen, der vollständig aussieht, aber die geschäftlichen Abläufe nicht mehr unterstützt. Innerhalb der Next-Cart Migration Services schließt Custom Service diese Lücke, indem eine nicht standardmäßige Anforderung in ein vereinbartes Migrationsergebnis übersetzt wird, mit definierten Quelldaten, vorgesehener Zieldarstellung, angepasster Arbeit und Abnahmekriterien.
Das Ziel besteht nicht darin, ein gesamtes Projekt pauschal als Custom zu bezeichnen. Es geht darum, genau die Bereiche zu identifizieren, in denen unterstütztes Verhalten und Standard Add-ons nicht ausreichen, und anschließend zu definieren, was ein praktikables migriertes Ergebnis bedeuten soll.
Ermitteln Sie, warum die Anforderung nicht standardmäßig ist
Eine Anforderung kann wegen ihrer Quelle, Struktur, Logik, Beziehung oder Zieldarstellung Custom Service benötigen.
| Ursache der Schwierigkeit | Grundlegende Frage |
|---|---|
| Custom Platform | Wie lässt sich das Quell- oder Zieldatenmodell verstehen und zugänglich machen? |
| Benutzerdefinierte Felder oder Tabellen | Welche geschäftliche Bedeutung tragen die Werte und welchen Datensätzen gehören sie? |
| Daten aus Anwendung, Plugin, Modul oder Erweiterung | Sind die Daten maßgeblich und welcher zukünftige Ablauf benötigt sie? |
| Externe Kennungen | Welche Systembeziehung muss nach der Migration erhalten bleiben? |
| Maßgeschneiderte Transformation | Wie sollen Werte oder Datensätze zusammengeführt, aufgeteilt, normalisiert oder neu strukturiert werden? |
| Nicht standardmäßige Beziehungen | Wie sollen Besitzverhältnisse und Referenzen auf der Zielplattform dargestellt werden? |
| Verändertes oder neues Add-on-Verhalten | Warum kann das verfügbare Standard Add-on das erforderliche Ergebnis nicht liefern? |
| Grenze der Zielplattform | Was ist die praktikabelste Darstellung und welche Implementierung bleibt separat? |
Diese Fragen machen den Custom-Umfang nachvollziehbar. „Alle individuellen Daten migrieren“ tut das nicht. Eine brauchbare Anforderung benennt die betroffenen Datensätze, den fortbestehenden Geschäftszweck, das erwartete Ergebnis im Zielshop und den Nachweis, mit dem der Erfolg bestätigt wird.
Arbeit an einer Custom Platform beginnt mit dem Datenmodell
Eine Custom Platform kann Quellplattform, Zielplattform oder beides sein. Die Herausforderung besteht nicht nur darin, Zugriff herzustellen. Die Migration muss verstehen, wie der Shop Products, Customers, Orders, Content, Beziehungen und unterstützende Strukturen abbildet.
Nützliche Quelleninformationen können enthalten:
- Schema- oder Exportbeschreibungen;
- repräsentative Products, Customers, Orders und Content;
- Primär- und Fremdschlüssel;
- Category- und Navigationsbeziehungen;
- benutzerdefinierte Status- oder Typwerte;
- Medien- und Dateireferenzen;
- Informationen zu externen Systemen;
- Beispiele für Geschäftsergebnisse, die fortbestehen müssen.
Anschließend sollte diese Quellenbedeutung mit den Möglichkeiten der Zielplattform verglichen werden. Manche Datensätze haben direkte Entsprechungen. Andere benötigen Transformation, Feldmapping, eine individuelle Zielstruktur oder einen Ausschluss mit dokumentierter Alternative.
Custom Service macht nicht jede Zieldarstellung möglich. Er schafft einen strukturierten Weg, festzustellen, was migriert werden kann, was sich ändern muss und welches Ergebnis der Kunde erwarten sollte.
Drittanbieterdaten als Eigentumsfrage behandeln
Shops hängen häufig von Daten ab, die durch Anwendungen, Plugins, Module, Erweiterungen oder verbundene Services erzeugt werden. Das Vorhandensein einer Tabelle oder eines Felds beweist nicht, dass diese Daten migriert werden sollten. Manche Datensätze sind maßgeblich. Andere sind Caches, Logs, abgeleitete Werte oder Überreste aufgegebener Funktionen.
Die Custom-Prüfung sollte feststellen:
- welches System die Daten besitzt;
- welcher Geschäftsprozess sie verwendet;
- ob sie weiterhin maßgeblich sind;
- zu welchem migrierten Datensatz sie gehören;
- was der Zielshop oder das verbundene System mit ihnen tun soll;
- wie das Ergebnis validiert wird.
Diese Eigentumsprüfung ist zuverlässiger, als jedes nicht standardmäßige Feld einfach zu kopieren. Daten ohne zukünftigen Besitzer können Unordnung oder Konflikte erzeugen. Daten mit fortbestehender operativer Rolle können dagegen kritisch sein, selbst wenn sie nur in einem einzigen Feld gespeichert sind.
Beispiele sind:
- Abonnementkennungen, die mit Products oder Customers verbunden sind;
- Loyalty-Salden, die mit Customer-Identitäten verbunden sind;
- Marketplace-Verkäuferzuordnung für Products und Orders;
- Referenzen der Auftragsabwicklung, die mit Order-Positionen verbunden sind;
- PIM-Kennungen, die mit Product-Datensätzen verbunden sind;
- Reporting-Klassifizierungen, die mit Products, Customers oder Orders verbunden sind.
Externe Kennungen über ihre Beziehungen erhalten
Eine externe Kennung ist nur dann nützlich, wenn ihre Beziehung erhalten bleibt. Eine ERP-Product-ID in ein beliebiges Textfeld zu kopieren kann zwar die Zeichenfolge erhalten, aber den Prozess zerstören, der von ihr abhängt.
Der Custom-Umfang sollte definieren:
- das System, das die Kennung besitzt;
- den migrierten Datensatz, auf den sie verweist;
- Anforderungen an Eindeutigkeit und Format;
- ob sich der Wert ändern darf;
- das kompatible Ziel;
- den Integrations- oder Reportingprozess, der die Kennung später nutzt;
- die Nachweise, mit denen die Beziehung bestätigt wird.
Das Erhalten einer Order-Referenz kann beispielsweise mehr erfordern, als nur den Wert im Order-Header zu übertragen. Kundenservice, Auftragsabwicklung oder Buchhaltung können darauf angewiesen sein, dass die Referenz mit der richtigen Order, den richtigen Positionen und dem historischen Kontext verbunden bleibt.
Das Deployment einer Integration bleibt separat, sofern es nicht ausdrücklich enthalten ist. Custom Service kann die migrationsseitigen Daten und Beziehungen erhalten, die im akzeptierten Umfang definiert sind. Er baut oder betreibt nicht automatisch jedes System, das diese Daten später nutzt.
Maßgeschneiderte Transformation über Bedeutung definieren
Individuelle Migrationslogik kann notwendig sein, wenn Standardverhalten das beabsichtigte Ergebnis nicht erzeugen kann. Typische Muster sind:
- mehrere Quellfelder in einem Zielfeld zusammenführen;
- einen Quellwert auf mehrere Zielfelder aufteilen;
- inkonsistente Werte normalisieren;
- Quellstatus in Zielstatus überführen;
- von Anwendungen verwaltete Datensätze umformen;
- nicht standardmäßige Beziehungen erhalten;
- Datensätze über projektspezifische Kennungen abgleichen;
- Regeln anwenden, die über Standard Add-ons nicht verfügbar sind.
Die Transformation sollte als Regel mit Beispielen und Ausnahmen beschrieben werden.
Schwache Anforderung:
Order-Status korrigieren.
Stärkere Anforderung:
Jeden freigegebenen Quell-Order-Status in den definierten Zielstatus überführen, den ursprünglichen Quellstatus für Audit-Zwecke erhalten, sofern vereinbart, und Beispiele aus abgeschlossenen, stornierten, erstatteten und teilweise abgewickelten Orders validieren.
Die stärkere Anforderung erklärt Quellbedingung, Zielergebnis und Nachweis. Sie lässt sich abgrenzen, anbieten, implementieren und abnehmen.
Erkennen, wann ein Add-on zu Custom wird
Standard Add-ons lösen klar begrenzte unterstützte Anforderungen:
- Data Filter wählt Datensätze aus, indem feldbasierte Bedingungen pro Datenkategorie angewendet 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, aber nur wenn sowohl Quellplattform als auch Zielplattform Open-Source sind;
- Data Transformation transformiert ausgewählte Zielfeldwerte während der Migration.
Custom Service wird relevant, wenn:
- ein Standard Add-on verändert werden muss und dadurch ein Tailored Add-on entsteht;
- kein Standard Add-on passt und ein Custom Add-on benötigt wird;
- die zugrunde liegenden Datensätze oder Beziehungen nicht unterstützt sind;
- die Anforderung maßgeschneiderte Logik außerhalb des verfügbaren Add-on-Verhaltens benötigt.
Ein Add-on kann weiterhin Teil eines Custom-Service-Projekts sein. Das Add-on adressiert eine fokussierte Funktion, während Custom Service das umfassendere nicht standardmäßige Ergebnis definiert.
Den Umfang um Nachweise herum aufbauen
Eine Custom-Service-Anfrage sollte genügend Informationen liefern, um Machbarkeit und Abnahme definieren zu können.
| Nachweis | Warum er wichtig ist |
|---|---|
| Details zu Quell- und Zielplattform | Legt Migrationspfad und Plattformkontext fest |
| Repräsentative Quelldatensätze | Zeigt tatsächliche Werte, Strukturen und Beziehungen |
| Datenbesitzer und Geschäftszweck | Erklärt, warum die nicht standardmäßigen Daten erhalten werden sollen |
| Erwartetes Ergebnis im Zielshop | Definiert die erforderliche Darstellung |
| Transformations- oder Abgleichsregeln | Macht angepasste Logik überprüfbar |
| Zugehörige Anwendungen oder externe Systeme | Zeigt Abhängigkeiten außerhalb standardmäßiger Plattformdatensätze |
| Ausnahmen und Fehlerfälle | Verhindert, dass der Umfang nur ideale Datensätze abdeckt |
| Validierungsstichproben und Verantwortliche | Legt fest, wie über die Abnahme entschieden wird |
| Entity Points Plan und gekaufte Add-ons | Trennt Kapazität und bestehende Erweiterungen von neuer Custom-Arbeit |
Die Nachweise sollten schwierige Fälle enthalten, nicht nur saubere Beispiele. Eine individuelle Regel, die für gewöhnliche Products funktioniert, kann bei Products mit fehlenden Kennungen, doppelten Werten oder ungewöhnlichen Beziehungen scheitern.
Der akzeptierte Umfang sollte festhalten, was extrahiert, transformiert, verknüpft oder geliefert wird. Außerdem sollte er benennen, was ausgeschlossen ist, was von den Möglichkeiten der Zielplattform abhängt und welche Implementierungsverantwortung separat bleibt.
Migrationsbehandlung von Zielimplementierung trennen
Custom Service kann angepasste Migrationsbehandlung definieren. Er umfasst nicht automatisch:
- Theme- oder Storefront-Design;
- Installation von Anwendungen oder Erweiterungen;
- Entwicklung und Deployment von Integrationen;
- Einrichtung von Zahlung, Versand, Steuern oder E-Mail;
- vollständige Rekonstruktion von Workflows;
- operative Konfiguration;
- jede Quellfunktion, die die Zielplattform nicht unterstützen kann.
Diese Trennung ist nicht nur vertraglich relevant. Sie schützt die Migrationsentscheidung. Ein Datensatz kann korrekt migriert sein, obwohl der Zielprozess, der ihn verwendet, noch nicht implementiert ist. Umgekehrt kann eine Zielanwendung installiert sein, obwohl die Migration die benötigten Daten nicht erhalten hat.
Der Umfang sollte die Übergabe sichtbar machen. Beispielsweise kann eine externe Kennung in ein vereinbartes Zielfeld migriert werden, während separate Integrationsarbeit dieses Feld mit dem ERP verbindet.
Realistische Erwartungen an Plattformunterschiede setzen
Custom Service kann zwei Plattformen nicht zwingen, sich identisch zu verhalten. Product-Optionen, Customer-Gruppen, Order-Status, Content-Hierarchien, URLs und Anwendungsdaten besitzen möglicherweise keine direkte Zielentsprechung.
Ein praktikables Ergebnis kann sein:
- direkte Erhaltung;
- Transformation in eine von der Zielplattform unterstützte Struktur;
- Mapping auf Feldebene;
- teilweise Erhaltung der geschäftlichen Bedeutung;
- Export zur separaten Nutzung;
- Ausschluss mit dokumentiertem Ersatzplan.
Das passende Ergebnis hängt vom Geschäftszweck und den Möglichkeiten der Zielplattform ab. Exakte Nachbildung ist nicht immer das stärkste Ziel. Eine einfachere Zieldarstellung kann besser sein, wenn sie das benötigte Ergebnis erhält, ohne veraltete Quelllogik mitzunehmen.
Umfang, Ausführung und Preis getrennt verstehen
Custom Service definiert maßgeschneiderte Arbeit. Expert Handle definiert, ob die expertengestützte Ausführung der vereinbarten Migrationsaktionen ebenfalls enthalten ist.
Ein Custom-Service-Projekt kann deshalb sein:
- kundengeführt, wobei die angepasste Arbeit enthalten ist und der Kunde die Migrationsaktionen ausführt; oder
- expertengestützt, wobei Expert Handle Teil des akzeptierten Umfangs ist.
Der angezeigte Custom-Service-Betrag beginnt mit dem Preis von Standard Service für den gewählten Entity Points Plan. Dieser Betrag legt die Kapazitätsuntergrenze fest. Der Endpreis ergänzt das vereinbarte Angebot für individuelle Arbeiten, gekaufte Add-ons, sofern relevant, Expert Handle, wenn enthalten, und weitere akzeptierte umfangsspezifische Kosten.
Wenn individuelle Arbeit zu einer bereits gekauften Migration ergänzt wird, verändert das akzeptierte Angebot den Gesamtwert der Migration. Bereits gezahlte Beträge bleiben berücksichtigt und nur die zusätzliche Differenz wird berechnet. Dasselbe Prinzip gilt für Tailored und Custom Add-ons.
Ein verantwortbarer Endpreis kann erst bestimmt werden, wenn das nicht standardmäßige Ergebnis klar genug abgegrenzt ist. Die Annahme und der Kauf des angebotenen Upgrades integrieren die Arbeit in dieselbe Migration. Dadurch entsteht weder ein neuer Pfad noch verlängert sich die einjährige Servicedauer.
Das angepasste Ergebnis validieren
Individuelle Arbeit benötigt individuelle Abnahmenachweise. Allgemeine Mengenprüfungen reichen nicht aus, wenn die Anforderung von Bedeutung, Transformation oder Beziehungen abhängt.
Die Validierung sollte Folgendes vergleichen:
- Quellbeispiel;
- vereinbarte Transformations- oder Behandlungsregel;
- Darstellung im Zielshop;
- verknüpfte Datensätze oder externe Kennungen;
- erwartete Geschäftsfunktion;
- Behandlung von Ausnahmen;
- Pass-, Watch- oder Block-Entscheidung.
Die Verantwortung für die abschließende Verifikation bleibt beim Kunden. Gerade bei individueller Arbeit ist das wichtig, weil der Abnahmestandard häufig von Geschäftswissen abhängt, das sich nicht allein aus dem Quellschema ableiten lässt.
Eine Watch-Entscheidung sollte die verbleibende Unsicherheit, ihre geschäftliche Folge, den noch benötigten Nachweis und die für die Klärung verantwortliche Person benennen. Ohne diese Interpretation wird die Custom-Validierung zu einer Liste von Beobachtungen statt zu einer belastbaren Abnahmeentscheidung.
Fazit
Next-Cart Custom Service behandelt die Teile einer Migration, die individuelle Interpretation, angepasste Logik, veränderte Add-ons, Custom-Platform-Analyse, nicht standardmäßige Beziehungen oder eine geplante Zieldarstellung erfordern.
Ein belastbarer Custom-Umfang beginnt mit Bedeutung und Nachweisen. Er identifiziert, wem die Daten gehören, welcher Geschäftszweck fortbesteht, wie der Zielshop das Ergebnis darstellen soll, welche Migrationsarbeit erforderlich ist, welche Implementierung separat bleibt und wie die Abnahme nachgewiesen wird.
Custom Service ist kein Versprechen, jedes Quellverhalten exakt nachzubilden. Er ist ein strukturierter Weg, das bestmögliche praktikable und überprüfbare Ergebnis zu erreichen, wenn unterstütztes Verhalten und Standard Add-ons nicht ausreichen.
Häufige Fragen
Ist Custom Service nur für Custom Platforms gedacht?
Nein. Er gilt auch für benutzerdefinierte Felder, Drittanbieterdaten, externe Kennungen, maßgeschneiderte Logik, Tailored Add-ons, Custom Add-ons und andere nicht standardmäßige Anforderungen.
Benötigt jedes benutzerdefinierte Feld Custom Service?
Nicht automatisch. Die Entscheidung hängt davon ab, ob das Feld unterstützt wird, welche geschäftliche Bedeutung es trägt, wo es dargestellt werden soll und ob die verfügbaren Mapping-Funktionen ausreichen.
Wie unterscheidet sich Custom Service von einem Standard Add-on?
Ein Standard Add-on löst eine klar begrenzte unterstützte Filter-, Transformations- oder Feldmapping-Anforderung. Custom Service adressiert veränderte, nicht unterstützte oder maßgeschneiderte Anforderungen, die einen individuellen Umfang benötigen.
Enthält Custom Service immer Expert Handle?
Nein. Das Projekt kann kundengeführt bleiben. Expert Handle wird nur aufgenommen, wenn expertengestützte Ausführung Teil des akzeptierten Custom-Umfangs ist.
Kann Custom Service jedes Quellverhalten exakt reproduzieren?
Nein. Das Ergebnis hängt vom Zustand der Quelldaten, den Möglichkeiten der Zielplattform, dem akzeptierten Umfang und den für die Kundenfreigabe erforderlichen Nachweisen ab.
Welche Nachweise werden für eine Custom-Service-Anfrage benötigt?
Benötigt werden repräsentative Datensätze, Eigentum und Geschäftszweck, beabsichtigte Zieldarstellung, Transformations- oder Beziehungsregeln, Ausnahmen, zugehörige Systeme und Validierungsbeispiele.
Ist die Implementierung auf der Zielplattform automatisch enthalten?
Nein. Design, Installation von Anwendungen, Deployment von Integrationen und operative Konfiguration bleiben separat, sofern sie nicht ausdrücklich im akzeptierten Umfang enthalten sind.
Warum ist der Custom-Service-Betrag ein Startpreis?
Er legt die Kapazitätsuntergrenze von Standard Service für den ausgewählten Entity Points Plan fest. Der Endpreis hängt von vereinbarter Custom-Arbeit, Add-ons, Expert Handle, sofern enthalten, und weiteren akzeptierten umfangsspezifischen Kosten ab. Bei später akzeptierter Arbeit bleibt der bereits gezahlte Betrag berücksichtigt und nur die zusätzliche Differenz wird berechnet.