Bei der Bewertung von Phoca Cart als mögliche Zielplattform bestimmt der Migrationsansatz, welcher Next-Cart Migrationsservice und welche unterstützten Maßnahmen für den Weg in dieses Ziel passen.
Wenn Phoca Cart als mögliche Zielplattform feststeht oder in die engere Auswahl kommt, muss der passende Migrationsansatz Commerce-Datensätze von der Joomla-Umgebung trennen, die diesen Datensätzen ihre betriebliche Bedeutung gibt. Phoca Cart kann Products, Categories, Manufacturers, Attribute, Optionen, Spezifikationen, Bestand, Customers, Kundengruppen, Orders, Coupons, Bonuspunkte, Währungen, Sprachen, Steuern, Rechnungen, Zahlungs- und Versandmethoden sowie Point-of-Sale-Aktivitäten verwalten. Gleichzeitig ist die Plattform modular: Plugins, Module, Templates, Content-Integrationen, Zugriffsebenen und individueller Code können das Verhalten eines konkreten Shops verändern.
Der Servicepfad sollte widerspiegeln, wo die benötigten Daten und Funktionen verantwortet werden. Standard Service kann zu einem klaren, unterstützten Migrationspfad passen. Managed Service hilft, wenn der Kunde fachkundige Ausführung und koordinierte Validierung benötigt. Add-ons unterstützen klar abgegrenzte Anforderungen wie Datensatzfilterung, Transformation von Feldwerten oder Feldzuordnung innerhalb des unterstützten Verhaltens. Custom Service ist erforderlich, wenn das erwartete Ergebnis von nicht unterstützten Erweiterungsdatensätzen, benutzerdefinierten Feldern mit nicht standardmäßiger Interpretation oder Behandlung außerhalb unterstützter Zuordnung, individuellen Transformationen, externen Kennungen oder eigener Migrationslogik abhängt.
Innerhalb der Next-Cart Migrationsservices sollten die Phoca-Cart-Nachweise zwischen unterstützten Commerce-Daten, Bedarf an fachkundig geführter Ausführung, Joomla-Abhängigkeiten und individueller Behandlung von Erweiterungen unterscheiden.
Mit dem Phoca-Cart- und Joomla-Umfang beginnen
Phoca Cart ist eine Joomla-E-Commerce-Erweiterung und keine isolierte Shop-Anwendung. Der Migrationsplan sollte deshalb bestimmen, welche Anforderungen zu den zentralen Commerce-Datensätzen gehören, welche zu Joomla-Inhalten und Website-Struktur, welche zur Phoca-Cart-Konfiguration und welche durch Plugins oder individuelle Entwicklung entstehen.
| Umfangsebene | Typische Beispiele | Auswirkung auf den Servicepfad |
|---|---|---|
| Zentrale Commerce-Daten | Products, Categories, Manufacturers, Customers, Orders, Coupons, Reviews, Bilder | Kann zu Standard Service oder Managed Service passen, wenn unterstützt und strukturell klar |
| Product-Verhalten | Attribute, Optionen, Spezifikationen, Downloads, Bestand, verwandte Products, Gruppenpreise | Erfordert repräsentative Zuordnung und Nachweise aus Demo Migration |
| Joomla-Kontext | Benutzer, Zugriffsebenen, Menüs, Aliase, Module, Sprachen, Inhalte und URLs | Muss in migrierbare Daten, Zielkonfiguration und Website-Implementierung getrennt werden |
| Erweiterungsebene | Zahlungs- und Versand-Plugins, POS, Bonusfunktionen, Newsletter, PDF-Tools, individuelle Module | Kann Custom Service oder separate Zielimplementierung erfordern |
| Betriebliche Konfiguration | Steuer-, Währungs-, Sprach-, Zahlungs-, Versand-, Rechnungs-, Status- und Template-Einstellungen | Wird durch die Migration historischer Datensätze nicht automatisch neu erstellt |
Auch ein Shop mit kleinem Katalog kann einen anspruchsvollen Servicepfad benötigen, wenn individuelle Joomla-Felder, Product-Optionen, Kundengruppen, Plugins oder externe Integrationen geschäftskritisch sind. Ein größerer Shop kann dagegen für Standard Service geeignet bleiben, wenn seine Datensätze konventionell aufgebaut sind und der Kunde die Ergebnisse eigenständig validieren kann.
Wann Standard Service ausreichen kann
Standard Service ist geeignet, wenn der Migrationspfad unterstützt wird und die benötigten Daten innerhalb des Standardverhaltens liegen. Bei diesem Next-Cart-Service ist der Kunde für Konfigurationsentscheidungen, die Ausführung der Migration und die Validierung verantwortlich.
Ein guter Kandidat für Standard Service hat in der Regel:
- klare Products, Categories, Manufacturers, Customers, Orders und unterstützte Inhalte;
- verständliche Attribute, Optionen und Spezifikationen;
- konsistente Product-Kennungen und Bildbeziehungen;
- gewöhnliche Kundengruppen und Adressen;
- lesbare historische Orders ohne verborgene, Plugin-eigene Bedeutung;
- einen definierten Sprach- und Währungsumfang;
- nur begrenzte individuelle Felder und Erweiterungsdaten;
- keine Annahme, dass Joomla-Templates, Module, Plugins oder aktive Checkout-Einstellungen durch die Migration neu aufgebaut werden;
- ein Team, das Ergebnisse aus Demo Migration und Full Migration bewerten kann.
Standard Service sollte gewählt werden, weil die Daten unterstützt werden und der Kunde die Arbeit selbst steuern kann, nicht weil der Shop optisch einfach wirkt. In Phoca Cart kann erhebliche geschäftliche Bedeutung hinter Product-Optionen, Kundengruppenpreisen, Bonusregeln, Zahlungs- und Versand-Plugins sowie mehrsprachiger Konfiguration liegen.
Wann Managed Service besser passt
Managed Service ist geeignet, wenn die Migration grundsätzlich unterstützt wird, der Händler aber Next-Cart-Spezialisten für Ausführung und koordinierte Validierung benötigt. Das ist besonders hilfreich, wenn Joomla- und Commerce-Verantwortung auf mehrere Teams verteilt sind.
Managed Service kann besser passen, wenn:
- der Händler die Migration nicht sicher eigenständig durchführen kann;
- mehrere Sprachen, Währungen, Kundengruppen oder Product-Strukturen eine koordinierte Prüfung erfordern;
- große Product- oder Order-Mengen einen erheblichen Validierungsaufwand erzeugen;
- das Launch-Fenster strukturierte Terminplanung und Problembearbeitung verlangt;
- Geschäftsverantwortliche, Joomla-Administratoren und Implementierungspartner unterschiedliche Ergebnisbereiche freigeben müssen;
- die Quelldaten unterstützt, aber so inkonsistent sind, dass eine disziplinierte Prüfung nötig ist;
- Expert Handle Bestandteil des vereinbarten Services sein soll.
Managed Service macht nicht unterstützte Plugin-Daten nicht zu Standarddaten. Er adressiert Ausführung und Koordination. Benötigt eine geschäftskritische Anforderung eine nicht standardmäßige Extraktion oder Transformation, sollte für genau diese Anforderung weiterhin Custom Service eingeplant werden.
Wo Add-ons eingesetzt werden
Add-ons sind sinnvoll, wenn die Hauptmigration unterstützt bleibt, aber eine klar abgegrenzte Anpassung benötigt wird. Sie können pro Datenkategorie Datensätze filtern, Feldwerte mit Ausdrücken transformieren, unterstützte Standardfelder neu zuordnen oder bei einem geeigneten Pfad Datenbankspalten neu zuordnen, ohne das gesamte Phoca-Cart-Projekt als individuell einzustufen.
Beispiele:
- unterstützte Bedingungen auf Product-, Customer-, Order- oder Inhaltsfelder mit Data Filter anwenden;
- unterstützte Feldwerte mit Ausdrücken über Data Transformation verändern;
- unterstützte Standard-Quellfelder mit unverändertem Wert über Advanced Data Mapping auf kompatible unterstützte Zielfelder neu zuordnen;
- unterstützte Datenbankspalten der Quelle mit unveränderten Werten über Advanced Database Mapping auf kompatible Phoca-Cart-Datenbankspalten abbilden, sofern auch die Quellplattform Open Source ist;
- ausgewählte SEO- oder Inhaltsausgaben behandeln, soweit unterstützt;
- gefilterte Datensätze, transformierte Werte und neu zugeordnete Felder gegen definierte Erwartungen validieren.
Add-ons dürfen nicht als Ersatz für Custom Service dargestellt werden. Die Zuordnung eines unterstützten Standard-Product-Felds aus der Quelle auf ein kompatibles unterstütztes Zielfeld bei unverändertem Wert kann zu Advanced Data Mapping passen. Für eine Migration nach Phoca Cart kommt Advanced Database Mapping nur infrage, wenn sowohl Quellplattform als auch Zielplattform Open Source sind. Das Extrahieren einer Bonushistorie aus einer individuellen Plugin-Tabelle, die Rekonstruktion von POS-Beziehungen oder die Transformation eines maßgeschneiderten Attributsystems fällt nicht darunter.
Die Grenze verläuft dort, wo die Anforderung das unterstützte Migrationsverhalten verlässt. Bleibt sie innerhalb dieses Rahmens, kann ein Add-on genügen. Erfordert sie individuelle Interpretation, eigene Logik oder nicht unterstützte Daten, ist Custom Service der passende Weg.
Wann Custom Service benötigt wird
Custom Service sollte geprüft werden, wenn das erwartete Ergebnis von Daten oder Logik außerhalb der unterstützten Standardstrukturen abhängt. Bei Phoca-Cart-Projekten kann dies durch Joomla-Anpassungen, von Erweiterungen verwaltete Datensätze und spezialisiertes Product- oder Customer-Verhalten entstehen.
Typische Eskalationssignale sind:
- individuelle Product-Felder, Attribute, Optionen oder Spezifikationen außerhalb der Standardstrukturen;
- individuelle Kundengruppenregeln, Bonushistorie oder Preislogik;
- POS-Datensätze oder externe Bestandsreferenzen;
- Zahlungs-, Versand-, Rechnungs- oder Steuerdaten in Plugin-Tabellen;
- individuelle Joomla-Benutzer, Zugriffsbeziehungen, Menülogik oder mehrsprachige Zuordnungen;
- individuelle Module, Template-Overrides oder Content-Integrationen, die geschäftskritische Datensätze speichern;
- externe ERP-, Buchhaltungs-, Auftragsabwicklungs-, Newsletter-, Marketplace- oder CRM-Kennungen;
- individuelle Transformation zwischen Quellfeldern und der Zielplattform;
- eine individuelle Plattform auf einer Seite des Migrationspfads;
- Anforderungen, die die Standard-Migrationslogik verändern.
Custom Service umfasst nicht automatisch Joomla-Upgrades, Phoca-Cart-Installation, Entwicklung von Erweiterungen oder Plugins, Rekonstruktion von Templates, POS-Implementierung, Konfiguration von Zahlung und Versand, Bereitstellung externer Integrationen oder den vollständigen Aufbau des Zielshop. Solche Verantwortlichkeiten müssen ausdrücklich Bestandteil des vereinbarten Umfangs sein.
Wie Entity Points die Planung beeinflussen
Entity Points dienen dazu, das Volumen berechtigter migrierter Datensätze zu bemessen. Bei späteren Phoca-Cart-Aktivitäten bleiben bereits gezählte berechtigte Datensätze auf demselben Migrationspfad einmal gezählt; Komplexität aus Joomla, Plugins, individuellen Feldern und Spezifikationen wird davon getrennt bewertet. Categories, Manufacturers, Reviews, Coupons, Attribute, Optionen, Spezifikationen, Kundengruppen, Bonusdaten, CMS Pages, Plugin-Datensätze und externe Kennungen können den Prüfaufwand erhöhen, ohne eigene Entity-Points-Datensatztypen zu werden.
Entity Points zählen berechtigte neue Products, Customers, Orders und Blog Posts, wenn sie erstmals migriert werden. Phoca-Cart-Categories, Manufacturers, Reviews, Coupons, Spezifikationen, Plugin-Datensätze und externe Kennungen können zusätzliche Prüfung erfordern, ohne neue gezählte Datensatztypen zu erzeugen; bereits gezählte Datensätze bleiben auf demselben Pfad nur einmal gezählt.
Diese Trennung hält Volumen und Komplexität auseinander:
| Planungsbedingung | Auswirkung auf Entity Points | Auswirkung auf den Servicepfad |
|---|---|---|
| Viele gewöhnliche Products | Benötigt passende Kapazität | Kann weiterhin zu Standard Service passen |
| Wenige Products mit individuellen Optionen oder Plugin-Daten | Geringeres Volumen | Kann Custom Service erfordern |
| Neue Orders vor dem Launch | Können bei der ersten Migration Entity Points verbrauchen | Erfordern anschließende Validierung |
| Bereits vorhandene Datensätze werden auf demselben Pfad erneut migriert | Kein doppelter Verbrauch allein wegen einer weiteren Aktion | Konfiguration muss weiterhin gültig sein |
Entity Points sollten vor Full Migration geplant werden, dürfen aber niemals als Beleg dafür dienen, dass individuelle Joomla- oder Phoca-Cart-Strukturen unterstützt werden.
Was Demo Migration beweisen sollte
Demo Migration sollte die schwierigen Datensätze testen, nicht nur die saubersten. Eine sinnvolle Phoca-Cart-Stichprobe umfasst:
- einfache Products sowie Products mit Attributen, Optionen, Spezifikationen oder Downloads;
- Products mit Gruppenpreisen, Bonusregeln, Bestandskontrollen oder mehrsprachigen Werten;
- Customers aus unterschiedlichen Gruppen- und Zugriffskontexten;
- Orders mit Rabatten, Coupons, Steuer, Zahlung, Versand, Statushistorie und Rechnungen;
- wichtige CMS Pages, Blog Posts, Menüs, Aliase und URLs;
- Datensätze, die von Plugins, Modulen, POS oder externen Systemen beeinflusst werden;
- Beispiele aus jeder relevanten Sprache, Währung oder Shop-Situation.
Demo Migration sollte belegen, dass der gewählte Ansatz die nutzbare geschäftliche Bedeutung erhält. Lücken sollten außerdem korrekt eingeordnet werden als:
- unterstützte Zielkonfiguration;
- klar abgegrenzter Add-on-Bedarf;
- Custom-Service-Bedarf;
- separate Verantwortung für Joomla- oder Phoca-Cart-Implementierung.
Ein Projekt sollte nicht zu Full Migration übergehen mit der Annahme, dass ein größeres Datenvolumen eine bereits in der Stichprobe sichtbare strukturelle Lücke lösen wird.
Optionen für spätere Migrationen für Phoca Cart
Optionen für spätere Migrationen sollten danach ausgewählt werden, ob die akzeptierte Konfiguration weiterhin gültig ist und was sich seit der früheren Migrationsaktivität geändert hat.
| Aktuelle Aktion | Geeignete Situation | Schwerpunkt der erneuten Phoca-Cart-Validierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Akzeptierter Umfang, Zuordnungen und Filter bleiben gültig, während neue Quellaktivität verarbeitet werden muss. | Neue Products, Customers, Orders, Blog Posts, Attribute, Optionen, Sprachwerte, URLs und Integrationskennungen. |
| Continue the Migration with a New Configuration | Derselbe Migrationspfad bleibt korrekt, aber unterstützte Filter, Zuordnungen oder Zieleinstellungen müssen geändert werden. | Product-Strukturen, Kundengruppen, Order-Status, Inhaltsauswahl, Sprachumfang, URLs und Ausschlüsse. |
| Perform a New Migration | Der Händler benötigt ein eigenständiges neues Zielergebnis statt einer Fortsetzung der bisherigen Konfiguration. | Vollständiger Commerce-, Joomla-, Content-, Plugin-, SEO- und Abnahmeumfang. |
Diese Aktionen installieren keine Plugins, bauen keine Templates neu auf, konfigurieren weder Zahlung noch Versand, implementieren kein POS und stellen keine externen Integrationen automatisch bereit. Sie arbeiten innerhalb des vereinbarten Migrationsserviceumfangs und ändern den festen, gekauften Pfad von der Quellplattform zur Zielplattform nicht. Ein anderer Plattformpfad erfordert einen separat gekauften Migrationsservice.
Migrierte Datensätze von der Phoca-Cart-Implementierung trennen
Phoca Cart verbindet Daten, Joomla-Kontext und betriebliche Konfiguration. Bevor Kosten und Verantwortung vereinbart werden, sollte der Migrationsansatz festlegen, welche Ebene jedes erwartete Ergebnis verantwortet.
| Erwartetes Ergebnis | Hauptverantwortung | Auswirkung auf den Servicepfad |
|---|---|---|
| Unterstützte Products, Customers, Orders, Blog Posts und zugehörige Datensätze | Migrationsservice | Unterstützung, Zuordnung, Entity Points und Abnahmekriterien bewerten. |
| Categories, Manufacturers, Attribute, Optionen, Spezifikationen und Inhaltsbeziehungen | Migration plus Zielvalidierung | Bestätigen, wie unterstützte Beziehungen dargestellt werden und welche Zieleinstellungen zusätzlich erforderlich bleiben. |
| Steuer-, Währungs-, Zahlungs-, Versand-, Rechnungs-, Status- und POS-Betrieb | Phoca-Cart-Konfiguration und Anbieter | Historische Werte dienen als Referenz; aktives Verhalten muss separat konfiguriert und getestet werden. |
| Joomla-Menüs, Module, Sprachen, Zugriffsebenen, Aliase und Templates | Website-Implementierung | Mit Migrationsergebnissen koordinieren, ohne vollständigen Website-Neuaufbau anzunehmen. |
| Plugins und individuelle Erweiterungen | Erweiterungs- oder Entwicklungsverantwortlicher | Daten identifizieren, die Custom Service benötigen, und Verhalten, das separat neu implementiert werden muss. |
| Externe Buchhaltungs-, Auftragsabwicklungs-, Newsletter-, CRM- oder Marketplace-Systeme | Integrationsverantwortlicher | Vereinbarte Kennungen erhalten und Verbindungen außerhalb der gewöhnlichen Migrationsausführung neu bereitstellen. |
Diese Trennung verhindert, dass eine Lücke in der Zielkonfiguration als Datenfehler interpretiert wird. Sie verhindert zugleich, dass von Erweiterungen verwaltete Daten vorschnell als reine Implementierung abgetan werden, obwohl sie tatsächlich über Custom Service extrahiert oder transformiert werden müssen. Erkenntnisse aus Demo Migration sollten anhand dieser Verantwortungsübersicht klassifiziert werden, bevor der Servicepfad finalisiert wird.
Mit praktischen Szenarien den Servicepfad auswählen
Szenario 1: Standardkatalog und historische Datensätze. Products verwenden gewöhnliche Attribute und Optionen, Customers und Orders sind verständlich, und das Zielteam konfiguriert Phoca Cart. Standard Service kann ausreichen, wenn Demo Migration die schwierigen Stichproben bestätigt.
Szenario 2: Unterstütztes, aber betrieblich anspruchsvolles Projekt. Der Shop enthält mehrere Sprachen, Kundengruppen, viele Orders und ein festes Launch-Fenster, benötigt aber keine nicht unterstützten Erweiterungsdatensätze. Managed Service kann besser passen, weil Ausführung und Validierung die Hauptrisiken sind.
Szenario 3: Definierte Filter- oder Feldzuordnungsanforderung. Inaktive Products sollen anhand von Product-Feldbedingungen ausgeschlossen, ausgewählte Orders anhand von Order-Feldbedingungen ausgeschlossen oder unterstützte Standard-Quellfelder mit unveränderten Werten auf kompatible unterstützte Zielfelder neu zugeordnet werden. Data Filter oder Advanced Data Mapping können die Anforderung ohne Custom Service abdecken. Eine geeignete Datenbankspaltenzuordnung kann stattdessen Advanced Database Mapping verwenden, sofern auch die Quellplattform Open Source ist.
Szenario 4: Individuelle Bonus-, POS- oder Plugin-Datensätze. Geschäftskritische Daten liegen in Erweiterungstabellen oder individuellen Joomla-Feldern, die über unterstützte Zuordnung hinaus nicht standardmäßig interpretiert werden müssen. Für diese Datensätze sollte Custom Service eingeplant werden. Plugin-Installation, Neuaufbau des POS-Betriebs oder Konfiguration des aktiven Checkouts bleiben getrennte Aufgaben, sofern sie nicht ausdrücklich eingeschlossen werden.
Szenario 5: Konfigurationsänderungen nach Demo Migration. Product-Optionen, Sprachumfang, Kundengruppen oder Inhaltsauswahl benötigen eine unterstützte Anpassung, während der Migrationspfad gleich bleibt. Verwenden Sie Continue the Migration with a New Configuration, statt die frühere Einrichtung ungeprüft wiederzuverwenden.
Szenario 6: Ein wirklich eigenständiges Migrationsergebnis wird auf demselben gekauften Pfad benötigt. Der Händler benötigt ein sauberes, unabhängiges Ergebnis, während der gekaufte Pfad von Quellplattform zu Zielplattform unverändert bleibt. Verwenden Sie Perform a New Migration und validieren Sie Umfang, Abnahmekriterien und Zielverantwortung vollständig neu. Muss sich Quellplattform oder Zielplattform selbst ändern, ist dafür ein separat gekaufter Migrationsservice für den anderen Migrationspfad erforderlich.
Jedes Szenario sollte durch repräsentative Datensätze und ein dokumentiertes erwartetes Ergebnis gestützt werden. So wird die endgültige Serviceentscheidung nachvollziehbar und der breite Funktionsumfang der Plattform dient nicht als vager Grund für Über- oder Unterdimensionierung.
Abschließende Entscheidung über den Phoca-Cart-Servicepfad
| Nachweis | Wahrscheinlicher Servicepfad |
|---|---|
| Unterstützte Datensätze, klare Product-Strukturen, gewöhnlicher Joomla-Kontext, kundengeführte Ausführung | Standard Service |
| Unterstützter Umfang mit hohem Ausführungs-, Koordinations- oder Validierungsaufwand | Managed Service |
| Klar abgegrenzte unterstützte Filterung, Transformation von Feldwerten, unterstützte Feldzuordnung oder geeignete Datenbankspaltenzuordnung auf einem Pfad, bei dem Quell- und Zielplattform Open Source sind | Standard Service oder Managed Service mit Add-ons |
| Plugin-Tabellen, benutzerdefinierte Felder mit nicht standardmäßiger Interpretation, individuelle Transformationen, POS, externe Kennungen oder individuelle Joomla-Logik | Custom Service, gegebenenfalls mit Expert Handle und vereinbarten Add-ons |
Die Entscheidung sollte vor Full Migration bestätigt und durch Demo Migration getestet werden. Der richtige Ansatz erhält die geschäftliche Bedeutung der Phoca-Cart-Datensätze, ohne zu behaupten, die gesamte Joomla-Website und Erweiterungsumgebung gehörten zur Standarddatenmigration. Der freigegebene Plan sollte Service, Add-ons, Custom-Service-Anforderungen, Entity Points Plan, Validierungsverantwortliche, Zielkonfiguration, Erweiterungsarbeit und Additional Migration Option benennen. So bleibt die Launch-Verantwortung sichtbar und ungelöste Plugin- oder Joomla-Arbeit wird nicht mit einem akzeptierten Migrationsergebnis verwechselt.
Fazit
Die Wahl des Migrationsansatzes für Phoca Cart hängt von der Trennung zwischen unterstützten Commerce-Datensätzen, Joomla-Kontext, Zielkonfiguration, Erweiterungsdaten und individueller Implementierung ab. Standard Service passt zu klaren unterstützten Pfaden. Managed Service unterstützt bei Ausführung und Validierung. Add-ons decken klar begrenzte unterstützte Anforderungen ab. Custom Service ist für maßgeschneiderte und nicht standardmäßige Anforderungen vorgesehen.
Optionen für spätere Migrationen spiegeln anschließend wider, ob die akzeptierte Konfiguration weiterhin gilt, angepasst werden muss oder durch ein neues Migrationsergebnis ersetzt werden soll.
Häufige Fragen
Kann Standard Service für Phoca Cart ausreichen?
Ja. Er kann ausreichen, wenn der Migrationspfad unterstützt wird, die Kerndatensätze klar sind, Product-Strukturen verständlich sind und der Kunde den Service eigenständig ausführen und validieren kann.
Wann sollte Managed Service für eine Phoca-Cart-Migration gewählt werden?
Managed Service ist sinnvoll, wenn der Umfang unterstützt ist, der Händler aber fachkundige Ausführung, koordinierte Prüfung zwischen Joomla- und Commerce-Teams oder eine disziplinierte Launch-Terminplanung benötigt.
Migrieren Add-ons Phoca-Cart-Plugins?
Nein. Add-ons decken klar abgegrenzte unterstützte Anforderungen ab. Plugin-Tabellen, POS-Daten, individuelle Bonuslogik, maßgeschneiderte Attribute und Datensätze externer Systeme erfordern normalerweise eine Custom-Service-Prüfung oder separate Implementierung.
Was sollte Demo Migration für Phoca Cart beweisen?
Sie sollte Product-Optionen und -Attribute, Kundengruppen, Orders, mehrsprachige Daten, Inhalte, URLs und mit Erweiterungen verknüpfte Datensätze prüfen und zeigen, ob Lücken zu Konfiguration, Add-ons, Custom Service oder separater Implementierung gehören.
Welche Additional Migration Option passt zu einer späteren Phoca-Cart-Aktivität?
Verwenden Sie Continue the Migration with the Last Used Configuration, wenn die akzeptierte Einrichtung weiterhin gilt, Continue the Migration with a New Configuration, wenn unterstützte Einstellungen geändert werden müssen, und Perform a New Migration, wenn ein eigenständiges Ergebnis mit vollständiger erneuter Validierung benötigt wird.