Wenn Zen Cart als mögliche Zielplattform bewertet wird, hängt der richtige Migrationsansatz davon ab, welcher Teil des Projekts in eine unterstützte Datenmigration passt und welcher Teil von Zielumgebung, Modulen, Templates, Plugins, benutzerdefinierten Feldern oder nicht standardmäßigem Datenverhalten abhängt. Zen Cart ist selbst gehostet und stark konfigurierbar. Deshalb sollte der Migrationsservicepfad anhand von Nachweisen gewählt werden und nicht allein nach dem Volumen einzelner Datenkategorien.
Ein sauberer Quellkatalog mit vorhersehbaren Products, Customers, Orders, CMS Pages und Blog Posts kann zu Standard Service passen. Benötigt der Händler servicegeführte Ausführung, kann Managed Service passender sein. Wenn unterstützte Datensätze gefiltert, Feldwerte per Ausdruck verändert oder Quellfelder auf andere Zielfelder gemappt werden müssen, können Add-ons erforderlich sein. Benutzerdefinierte Tabellen, nicht unterstützte plugin-basierte Daten, benutzerdefinierte Felder, deren erforderliche Behandlung über den unterstützten Umfang der Zuordnung hinausgeht, externe Identifikatoren, individuelle Transformationen oder Anforderungen an eine individuelle Plattform gehören in die Prüfung durch Custom Service.
Innerhalb der Next-Cart Migrationsservices sollte die Zen-Cart-Evidenz unterstützte Datensätze, Ausführungsverantwortung, klar begrenzte Add-ons, moduleigene Daten, benutzerdefinierte Strukturen und die Einrichtung der Zielumgebung voneinander trennen.
Mit dem Migrationsumfang für Zen Cart beginnen
Die erste Entscheidung für den Migrationsservicepfad lautet, ob das Projekt überwiegend eine unterstützte Datenmigration oder ein Problem individueller Interpretation ist. Unterstützte Datenmigration konzentriert sich darauf, erkannte Records in eine vorbereitete Zielplattform zu übertragen. Individuelle Interpretation wird erforderlich, wenn der Quellshop geschäftliche Bedeutung in Strukturen speichert, die mit gewöhnlichem unterstütztem Migrationsverhalten nicht verarbeitet werden können.
Bei Zen Cart wird der Umfang durch Zielumgebung, Product Attributes, Order-Historie, Inhaltsstruktur, URL-Anforderungen, Zahlungs- und Versandbezeichnungen, Order-Total-Verhalten, Plugins, Templates und Änderungen an benutzerdefinierten Datenbankstrukturen geprägt. Je mehr dieser Elemente in unterstützten Strukturen bleiben, desto vorhersehbarer wird der Migrationsansatz. Je stärker sie von individueller Logik abhängen, desto früher sollte Custom Service geprüft werden.
| Umfangssignal | Typische Bedeutung |
|---|---|
| Sauberer Katalog, Standard-Customers, nachvollziehbare Orders, vorbereitete Zielinstallation | Standard Service kann ausreichen. |
| Standard-Migrationsbedarf, aber der Kunde möchte servicegeführte Ausführung | Managed Service kann operativ besser passen. |
| Unterstützte Datensätze benötigen datenkategoriespezifische Bedingungen, Quellfelder andere Zielorte oder Feldwerte ausdrucksbasierte Änderungen | Data Filter, Advanced Data Mapping oder Data Transformation sollten geprüft werden. |
| Nicht unterstützte Plugin-Daten, benutzerdefinierte Felder außerhalb des unterstützten Zuordnungsumfangss, benutzerdefinierte Tabellen oder individuelle Transformationen | Custom Service sollte vor Full Migration geprüft werden. |
| Unklares Ergebnis der Demo Migration | Nicht nach Annahmen fortfahren; zuerst die Lücke klassifizieren. |
Ziel ist nicht, den größten Migrationsservicepfad zu wählen. Ziel ist der Pfad, der zur tatsächlichen Migrationsverantwortung passt.
Wann Standard Service zu Zen Cart passt
Standard Service kann zu Zen-Cart-Projekten passen, wenn die Quelldaten über unterstütztes Plattformverhalten migriert werden können und der Zielshop bereits für die Validierung vorbereitet ist. Das bedeutet meist, dass Katalog, Customers, Orders, Inhaltsdatensätze und unterstützte Felder vorhersehbar genug sind, sodass keine individuelle Extraktion, individuelle Platzierung oder Anpassung der Migrationslogik erforderlich ist.
Ein starker Standard-Service-Kandidat hat in der Regel:
- eine vorbereitete Zen-Cart-Installation;
- gewöhnliche Products und Categories;
- Product Attributes, die ohne individuelle Transformation geprüft werden können;
- Customer-Datensätze mit Standard-Identitäts- und Adressdaten;
- Order-Datensätze, die ohne individuelle Rekonstruktion der Order Totals nachvollziehbar bleiben;
- Inhaltsdatensätze, die bei Auswahl in die unterstützte Behandlung von CMS Pages oder Blog Posts passen;
- keine nicht unterstützten plugin-basierten Datensätze, die erhalten werden müssen;
- keine benutzerdefinierten Tabellen oder externen Identifikatoren, die spezielle Platzierung benötigen.
Standard Service bedeutet nicht, dass der Kunde die Zielkonfiguration überspringen kann. Zen-Cart-Zahlungsmodule, Versandmodule, Steuerregeln, Templates, Sideboxes, Funktionsweise des Live-Checkouts und Konfiguration der Shop-Oberfläche bleiben Zielshop-Aufgaben, sofern sie nicht separat außerhalb des gewöhnlichen Migrationsumfangs behandelt werden. Der Migrationsservicepfad ist nicht allein dann erfolgreich, wenn die Anzahl der Datensätze stimmt, sondern wenn die migrierten Datensätze im Zielshop tatsächlich nutzbar sind.
Wann Managed Service operativ besser passt
Managed Service passt, wenn die unterstützte Funktionalität ausreicht, der Kunde aber fachlich geführte Ausführung und Koordination benötigt. Das ist hilfreich, wenn wenig Zeit verfügbar ist, die Ausführung stärker kontrolliert werden soll oder fachkundig geführte Bearbeitung gewünscht wird, während weiterhin mit unterstütztem Migrationsverhalten gearbeitet wird.
Managed Service ist nicht dasselbe wie Custom Service. Wenn das Projekt nicht unterstützte Datenbehandlung, individuelle Transformation, Interpretation von Plugin-Tabellen oder Anpassung der Migrationslogik benötigt, darf es nicht künstlich in Managed Service eingeordnet werden. Managed Service verändert die operative Verantwortung; Custom Service verändert die technische und datenbezogene Verantwortung.
| Situation | Eignung für Managed Service |
|---|---|
| Unterstützte Zen-Cart-Migration, aber der Kunde hat keine Zeit, sie selbst auszuführen | Gute Eignung. |
| Kunde möchte servicegeführte Ausführung mit Standardfunktionen | Gute Eignung. |
| Kunde braucht Unterstützung bei der Interpretation der Demo-Migration-Ergebnisse | Je nach Migrationsumfang möglich. |
| Shop enthält nicht unterstützte benutzerdefinierte Tabellen oder plugin-basierte Datensätze | Nicht ausreichend; Custom Service muss geprüft werden. |
| Shop benötigt Ziel-Template-, Modul- oder Checkout-Implementierung | Kein gewöhnlicher Managed-Service-Umfang, sofern nicht separat definiert. |
Managed Service funktioniert am besten bei klaren Rollen. Fachkundig geführte Migrationsausführung nimmt dem Kunden oder Entwicklungsteam nicht die Verantwortung für Zielkonfiguration, Hosting-Bereitschaft, Template-Arbeit, Zahlungs- und Versandsetup und finale Freigabe zum Go-live ab, sofern diese Aufgaben nicht separat vereinbart sind.
Wo Add-ons in einer Zen-Cart-Migration sinnvoll sind
Add-ons sind geeignet, wenn das Projekt weiterhin in unterstütztes Migrationsverhalten passt, aber mehr Kontrolle benötigt. Sie sind klar begrenzte Service-Funktionen und keine allgemeine Zusage für beliebige Anpassungen. In Zen-Cart-Projekten können sie Datensätze anhand feldbasierter Bedingungen pro Datenkategorie filtern, unterstützte Feldwerte per Ausdruck transformieren oder Quellfelder auf andere Zielfelder mappen.
| Add-on | Zen-Cart-Anwendungsfall | Grenze |
|---|---|---|
| Data Filter | Unterstützte Feldbedingungen für Product-, Customer-, Order-, CMS-Page- oder Blog-Post-Datensätze anwenden, sodass nur passende Records migriert werden. | Filterung extrahiert keine nicht unterstützten Plugin-Daten oder benutzerdefinierte Tabellen. |
| Data Transformation | Ausdrücke verwenden, um unterstützte Feldwerte, Labels oder Status während der Migration zu verändern. | Individuelle Geschäftsregeln oder nicht unterstützte Transformationslogik benötigen Custom Service. |
| Advanced Data Mapping | Unterstützte Quellfelder auf andere Zen-Cart-Zielfelder mappen. | Mapping kann nicht unterstützte Strukturen nicht in standardmäßige Zen-Cart-Datensätze verwandeln. |
Für eine Migration zu Zen Cart ist Advanced Database Mapping nur verfügbar, wenn auch die Quellplattform Open-Source ist. Damit ist die vollständige Voraussetzung Open-Source-Quellplattform → Open-Source-Zielplattform Zen Cart erfüllt. Die gewünschte Feld- oder Datenbankspaltenzuordnung muss zusätzlich innerhalb der unterstützten Ziel- und Datentypgrenzen liegen.
Add-ons sollten erst ausgewählt werden, wenn die Anforderung klar definiert ist. Die allgemeine Vermutung, dass Anpassungen nötig sein könnten, reicht nicht. Eine brauchbare Anforderung nennt die Bedingung für die Datenkategorie, den Transformationsausdruck oder die Quell- und Zielfelder und definiert anschließend, wie das Ergebnis nach der Demo Migration validiert wird.
Wann Custom Service erforderlich ist
Custom Service ist erforderlich, wenn die Migration individuelle Prüfung, nicht standardmäßige Behandlung, Interpretation nicht unterstützter Daten oder Anpassung der Migrationslogik benötigt. Zen-Cart-Shops erreichen diesen Punkt häufig, wenn ältere Installationen über Jahre verändert wurden, Plugins zusätzliche Tabellen erzeugt haben, Template- oder Modulverhalten geschäftliche Bedeutung speichert oder externe Systeme von Identifikatoren abhängen, die in bestimmter Form erhalten werden müssen.
Custom Service sollte geprüft werden, wenn das Projekt Folgendes umfasst:
- eine individuelle Plattform als Quelle;
- benutzerdefinierte Datenbanktabellen;
- nicht unterstützte benutzerdefinierte Felder;
- plugin-basierte Product-, Customer-, Order-, Coupon-, Gift-Certificate-, Loyalty-, Subscription-, Berichts- oder Integrationendaten;
- Product Attributes, die individuelle Transformation benötigen;
- Bundles, Kits, konfigurierbare Products oder Quellvarianten, die sich nicht sauber übertragen lassen;
- individuelles Order-Total-, Tax-, Shipping-, Discount- oder Payment-Verhalten;
- ERP-, PIM-, Accounting-, Warehouse-, Shipping-, Marketplace- oder Feed-Identifikatoren, die erhalten werden müssen;
- individuelle URL-, Redirect-, Metadata- oder Content-Transformationsregeln;
- geänderte Zen-Cart-Zielstrukturen, die von Standardannahmen abweichen.
Custom Service beinhaltet nicht automatisch einen vollständigen Shop-Neuaufbau, die Installation von Modulen, Template-Design oder Implementierung externer Systeme. Es bedeutet, dass die Migration Customization oder nicht standardmäßige Behandlung umfasst, die vor Full Migration geprüft und geplant werden muss.
Entity Points zur Umfangsplanung verwenden, nicht als Komplexitätsscore
Entity Points helfen, den Umfang qualifizierter Datensätze einzuschätzen. Sie ersetzen keine Analyse des Migrationsservicepfads. Ein kleiner Shop kann Custom Service benötigen, wenn Records von benutzerdefinierten Tabellen oder plugin-basierten Strukturen abhängen. Ein großer Shop kann für Standard Service geeignet bleiben, wenn die Datensätze unterstützt und vorhersehbar sind.
Neue qualifizierte Products, Customers, Orders und Blog Posts verbrauchen Entity Points, wenn sie innerhalb der gekauften Migration zum ersten Mal migriert werden. Bei späterer Zen-Cart-Aktivität bleiben bereits gezählte qualifizierte Datensätze auf dem festen Migrationspfad genau einmal gezählt; Komplexität durch Module, Templates, benutzerdefinierte Tabellen und Checkout wird separat bewertet.
Nutzen Sie die Entity-Points-Planung für praktische Fragen:
- welche qualifizierten Datensätze innerhalb der gekauften Migration und des festen Migrationspfads bereits erfasst sind;
- welche neuen qualifizierten Datensätze zusätzliche Entity Points verbrauchen können;
- ob Blog Posts oder zusätzliche Orders den Plan verändern;
- ob eine Fortsetzung der Migration neue qualifizierte Datensätze hinzufügen kann;
- ob das Projekt nach einer Umfangserweiterung weiterhin in unterstütztes Verhalten passt.
Entity Points beschreiben Volumen. Sie entscheiden nicht, ob benutzerdefinierte Felder außerhalb des unterstützten Zuordnungsumfangss, Plugin-Daten oder individuelle Logik ohne Custom Service behandelt werden können.
Demo Migration als Grundlage für die nächste Entscheidung verwenden
Demo Migration sollte als Evidenz für den Migrationsservicepfad genutzt werden. Die Stichprobe sollte gewöhnliche Records und Grenzfälle enthalten, die die tatsächlichen Druckpunkte einer Zen-Cart-Migration abbilden: Attribute, Downloads, Order Totals, Coupons, Gift Certificates, Customer-Adressen, Inhaltsseiten, URLs, Bilder und Records, die von Plugins oder benutzerdefinierten Feldern beeinflusst werden.
Klassifizieren Sie nach der Demo Migration jedes Problem sorgfältig:
| Befund der Demo Migration | Wahrscheinlicher nächster Schritt |
|---|---|
| Unterstützte Datensätze fehlen, weil sie nicht ausgewählt oder nicht im Umfang waren | Migrationsumfang oder ausgewählte Datenkategorien anpassen. |
| Unterstützte Fields brauchen bessere Zuordnung | Advanced Data Mapping prüfen. |
| Unterstützte Datensätze müssen gefiltert werden | Data Filter prüfen. |
| Unterstützte Werte brauchen kontrollierte Änderungen | Data Transformation prüfen. |
| Zielverhalten ist nicht konfiguriert | Zen-Cart-Zielkonfiguration korrigieren und erneut testen. |
| Nicht unterstützte Plugin-Daten oder benutzerdefinierte Tabellen werden benötigt | Custom Service prüfen. |
| Zusätzliche Records sind nach dem Test des Migrationspfads entstanden | Optionen für spätere Migrationen prüfen. |
Diese Klassifikation verhindert Überkorrektur. Nicht jedes Problem erfordert Custom Service, aber ebenso wenig lässt sich jedes Problem mit einem Add-on oder Zielkonfiguration lösen.
Optionen für spätere Migrationen einplanen, wenn sich Zeitplan oder Migrationsumfang ändern
Zen-Cart-Projekte laufen häufig weiter, während der Quellshop aktiv bleibt. Zwischen Demo Migration und Go-live können neue Products, Customers, Orders oder Blog Posts entstehen, während Attribute Mapping, Inhaltsumfang oder Zielkonfiguration sich nach der ersten Prüfung verändern können. Optionen für spätere Migrationen sollten nach Art der Änderung gewählt werden und nicht als austauschbare Wiederholungsaktionen betrachtet werden.
| Aktuelle Aktion | Wann sie verwendet wird | Fokus der Zen-Cart-Revalidierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Genehmigtes Mapping und Filtering bleiben gültig und neue qualifizierte Records müssen übertragen werden. | Neue Products, Customers, Orders, Blog Posts, Attribute Links, Adressen, Totals und geprüfte URLs. |
| Continue the Migration with a New Configuration | Unterstützte Filterung, Zuordnung, ausgewählte Daten oder Konfiguration müssen geändert werden. | Product Attributes, Option Values, Customer Groups, Status, Inhaltsfelder, Metadaten und betroffene Stichproben. |
| Perform a New Migration | Vorgesehene Zen-Cart-Struktur, Zielumgebung oder akzeptierter Migrationsumfang haben sich so stark geändert, dass das frühere Ergebnis das Projekt nicht mehr steuern sollte. | Vollständiges Product-, Attribute-, Customer-, Order-, Content-, Route-, Module-Data- und Ergebnis benutzerdefinierter Tabellen erneut validieren. |
Nach jeder Aktion ist Revalidierung verpflichtend. Zen-Cart-Attribute können kaufbare Auswahl, Preiseffekte, Bestandsfolgen und Display Logic kombinieren. Plugins können außerdem Customer-, Order-, Coupon-, Gift-Certificate-, Tax-, Shipping- oder Loyalty-Datensätze beeinflussen. Eine Folgeaktion sollte deshalb sowohl neue Records als auch bestehende Beziehungen prüfen, die von der geänderten Konfiguration betroffen sind.
Optionen für spätere Migrationen dürfen nicht verwendet werden, um die Prüfung des Migrationsservicepfads zu umgehen. Neue plugin-basierte Daten, benutzerdefinierte Tabellen, externe Systemidentifikatoren oder individuelle Transformationsregeln können eine bislang unterstützte Folgeaktion in den Umfang von Custom Service verschieben.
Ein sinnvoller Kontrollpunkt ist der Vergleich der Folgeanforderung mit der genehmigten Demo-Migration-Evidenz. Fügt die Anforderung nur neue qualifizierte Records unter derselben Struktur hinzu, kann die letzte Konfiguration weiterhin passen. Wurden Product-Attribute-Behandlung, Datensatzfilter, Inhaltsumfang oder Customer-Group-Mapping verändert, sollte eine neue Konfiguration an repräsentativen Records getestet werden. Haben sich Zieldesign oder Vorbereitung des Quellshops so stark verändert, dass die frühere Validierung kaum noch Aussagekraft besitzt, schafft eine neue Migration eine sauberere Ausgangsbasis und verhindert, dass veraltete Annahmen weitergetragen werden.
Eskalationssignale vor Full Migration
Der passende Migrationsansatz für Zen Cart sollte vor Full Migration bestätigt werden, nicht erst nach dem Go-live. Eskalation ist kein Zeichen für ein scheiterndes Projekt. Sie zeigt, dass der Quellshop Verhalten enthält, das einen präziseren Behandlungspfad benötigt als zunächst angenommen. Die wichtigsten Signale treten meist bei attributreichen Products, Legacy Order Totals, plugin-generierten Records, benutzerdefinierte Datenbase Fields, Content- und URL-Abhängigkeiten oder externen Systemidentifikatoren auf.
Standard Service kann passend bleiben, wenn Quelldatensätze in unterstützte Strukturen passen und die Zielshop-Konfiguration verstanden ist. Managed Service wird sinnvoller, wenn der Händler geführte Koordination, wiederholte Prüfzyklen und eine klarere Trennung zwischen Migrationsbefunden und Zielsetup-Befunden benötigt. Add-ons werden relevant, wenn innerhalb unterstützten Verhaltens eine begrenzte Anpassung erforderlich ist, etwa feldbasierte Bedingungen pro Datenkategorie, ausdrucksbasierte Transformation von Feldwerten oder Neuzuordnung von Quellfeldern auf kompatible Zielfelder. Custom Service ist erforderlich, wenn die Anforderung selbst nicht standardmäßig ist, etwa plugin-basierte Daten, benutzerdefinierte Tabellen, individuelle Interpretation oder externe Identifikatoren mit maßgeschneiderter Behandlung.
| Eskalationssignal | Wahrscheinlicher Behandlungspfad | Grund |
|---|---|---|
| Nur ausgewählte Products, Customers oder Orders sollen migriert werden | Data Filter | Begrenzte Auswahl innerhalb unterstützter Daten. |
| Quellfelder benötigen kontrollierte Interpretation der Zielfelder | Advanced Data Mapping | Records sind unterstützt, ihre Feldbedeutung braucht aber bewusste Platzierung. |
| Unterstützte Werte brauchen konfigurierte Anpassung | Data Transformation | Daten können migriert werden, Zielwerte benötigen jedoch kontrollierte Änderung. |
| plugin-basierte Tabellen müssen erhalten werden | Custom Service | Anforderung liegt außerhalb gewöhnlicher unterstützter Strukturen. |
| Historische Order Totals benötigen besondere Interpretation | Managed Service oder Custom Service | Problem kann Prüfung-Koordination oder individuelle Transformation betreffen. |
| Checkout im Zielshop muss altes Modulverhalten reproduzieren | Zielimplementierung, nicht nur Migration | Zahlungs-, Versand- und Modulverhalten benötigt häufig Konfiguration oder Entwicklung. |
| Neue Records entstehen nach Demo Migration | Optionen für spätere Migrationen | Timing erzeugt Folgeanforderungen nach dem ersten Migrationsdurchlauf. |
Diese Signale sollten anhand konkreter Beispiele bewertet werden. Custom Service sollte nicht gewählt werden, nur weil ein Shop allgemein komplex wirkt. Die Entscheidung muss an konkrete Daten, konkretes Verhalten und konkrete nicht unterstützte Strukturen gebunden sein. Ebenso sind Add-ons keine unspezifische Lösung für alles Ungewöhnliche. Add-ons sind begrenzt; Custom Service ist maßgeschneidert.
Befunde der Demo Migration in Migrationsserviceentscheidungen überführen
Demo Migration ist der praktische Test des gewählten Ansatzes. Für Zen Cart sollte die Stichprobe einfache Products, attributreiche Products, Download-Produkte, Zuordnungen zu verknüpften Categories, Customer-Datensätze, gewöhnliche Orders, rabattierte Orders, Coupon- oder Gift-Certificate-Beispiele, wichtige Inhaltsseiten und bei Go-live-Relevanz Datensätze mit Plugin-Einfluss oder benutzerdefinierten Feldern enthalten.
Nach der Demo Migration wird jeder Befund in eine Migrationsserviceentscheidung übersetzt. Ein fehlender unterstützter Record kann eine Korrektur des Migrationsumfangs erfordern. Eine falsche Feldinterpretation kann Prüfung der Zuordnung nötig machen. Eine Wertanpassung kann Data Transformation verlangen. Eine selektive Einschlussregel kann Data Filter erfordern. Eine plugin-basierte Tabelle kann Custom Service benötigen. Ein Live-Checkout-Fehler kann Zielmodul-Setup statt einer Migrationsänderung erfordern.
Dieser Ansatz schützt den Händler gleichzeitig vor Überkauf und Unterplanung. Custom Service wird nicht verwendet, wenn ein begrenztes Add-on genügt, und Standard Service versteckt keine nicht standardmäßigen Anforderungen. Der finale Ansatz sollte der kleinste Migrationsservicepfad sein, der geschäftliche Bedeutung sicher erhält und Arbeiten an der Zielumgebung klar ausweist.
Fazit
Der richtige Migrationsansatz für Zen Cart wird durch unterstütztes Datenverhalten, Zielbereitschaft, operative Verantwortung, Anpassungsbedarf, Entity-Points-Umfang und Evidenz aus der Demo Migration bestimmt. Standard Service passt zu sauberen unterstützten Migrationen. Managed Service passt zu Projekten mit Standardfunktionalität, die fachkundig geführte Ausführung benötigen. Add-ons unterstützen begrenztes Datensatzfilterung, Transformation von Feldwerten und Neuzuordnung von Feldern. Custom Service ist erforderlich, wenn nicht unterstützte Daten, benutzerdefinierte Felder außerhalb des unterstützten Zuordnungsumfangss, plugin-basierte Datensätze, Behandlung einer individuellen Plattform oder individuelle Transformation beteiligt sind.
Eine belastbare Migrationsservicepfad-Entscheidung trennt migrierte Records von Einrichtung der Zielumgebung. Zen-Cart-Module, Templates, Hosting, Security, Checkout-Konfiguration und Live-Store-Verhalten benötigen weiterhin klar verantwortete Verantwortung. Demo Migration sollte vor Full Migration bestätigen, dass der gewählte Ansatz geschäftliche Bedeutung zuverlässig schützt.
Häufige Fragen
Reicht Standard Service für Zen Cart aus?
Standard Service kann ausreichen, wenn die Quelldatensätze in unterstützte Zen-Cart-Strukturen passen und die Zielumgebung für die Prüfung vorbereitet ist. Nicht unterstützte benutzerdefinierte Felder, Plugin-Daten, benutzerdefinierte Tabellen oder individuelle Transformationen benötigen eine Custom-Service-Prüfung.
Wann sollte Managed Service für eine Zen-Cart-Migration gewählt werden?
Managed Service ist sinnvoll, wenn die Migration in unterstützte Funktionalität passt, der Kunde aber fachkundig geführte Ausführung bevorzugt. Für individuelle oder nicht unterstützte Datenbehandlung ersetzt Managed Service den Custom Service nicht.
Können Add-ons Zen-Cart-Plugin-Daten behandeln?
Add-ons können bei unterstützter Datensatzfilterung, Transformation von Feldwerten und Neuzuordnung von Feldern helfen. Nicht unterstützte plugin-basierte Daten, benutzerdefinierte Tabellen und individuelle Logik benötigen Custom Service.
Wann sollten Optionen für spätere Migrationen für Zen Cart berücksichtigt werden?
Wenn neue Records entstehen, die Migrationskonfiguration geändert wird oder sich das Zielkonfiguration verändert, nachdem der erste Migrationspfad bereits getestet wurde.
Beinhaltet die Migration ein Zen-Cart-Upgrade oder den Neuaufbau von Plugins und Template?
Nein. Die Migration verarbeitet die vereinbarten Records und Transformationen. Anwendungs-Upgrades, Plugin-Ersatz, Neuentwicklung des Templates, Konfiguration des Live-Checkouts und Implementierung externer Systeme sind separate Verantwortlichkeiten, sofern sie nicht ausdrücklich im finalen Umfang enthalten sind.