Le choix de l’approche de migration vers J2Commerce doit commencer par la structure de fonctionnement de la boutique. J2Commerce n’est pas seulement une destination de catalogue. Il s’agit d’un environnement e-commerce natif de Joomla dans lequel les Products, les articles, les Categories, les champs du processus de commande, les moyens de paiement, les modes de livraison, les statuts de commande, les apps, les Modules, les templates et les extensions peuvent tous influencer le résultat migré.
La bonne approche est celle qui protège le sens commercial des données sans complexifier inutilement le projet. Une boutique simple peut correspondre au Standard Service. Un périmètre pris en charge mais sensible sur le plan opérationnel peut davantage bénéficier du Managed Service. Une condition définie sur un type de données, une expression appliquée à une valeur, une destination de champ standard prise en charge ou une destination de colonne de base de données éligible peut relever d’un Standard Add-on. Des données appartenant à une app, un processus de commande personnalisé, une logique Product inhabituelle, des identifiants externes ou une forte complexité héritée de J2Store peuvent nécessiter une évaluation dans le cadre du Custom Service.
Dans les services de migration Next-Cart, les éléments utilisés pour décider de l’approche J2Commerce doivent distinguer les données Joomla natives prises en charge, la responsabilité d’exécution, les besoins circonscrits de mise en correspondance ou de filtrage et le périmètre personnalisé propre aux extensions.
Ce que l’approche de migration doit prendre en compte
L’approche doit correspondre à trois dimensions : la structure des données source, le modèle de fonctionnement de J2Commerce en cible et la capacité du marchand à examiner les résultats. Un projet n’est pas nécessairement simple parce que son catalogue est petit. Il peut devenir complexe si le fonctionnement des Products dépend d’options, d’accès à des téléchargements, d’abonnements, de réservations, d’acomptes, de champs de commande, de statuts personnalisés ou d’extensions.
Le choix doit également tenir compte de la couche Joomla. Les pages Product peuvent dépendre de la structure des articles, des Categories, des alias, des métadonnées, des menus, des Modules, des templates et des règles d’accès. Le processus de commande peut exiger une configuration dans la plateforme cible. Les Orders historiques peuvent nécessiter une mise en correspondance des statuts et un contexte lisible concernant le paiement ou la livraison. Ces exigences doivent orienter le choix du service avant la Full Migration.
| Signal lié au périmètre | Conséquence pour l’approche |
|---|---|
| Données Product, Customer et Order prises en charge avec une complexité limitée | Le Standard Service peut suffire. |
| Données prises en charge, mais le marchand souhaite que Next-Cart pilote l’exécution et la revue | Le Managed Service peut être plus approprié. |
| Besoins ciblés de filtrage des enregistrements, de transformation des valeurs ou de mise en correspondance de champs | Des Add-ons peuvent être utiles. |
| Données appartenant à une app, champs non pris en charge, processus de commande personnalisé, logique Product inhabituelle ou identifiants externes | Le Custom Service doit être évalué. |
| Boutique J2Store historique avec add-ons, overrides ou fonctionnement personnalisé | Traiter le projet comme une transition à planifier, et non comme un simple rafraîchissement. |
| Exigences incertaines concernant la vitrine, les URL ou la configuration | Élargir les éléments de preuve de la Demo Migration avant d’approuver le périmètre. |
L’approche doit être choisie une fois que le marchand sait clairement ce qui doit être transféré comme données, ce qui doit être configuré dans J2Commerce et ce qui exige une interprétation personnalisée.
Quand le Standard Service peut convenir
Le Standard Service peut être adapté lorsque la plateforme source est prise en charge, que les types de données et les enregistrements requis entrent dans les capacités habituelles de migration, que la boutique ne dépend pas fortement d’une logique personnalisée non prise en charge et que le marchand peut exécuter, examiner et approuver la migration avec l’appui d’experts lorsqu’il en a besoin.
Pour J2Commerce, le Standard Service est particulièrement pertinent lorsque les Products peuvent être représentés clairement, que les Customers et Orders reposent sur des champs prévisibles, que le processus de commande ne dépend pas d’une logique source inhabituelle et que la configuration cible peut être assurée par le marchand ou son équipe d’implémentation. Il peut aussi convenir aux boutiques qui souhaitent transférer proprement des données prises en charge et sont en mesure de valider les pages Product, Categories, Customers, Orders et le fonctionnement de la vitrine après la Demo Migration.
| Signal favorable au Standard Service | Exemple dans J2Commerce |
|---|---|
| Structure Product prévisible | Des Products simples ou des options Product bien documentées peuvent être représentés sans ambiguïté. |
| Enregistrements Customer et Order ordinaires | Les données de facturation, livraison, paiement, taxe et statut restent compréhensibles. |
| Environnement Joomla cible préparé | Articles, Categories, menus, templates et Modules sont prêts pour la validation. |
| Champs du processus de commande gérables | Les champs requis sont pris en charge ou peuvent être traités par la configuration cible. |
| Dépendance limitée aux extensions | Les apps et plugins ne détiennent pas de données migrées critiques. |
| Marchand en mesure de vérifier les résultats | Les retours issus de la Demo Migration peuvent être examinés sans coordination lourde. |
Le Standard Service ne doit pas être choisi uniquement parce qu’il est plus léger. Si la boutique dépend d’add-ons J2Store historiques, de données appartenant à des apps, de champs personnalisés, d’un processus de commande personnalisé ou d’identifiants externes, une approche trop simple peut créer des problèmes au moment de la validation.
Quand le Managed Service est plus adapté
Le Managed Service est utile lorsque les capacités standard couvrent le projet, mais que le marchand souhaite que Next-Cart pilote l’exécution, structure la coordination et apporte un accompagnement plus étroit lors des revues. Il ne s’agit pas du Custom Service. Le Managed Service peut renforcer l’exécution et l’accompagnement, mais il ne transforme pas une exigence non prise en charge en exigence prise en charge.
Pour J2Commerce, le Managed Service convient souvent aux marchands dont la plateforme est suffisamment complexe pour justifier une revue guidée, sans pour autant exiger un développement sur mesure. La boutique peut comporter plusieurs types de Products, un historique Customer et Order important, des URL sensibles au SEO, des informations de paiement et de livraison, des statuts personnalisés ou des éléments hérités de J2Store qui nécessitent une validation attentive.
| Signal favorable au Managed Service | Pourquoi cela aide |
|---|---|
| Le marchand souhaite une exécution pilotée par Next-Cart | Réduit la charge opérationnelle pendant la préparation, la Demo Migration et la Full Migration, tout en laissant au marchand la responsabilité de la vérification finale. |
| La revue exige une coordination | Aide à organiser les retours sur le catalogue, les Customers, les Orders et la vitrine. |
| La boutique possède un historique important | Les anciens Orders, Customers, statuts et données de traitement des commandes nécessitent une validation structurée. |
| Des éléments hérités de J2Store existent | Add-ons, overrides et anciennes hypothèses doivent être examinés de façon délibérée. |
| Le calendrier de lancement est sensible | Les activités de migration, les données récentes et les points de validation doivent être séquencés plus clairement. |
Le Managed Service est pertinent lorsque la migration est prise en charge, mais que le marchand bénéficie d’un processus davantage guidé. Si le projet exige une logique personnalisée, le traitement d’une source non prise en charge, une nouvelle interprétation des champs ou une transformation propre à une app, le Custom Service doit toujours être évalué.
Comment les Add-ons s’intègrent dans une migration vers J2Commerce
Les Add-ons doivent répondre à des besoins ciblés correspondant à une capacité disponible. Ils sont utiles lorsque l’exigence est spécifique, prise en charge et directement liée au résultat de migration. Ils ne doivent pas servir de substitut général à la configuration de J2Commerce ou à du développement personnalisé.
Dans J2Commerce, les Add-ons peuvent aider lorsque le marchand doit filtrer les enregistrements d’un type de données donné, transformer les valeurs de champs au moyen d’expressions, rediriger un champ standard pris en charge vers un autre champ standard pris en charge, ou réaffecter une colonne de base de données éligible dans le cadre d’un besoin clairement défini. Ils sont particulièrement utiles lorsque la Demo Migration révèle un écart précis qui peut être corrigé sans modifier l’approche générale du service.
| Besoin | Add-on à envisager | Exemple dans J2Commerce |
|---|---|---|
| Limiter les enregistrements migrés | Data Filter | Appliquer des conditions fondées sur des champs aux Products, Customers, Orders ou contenus pris en charge afin que seuls les enregistrements correspondants soient migrés. |
| Transformer les valeurs de champs prises en charge | Data Transformation | Appliquer des expressions afin de produire, pendant la migration, des valeurs définies compatibles avec la cible. |
| Changer la destination de champs standards pris en charge | Advanced Data Mapping | Faire correspondre un champ source pris en charge à un autre champ cible J2Commerce ou Joomla pris en charge, sans modifier la valeur. |
| Changer la destination de colonnes de base de données éligibles | Advanced Database Mapping | Pour une migration vers J2Commerce, faire correspondre une colonne de base de données source prise en charge à une colonne cible compatible sans modifier la valeur, uniquement lorsque la plateforme source est elle aussi Open-Source. |
| Modifier un Add-on | Tailored Add-on via le Custom Service | Adapter un Standard Add-on à une exigence spécifique au projet. |
| Créer un traitement sur mesure | Custom Add-on via le Custom Service | Traiter des enregistrements appartenant à une app, des identifiants externes ou un fonctionnement Product non pris en charge. |
La frontière est essentielle. Si le besoin concerne un filtrage pris en charge, une transformation de valeurs, une mise en correspondance de champs standards ou une mise en correspondance éligible de colonnes de base de données, un Standard Add-on peut suffire. Si le projet exige de comprendre le fonctionnement d’une app source, d’un add-on J2Store, d’un champ de commande personnalisé ou d’un système externe, le Custom Service constitue une voie d’évaluation plus sûre.
Quand évaluer le Custom Service
Le Custom Service doit être évalué lorsque l’exigence de migration dépend d’un fonctionnement, d’une propriété de données personnalisée ou d’une interprétation qui ne peut pas être traitée par les capacités standard. Dans les projets J2Commerce, ces cas apparaissent souvent autour des types de Products, des apps, de champs personnalisés dont le traitement requis dépasse les capacités de mise en correspondance prises en charge, du processus de commande, des intégrations externes, des structures historiques de J2Store ou d’un travail d’implémentation Joomla personnalisé.
Une évaluation Custom Service ne signifie pas que le projet pose problème. Elle indique qu’un cadrage explicite est nécessaire. L’objectif est d’éviter qu’un fonctionnement important reste dissimulé dans une demande générale de migration et ne soit découvert qu’après la Demo Migration.
| Déclencheur du Custom Service | Pourquoi le traitement standard peut ne pas suffire |
|---|---|
| Données appartenant à une app | Elles peuvent se trouver en dehors des structures Product, Customer ou Order ordinaires. |
| Processus de commande personnalisés | Les champs, étapes, règles de validation et contenus d’e-mails peuvent nécessiter une interprétation sur mesure. |
| Fonctionnement Product non pris en charge | Abonnements, réservations, bundles, acomptes ou logique d’options peuvent dépendre d’une extension. |
| Identifiants externes | ERP, entrepôt, CRM ou intégrations peuvent dépendre d’identifiants qui doivent rester stables. |
| Add-ons J2Store historiques | Des données ou règles peuvent dépendre d’un composant sans équivalent direct en cible. |
| Attentes liées aux templates ou aux routes | Les données seules ne peuvent pas reproduire la structure de présentation ou de routage. |
| Plateforme source Custom Platform | Le modèle source peut devoir être analysé avant de déterminer ce qui peut être migré. |
Le Custom Service doit également être envisagé lorsqu’un Standard Add-on doit être adapté au-delà de son périmètre fixe, ou lorsqu’un Custom Add-on ou une logique de migration spécifique est nécessaire. Un champ personnalisé n’est pas, à lui seul, une raison de basculer vers le Custom Service : il faut d’abord vérifier si une mise en correspondance standard prise en charge répond au besoin, puis, lorsque le parcours de migration est éligible, si Advanced Database Mapping peut répondre à l’exigence au niveau des colonnes de base de données.
Comment la Demo Migration doit tester l’approche
La Demo Migration doit tester les hypothèses qui ont servi à choisir l’approche. Pour J2Commerce, un échantillon représentatif doit couvrir les principaux types de Products et options, les relations avec les articles et Categories Joomla, les téléchargements lorsqu’ils sont utilisés, les Customers avec plusieurs adresses, les Orders invités et enregistrés, les coupons, les taxes, les données de livraison et de paiement, les statuts personnalisés et les champs du processus de commande. Lorsqu’une boutique provient de J2Store, l’échantillon doit aussi inclure les relations et dépendances historiques qui peuvent être affectées par la transition.
La Demo Migration ne doit pas seulement montrer que des enregistrements existent. Elle doit montrer que les relations et la signification restent utilisables dans l’administration et dans la vitrine représentative.
| Résultat observé dans la Demo Migration | Décision probable |
|---|---|
| Les enregistrements sont corrects et le fonctionnement de la vitrine est compréhensible | Continuer avec l’approche sélectionnée. |
| Les enregistrements sont globalement corrects mais des champs standard pris en charge doivent changer de destination | Examiner Advanced Data Mapping et vérifier chaque champ source et cible. |
| Les enregistrements sont présents mais le processus de commande, les taxes, la livraison ou le paiement dépendent de la configuration | Terminer la configuration de la cible avant d’approuver Full Migration. |
| Le sens d’un Product ou d’un Order est perdu à cause de données appartenant à une app ou de données personnalisées | Examiner Custom Service. |
| Le fonctionnement provenant de J2Store ne correspond pas aux attentes | Traiter le projet comme une transition à part entière, et non comme une simple mise à jour au sein de la même famille. |
| L’échantillon ne couvre pas une complexité importante | Élargir les échantillons Demo Migration avant de décider. |
Cette classification évite de transformer chaque écart en développement personnalisé ou, à l’inverse, de traiter comme un simple réglage un besoin qui exige réellement une interprétation sur mesure.
Entity Points et planification du périmètre
Les Entity Points mesurent la capacité de données comptabilisées, pas la complexité architecturale de J2Commerce. Pour les activités ultérieures sur le même parcours de migration, les enregistrements éligibles déjà comptabilisés restent comptés une seule fois ; la complexité liée aux apps Joomla, au processus de commande et aux champs personnalisés est évaluée séparément. Les Categories, Reviews, Coupons, utilisateurs Joomla, articles Joomla qui ne sont pas comptabilisés comme Blog Posts, apps, Modules, tables personnalisées et configurations cibles ne doivent pas être considérés comme des types de données supplémentaires consommant des Entity Points simplement parce qu’ils ajoutent du travail ou des besoins de validation.
| Question de planification | Conséquence pour J2Commerce |
|---|---|
| Combien de Products, Customers, Orders et Blog Posts éligibles sont attendus ? | Utiliser ces enregistrements pour choisir la capacité de l’Entity Points Plan. |
| Quels enregistrements ont déjà été comptabilisés dans la migration achetée et son parcours fixe ? | Ils ne consomment pas à nouveau des Entity Points simplement parce qu’une autre action de migration est exécutée. |
| Quels enregistrements éligibles sont nouveaux depuis l’activité de migration précédente ? | Les nouveaux enregistrements éligibles peuvent consommer des Entity Points lorsqu’ils sont transférés pour la première fois. |
| Le projet inclut-il des apps J2Store, des tables personnalisées, des relations Joomla ou un fonctionnement Product spécialisé ? | Ces éléments influencent la prise en charge et le choix du service, pas la formule des Entity Points. |
| L’implémentation cible est-elle passée de J2Commerce 4 à J2Commerce 6 ? | Le périmètre d’implémentation et de validation peut changer, mais le parcours plateforme source → plateforme cible acheté reste fixe. |
Un projet J2Commerce comportant peu d’enregistrements peut tout de même nécessiter un Custom Service si la source contient des données appartenant à une app ou des structures Joomla personnalisées. À l’inverse, un projet volumineux peut rester dans le Standard Service ou le Managed Service si le modèle de données pris en charge est ordinaire et bien documenté.
Additional Migration Options pour J2Commerce
Les Additional Migration Options doivent être choisies selon ce qui a changé depuis l’activité de migration précédente. La version de J2Commerce, les relations avec les articles Joomla, le fonctionnement des Products, l’état des extensions, les URL et la configuration cible déterminent ce qui doit être revalidé.
| Action actuelle | Quand l’utiliser | Revalidation propre à J2Commerce |
|---|---|---|
| Continue the Migration with the Last Used Configuration | De nouveaux enregistrements éligibles doivent être ajoutés avec la même mise en correspondance et la même configuration approuvées. | Vérifier les nouveaux Products, Customers, Orders, Blog Posts, contenus Product liés à Joomla, images et enregistrements sensibles aux URL. |
| Continue the Migration with a New Configuration | Les choix de mise en correspondance, filtrage ou configuration pris en charge doivent être ajustés. | Revérifier les types de Products, options, champs du processus de commande, Categories, propriété des articles Joomla, relations Customer et chaque champ de destination concerné. |
| Perform a New Migration | Un résultat migré distinct est requis alors que le parcours plateforme source → plateforme cible acheté reste inchangé, par exemple parce que l’implémentation J2Commerce, le périmètre ou la référence d’acceptation ont fortement changé. | Revalider l’ensemble représentatif complet, notamment les enregistrements provenant de J2Store, les apps, les URL, les frontières des extensions, le fonctionnement Product et les Orders historiques. |
Ces actions ne changent pas le parcours plateforme source → plateforme cible acheté. Elles n’installent pas non plus les extensions J2Commerce, ne reconstruisent pas les templates Joomla, ne configurent pas les moyens de paiement ou de livraison et ne rendent pas les anciennes apps J2Store compatibles avec J2Commerce 6. Un parcours plateforme source → plateforme cible différent nécessite l’achat d’un service de migration distinct ; les responsabilités liées à l’implémentation cible et au périmètre personnalisé restent des décisions séparées.
Choisir l’approche pour une boutique provenant de J2Store
Les marchands provenant de J2Store peuvent s’attendre à ce que l’approche soit plus simple en raison de la relation entre les plateformes. Cette hypothèse doit être vérifiée, et non présumée. L’ancienne boutique peut contenir des add-ons, des overrides de templates, des champs personnalisés, des règles de commande, des plugins de paiement, des plugins de livraison, d’anciens schémas d’URL et des processus historiques autour des Orders qui exigent une revue attentive.
Un projet issu de J2Store peut relever du Standard Service lorsque les données sont prises en charge et que la transition est propre. Il peut relever du Managed Service lorsque le marchand souhaite une exécution et une validation guidées. Il peut nécessiter un Standard Add-on lorsqu’une condition sur un type de données pris en charge, une expression de valeur, une destination de champ standard ou une destination de colonne de base de données éligible est requise. Il peut nécessiter le Custom Service lorsque des add-ons historiques, du code personnalisé ou des champs non pris en charge portent une signification commerciale critique.
| Signal provenant de J2Store | Considération pour l’approche |
|---|---|
| Structure Product propre fondée sur les articles | Le Standard Service ou le Managed Service peut suffire si la validation est simple. |
| Nombreux add-ons ou champs personnalisés dont le traitement requis dépasse les capacités de mise en correspondance prises en charge | Examiner les besoins de mise en correspondance, les solutions de remplacement et les déclencheurs du Custom Service. |
| URL historiques importantes | Prévoir la continuité SEO, les redirections ou la conservation du routage. |
| Processus de commande ou statuts personnalisés | Déterminer si le besoin relève de la mise en correspondance, de la configuration ou du Custom Service. |
| Intégrations externes | Examiner les identifiants stables, les références Order et la propriété des données avant la Full Migration. |
La décision pratique n’est pas de savoir si l’ancienne boutique paraît familière. Elle consiste à déterminer si la boutique J2Commerce cible peut préserver le sens commercial dont dépendent les clients, les administrateurs et les systèmes connectés.
Décision finale avant la Full Migration
Avant la Full Migration, le marchand doit pouvoir indiquer l’approche choisie et expliquer pourquoi elle convient. Le Standard Service est approprié lorsque les données prises en charge et une exécution gérée par le marchand correspondent au projet. Le Managed Service convient lorsque les capacités standard suffisent mais que le marchand souhaite une exécution pilotée par Next-Cart et un accompagnement structuré lors des revues, tout en conservant la responsabilité de la vérification finale. Les Add-ons conviennent aux besoins ciblés et pris en charge. Le Custom Service est approprié lorsque le projet exige un traitement sur mesure, une revue de données non prises en charge, l’analyse d’une Custom Platform, des Tailored Add-ons, des Custom Add-ons ou une logique de migration personnalisée.
La décision finale doit être étayée par la Demo Migration. Si l’échantillon n’a pas inclus les principaux types de Products, les relations avec les articles, les groupes Customer, les Orders, les champs du processus de commande, les données de paiement et de livraison, les URL, les apps et les dépendances historiques de J2Store, l’approche n’est pas encore prête à être approuvée.
| Question finale | Condition de validation |
|---|---|
| L’environnement cible est-il suffisamment prêt ? | J2Commerce, la structure Joomla, le paiement, la livraison, le processus de commande, les templates et les Modules permettent de tester l’échantillon. |
| Le périmètre de données est-il clair ? | Products, Customers, Orders, Categories, Coupons, Reviews, contenus CMS et autres types de données sélectionnés sont définis. |
| Les responsabilités de configuration sont-elles séparées ? | Taxes, livraison, paiement, e-mails, facturation, processus de commande et comportement des statuts ne sont pas confondus avec des enregistrements migrés. |
| Les Add-ons sont-ils justifiés ? | Chaque Add-on résout un besoin ciblé et pris en charge. |
| Le Custom Service est-il nécessaire ? | Les besoins non pris en charge, personnalisés, appartenant à des apps ou sensibles aux intégrations sont examinés avant la Full Migration. |
| La Demo Migration a-t-elle suffisamment démontré le résultat ? | Les enregistrements représentatifs conservent leur sens dans l’administration et dans la vitrine. |
Une approche de migration est prête lorsqu’elle peut être défendue par des éléments observables plutôt que par des suppositions.
Conclusion
Choisir l’approche adaptée à J2Commerce signifie faire correspondre le service à la structure réelle du commerce Joomla. Le Standard Service peut convenir à une boutique propre et prise en charge. Le Managed Service peut convenir à un projet pris en charge qui nécessite une exécution guidée. Les Add-ons peuvent répondre à des besoins ciblés et pris en charge. Le Custom Service doit être évalué lorsque du fonctionnement personnalisé, des données appartenant à des apps, des champs non pris en charge, une forte complexité héritée de J2Store ou des identifiants externes influencent le résultat cible.
La Demo Migration doit confirmer cette décision avant la Full Migration. Lorsque les Products représentatifs, leurs relations avec les articles Joomla, les Categories, Customers, Orders, champs du processus de commande, contexte de paiement et de livraison, URL, apps et dépendances d’extensions conservent leur sens dans J2Commerce, l’approche choisie peut progresser.
Questions fréquentes
Quels éléments faut-il préparer pour une évaluation Custom Service dans une migration vers J2Commerce ?
Préparez des exemples J2Commerce montrant les données appartenant à des apps, les processus de commande personnalisés et les fonctionnements Product que Joomla ou la couche e-commerce cible ne représente pas directement. Pour chaque exemple, indiquez le résultat cible attendu, le propriétaire technique et les éléments permettant d’accepter le travail Custom Service.
Quand faut-il choisir le Managed Service pour une migration vers J2Commerce ?
Le Managed Service est utile lorsque les capacités standard couvrent le projet mais que le marchand souhaite une exécution pilotée par Next-Cart, une coordination structurée et un accompagnement plus clair pour la revue des Products, Customers, Orders, du processus de commande, des URL et de la vitrine.
Quand une migration vers J2Commerce nécessite-t-elle le Custom Service ?
Le Custom Service doit être évalué lorsque le projet comporte des données appartenant à des apps, des champs non pris en charge, un processus de commande personnalisé, une logique Product inhabituelle, des identifiants externes, une source Custom Platform, des Tailored Add-ons, des Custom Add-ons ou une logique de migration personnalisée.
Les Add-ons peuvent-ils résoudre les difficultés de transition de J2Store vers J2Commerce ?
Data Filter, Advanced Data Mapping et Data Transformation peuvent aider pour des contrôles définis et pris en charge. Dans une migration vers J2Commerce, Advanced Database Mapping ne peut être envisagé que lorsque la plateforme source est elle aussi Open-Source et que l’exigence au niveau de la base de données reste prise en charge. Ces Add-ons ne doivent pas remplacer le Custom Service lorsque d’anciens add-ons J2Store, des champs personnalisés dont le traitement requis dépasse les capacités de mise en correspondance prises en charge ou des processus personnalisés exigent une interprétation sur mesure.
Que doit prouver la Demo Migration pour J2Commerce avant la Full Migration ?
La Demo Migration doit démontrer que les Products représentatifs, les relations avec les articles, les Categories, Customers, Orders, champs du processus de commande, données de paiement et de livraison, URL, apps et dépendances historiques conservent leur sens dans J2Commerce.