Wenn osCMax als mögliche Zielplattform bewertet wird, sollte der Migrationsansatz zur Komplexität des Quellshops, zum gewählten osCMax-Zielaufbau, zum unterstützten Umfang der Next-Cart Migrationsservices, zur gewünschten Verantwortungsstufe und zum Validierungsaufwand passen. Die Entscheidung hängt nicht allein von der Bezeichnung der Altplattform ab, sondern davon, was im Ziel dargestellt werden muss und wie viel unterstützte Behandlung dafür erforderlich ist.
Ein geradliniges Projekt kann zu Standard Service passen, wenn unterstützte Datensätze ohne individuelle Zielstrukturen dargestellt werden können. Managed Service ergänzt Ausführungsverantwortung und Koordination, wenn der Umfang unterstützt bleibt, die Validierung aber anspruchsvoll ist. Bei osCMax können klar abgegrenzte Anforderungen Data Filter, Advanced Data Mapping oder Data Transformation nutzen, sofern sie unterstützt werden. Ein Custom Field allein macht aus dem Projekt noch keinen Custom-Service-Fall.
Custom Service gehört zu tatsächlich nicht unterstützten oder individuellen Anforderungen, etwa nicht standardisierten Datensätzen, individuellen Zielstrukturen, Contribution-eigenen Daten ohne unterstützten Behandlungsweg oder Transformationslogik außerhalb des Standardumfangs. Demo Migration sollte die repräsentativen Quellmuster prüfen, die zeigen, ob das geplante osCMax-Ziel und der gewählte Serviceansatz vor Full Migration belastbar sind.
Mit dem Migrationsumfang beginnen, nicht mit dem Servicenamen
Zuerst muss beschrieben werden, was übertragen werden soll und was nach der Migration weiter funktionieren muss. Products, Customers, Orders, Categories, Reviews, Coupons, CMS Pages und Blog Posts können zulässige Datenbereiche sein, der osCMax-Umfang kann jedoch über diese Bezeichnungen hinausgehen. Ein Product kann Attribute, individuelle Felder, Bildkonventionen, Specials oder Contribution-gesteuerte Darstellung enthalten. Eine Order kann Zahlungsbezeichnungen, Versandreferenzen, individuelle Exportfelder, Customer-Group-Kontext oder veränderte Statusbedeutung tragen.
Der Servicepfad sollte erst gewählt werden, nachdem der Shop in vier Gruppen aufgeteilt wurde:
- Standarddatensätze, die über unterstütztes Verhalten migriert werden können;
- Datensätze, die Filterung, Mapping oder Konfigurationsanpassung benötigen;
- Verhalten auf der Zielseite, das außerhalb der Datenmigration konfiguriert oder neu aufgebaut werden muss;
- individuelle oder Contribution-eigene Daten, die eine maßgeschneiderte Prüfung erfordern.
Diese Trennung verhindert, dass Standard Service mit altem Individualverhalten überladen wird. Gleichzeitig verhindert sie, dass Custom Service unnötig eingesetzt wird, wenn lediglich eine klar begrenzte Bedingung für eine Datenkategorie, eine unterstützte Werttransformation oder ein anderes unterstütztes Zielfeld benötigt wird.
| Signal aus dem Umfang | Wahrscheinliche Servicewirkung | Was bestätigt werden muss |
|---|---|---|
| Saubere Products, Customers und Orders | Standard Service kann ausreichen. | Vollständigkeit der Felder und Genauigkeit der Stichproben bestätigen. |
| Viele Datensätze bei standardisierter Struktur | Managed Service kann größere Ausführung und Validierung koordinieren. | Timing, Umfang und Launch-Verantwortung bestätigen. |
| Datenkategorie-spezifische Bedingung, unterstützte Feldwert-Transformation oder kompatibles Zielfeld für ein unterstütztes Quellfeld | Data Filter, Advanced Data Mapping oder Data Transformation können den abgegrenzten Bedarf unterstützen. | Unterstützte Datenkategorien, Felder, Ausdrücke und Ziele bestätigen. |
| Contribution-eigene Tabellen oder individuelle Felder, deren benötigte Behandlung den unterstützten Mapping-Umfang überschreitet | Custom Service kann erforderlich sein. | Datenort, Geschäftsbedeutung und Zielerwartung bestätigen. |
| Alte Module oder Template-Logik müssen weitergeführt werden | Kann Ersatz auf der Zielseite oder Prüfung über Custom Service erfordern. | Datenmigration von Zielimplementierung trennen. |
Die beste Ausgangsfrage lautet nicht, welcher Service am stärksten klingt, sondern welche Nachweise den tatsächlichen Migrationsumfang des Shops belegen.
Wann Standard Service gut passt
Standard Service ist geeignet, wenn die osCMax-Migration überwiegend unterstützte Core-Datensätze umfasst und der Händler akzeptiert, dass Zielkonfiguration, Theme-Implementierung, App-Installation und individuelle Entwicklung von der Datenmigration getrennt sind. Dies kann für Shops mit klaren Categories, Products, Customers, Orders, Reviews, Coupons, CMS Pages und anderen zulässigen Daten gelten, die nicht stark von Custom Tables oder Legacy-Contribution-Logik abhängen.
Auch bei osCMax sollte Standard Service bewusst gewählt werden. Ein Shop kann in der Storefront standardisiert wirken und dennoch alte Module oder individuelle Felder in der Datenbank verbergen. Bevor Standard Service als ausreichend gilt, sollte bestätigt sein, dass der wesentliche Geschäftswert in übertragbaren Datensätzen liegt und nicht in Contribution-eigenem Verhalten.
Standard Service ist besonders passend, wenn:
- die Shop-Version bekannt ist;
- die Datenbankstruktur verständlich ist;
- Products und Orders überwiegend erwartete Felder verwenden;
- Templates nicht als Migrationsdeliverable betrachtet werden;
- alte Module auf der Zielplattform nicht identisch weiterarbeiten müssen;
- Validierungsstichproben zeigen, dass migrierte Datensätze ihre Geschäftsbedeutung behalten.
Das Entscheidungssignal ist klar: Standard Service passt, wenn das Migrationsziel die Übertragung unterstützter Daten ist und nicht die Rekonstruktion der alten osCMax-Umgebung.
Wann Managed Service zusätzlichen Nutzen bringt
Managed Service ist sinnvoll, wenn der Händler Koordination, Unterstützung bei der Migrationsplanung, Umfangskontrolle und geführte Validierung benötigt. Er macht nicht jedes nicht unterstützte Legacy-Verhalten zu einem Standarddeliverable, hilft aber bei Projekten, in denen Nachweise geprüft, Entscheidungen in Reihenfolge getroffen und Ergebnisse diszipliniert validiert werden müssen.
Bei osCMax ist Managed Service häufig sinnvoll, wenn der Shop älter ist, mehrere Contributions besitzt, eine unsichere Datenqualität aufweist oder technische und geschäftliche Stakeholder koordiniert werden müssen. Nicht jeder Bereich braucht eine maßgeschneiderte Transformation, doch das Team kann Unterstützung dabei benötigen, was migriert, ausgeschlossen, gemappt und vor Full Migration validiert werden soll.
Managed Service ist besonders hilfreich, wenn:
- der Händler einen großen Katalog oder umfangreiche Order-Historie besitzt;
- Versionsnachweise vorhanden sind, ältere Änderungen aber interpretiert werden müssen;
- mehrere Stakeholder Katalog-, Customer-, Order-, Inhalts- und SEO-Ergebnisse freigeben müssen;
- Erkenntnisse aus der Demo Migration Mapping- oder Konfigurationsentscheidungen beeinflussen sollen;
- der Launch-Termin eine strukturierte Prüfung statt spontaner Einzelkontrollen verlangt.
| Bedarf an Managed Service | osCMax-Beispiel | Planungsnutzen |
|---|---|---|
| Umfangskoordinierung | Manche Contributions sind aktiv, andere aufgegeben. | Hilft festzulegen, was zum Migrationsumfang gehört. |
| Validierungsplanung | Bilder, Attribute, Orders und Inhalte müssen geprüft werden. | Reduziert Überraschungen vor dem Launch. |
| Reihenfolge von Entscheidungen | Demo Migration kann individuelle Felder oder alte Modulabhängigkeiten sichtbar machen. | Unterstützt gestufte Entscheidungen vor Full Migration. |
| Stakeholder-Abstimmung | Technischer und geschäftlicher Verantwortlicher kennen unterschiedliche Teile des Altshops. | Verknüpft Nachweise, Umfang und Freigaben. |
Managed Service ersetzt Custom Service nicht, wenn nicht unterstützte Daten maßgeschneidert behandelt werden müssen. Er ist der stärkere Managementpfad für Migrationen, die Aufsicht und strukturierte Entscheidungen benötigen.
Wo Add-ons in einer osCMax-Migration passen
Add-ons unterstützen klar begrenzte Migrationsanforderungen. Sie eignen sich, wenn der Bedarf spezifisch, unterstützt und über feldbasierte Filterbedingungen je Datenkategorie, ausdrucksbasierte Transformation unterstützter Feldwerte oder Remapping eines unterstützten Quellfelds kontrollierbar ist. Bei osCMax können Add-ons helfen, Legacy-Daten selektiv zu behandeln, ohne maßgeschneiderte Entwicklung oder Interpretation nicht unterstützter Quellstrukturen zu benötigen.
Beispiele sind eine unterstützte Bedingung auf einem Product-Feld, um inaktive Products auszuschließen, ein Ausdruck zur Transformation eines unterstützten Feldwerts oder das Remapping eines bekannten Quellfelds auf ein kompatibles Zielfeld.
Add-ons dürfen nicht als unspezifische Antwort auf altes Contribution-Verhalten verwendet werden. Erzeugt eine Contribution Custom Tables, speichert Daten in ungewöhnlichen Feldern, verändert Checkout-Verhalten oder erstellt einen weiterhin benötigten Report, kann Custom Service oder ein Ersatz auf der Zielseite erforderlich sein. Diese Grenze ist wichtig, denn Add-ons sind kein Versprechen, alte Module, Templates, Admin-Funktionen oder individuelle Anwendungen zu rekonstruieren.
| Bedarf | Add-on kann passen, wenn | Add-on reicht nicht, wenn |
|---|---|---|
| Data Filter | Datenkategorie, Quellfeld, Bedingung und Ein-/Ausschlussregel unterstützt und eindeutig sind. | Der Filter von individueller Logik im Code abhängt. |
| Data Transformation | Quellfeld, Ausdruck und erwartete Zielwerte unterstützt und testbar sind. | Die Transformation von Custom Tables, abgeleitetem Verhalten oder maßgeschneiderter Logik abhängt. |
| Advanced Data Mapping | Quellfeld und kompatibles Zielfeld bekannt und unterstützt sind. | Das Ziel eine nicht unterstützte Struktur oder Funktion erfordert. |
Die praktische Regel lautet: Add-ons sind für abgegrenzte Migrationsanpassungen gedacht, nicht für den Erhalt unbekannten Legacy-Verhaltens.
Wann Custom Service erforderlich ist
Custom Service ist erforderlich, wenn der Migrationsbedarf außerhalb des unterstützten Verhaltens liegt und eine maßgeschneiderte Prüfung benötigt. Bei osCMax tritt diese Grenze häufig auf, weil ältere Shops Contribution-eigene Datensätze, individuelle Felder mit Anforderungen außerhalb des unterstützten Mapping-Umfangs, Custom Tables, geänderte Dateien, maßgeschneiderte Reports, alte Exportlogik, Template-gebundene Inhalte oder durch Code erzeugte Storefront-Funktionen enthalten können.
Custom Service kann nötig sein, wenn ein Geschäftsergebnis erhalten werden soll, die Nachweise aber zeigen, dass es von nicht standardisierten Strukturen abhängt. Ein Großhandelsformular, Zugriffslogik für eingeschränkte Inhalte, besondere Versandfunktionen, individueller Order-Export, alte Bildbehandlung oder Template-spezifische Navigation sind beispielsweise nicht automatisch gewöhnliche Datenmigration. Zuerst muss geklärt werden, ob die Anforderung Daten, Konfiguration, Zielplattform-Funktion oder eine individuelle Transformationsanforderung ist.
Custom Service muss sorgfältig abgegrenzt werden. Er verspricht nicht automatisch vollständige Einrichtung des Zielshops, App-Implementierung, individuelle Entwicklung oder Theme-Redesign. Er ist ein maßgeschneiderter Prüf- und Behandlungspfad für Migrationsanforderungen, die nicht standardisierte Bearbeitung brauchen. In manchen Fällen werden bestimmte Daten migriert oder transformiert. In anderen Fällen lautet die richtige Empfehlung, die Funktion direkt auf der Zielplattform neu aufzubauen.
Signale für Custom Service sind:
- Custom Tables oder individuelle Felder, die mit aktiven Geschäftsprozessen verbunden sind;
- geänderte Core-Dateien, die Katalog-, Customer-, Order- oder Checkout-Bedeutung verändern;
- Contribution-eigene Datensätze ohne standardisiertes Zielgegenstück;
- altes Modulverhalten, das für betriebliche Kontinuität erhalten werden muss;
- maßgeschneiderte Transformationen, bevor Daten nutzbar werden;
- Anforderungen einer individuellen Plattform oder nicht unterstütztes Quellverhalten.
Bei osCMax sollte Custom Service als Präzisionswerkzeug verstanden werden. Er schützt das Projekt davor, individuelles Legacy-Verhalten als gewöhnliche Daten auszugeben.
Custom Service umfasst nicht automatisch den Wiederaufbau von Legacy-Contributions, den Austausch von Templates, die Rekonstruktion von Checkout-Verhalten, das Upgrade der alten Anwendung oder die Entwicklung der Zielplattform, sofern diese Verantwortlichkeiten nicht ausdrücklich im vereinbarten Umfang enthalten sind.
Datenmigration von Neuaufbau-Entscheidungen auf der Zielseite trennen
Eine der wichtigsten Servicepfad-Entscheidungen in einem osCMax-Projekt lautet, ob eine Legacy-Funktion migriert, neu aufgebaut, ersetzt oder stillgelegt werden soll. Viele osCMax-Shops erhielten ihre Funktionen durch Contributions und Dateiänderungen. Manche speichern Daten, die migriert werden können. Andere erzeugen Verhalten, das zur Zielkonfiguration oder -entwicklung gehört. Alles als Datenmigration zu behandeln schafft unrealistische Erwartungen.
Eine Product-Bildergalerie, besondere Versandtabelle, Zugriffsregel für eingeschränkte Inhalte, individueller Order-Export oder Template-basierte Navigationsbox können für den Händler wichtig sein. Sie verlangen jedoch nicht denselben Migrationsweg. Bilddatensätze können migriert werden, wenn Struktur unterstützt und Assets vorhanden sind. Versandlogik kann Zielkonfiguration benötigen. Eingeschränkter Zugriff kann Mapping von Customer Groups, Zielfunktionen oder ein neues Zugriffskonzept erfordern. Order-Exporte können durch Ziel-Reporting ersetzt werden. Template-Boxen können zu Inhalten, Theme-Arbeit oder stillgelegten Interface-Elementen werden.
Der Servicepfad sollte deshalb eine Entscheidung über jedes wichtige Altverhalten enthalten. Es erhält eines von vier Ergebnissen: als unterstützte Daten migrieren, mit Add-ons anpassen, über Custom Service prüfen oder außerhalb des Datenmigrationsumfangs neu aufbauen. Dadurch bleibt das Projekt kontrollierbar und Custom Service wird nicht zum Sammelbegriff für jedes alte Feature.
| Art des Legacy-Verhaltens | Beste erste Frage | Wahrscheinlicher Behandlungspfad |
|---|---|---|
| Daten in unterstützten Feldern | Lässt sich das Feld sauber auf die Zielplattform abbilden? | Standard Service, Managed Service oder Add-ons. |
| Daten in Custom Tables | Welche Geschäftsbedeutung muss erhalten werden? | Prüfung über Custom Service. |
| Verhalten aus alten Modulen | Wird die Funktion im neuen Shop noch benötigt? | Zielkonfiguration, Ersatz oder Prüfung über Custom Service. |
| Template-basierte Darstellung | Ist dies Inhalt, Navigation oder Design? | Theme-/Inhaltsplanung auf der Zielseite, keine automatische Datenmigration. |
| Admin-Komfortfunktionen | Sind historische Daten betroffen oder nur die Produktivität im Admin-Bereich? | Meist Ersatz, Stilllegung oder separate Zieleinrichtung. |
Diese Trennung ist besonders für Händler wichtig, die mit dem neuen Shop stabiler arbeiten wollen als mit dem alten. Der Migrationsansatz soll Geschäftskontinuität erhalten und nicht jeden historischen Workaround neu bauen.
Verantwortliche für jede Validierungsentscheidung festlegen
Die Serviceauswahl hängt auch davon ab, wer validiert. Eine Migration kann technisch sauber ausgeführt werden und trotzdem bei der Launch-Prüfung scheitern, wenn niemand für die Bestätigung der Geschäftsbedeutung verantwortlich ist. osCMax-Migrationen brauchen häufig unterschiedliche Prüfer für Katalogdaten, Template-Erwartungen, Order-Historie, Customer Groups, Versandreferenzen und Legacy-Contribution-Verhalten. Der Servicepfad sollte diesen Koordinationsaufwand berücksichtigen.
Ein kleiner Händler mit sauberen Datensätzen kann Ergebnisse nach der Demo Migration direkt prüfen. Ein größerer oder stärker angepasster Shop kann Managed Service benötigen, weil Shop-Verantwortlicher, Entwickler, Operations, SEO und Kundenservice gemeinsam koordinieren müssen. Custom Service kann nötig sein, wenn ein technischer Prüfer Custom Tables oder Codeverhalten interpretieren muss, bevor der Migrationsplan abgeschlossen werden kann.
Die Validierungsverantwortung sollte vor Full Migration feststehen. Der Katalogprüfer bestätigt Product-Struktur, Attribute, Bilder und Categories. Operations bestätigt Order-Status, Zahlungsbezeichnungen, Versandreferenzen und Reporting-Bedarf. Storefront-Verantwortliche prüfen CMS Pages, Navigation und wichtige Assets. Technische Prüfer klären, ob individuelle Daten maßgeschneiderte Behandlung brauchen. Diese Aufteilung zeigt, ob lediglich Ausführung oder zusätzlich Koordination und individuelle Interpretation nötig sind.
| Prüferrolle | Zu bestätigender osCMax-Bereich | Auswirkung auf den Servicepfad |
|---|---|---|
| Shop-Verantwortlicher | Kommerzielle Bedeutung und Launch-Prioritäten. | Klärt, was weiterlaufen muss und was sich ändern darf. |
| Katalogprüfer | Products, Attribute, Categories, Bilder, Specials. | Bestätigt, ob Standard Service oder Add-ons ausreichen. |
| Operations-Prüfer | Orders, Status, Versand, Zahlung, Exporte. | Identifiziert Trigger für Managed Service oder Custom Service. |
| Technischer Prüfer | Individuelle Dateien, Tabellen, Module, Templates. | Bestimmt, ob maßgeschneiderte Prüfung nötig ist. |
| SEO-/Inhaltsprüfer | CMS Pages, URLs, Metadaten, Navigations-Assets. | Trennt Migrationsumfang von SEO-Arbeit auf der Zielseite. |
Ein Servicepfad ohne Validierungsverantwortung ist unvollständig. Die Komplexität von osCMax zeigt sich oft nicht im Export, sondern in der Prüfung dessen, was der Export geschäftlich bedeutet.
Entity Points zur Umfangsgröße und nicht als Komplexitätsscore verwenden
Entity Points helfen, das Volumen zulässiger Datensätze zu dimensionieren. Neue zulässige Products, Customers, Orders und Blog Posts verbrauchen Entity Points bei ihrer ersten Migration. Bei späteren Aktivitäten auf demselben Migrationspfad bleiben bereits gezählte zulässige Datensätze einmal gezählt; Komplexität aus Contributions, Templates, Custom Tables und Legacy-Code wird separat bewertet.
Für osCMax ist diese Trennung wichtig, weil Komplexität und Datensatzanzahl nicht parallel steigen müssen. Ein Shop mit vielen standardisierten Products kann groß, aber beherrschbar sein. Ein kleinerer Shop mit mehreren aktiven Contributions kann mehr individuelle Prüfung brauchen. Entity Points helfen beim Volumen, messen aber weder Versionsunsicherheit noch Contribution-Abhängigkeit, Custom-Table-Risiken, Template-Kopplung oder altes Checkout-Verhalten.
Entity Points beantworten die Frage: Wie viele zulässige Daten werden migriert? Die Servicepfad-Prüfung beantwortet eine andere: Wie komplex ist das Verhalten rund um diese Daten?
| Planungsfrage | Entity Points verwenden? | Servicepfad prüfen? |
|---|---|---|
| Wie viele neue zulässige Products, Customers, Orders oder Blog Posts werden erstmals migriert? | Ja | Manchmal |
| Benötigt eine individuelle Contribution maßgeschneiderte Behandlung? | Nein | Ja |
| Muss altes Bild- oder Template-Verhalten validiert werden? | Nein | Ja |
| Verbraucht eine zweite Migrationsaktion für dieselben bereits gezählten Datensätze erneut Entity Points? | Nein | Nur prüfen, wenn neue zulässige Datensätze hinzukommen |
| Braucht der Shop Add-ons oder Custom Service? | Nicht allein daraus ableitbar | Ja |
Diese Trennung verhindert den Planungsfehler, eine niedrige Datensatzanzahl mit einer einfachen osCMax-Migration gleichzusetzen.
Mit Demo Migration den finalen Pfad wählen
Demo Migration ist der sicherste Test dafür, ob der gewählte Ansatz realistisch ist. Bei osCMax sollte sie mehr als saubere Products und neue Orders enthalten. Sie sollte repräsentative Datensätze auswählen, die Annahmen zu Versionslinie, Contributions, Templates, Bildern, Customers, Inhalten und Orders sichtbar machen.
Die Demo Migration sollte mehrere Fragen beantworten: Kommen Core-Datensätze korrekt an? Bleiben Product-Attribute und Bilder sinnvoll interpretierbar? Sind Customer- und Order-Beziehungen verständlich? Sind alte Status, Rabatte, Versandreferenzen und Zahlungsbezeichnungen im Zielkontext nachvollziehbar? Werden CMS Pages und Inhaltsdatensätze passend repräsentiert? Gibt es Datensätze in der alten Datenbank, die in unterstützten Migrationsergebnissen fehlen, weil sie zu individuellen oder Contribution-spezifischen Strukturen gehören?
Bestätigt die Demo Migration die erwarteten Ergebnisse, kann das Projekt mit dem gewählten Servicepfad in Richtung Full Migration gehen. Zeigt sie fehlende Felder, unerwartete Beziehungen, nicht unterstützte Strukturen oder individuelles Verhalten, sollte der Servicepfad vor Full Migration angepasst werden. Das kann Add-ons, Koordination über Managed Service, Prüfung über Custom Service oder die Entscheidung umfassen, altes Verhalten auf der Zielplattform neu umzusetzen statt es zu migrieren.
Demo Migration ist keine symbolische Vorschau. Sie ist der Entscheidungspunkt, an dem Annahmen zu Nachweisen werden.
Spätere Migrationsaktionen sorgfältig planen
Zusätzliche Migrationsaktionen werden relevant, wenn nach dem ersten Ergebnis weitere Migration nötig ist. Bei osCMax ist die Planung besonders nützlich, wenn neue Datensätze hinzugekommen sind, Konfiguration nach Erkenntnissen aus der Demo Migration geändert werden muss oder ein deutlich veränderter Umfang ein eigenständiges neues Ergebnis erfordert.
Dafür gibt es drei konkrete Optionen. Mit Continue the Migration with the Last Used Configuration wird weitergearbeitet, wenn das ursprüngliche Setup weiterhin gilt. Mit Continue the Migration with a New Configuration wird fortgesetzt, wenn Mapping-, Filter- oder Konfigurationsentscheidungen geändert wurden. Perform a New Migration ist passend, wenn auf demselben gekauften Plattformpfad ein eigenständiges neues Migrationsergebnis benötigt wird und das frühere Ergebnis nicht länger als Arbeitsbasis dienen soll.
Die Wahl sollte bei osCMax anhand der Nachweise erfolgen. Sind lediglich neue zulässige Orders hinzugekommen, kann die letzte Konfiguration genügen. Zeigt die Demo Migration, dass Product-Felder, Customer Groups oder Inhaltsbehandlung anders konfiguriert werden müssen, ist eine neue Konfiguration sicherer. Wird eine größere Contribution-eigene Datenebene entdeckt, kann nach Klärung des Umfangs ein neues Migrationsergebnis sinnvoller sein. Eine andere Zielplattform erfordert einen separat gekauften Migrationsservice, weil der gekaufte Migrationspfad nicht geändert werden kann.
| Folgesituation | Bessere Option | Grund |
|---|---|---|
| Gleicher Umfang, gleiche Konfiguration, neue zulässige Datensätze | Continue the Migration with the Last Used Configuration | Hält den Migrationspfad konsistent. |
| Gleicher Shop, aber geändertes Mapping oder Filtering | Continue the Migration with a New Configuration | Bildet aktualisierte Migrationsentscheidungen ab. |
| Deutlich veränderter Umfang oder gewünschtes neues Ergebnis auf demselben gekauften Plattformpfad | Perform a New Migration | Verhindert, dass das frühere Ergebnis in das veränderte Projekt übernommen wird; ein anderer Plattformpfad erfordert einen separaten gekauften Migrationsservice. |
| Individuelle Daten nach Demo Migration entdeckt | Vor Auswahl prüfen | Kann Custom Service statt einer einfachen Fortsetzung erfordern. |
Die drei Optionen dienen der Kontrolle. Sie sollten nicht verwendet werden, um schwierige Umfangsentscheidungen aufzuschieben.
Fazit
Der richtige Migrationsansatz für osCMax hängt davon ab, wie viel des Quellshops aus sauberen Daten besteht und wie viel von Contribution-Verhalten, individuellen Dateien, Templates, Versionshistorie und Hosting-Annahmen abhängt. Standard Service kann für saubere unterstützte Datensätze passen. Managed Service ergänzt Koordination und Validierung. Add-ons unterstützen klar begrenzte Anforderungen an Datensatzfilterung, Feldwerttransformation und Field Mapping. Custom Service behandelt nicht standardisierte Datensätze, Custom Tables, maßgeschneiderte Transformationen und Contribution-eigenes Verhalten, das individuelle Prüfung erfordert.
Demo Migration sollte vor Full Migration Annahmen in Nachweise verwandeln. Spätere Migrationsaktionen sollten nur genutzt werden, wenn der Folgepfad klar ist. So bleibt die osCMax-Migration praktisch, kontrolliert und am tatsächlichen Shop statt an einer vereinfachten Plattformbezeichnung ausgerichtet.
Häufige Fragen
Kann eine osCMax-Migration Standard Service verwenden?
Ja, wenn die Migration hauptsächlich unterstützte Core-Datensätze umfasst und der Händler nicht erwartet, dass altes Contribution-Verhalten, Templates, Module oder individueller Code als Teil der Datenmigration rekonstruiert werden.
Wann benötigt osCMax Custom Service?
Custom Service ist angemessen, wenn aktive Geschäftsbedeutung von Custom Tables, individuellen Feldern außerhalb des unterstützten Mapping-Umfangs, geänderten Dateien, Contribution-eigenen Datensätzen, maßgeschneiderten Transformationen, nicht unterstütztem Quellverhalten oder Anforderungen einer individuellen Plattform abhängt.
Wie sollte Demo Migration den Servicepfad beeinflussen?
Demo Migration sollte bestätigen, ob der gewählte Pfad repräsentative Datensätze korrekt behandelt. Zeigt sie nicht unterstützte Strukturen, fehlende individuelle Felder oder Contribution-gesteuertes Verhalten, sollte der Servicepfad vor Full Migration angepasst werden.
Welche Nachweise sollten für eine Prüfung über Custom Service bei osCMax vorbereitet werden?
Bereiten Sie osCMax-Beispiele vor, die Contribution-eigene Felder, Custom Tables und Legacy-Code-Verhalten mit Storefront, Administration, Reporting oder Integration verbinden, die diese Daten weiterhin nutzen. Der Umfang von Custom Service sollte Zielrepräsentation, Verantwortlichen für Abhängigkeiten und erforderliche Abnahmenachweise festlegen.