Choisir l’approche de migration adaptée à EShop by Ossolution Team dépend de la quantité de sens métier qui doit survivre au-delà des simples enregistrements Products, Customers et Orders. EShop étant une extension de panier d’achat pour Joomla, l’approche doit tenir compte de la structure du catalogue, des options de Product, attributs, champs personnalisés, données de commande, groupes de Customers, historique des Orders, taxes, expédition, contexte de paiement, contenu multilingue, présentation Joomla, modules, templates, extensions et implémentations personnalisées.
Une approche légère peut convenir lorsque les données source sont propres, que le parcours de migration sélectionné prend en charge les enregistrements nécessaires et que le marchand peut gérer avec assurance la revue de la cible. Une approche plus encadrée devient nécessaire lorsque la boutique comporte des règles de catalogue complexes, des champs de commande personnalisés, des données appartenant à des intégrations, une restructuration multilingue, des dépendances d’implémentation Joomla ou un fonctionnement spécifique qui ne peut pas être représenté par des enregistrements standard uniquement.
L’approche adaptée n’est donc pas, par défaut, la plus élaborée. C’est celle qui correspond à la difficulté réelle de traduire la boutique source en un environnement EShop exploitable.
Dans les services de migration Next-Cart, les éléments recueillis pour EShop doivent permettre d’identifier le périmètre de migration pris en charge, le niveau de responsabilité nécessaire pour l’exécution et les dépendances Joomla ou d’extensions qui nécessitent un traitement particulier.
Ce que l’approche EShop doit décider avant l’exécution
Une approche de migration vers EShop doit résoudre trois questions avant l’exécution : les données entrent-elles dans les capacités prises en charge, qui doit gérer l’exécution et la validation, et quelles exigences nécessitent des Add-ons ou Custom Service ? Ces décisions doivent être prises avant l’approbation finale, car les projets EShop associent fréquemment des enregistrements commerciaux ordinaires à des responsabilités d’implémentation propres à Joomla.
| Domaine de décision | Éléments à évaluer | Pourquoi cela compte pour EShop |
|---|---|---|
| Adéquation des données prises en charge | Products, Categories, fabricants, Customers, Orders, avis, coupons, options, attributs, champs et autres enregistrements inclus dans le parcours sélectionné | L’exécution standard est la plus solide lorsque le sens source est clair et que les destinations cibles sont prises en charge. |
| Responsabilité de l’exécution | Le marchand gère-t-il lui-même le processus ou souhaite-t-il une exécution pilotée par Next-Cart ? | Les projets EShop plus volumineux ou sensibles peuvent nécessiter Managed Service même si les données sont standard. |
| Support facultatif | Faut-il appliquer une condition à un type de données, transformer une valeur par expression ou envoyer un champ source vers une autre destination ? | Data Filter, Advanced Data Mapping ou Data Transformation peuvent répondre à un besoin défini sans transformer tout le projet en engagement personnalisé. |
| Examen des exigences personnalisées | Données de Custom Platform, données d’extension non prises en charge, identifiants tiers, champs de commande spécifiques et logique personnalisée | Ces domaines peuvent nécessiter Custom Service plutôt que des hypothèses de traitement standard. |
| Frontière d’implémentation cible | Menus Joomla, modules, templates, plugins de paiement et d’expédition, configuration fiscale, e-mails et redirections | Certaines responsabilités appartiennent à la configuration et à l’implémentation de la cible, pas au résultat de migration. |
Cette grille évite de choisir l’approche uniquement selon le volume. Une petite migration EShop peut nécessiter Custom Service si elle dépend de champs de commande spécifiques ou de données d’extension non prises en charge. Une migration volumineuse peut rester compatible avec un parcours standard lorsque les enregistrements sont propres, pris en charge et faciles à valider.
Quand Standard Service peut convenir à EShop
Standard Service peut convenir lorsque la boutique source présente une structure de catalogue claire, des enregistrements pris en charge et une équipe capable d’utiliser le processus Next-Cart et de valider le résultat. Ce choix est particulièrement adapté lorsque Products, Categories, fabricants, Customers, Orders, avis, coupons et champs de catalogue courants peuvent être migrés sans interprétation spécifique.
Pour EShop, l’adéquation dépend aussi de la clarté des options et attributs de Product. Les options doivent représenter des choix d’acheteur ; les attributs, des informations ou spécifications de Product. Lorsque les valeurs source sont propres et que leur destination est claire, un parcours plus complexe n’est pas nécessaire.
| Signal d’adéquation à Standard Service | Ce qu’il signifie généralement | Point de validation propre à EShop |
|---|---|---|
| Catalogue propre | Products, Categories, fabricants, images, descriptions, prix et stocks sont cohérents. | Les pages Product peuvent être revues sans nettoyage ni interprétation importants. |
| Options compréhensibles | Les choix source, par exemple taille, couleur, conditionnement ou format, ont un sens clair. | Les valeurs d’option restent achetables et lisibles dans les lignes d’Order. |
| Attributs et spécifications clairs | Les valeurs techniques sont descriptives et ne pilotent pas l’achat. | Le placement en attribut ou champ personnalisé peut être validé sans logique spécifique. |
| Historique Customer et Order ordinaire | Customers, adresses, lignes d’Order, statuts, coupons, bons, taxes, expédition et libellés de paiement sont lisibles. | L’historique reste utile au service et au reporting. |
| Validation pilotée par le marchand réaliste | L’équipe peut examiner les échantillons, comparer les enregistrements et suivre la configuration cible. | Une exécution standard ne supprime pas l’obligation de revue de la cible. |
Standard Service ne doit pas être choisi simplement parce que la boutique est petite. Il doit l’être parce que les données source sont claires, la structure cible adaptée et qu’aucun fonctionnement personnalisé non pris en charge n’est indispensable.
Quand Managed Service est plus sûr
Managed Service est plus sûr lorsque la migration peut toujours utiliser les capacités standard, mais que le marchand souhaite confier à Next-Cart l’exécution et la coordination de la revue. Cela peut convenir à des projets EShop avec de gros catalogues, des délais de lancement serrés, plusieurs parties prenantes, un historique d’Orders détaillé, du contenu multilingue ou un besoin de supervision plus étroite.
Managed Service ne résout pas automatiquement les données personnalisées ou les logiques non prises en charge. Il renforce la responsabilité d’exécution lorsque le parcours de migration reste par ailleurs adapté. Si le projet nécessite une interprétation sur mesure, une transformation de champ personnalisé au-delà du périmètre pris en charge par Data Transformation, la prise en charge d’une extension non prise en charge ou un ajustement personnalisé de la logique de migration, Custom Service doit être étudié.
| Signal en faveur de Managed Service | Pourquoi c’est important | Frontière à préserver |
|---|---|---|
| Catalogue volumineux | Davantage d’échantillons, de Categories, de relations avec les fabricants et de travail de validation | Le volume seul ne signifie pas qu’un traitement personnalisé est nécessaire. |
| Historique d’Orders détaillé | Les Orders peuvent contenir options, bons, coupons, taxes, expédition, libellés de paiement, commentaires et historique de statuts | La lisibilité historique dépend toujours des champs disponibles à la source et à la cible. |
| Vitrine multilingue | Products, Categories, alias, modules, métadonnées et relations linguistiques nécessitent une revue coordonnée | La configuration des langues Joomla peut nécessiter une implémentation cible au-delà de la migration. |
| Pression de lancement | Le marchand a besoin d’une coordination plus serrée et souhaite réduire le risque lié à une exécution autonome | La configuration cible et l’approbation métier exigent toujours la participation du marchand. |
| Plusieurs responsables internes | Marketing, opérations, support, finance et équipes techniques peuvent valider des domaines différents | Une exécution gérée ne remplace pas la responsabilité des décisions métier. |
Managed Service constitue souvent un bon choix lorsque la migration n’est pas techniquement personnalisée mais reste sensible sur le plan opérationnel. Le projet bénéficie alors d’une exécution pilotée par Next-Cart, d’une revue structurée et d’une meilleure coordination sans modifier les capacités de données sous-jacentes.
Dans quels cas les Add-ons peuvent aider une migration EShop
Les Add-ons peuvent compléter une migration EShop lorsqu’un besoin correspond à une capacité facultative définie. Ils sont particulièrement utiles lorsqu’il faut filtrer des enregistrements selon des conditions propres à un type de données, transformer des valeurs de champs à l’aide d’expressions ou rediriger des champs source vers d’autres champs cibles. Ils ne doivent pas servir d’explication générique à tout fonctionnement personnalisé.
Les besoins apparaissent souvent pendant la préparation : exclure des enregistrements obsolètes selon des conditions prises en charge, transformer certaines valeurs par expression ou envoyer des champs source connus vers des champs cibles compatibles.
| Besoin | Add-on pertinent | Frontière à surveiller |
|---|---|---|
| Exclure Products archivés, Orders de test, anciens Customers ou enregistrements inactifs | Data Filter peut appliquer des conditions fondées sur des champs à chaque entité concernée. | Le filtrage ne transforme pas un modèle métier personnalisé. |
| Transformer des libellés, statuts ou autres valeurs prises en charge | Data Transformation peut appliquer une expression définie pendant la migration. | Une interprétation sur mesure ou une logique non prise en charge peut nécessiter Custom Service. |
| Envoyer des champs source connus vers d’autres champs EShop | Advanced Data Mapping peut convenir lorsque le sens source et la destination sont clairs. | Des champs non pris en charge ou un fonctionnement cible spécifique peuvent nécessiter Custom Service. |
| Préserver certains enregistrements facultatifs | L’examen des Add-ons peut aider lorsque le type d’enregistrement est pris en charge comme option de service. | Les données d’une extension non prise en charge ne doivent pas être présentées comme un travail Add-on ordinaire. |
| Réduire les données inutiles avant le lancement | Data Filter peut exclure les enregistrements correspondant à des conditions approuvées propres au type de données. | Les décisions de suppression doivent être approuvées avant l’exécution. |
Les Add-ons fonctionnent le mieux lorsque le marchand peut formuler précisément son besoin. Une demande vague du type « tout reprendre exactement comme avant » n’est pas une exigence d’Add-on : elle indique qu’il faut approfondir le modèle de données et les dépendances personnalisées.
Quand faut-il étudier Custom Service ?
Custom Service doit être étudié lorsque la migration EShop dépend de données ou d’un fonctionnement qui ne peuvent pas être traités de manière sûre par les capacités standard et les Add-ons disponibles. Cela inclut les données de Custom Platform, les données d’extension non prises en charge, les champs personnalisés nécessitant une interprétation non standard au-delà de la mise en correspondance prise en charge, les enregistrements appartenant à des plugins, les identifiants tiers, une logique de commande spécifique, les données appartenant à des intégrations, les Tailored Add-ons, les Custom Add-ons et les ajustements personnalisés de la logique de migration.
La base Joomla d’EShop peut augmenter la probabilité de besoins personnalisés, car les anciennes boutiques peuvent s’appuyer sur des extensions, surcharges de template, modules, plugins de contenu, tables de base de données personnalisées ou systèmes externes pour définir leur fonctionnement. La présence de données personnalisées ne rend pas la migration impossible, mais leur nature doit être classifiée avant l’approbation du périmètre.
| Déclencheur de revue Custom Service | Pourquoi Standard Service ou les Add-ons peuvent ne pas suffire | Éléments à préparer |
|---|---|---|
| Champs de commande personnalisés avec règles métier | Affichage, validation, e-mails, facture ou sens de l’Order peuvent être spécifiques. | Liste des champs, Orders exemples, captures et résultat cible attendu. |
| Données d’extension non prises en charge | Les enregistrements peuvent ne pas appartenir aux structures standard Product, Customer, Order ou Category. | Noms d’extensions, exemples de base de données et d’export, notes de propriété. |
| Fonctionnement paiement/expédition appartenant à un plugin | Les libellés historiques peuvent migrer, mais le fonctionnement actif peut dépendre d’un plugin ou de code personnalisé. | Liste des plugins, exemples de méthodes, Orders exemples et exigences futures. |
| Identifiants d’intégration | Les ID ERP, comptabilité, CRM, traitement logistique, inventaire ou affiliation peuvent devoir être conservés. | Liste des champs source, valeurs exemples, destination attendue et responsable de l’intégration. |
| Champs ou onglets Product personnalisés à portée opérationnelle | Les valeurs peuvent affecter traitement, conformité, sélection ou reporting. | Exemples de Products et explication métier de chaque champ. |
| Travail Tailored Add-on ou Custom Add-on | Un Standard Add-on doit être adapté au projet ou une fonctionnalité Add-on spécifique est nécessaire. | Revue et devis via Custom Service, avec résultat attendu et critères d’acceptation explicitement définis. |
Custom Service doit être discuté tôt lorsque la boutique source comporte des dépendances cachées. Attendre la fin de Demo Migration peut compliquer l’examen si l’échantillon ne contient déjà plus les enregistrements qui expliquent le besoin réel.
Le travail sur les templates Joomla, l’installation d’extensions, la configuration des plugins de paiement ou d’expédition et la refonte du site ne sont pas automatiquement inclus, sauf accord explicite.
Comment Demo Migration doit tester l’approche
Demo Migration doit démontrer que l’approche choisie est suffisamment solide. Pour EShop, un échantillon utile ne montre pas seulement que Products, Customers et Orders apparaissent ; il doit montrer que les significations opérationnelles les plus importantes de la boutique peuvent être examinées dans EShop et Joomla.
L’échantillon doit combiner enregistrements ordinaires et cas à risque : Products avec options, attributs, fabricants, téléchargements, pièces jointes, champs personnalisés dont le traitement dépasse la mise en correspondance prise en charge, Customers appartenant à différents groupes, Orders avec coupons ou bons, taxes et expédition, exemples de méthodes de paiement, données multilingues et tout élément susceptible de nécessiter un Add-on ou Custom Service.
| Domaine Demo Migration | Ce qu’il faut tester | Décision d’approche éclairée |
|---|---|---|
| Options de Product | Choix obligatoires, changements de prix, SKU ou image et sortie dans les lignes d’Order | Le traitement standard préserve-t-il correctement le choix de l’acheteur ? |
| Attributs et champs Product | Spécifications, champs personnalisés dépassant la mise en correspondance prise en charge, onglets, pièces jointes et informations supplémentaires | Faut-il une autre mise en correspondance ou une revue Custom Service ? |
| Customers et groupes | Identité Customer, adresses, relation User Joomla, groupes et historique du compte | La continuité Customer reste-t-elle compréhensible ? |
| Orders et historique commercial | Lignes, statuts, coupons, bons, taxes, expédition, libellés de paiement, commentaires et champs personnalisés | Les enregistrements historiques restent-ils utiles aux opérations ? |
| Présentation Joomla | Menus, alias, modules, templates, pages multilingues, métadonnées et chemins sensibles au SEO | Les responsabilités d’implémentation cible sont-elles clairement séparées du périmètre de migration ? |
| Données personnalisées ou non prises en charge | Identifiants tiers, enregistrements appartenant à des plugins, champs spécifiques et anciennes données d’extension | Custom Service doit-il être étudié avant de poursuivre ? |
La revue de Demo Migration doit conduire à une décision de parcours de service avant Full Migration. Si l’échantillon est propre, l’exécution standard peut convenir. S’il est propre mais sensible opérationnellement, Managed Service peut être plus sûr. Si des besoins facultatifs précis et pris en charge apparaissent, des Add-ons peuvent être utiles. Si le sens essentiel dépend de données personnalisées ou non prises en charge, Custom Service doit être étudié.
Entity Points et planification du périmètre EShop
Entity Points mesure la capacité comptabilisée pour la migration. Lors d’activités EShop ultérieures, les enregistrements éligibles déjà comptés restent comptés une seule fois sur le même parcours de migration ; la complexité des extensions Joomla, champs de commande et plugins est évaluée séparément. Categories, Manufacturers, Reviews, Coupons, Users Joomla, options EShop, attributs, champs personnalisés et données appartenant à des extensions peuvent influencer le périmètre et la validation, mais ne doivent pas être traités comme des types de données supplémentaires comptabilisés par la formule Entity Points.
| Question de planification | Conséquence pour EShop |
|---|---|
| Combien de Products, Customers, Orders et Blog Posts éligibles sont prévus ? | Utiliser ce volume pour choisir l’Entity Points Plan. |
| Quels enregistrements éligibles ont déjà été compté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 nouvellement créés ? | Ils peuvent consommer des Entity Points lors de leur première migration. |
| Les Products comportent-ils des options, attributs, pièces jointes ou champs personnalisés complexes ? | Cela affecte la mise en correspondance, la prise en charge et la validation, pas la formule de comptage des entités. |
| La boutique dépend-elle d’extensions Joomla ou d’identifiants externes ? | Custom Service peut être nécessaire même lorsque le volume comptabilisé reste modeste. |
Entity Points ne doit pas déterminer à lui seul le parcours de service. Celui-ci dépend du sens des données, de la responsabilité d’exécution et de la compatibilité du résultat attendu avec les capacités prises en charge.
Additional Migration Options pour EShop
Les Additional Migration Options doivent être choisies selon ce qui a changé entre l’activité de migration précédente et le prochain résultat cible. Pour EShop, une attention particulière doit être portée aux options et attributs de Product, relations avec Manufacturers, groupes de Customers, Orders, contenus Joomla, URL et champs appartenant à des extensions.
| Action actuelle | Quand l’utiliser | Revalidation propre à EShop |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Ajouter de nouveaux enregistrements éligibles avec la même configuration approuvée. | Contrôler les nouveaux Products, Customers, Orders et Blog Posts ainsi que les options, Categories, Manufacturers, images et URL prioritaires associés. |
| Continue the Migration with a New Configuration | Modifier des choix de mise en correspondance, filtrage ou configuration pris en charge. | Recontrôler les options, attributs, champs personnalisés, groupes de Customers, champs d’Order et chaque destination modifiée. |
| Perform a New Migration | Remplacer le résultat cible antérieur parce que la structure cible, le périmètre ou la référence d’acceptation a changé de manière importante. | Revalider l’échantillon représentatif complet, notamment relations de catalogue, Customers, Orders, contenu multilingue, routes Joomla et limites des données personnalisées. |
Ces actions ne configurent pas le paiement, l’expédition, les taxes, les e-mails, modules Joomla, templates ou extensions pour leur fonctionnement actif. Elles ne rendent pas non plus des enregistrements non pris en charge soudainement pris en charge. Utilisez les Add-ons pour des besoins limités et pris en charge, et Custom Service pour un traitement non standard.
Comparer les quatre parcours de service EShop
Ces quatre parcours diffèrent par leur périmètre pris en charge, la responsabilité d’exécution et la quantité d’interprétation nécessaire. Ils ne constituent pas une échelle de qualité. Le meilleur choix est le parcours le moins complexe qui permet malgré tout d’obtenir un résultat que le marchand peut valider avec confiance.
| Parcours | Meilleur contexte | Frontière principale |
|---|---|---|
| Standard Service | Enregistrements propres et pris en charge, avec exécution et validation pilotées avec assurance par le client | N’inclut pas l’implémentation Joomla ni le traitement des données non prises en charge |
| Managed Service | Migration prise en charge avec forte charge de coordination ou de validation | Ne transforme pas les données d’extension personnalisées en périmètre standard |
| Add-ons | Besoins limités de filtrage d’enregistrements, transformation de valeurs ou remise en correspondance de champs | Ne remplacent ni Custom Service ni le développement cible |
| Custom Service | Données d’extension non prises en charge, champs personnalisés dont le traitement requis dépasse la mise en correspondance prise en charge, ID externes, transformation sur mesure ou logique de migration spécifique | Le périmètre final et le prix dépendent du travail personnalisé convenu |
Cette comparaison doit être appliquée une fois les éléments EShop compris. Choisir un parcours plus impliqué ne peut pas compenser une représentation cible indéfinie, une propriété d’extension inconnue ou une norme d’acceptation qu’aucun réviseur ne peut appliquer.
Signes qu’une approche est trop légère
Une approche EShop est trop légère lorsque le plan suppose que l’extension cible reproduira automatiquement un fonctionnement qui dépend en réalité de logique source personnalisée, de configuration cible, d’implémentation Joomla ou d’enregistrements non pris en charge. Ces signaux apparaissent généralement pendant la préparation ou la revue de Demo Migration.
| Signal d’alerte | Ce qu’il indique | Réponse plus solide |
|---|---|---|
| Les Products apparaissent mais les choix d’achat sont incomplets | Les options, valeurs de variantes ou sélections personnalisées n’ont pas été correctement interprétées. | Vérifier si un champ source pris en charge nécessite Advanced Data Mapping ou si le fonctionnement source exige Custom Service. |
| Les attributs deviennent confus ou mal placés | Spécifications, filtres, champs personnalisés et choix de commande peuvent avoir été mélangés. | Reclasser les champs avant l’exécution finale. |
| Les Orders existent mais sont peu utiles au support | Lignes, valeurs d’options, totaux, statuts, contexte de paiement/expédition ou commentaires manquent de sens. | Élargir les échantillons d’Orders et revoir le traitement des champs. |
| Les groupes de Customers perdent leur finalité métier | L’affectation peut influencer prix, taxes, accès, reporting ou service Customer. | Confirmer le sens du groupe et la configuration cible. |
| On suppose que la commande active fonctionnera automatiquement | Paiement, expédition, taxes, e-mails et commande nécessitent configuration et tests sur la cible. | Attribuer explicitement la responsabilité de configuration cible. |
| La présentation Joomla est ignorée | Menus, modules, templates, alias, métadonnées et redirections peuvent ne pas être prêts. | Séparer la validation de migration du travail d’implémentation Joomla. |
| Les champs personnalisés sont traités comme des enregistrements ordinaires | Leur sens peut dépendre d’anciennes applications, extensions, plugins ou code spécifique. | Tester d’abord la mise en correspondance prise en charge ; envisager Custom Service seulement lorsque l’interprétation ou le traitement nécessaire dépasse ce périmètre. |
Une approche plus solide ne signifie pas toujours Custom Service. La bonne réponse peut être une meilleure préparation, un meilleur échantillon Demo Migration, Managed Service ou des Add-ons. L’essentiel est de classifier correctement le problème avant que le marchand ne s’appuie sur le résultat pour le lancement.
Conclusion
La bonne approche de migration vers EShop dépend du sens réel des données, pas seulement du volume d’enregistrements. Standard Service peut convenir à des données propres et prises en charge lorsque le marchand peut gérer lui-même exécution et validation. Managed Service est plus sûr lorsque la migration reste standard sur le plan des capacités mais sensible opérationnellement. Data Filter, Advanced Data Mapping ou Data Transformation peuvent répondre à un besoin limité et précisément défini. Custom Service doit être étudié lorsque le projet dépend de données de Custom Platform, de données d’extension non prises en charge, de champs spécifiques, d’enregistrements appartenant à des plugins, d’identifiants d’intégration, de Tailored Add-ons, Custom Add-ons ou d’une logique de migration personnalisée.
Demo Migration doit servir à démontrer que l’approche est correcte avant l’exécution. L’échantillon doit tester options, attributs, champs personnalisés, pièces jointes, fabricants, Customers, groupes de Customers, Orders, coupons, bons, taxes, expédition, contexte de paiement, contenu multilingue, présentation Joomla et données personnalisées. Une bonne approche est celle qui donne à la future boutique EShop suffisamment de structure, de contexte et de résultats vérifiables pour fonctionner après le lancement.
Questions fréquentes
Quels éléments faut-il préparer pour une revue Custom Service dans une migration EShop ?
Préparez des exemples EShop montrant les champs de commande porteurs de règles, les enregistrements d’extensions non pris en charge et le contexte paiement/expédition appartenant à des plugins. Documentez l’impact métier de chaque valeur, sa représentation cible attendue et la manière dont le résultat convenu de Custom Service sera validé séparément de la configuration Joomla.
Quand Managed Service est-il préférable pour EShop ?
Managed Service est préférable lorsque les données restent compatibles avec les capacités standard mais que le projet nécessite une exécution pilotée par Next-Cart, une validation coordonnée, un périmètre important, une revue multilingue ou un contrôle plus serré du lancement.
Les Add-ons remplacent-ils Custom Service ?
Non. Les Standard Add-ons répondent à des conditions définies sur des types de données, des expressions de valeurs ou des destinations de champs source. Custom Service est nécessaire lorsque le besoin concerne des données de Custom Platform, des données d’extension non prises en charge, une interprétation sur mesure, des Tailored Add-ons, des Custom Add-ons ou une logique de migration personnalisée.
Que doit tester Demo Migration avant de choisir l’approche finale ?
Demo Migration doit tester des Products représentatifs, options, attributs, champs personnalisés, pièces jointes, Customers, groupes de Customers, Orders, coupons, bons, taxes, expédition, contexte de paiement, enregistrements multilingues, dépendances de présentation Joomla et toute donnée personnalisée ou non prise en charge.
Le fonctionnement actif du paiement, de l’expédition et des taxes peut-il être migré automatiquement ?
Le contexte historique de paiement, d’expédition et de taxe peut rester utile dans les anciens Orders, mais le fonctionnement futur exige généralement une configuration cible, la mise en place des plugins et des tests dans EShop.