Wenn J2Store als Zielplattform bewertet oder ausgewählt wird, beginnt die Wahl des richtigen Migrationsansatzes mit einer klaren Entscheidung über die vorgesehene Zielumgebung. J2Store-basierte Shops sind eng mit Joomla-Inhalten, Benutzern, Menüs, Templates, Plugins und Erweiterungsdaten verbunden. Die aktuelle J2Commerce-Dokumentation beschreibt außerdem einen Migrationspfad aus J2Store 3 und führt das Joomla-native Modell fort, in dem Joomla-Artikel als Products dienen können. Ein J2Store-Projekt darf deshalb nicht als generischer Transfer von Products und Orders geplant werden, ohne zuvor Versionen, Erweiterungen und Storefront-Abhängigkeiten zu identifizieren.
Der Servicepfad sollte sich danach richten, was der Händler erhalten möchte. Standard Service kann für saubere unterstützte Datensätze geeignet sein. Managed Service hilft, wenn Ausführung und Validierung eine koordinierte Betreuung durch Spezialisten erfordern. Add-ons unterstützen klar begrenzte Anforderungen an Datensatzfilterung, feldwertbezogene Transformation oder Feldzuordnung innerhalb unterstützter Funktionen. Custom Service ist erforderlich, wenn das erwartete Ergebnis von nicht unterstützten App- oder Plugin-Daten, benutzerdefinierten Feldern mit nicht standardmäßiger Interpretation, individueller Verarbeitung außerhalb unterstützter Zuordnungen, maßgeschneiderten Transformationen, Legacy-Datenbankstrukturen, externen Kennungen oder individueller Migrationslogik abhängt.
Innerhalb der Next-Cart Migrationsservices sollte der beabsichtigte J2Store-Übergang bestimmen, welcher Umfang unterstützt wird, wer die Ausführung verantwortet, welche Add-ons benötigt werden und welche Legacy-Joomla-Anforderung tatsächlich in den Custom Service gehört.
Den J2Store-Übergang definieren, bevor ein Service gewählt wird
Ein J2Store-Projekt kann verschiedene geschäftliche Situationen darstellen:
- Migration von einer anderen Plattform in eine J2Store- oder J2Commerce-kompatible Joomla-Umgebung;
- Bewahrung historischer J2Store-Datensätze, während der Händler die Joomla-Commerce-Schicht modernisiert;
- Migration aus einer Legacy-J2Store-Installation in eine andere Zielplattform;
- Konsolidierung von Joomla-Inhalten und Commerce-Datensätzen in einem neuen Betriebsmodell.
Diese Situationen sollten nicht mit derselben Standardentscheidung behandelt werden. Ein Shop, der innerhalb der Joomla-/J2Commerce-Familie bleibt, braucht besondere Aufmerksamkeit für artikelbasierte Product-Beziehungen, Checkout-Verhalten, Plugins und Darstellung. Bei einem Wechsel weg von J2Store können dagegen historische Products, Customers, Orders, URLs und Nachweise für die Stilllegung der Legacy-Umgebung im Mittelpunkt stehen.
| Übergangsfrage | Signal für geringere Komplexität | Signal für höhere Komplexität |
|---|---|---|
| Product-Darstellung | Products verwenden klare Joomla-Artikelbeziehungen und erkennbare Product-Felder. | Product-Bedeutung hängt von benutzerdefinierten Feldern, Plugins, Abonnements, Buchungen, Bundles oder individuellen Artikellayouts ab. |
| Customer- und Order-Historie | Standard-Joomla-Benutzer, Customers, Adressen und Orders. | Individuelle Registrierungsfelder, Mitgliedschaftsregeln, Teilzahlungen, Abonnementstatus oder plugin-eigene Order-Details. |
| Storefront-Beziehung | Einfache Menüs und konventionelle Joomla-Templates. | Komplexes Menürouting, Page-Builder-Ausgabe, Template-Overrides, Module, mehrsprachige Assoziationen oder individuelle URLs. |
| Verantwortung für Erweiterungen | Wenige unterstützte Erweiterungen. | Zahlungs-, Versand-, Checkout-, Mitgliedschafts-, Buchungs-, Steuer- oder Integrations-Erweiterungen speichern wesentliche Daten. |
| Zielrichtung | Klar definierte unterstützte Zielplattform und eindeutiger Umfang. | Unklarer Versionsübergang, gemischtes J2Store-/J2Commerce-Verhalten oder umfassender Joomla-Neuaufbau. |
Der Servicepfad sollte erst ausgewählt werden, nachdem der Händler bestätigt hat, welcher dieser Betriebskontexte tatsächlich vorliegt.
Wann Standard Service ausreichen kann
Standard Service kann geeignet sein, wenn der Migrationspfad unterstützt wird, die Quelldatensätze zugänglich sind und das erwartete Ergebnis innerhalb gewöhnlicher Migrationsfunktionen liegt. Bei diesem Next-Cart Service verantwortet der Kunde Vorbereitung, Verbindungsdaten, Konfigurationsentscheidungen, Ausführung und Validierung.
Ein guter Kandidat für Standard Service hat typischerweise:
- eine klar identifizierte Quellplattform und Zielplattform;
- konventionelle Products, Categories, Customers, Orders und Inhalte;
- Joomla-artikelbasierte Products mit konsistenten Kennungen;
- begrenzte Nutzung benutzerdefinierter Felder und erweiterungseigener Datensätze;
- verständliche Customer- und Order-Beziehungen;
- einen definierten Umgang mit Joomla-Benutzern, Menüs, Aliassen und Inhalts-URLs;
- keine Erwartung, dass Themes, Plugins, Zahlungsmethoden oder Checkout-Logik durch die Standardmigration neu aufgebaut werden;
- ein Team, das Ergebnisse von Demo Migration und Full Migration bewerten kann.
Standard Service ist nicht auf kleine Shops beschränkt. Auch eine große Menge gewöhnlicher Datensätze kann geeignet bleiben, wenn die Entity Points-Kapazität richtig geplant ist und die Datenbedeutung klar ist. Umgekehrt kann ein kleiner Shop ungeeignet sein, wenn Abonnements, Buchungen, individuelle Checkout-Felder oder plugin-eigene Daten geschäftskritisch sind.
Wann Managed Service die sicherere Wahl ist
Managed Service ist sinnvoll, wenn der Umfang weitgehend unterstützt bleibt, der Händler aber Next-Cart Spezialisten für die Ausführung und strukturierte Koordination benötigt. Er reduziert den operativen Aufwand für Teams, die den Prozess nicht sicher allein steuern können.
Managed Service ist häufig passend, wenn:
- der Händler mit der Beziehung zwischen Joomla- und J2Store-Datensätzen nicht vertraut ist;
- ein großer Katalog oder umfangreiche Order-Historie einen hohen Prüfaufwand erzeugt;
- das Projekt mehrere Joomla-Sprachen, Benutzergruppen oder Inhaltsbereiche umfasst;
- mehrere Geschäftsverantwortliche Product-, Customer-, Order- und SEO-Ergebnisse freigeben müssen;
- ein fester Launch-Termin disziplinierte Reihenfolge und Issue-Tracking verlangt;
- die Quelldaten unterstützt, aber inkonsistent genug für eine sorgfältige Prüfung sind;
- der Händler Expert Handle im Serviceplan einsetzen möchte.
Managed Service macht nicht unterstützte Plugin-Daten nicht zu Standarddaten. Er verändert die Ausführungsverantwortung. Hängt das Ergebnis von individuellen Datensätzen oder Transformationen ab, muss Custom Service weiterhin geprüft werden, selbst wenn die Migration zusätzlich gemanagt wird.
Wo Add-ons eingesetzt werden
Add-ons unterstützen konkrete Anforderungen innerhalb eines unterstützten Migrationspfads. Sie sind sinnvoll, wenn die Kerndatensätze normal migriert werden können, der Händler aber klar begrenzte Filterung, ausdrucksbasierte Transformation von Feldwerten oder eine unterstützte Feldzuordnung benötigt.
Beispiele für J2Store sind:
- Data Filter, um Bedingungen auf Product-, Customer- oder Order-Felder anzuwenden;
- Data Transformation, um unterstützte Feldwerte über Ausdrücke zu transformieren;
- Advanced Data Mapping, um unterstützte Standard-Quellfelder auf kompatible unterstützte Zielfelder umzulegen, ohne den Wert zu verändern;
- Advanced Database Mapping für eine unterstützte Zuordnung von Datenbankspalten, wenn sowohl die Quellplattform als auch J2Store als Zielplattform Open Source sind;
- ausgewählte CMS Pages oder Blog Posts zu verarbeiten, sofern unterstützt;
- jeden gefilterten Datensatzsatz, transformierten Wert und jedes neu zugeordnete Feld gegen ein definiertes Ergebnis zu validieren.
Add-ons ersetzen Custom Service nicht. Sie dürfen nicht den Eindruck erwecken, dass ein J2Store-Plugin, eine Abonnement-Engine, ein Buchungsablauf, eine Zahlungserweiterung, ein Page-Builder-Layout oder eine individuelle Joomla-Komponente automatisch extrahiert und neu aufgebaut wird.
Die praktische Frage lautet, ob der Bedarf klar begrenzt und unterstützt bleibt. Eine eindeutige unterstützte Neuzuordnung von Quell- zu Zielfeld kann Advanced Data Mapping entsprechen. Bei einer Migration nach J2Store kommt Advanced Database Mapping für eine unterstützte Datenbankspalten-Neuzuordnung nur infrage, wenn sowohl die Quellplattform als auch J2Store als Zielplattform Open Source sind. Eine Plugin-Tabelle mit wiederkehrendem Zahlungsstatus erfordert typischerweise eine Prüfung durch Custom Service und kann zusätzlich eine separate Zielimplementierung benötigen.
Wann Custom Service geprüft werden sollte
Custom Service ist passend, wenn das gewünschte Migrationsergebnis eine individuelle Prüfung oder nicht standardmäßige Verarbeitung benötigt. Bei J2Store ist das häufig der Fall, weil die Commerce-Schicht in Joomla eingebettet und durch Apps, Plugins, benutzerdefinierte Felder außerhalb unterstützter Zuordnungen, Templates und externe Systeme erweitert wird.
Typische Eskalationssignale sind:
- Product-Daten in individuellen Joomla-Feldern oder Erweiterungstabellen;
- Abonnements, Mitgliedschaften, Buchungen, Reservierungen, Teilzahlungen oder Bundles mit nicht standardmäßigen Datensätzen;
- individuelle Checkout-Felder oder Order-Metadaten;
- plugin-eigene Zahlungs- oder Versandinformationen, die in einer bestimmten Form erhalten werden müssen;
- individuelle Benutzergruppen, Zugriffsregeln oder Kontobeziehungen;
- maßgeschneiderte Menü-, Alias- oder Mehrsprachigkeitsbeziehungen, die das Zielergebnis beeinflussen;
- ERP-, CRM-, Auftragsabwicklungs-, Buchhaltungs- oder Marketplace-Kennungen;
- individuelle Datenbankspalten, Komponenten, Module oder APIs;
- ein Zielübergang, der eine nicht standardmäßige Transformation aus J2Store-Strukturen erfordert;
- eine individuelle Plattform auf einer Seite des Migrationspfads.
Custom Service umfasst nicht automatisch die Installation von J2Commerce, Joomla-Upgrades, Plugin-Entwicklung, Theme- oder Page-Builder-Implementierung, Zahlungs- oder Versandkonfiguration, Einrichtung einer Abonnement-Engine, Bereitstellung externer Integrationen oder den vollständigen Neuaufbau der Site. Diese Verantwortlichkeiten müssen ausdrücklich Teil des vereinbarten Umfangs sein.
Entity Points und Umfangsplanung für J2Store
Entity Points helfen, das Volumen berechtigter Migrationsdatensätze zu planen. Bei späterer J2Store-Aktivität bleiben bereits gezählte berechtigte Datensätze auf demselben Migrationspfad einmal gezählt; Komplexität aus Joomla-Inhalten, Erweiterungen, Menüs und benutzerdefinierten Feldern wird separat bewertet. Joomla-Artikel, die als Products verwendet werden, sollten entsprechend ihrer berechtigten Product-Rolle gezählt werden und nicht allein deshalb doppelt, weil sie zugleich Joomla-Inhaltsdatensätze sind.
Categories, Joomla-Benutzer, CMS Pages, benutzerdefinierte Felder, Menüs, Module, Plugins, Zahlungsdatensätze, Versandregeln und Erweiterungstabellen können die Migrationskomplexität erhöhen, ohne eigene Entity Points-Datensatztypen zu werden.
Bei J2Store zählen Entity Points berechtigte neue Products, Customers, Orders und Blog Posts beim ersten Migrationsvorgang. Joomla-Artikel, Benutzer, Menübeziehungen, Erweiterungsdatensätze und benutzerdefinierte Felder können die Komplexität erhöhen, ohne als zusätzliche gezählte Datensatztypen zu gelten; bereits gezählte Datensätze werden nicht nur deshalb erneut gezählt, weil später eine weitere Aktion auf demselben Pfad erfolgt.
| Umfangsfrage | Bedeutung für Entity Points | Separate Komplexitätsfrage |
|---|---|---|
| Große Menge gewöhnlicher Products | Erfordert ausreichende Entity Points-Kapazität. | Sind Artikel-/Product-Beziehungen konsistent? |
| Neue Orders vor dem Launch | Können Entity Points verbrauchen, wenn sie erstmals migriert werden. | Bleiben Status, Summen und Plugin-Details verständlich? |
| Bereits vorhandene Datensätze werden erneut verarbeitet | Kein doppelter Verbrauch allein wegen einer weiteren Aktion. | Passt die Zielkonfiguration weiterhin? |
| Benutzerdefinierte Felder und Plugin-Tabellen | Keine eigenen Entity Points-Typen. | Werden sie unterstützt, individuell in Custom Service behandelt oder der Zielimplementierung zugewiesen? |
Entity Points dimensionieren berechtigte Datensätze. Sie entscheiden nicht darüber, ob J2Store-Erweiterungen oder Legacy-Strukturen unterstützt werden.
Was Demo Migration beweisen sollte
Demo Migration sollte gezielt die Datensätze prüfen, die J2Store-spezifische Komplexität sichtbar machen. Eine Stichprobe nur mit einfachen Products und aktuellen Orders reicht nicht aus.
Eine sinnvolle Stichprobe umfasst:
- Joomla-artikelbasierte Products mit unterschiedlichen Produkttypen;
- Products mit Optionen, benutzerdefinierten Feldern, Medien und sprachspezifischen Inhalten;
- Products, die von Abonnements, Buchungen, Mitgliedschaften oder Plugins beeinflusst werden, sofern relevant;
- registrierte Customers, Gast-Orders und komplexe Adressdatensätze;
- Orders mit Rabatten, Steuern, Versand, Zahlungskontext, Statushistorie und benutzerdefinierten Feldern;
- priorisierte Joomla-Artikel, CMS Pages, Blog Posts, Menüs, Aliasse und URLs;
- Datensätze mit Kennungen externer Systeme;
- Beispiele aus jedem relevanten Storefront- oder Sprachkontext.
Demo Migration sollte zeigen, ob der gewählte Servicepfad stark genug ist. Sind gewöhnliche Datensätze korrekt, fehlt jedoch plugin-eigene Bedeutung, darf das Projekt nicht mit der Annahme in Full Migration gehen, das größere Volumen werde die Lücke lösen. Die Lücke muss als Konfiguration, Add-on-Umfang, Custom Service oder separate Zielimplementierung klassifiziert werden.
Die Entscheidung nach Demo Migration sollte ausdrücklich lauten: fortfahren, unterstützte Konfiguration anpassen, klar begrenzte Add-ons ergänzen oder definierte Anforderungen an Custom Service eskalieren.
Optionen für spätere Migrationen für J2Store
Optionen für spätere Migrationen sollten danach gewählt werden, ob die akzeptierte Konfiguration gültig bleibt, nachdem sich die Quelle oder Projektrichtung verändert hat.
| Aktuelle Aktion | Passender Einsatz | Schwerpunkt der J2Store-Neuvalidierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Der akzeptierte Umfang und die Zuordnungen bleiben gültig und spätere Quellaktivität muss konsistent verarbeitet werden. | Neue Products, Customers, Orders, Blog Posts, Joomla-Artikelbeziehungen, Aliasse und mit Erweiterungen verknüpfte Felder. |
| Continue the Migration with a New Configuration | Derselbe Migrationspfad bleibt passend, aber unterstützte Filter-, Zuordnungs- oder Zieleinstellungen müssen geändert werden. | Product-/Artikelzuordnung, Customer-Behandlung, Order-Statuszuordnung, Inhaltsauswahl, URLs und Ausschlüsse. |
| Perform a New Migration | Der Händler benötigt ein eigenständiges Migrationsergebnis statt einer Fortsetzung der früheren Einrichtung. Der gekaufte Migrationspfad von Quellplattform zu Zielplattform bleibt unverändert. | Vollständiger Product-, Customer-, Order-, Inhalts-, Joomla-, Plugin-, SEO- und Abnahmeumfang. |
Diese Aktionen führen nicht automatisch Joomla-Upgrades durch, installieren J2Commerce, erstellen Plugins neu, bauen Templates wieder auf oder stellen Integrationen bereit. Sie arbeiten innerhalb des vereinbarten Migrationsserviceumfangs.
Datenmigration von Joomla- und Commerce-Implementierung trennen
Eine Serviceentscheidung wird belastbarer, wenn jede Anforderung dem Team und der Ebene zugeordnet ist, die sie tatsächlich verantwortet. Eine Migration kann vereinbarte Datensätze bewahren oder transformieren. Der zukünftige Shop hängt jedoch zusätzlich von Joomla-Konfiguration, Einrichtung der Commerce-Erweiterung, Darstellung, Zugriffskontrolle und verbundenen Diensten ab. Werden all diese Punkte zu einer einzigen „Migrationsanforderung“ vermischt, lässt sich der Serviceumfang weder sauber bepreisen noch konsistent validieren.
| Anforderung | Primäre Zuständigkeit | Relevanz für die Migration |
|---|---|---|
| Product-, Customer-, Order- und unterstützte Inhaltsdatensätze | Migrationsserviceumfang | Datensatzunterstützung, Zuordnung, Entity Points und Abnahmekriterien bestätigen. |
| Joomla-Benutzer, Menüs, Sprachen, Aliasse und Zugriffskonfiguration | Zielvorbereitung und Implementierung | Abhängigkeiten identifizieren und Ergebnisse validieren, ohne vollständige Site-Einrichtung als enthalten vorauszusetzen. |
| Installation und Konfiguration von J2Commerce oder Nachfolge-Erweiterung | Zielimplementierung | Betriebsumgebung vor der finalen Validierung herstellen. |
| Zahlung, Versand, Steuer, Checkout, Abonnements und Buchungsverhalten | Zielkonfiguration, Erweiterungen und Anbieter | Historischen Kontext im vereinbarten Umfang bewahren; Live-Verhalten separat konfigurieren. |
| Templates, Page Builder, Module und Layout-Overrides | Design und Implementierung | Darstellung außerhalb der gewöhnlichen Datensatzmigration neu aufbauen oder anpassen. |
| ERP-, CRM-, Buchhaltungs-, Auftragsabwicklungs- oder Marketplace-Verbindungen | Integrationsverantwortlicher | Benötigte Kennungen im vereinbarten Umfang erhalten und Integrationen separat neu bereitstellen. |
Diese Zuständigkeitskarte verhindert zwei gegensätzliche Fehler. Der erste besteht darin, Custom Service für Aufgaben zu wählen, die tatsächlich Zielimplementierung sind. Der zweite besteht darin, bei einem Standardansatz zu bleiben, obwohl geschäftskritische Daten in Erweiterungstabellen verborgen sind und echte individuelle Migrationsarbeit benötigen. Jede Fragestellung sollte anhand von Nachweisen klassifiziert werden, bevor der finale Serviceplan freigegeben wird.
Den Ansatz mit szenariobasierten Nachweisen bestätigen
Eine szenariobasierte Prüfung übersetzt abstrakte Servicebeschreibungen in eine konkrete J2Store-Entscheidung.
Szenario 1: Konventioneller artikelbasierter Katalog. Products verwenden Joomla-Artikel konsistent, Customers und Orders sind verständlich, und das Zielteam übernimmt Joomla- und Commerce-Konfiguration. Standard Service kann ausreichen, nachdem Demo Migration repräsentative Product-, Customer-, Order-, Inhalts- und URL-Beziehungen bestätigt hat.
Szenario 2: Unterstützte Daten bei begrenzter interner Kapazität. Die Datensätze bleiben konventionell, doch der Händler hat einen großen Katalog, mehrere Sprachen und einen festen Launch-Termin. Managed Service kann sicherer sein, weil die Hauptschwierigkeit in Ausführung und koordinierter Validierung statt in individueller Extraktion liegt.
Szenario 3: Klar begrenzte Anpassung des Ergebnisses. Der Händler möchte veraltete Products über eine Bedingung auf Product-Feldern ausschließen, ausgewählte Orders über eine Order-Feldbedingung filtern oder unterstützte Standard-Quellfelder auf kompatible unterstützte Zielfelder umlegen, ohne die Werte zu verändern. Data Filter oder Advanced Data Mapping können die definierte Anforderung lösen, ohne das gesamte Projekt in Custom Service zu verschieben. Geht es stattdessen um eine unterstützte Datenbankspalten-Neuzuordnung, kann Advanced Database Mapping passen, wenn sowohl die Quellplattform als auch J2Store als Zielplattform Open Source sind.
Szenario 4: Erweiterungseigene Geschäftslogik. Abonnements, Buchungen, Mitgliedschaften, individuelle Checkout-Felder oder externe Kennungen liegen außerhalb gewöhnlicher Datensätze. Für die Datenanforderung sollte Custom Service geprüft werden; Installation der Erweiterung und aktive Betriebskonfiguration bleiben separat, sofern nicht ausdrücklich vereinbart.
Szenario 5: Zielannahmen ändern sich nach dem Test. Demo Migration zeigt, dass die aktuelle Konfiguration nicht zur vorgesehenen Joomla- oder Commerce-Struktur passt. Der Händler sollte die unterstützte Konfiguration oder den Zielimplementierungsplan überarbeiten und die passende Additional Migration Option nur dann wählen, wenn der feste Migrationspfad unverändert bleibt. Ein anderer Quellplattform-zu-Zielplattform-Pfad erfordert eine separat gekaufte Migration.
Der bevorzugte Ansatz ist der kleinste, der die dokumentierten Abnahmekriterien vollständig erfüllt. Szenarionachweise sollten mit repräsentativen IDs, erwarteten Ergebnissen und klarer Zuständigkeit dokumentiert werden, damit die Serviceauswahl überprüfbar statt subjektiv bleibt.
Finale Servicepfad-Entscheidung für J2Store
Die praktische Auswahl lässt sich so zusammenfassen:
| Nachweis | Wahrscheinlicher Servicepfad |
|---|---|
| Unterstützte Datensätze, klare Joomla-Beziehungen, gewöhnlicher Umfang, kundengeführte Durchführung | Standard Service |
| Unterstützter Umfang mit anspruchsvoller Koordination, Validierung oder Launch-Planung | Managed Service |
| Klar begrenzte unterstützte Anforderungen an Datensatzfilterung, Feldwerttransformation oder Feldzuordnung | Standard oder Managed Service mit Add-ons |
| Benutzerdefinierte Felder mit nicht standardmäßiger Interpretation, Plugin-Tabellen, Legacy-Strukturen, maßgeschneiderte Transformationen oder Abhängigkeiten von externen Systemen | Custom Service, gegebenenfalls mit Expert Handle und vereinbarten Add-ons |
Der Servicepfad sollte vor Full Migration bestätigt und durch Demo Migration geprüft werden. Der richtige Ansatz ist nicht der mit den meisten Funktionen, sondern derjenige, der zur tatsächlichen Zuständigkeit und Bedeutung der J2Store-Datensätze passt. Die finale Entscheidung sollte ausgewählten Service, gekaufte Add-ons, individuelle Anforderungen, Entity Points Plan, Validierungsverantwortliche, Zuständigkeiten der Zielimplementierung und die vorgesehene Folgeaktion benennen. Jede ungeklärte Erweiterungsabhängigkeit bleibt eine ausdrückliche Bedingung und darf nicht in einer allgemeinen Freigabe verborgen werden.
Fazit
Die Auswahl des J2Store-Migrationsansatzes hängt von Joomla-Kontext, Product-Darstellung, Erweiterungsverantwortung, Anforderungen an historische Daten und der vorgesehenen Zielumgebung ab. Standard Service kann für klare unterstützte Datensätze funktionieren. Managed Service reduziert Ausführungs- und Koordinationsaufwand. Add-ons unterstützen begrenzte unterstützte Anforderungen. Custom Service übernimmt maßgeschneiderte und nicht standardmäßige Anforderungen.
Optionen für spätere Migrationen werden anschließend danach gewählt, ob die akzeptierte Konfiguration unverändert gültig bleibt, angepasst werden muss oder durch ein eigenständiges neues Migrationsergebnis ersetzt werden soll.
Häufige Fragen
Kann J2Store Standard Service verwenden?
Ja, wenn der Migrationspfad unterstützt wird, Datensätze zugänglich und erkennbar sind, Joomla-Artikel-/Product-Beziehungen klar sind und der Kunde den Service eigenständig bedienen und validieren kann.
Wann ist Managed Service sicherer?
Managed Service ist sinnvoll, wenn die Daten weitgehend unterstützt werden, der Händler aber fachliche Ausführung, koordinierte Validierung oder Launch-Planung über Commerce- und Joomla-Verantwortliche hinweg benötigt.
Migrieren Add-ons J2Store-Plugins?
Nein. Add-ons behandeln klar begrenzte unterstützte Anforderungen. Plugin-Tabellen, Abonnements, Buchungen, individuelles Checkout-Verhalten und maßgeschneiderte Joomla-Daten benötigen typischerweise eine Custom Service-Prüfung oder eine separate Zielimplementierung.
Was sollte Demo Migration für J2Store beweisen?
Sie sollte Product-/Artikelbeziehungen, Customer- und Order-Bedeutung, Inhalts- und URL-Kontinuität sowie die Behandlung von benutzerdefinierten Feldern, Plugins und externen Kennungen vor Full Migration belegen.
Welche Additional Migration Option passt zu einer J2Store-Folgeaktion?
Verwenden Sie Continue the Migration with the Last Used Configuration, wenn die akzeptierte Einrichtung gültig bleibt, Continue the Migration with a New Configuration, wenn unterstützte Einstellungen geändert werden müssen, und Perform a New Migration, wenn der Händler ein eigenständiges Ergebnis mit vollständiger Neuvalidierung benötigt.