Choisir l’approche de migration adaptée à Shift4Shop ne dépend pas uniquement du nombre d’enregistrements à transférer. Une boutique disposant d’un catalogue de taille moyenne peut demander un traitement attentif si elle repose sur des Advanced Options, une tarification par Customer Group, des règles de vente en gros, du contenu sensible pour le SEO, des champs personnalisés ou un historique de commandes dépendant d’intégrations. À l’inverse, une boutique plus volumineuse peut rester relativement simple à traiter si les données de la boutique source sont propres et si les règles métier sont peu complexes.
L’approche doit être choisie en comparant la complexité de la boutique source avec le modèle d’exploitation attendu sur Shift4Shop comme plateforme cible. Les enregistrements principaux peuvent convenir à un parcours de migration standard, tandis que les constats issus de la préparation peuvent montrer qu’un Add-on, un Custom Service ou une revue accompagnée est nécessaire pour certains besoins. L’objectif est de réduire le risque au lancement sans construire un périmètre de migration inutilement complexe.
Dans le cadre des services de migration Next-Cart, l’analyse d’un projet Shift4Shop doit distinguer le périmètre pris en charge, la responsabilité d’exécution, les besoins circonscrits pouvant relever d’un Add-on, ainsi que les exigences particulières liées aux options, à la tarification ou aux intégrations.
Commencer par définir le périmètre de migration vers la plateforme
Commencez par préciser ce que la migration vers Shift4Shop doit réellement préserver. Le périmètre doit séparer le transfert des données principales des règles métier, du fonctionnement de la boutique en ligne, de la continuité SEO et des dépendances opérationnelles. Sans cette distinction, le projet risque soit d’être trop superficiel, soit de devenir inutilement complexe.
Un périmètre de base peut se concentrer sur les Products, Categories, Customers, Orders, Reviews, Coupons et contenus. Un périmètre plus complet peut également inclure les options de Products, les Advanced Options, les modèles d’options, les SmartCategories, les chèques-cadeaux, les remises par quantité, les Customer Groups, les règles tarifaires B2B, les Extra Pages, les Blog Posts, les redirections, les champs personnalisés et les données liées aux intégrations.
| Domaine du périmètre | Signe de simplicité | Signe de complexité | Conséquence sur l’approche |
|---|---|---|---|
| Catalogue | Les Products utilisent des SKU, descriptions, prix, images et Categories simples | Les Products reposent sur des options, Advanced Options, modèles d’options, bundles, médias enrichis ou champs personnalisés qui nécessitent d’abord une revue de la mise en correspondance prise en charge | Peut nécessiter une mise en correspondance prise en charge et une validation sur échantillon ; les besoins restant hors prise en charge doivent être cadrés séparément. |
| Customers | Les Customers sont principalement des comptes de détail avec des adresses standard | Les Customer Groups déterminent les prix de gros, le traitement fiscal, la visibilité ou d’autres règles au niveau du compte | Nécessite une revue attentive des Customer Groups et éventuellement une validation accompagnée. |
| Orders | L’historique des Orders sert surtout de référence | Les Orders servent à la comptabilité, au traitement des commandes, au support, aux garanties ou aux parcours de réapprovisionnement B2B | Nécessite une revue plus poussée d’Orders représentatives et éventuellement un traitement personnalisé. |
| SEO et contenu | Seules les URLs prioritaires des Products et Categories nécessitent des redirections | Les Extra Pages, Blog Posts, anciennes URLs, métadonnées, Reviews et Product Q&A ont une valeur organique importante | Peut nécessiter des Add-ons, une planification des redirections ou un traitement spécifique du contenu. |
| Intégrations | Les systèmes externes peuvent être reconnectés après le lancement avec peu de dépendances aux données | Les flux produits, ERP, traitement logistique, fiscalité, marketplaces ou systèmes comptables dépendent de champs migrés | Nécessite une revue des intégrations avant de choisir le parcours final. |
Le choix du périmètre doit également préciser ce qui ne doit pas être migré. Les anciens champs personnalisés issus de l’époque 3dcart, remises inactives, Categories obsolètes, contenus abandonnés, Customer Groups retirés et enregistrements d’intégration déconnectés peuvent gonfler le périmètre sans améliorer la nouvelle boutique. Les décisions d’exclusion font donc partie du choix de l’approche.
Quand le Standard Service peut suffire
Le Standard Service peut suffire lorsque la migration porte principalement sur des données principales prises en charge, des enregistrements source propres et des règles métier peu complexes. Il est particulièrement adapté lorsque la boutique source contient des Products conventionnels, des Categories claires, des Customers exploitables, des Orders lisibles, des Reviews standard, des Coupons actifs et des contenus ne nécessitant pas de restructuration inhabituelle.
Un parcours en Standard Service exige tout de même de la préparation et de la validation. La différence est que le comportement attendu de la migration est suffisamment clair pour que le projet ne dépende pas d’une mise en correspondance personnalisée étendue ou d’une reconstruction manuelle. Pour Shift4Shop, cette approche convient surtout lorsque les options de Products sont simples, que les Customer Groups ne pilotent pas une tarification complexe et que les priorités SEO peuvent être traitées par une planification normale du contenu et des redirections.
| Adéquation au Standard Service | Ce qui doit être vrai | Priorité de validation |
|---|---|---|
| Données Product | Les champs Product sont propres, les options sont simples, les images sont accessibles et les Categories sont définies | Confirmer l’affichage, l’achetablité, le classement dans les Categories et le transfert des images. |
| Données Customer | Les Customers ont des informations de compte et des adresses standard sans segmentation complexe | Confirmer l’identité du compte, la correspondance des e-mails, les adresses et l’affectation au groupe si elle est utilisée. |
| Historique des Orders | Les Orders servent davantage de référence que de reproduction de processus | Confirmer les totaux, dates, statuts, Products, taxes, frais de livraison et remises. |
| Contenu SEO | Les besoins de redirection sont connus et le périmètre de contenu reste maîtrisable | Confirmer les URLs prioritaires, les métadonnées, les Extra Pages et les Blog Posts lorsqu’ils sont inclus. |
| Périmètre de revue | Les échantillons de Demo Migration représentent réellement la boutique | Confirmer que les résultats de l’échantillon sont suffisamment solides pour justifier la Full Migration. |
Le Standard Service ne doit pas être choisi simplement parce qu’il est plus simple. Il convient lorsque les données source et les attentes envers la boutique cible s’inscrivent réellement dans un parcours de migration prévisible.
Quand le Managed Service est plus adapté
Le Managed Service devient plus approprié lorsque l’entreprise a besoin de davantage d’accompagnement, de coordination ou de soutien lors des revues. Les données peuvent toujours être migrables par des voies ordinaires, mais l’environnement de décision est plus complexe. C’est souvent le cas lorsque plusieurs équipes interviennent, lorsque la boutique supporte un chiffre d’affaires actif important ou lorsque la préparation révèle de nombreux points à confirmer avant la Full Migration.
Pour Shift4Shop, le Managed Service est particulièrement utile lorsque plusieurs parties prenantes doivent interpréter les résultats de la Demo Migration sur le catalogue, les Customers, les Orders, le SEO et les intégrations. L’équipe produit peut se concentrer sur les options et Categories, l’équipe commerciale sur les Customer Groups et les prix de gros, le support sur l’historique des Orders, et le marketing sur les URLs et le contenu. Une coordination accompagnée permet de relier ces revues en une décision de migration cohérente.
| Signal en faveur du Managed Service | Pourquoi c’est important | Ce que l’accompagnement doit clarifier |
|---|---|---|
| Plusieurs responsables métier | Catalogue, ventes, support, SEO et opérations peuvent avoir des critères de réussite différents | Qui valide chaque type de données et ce qui constitue un résultat acceptable. |
| Règles B2B ou de vente en gros | Les Customer Groups et la tarification par quantité peuvent affecter le chiffre d’affaires et l’accès des acheteurs | Quelles règles sont migrées, lesquelles sont recréées et lesquelles doivent être testées. |
| Migration sensible pour le SEO | La perte de visibilité des Products, Categories, Extra Pages ou Blog Posts peut affecter le trafic | Quelles URLs et quels contenus doivent être prioritaires. |
| Résultats de Demo Migration difficiles à interpréter | Le transfert technique peut réussir alors que l’usage métier reste incertain | Quels écarts sont des défauts de migration, des problèmes de données source ou des décisions de configuration. |
| Calendrier de lancement sensible | Les retards de revue peuvent devenir un risque de lancement | Quelles décisions doivent être prises avant la Full Migration. |
Le Managed Service ne remplace pas la préparation. Il facilite la coordination de la préparation et de la validation lorsque le projet comporte assez de dépendances pour qu’une revue entièrement autonome risque d’en manquer certaines.
Quand envisager les Add-ons
Les Add-ons doivent être envisagés lorsqu’une migration prise en charge nécessite un contrôle de données prévisible et clairement délimité. Ils ne remplacent pas un développement personnalisé. Pour une migration vers Shift4Shop, les contrôles pertinents sont le filtrage d’enregistrements à partir de conditions sur les champs de chaque type de données, la transformation des valeurs de champs au moyen d’expressions et la mise en correspondance d’un champ source avec un autre champ cible.
La décision doit partir du besoin exact sur les données. Le filtrage détermine quels enregistrements pris en charge sont migrés. La transformation modifie les valeurs de champs pris en charge pendant la migration. La mise en correspondance détermine quel champ cible reçoit un champ source pris en charge. Le routage SEO, l’activité proche du lancement, la prise en charge des entités et la conception des échantillons restent des sujets de planification distincts, sauf si l’un de ces trois contrôles répond directement au besoin.
| Standard Add-on | Application pour Shift4Shop | À confirmer en premier |
|---|---|---|
| Data Filter | Appliquer des conditions prises en charge sur les champs de Products, Customers, Orders ou contenus afin que seuls les enregistrements correspondants soient migrés. | L’entité, le champ source, la condition et la règle d’inclusion ou d’exclusion. |
| Data Transformation | Appliquer des expressions pour transformer les valeurs de champs pris en charge destinées à Shift4Shop pendant la migration. | Les valeurs d’entrée, le fonctionnement de l’expression, les résultats attendus et les exceptions. |
| Advanced Data Mapping | Remapper des champs source pris en charge vers des champs cible Shift4Shop compatibles. | Le sens du champ, son type de données, son propriétaire dans la destination et son utilisation en aval. |
Les Add-ons doivent rester distincts des décisions relatives au Custom Service. Si le besoin est pris en charge, répétable et clairement cadré par l’un de ces trois contrôles, un Standard Add-on peut suffire. Si le besoin exige de reconstruire des règles métier, de traiter des données non prises en charge ou d’interpréter un cas personnalisé, il faut plutôt examiner le Custom Service.
Quand le Custom Service est nécessaire
Le Custom Service est nécessaire lorsque le besoin de migration ne peut pas être traité de manière fiable par le parcours standard ou les Add-ons disponibles. Cela concerne généralement des structures source uniques, des champs personnalisés dont le traitement requis dépasse la mise en correspondance prise en charge, des relations inhabituelles, d’anciens contournements ou des règles métier qui doivent être interprétées avant de devenir exploitables dans Shift4Shop.
Une migration vers Shift4Shop peut nécessiter un Custom Service lorsque les Products source utilisent des structures de variantes complexes devant devenir des options ou des Advanced Options, lorsqu’une tarification propre à certains Customers doit être reconstruite, lorsque des comptes de gros reposent sur des règles non standard, lorsque des champs créés par une intégration pilotent le traitement logistique ou le reporting, ou lorsque d’anciennes personnalisations 3dcart ne correspondent pas naturellement au fonctionnement actuel de Shift4Shop.
| Déclencheur potentiel du Custom Service | Exemple dans une migration Shift4Shop | Pourquoi un transfert ordinaire peut ne pas suffire |
|---|---|---|
| Fonctionnement Product complexe | Les choix Product modifient prix, stock, image, livraison ou traitement logistique de manière non standard | Le transfert des champs seul peut ne pas préserver la manière dont le Product doit être vendu. |
| Règles commerciales propres à certains Customers | Les acheteurs de gros, comptes exonérés de taxe, tarifs spéciaux ou règles de visibilité exigent une interprétation | Les données Customer doivent parfois être reliées au fonctionnement cible, pas seulement importées. |
| Champs personnalisés hérités | D’anciens champs issus de processus 3dcart influencent encore les opérations | Le sens du champ doit être confirmé avant migration ou exclusion. |
| Enregistrements dépendant d’intégrations | ERP, comptabilité, marketplaces, traitement logistique ou flux produits reposent sur des valeurs propres au système source | La continuité du système externe peut nécessiter une mise en correspondance ou une documentation spécifique. |
| Restructuration de contenu | Extra Pages, Blog Posts, pages de politique ou landing pages doivent être consolidés ou changer de route | Le contenu peut demander des décisions éditoriales et SEO, pas seulement un transfert. |
Le Custom Service doit être cadré de manière précise. L’objectif n’est pas de rendre toute la migration personnalisée, mais d’identifier les parties pour lesquelles le traitement standard entraînerait une perte opérationnelle, une confusion pour les clients, un risque SEO ou des difficultés pour les équipes.
Ce que la Demo Migration doit démontrer pour Shift4Shop
La Demo Migration doit tester les enregistrements les plus susceptibles de modifier le choix du service. Un échantillon composé uniquement de Products simples et d’Orders ordinaires n’est pas suffisant si la boutique source dépend d’Advanced Options, de règles de vente en gros, de champs personnalisés, d’anciens comportements 3dcart, d’Extra Pages ou d’identifiants créés par des intégrations.
| Échantillon de Demo Migration | Ce qu’il doit démontrer | Signal de décision |
|---|---|---|
| Product avec options simples | Le Product, la Category, l’image, le prix, le stock et le choix du client restent exploitables. | Soutient le parcours standard lorsque les enregistrements ordinaires réussissent de façon cohérente. |
| Product avec Advanced Options ou logique de variante complexe | Prix, stock, image, poids, SKU et sens du choix client peuvent être représentés correctement. | Montre si une expression de valeur prise en charge, une destination cible compatible pour un champ source pris en charge ou un Custom Service est nécessaire. |
| Customer avec contexte de groupe, vente en gros, exonération fiscale ou tarification spéciale | Le compte et l’éligibilité commerciale restent compréhensibles. | Indique si les enregistrements Customer suffisent ou si une configuration cible/un traitement personnalisé est nécessaire. |
| Order historique avec remise, taxe, livraison, remboursement ou statut inhabituel | Les équipes peuvent utiliser l’Order pour le support, le reporting, les réapprovisionnements, les garanties ou la comptabilité. | Révèle une perte de sens historique avant la Full Migration. |
| Extra Page, Blog Post ou URL prioritaire | Le contenu, les métadonnées, les liens internes et les attentes de redirection restent réalistes. | Confirme si le périmètre SEO et contenu est prêt pour le lancement. |
| Enregistrement lié à une intégration | Les identifiants ERP, entrepôt, comptabilité, traitement logistique, marketplace ou flux restent disponibles là où ils sont requis. | Déclenche une revue du Custom Service ou du système externe lorsque les enregistrements standard sont insuffisants. |
La Demo Migration doit se conclure par une décision documentée : poursuivre avec le parcours choisi, ajouter des Add-ons clairement délimités, déplacer certains besoins vers le Custom Service, revoir le périmètre ou retarder la Full Migration jusqu’à ce que la configuration cible soit prête. L’échec d’un échantillon complexe est une information utile lorsqu’il empêche de conserver un parcours de service inadapté pour l’exécution complète.
Comment les Entity Points influencent la planification
Les Entity Points influencent la planification car ils déterminent le volume de données pouvant être migré dans le cadre du forfait ou de la capacité achetée. Ils doivent être examinés avant la Full Migration, en particulier lorsque la boutique source contient des doublons, des enregistrements inactifs, d’anciens contenus, des Orders archivés, des Customers de test, des Coupons inutilisés ou des structures Product héritées.
La planification des Entity Points ne doit pas porter uniquement sur le volume total. Un même nombre d’enregistrements peut représenter des efforts très différents selon la complexité. Un catalogue comportant de nombreux Products simples peut être plus facile à planifier qu’un catalogue plus petit dans lequel chaque Product utilise des options, Advanced Options, médias enrichis, Reviews et champs créés par des intégrations.
| Domaine de planification des Entity Points | À vérifier | Décision de planification |
|---|---|---|
| Products et variantes | Nombre de Products, modèles d’options, Advanced Options, doublons, Products inactifs et de test | Décider ce qui doit être migré, nettoyé, fusionné ou exclu avant la Full Migration. |
| Customers | Comptes actifs/inactifs, e-mails en double, Customer Groups et comptes B2B | Éviter de consommer le périmètre pour des enregistrements qui n’apportent aucune valeur à la boutique cible. |
| Orders | Historique complet ou récent, Orders archivés/de test et plages indispensables au métier | Choisir la période qui soutient le support, la comptabilité et la continuité client. |
| Contenus | Extra Pages, Blog Posts, pages en double, contenus faibles et anciennes campagnes | Préserver les contenus utiles et exclure ceux qui ne feraient qu’encombrer la nouvelle boutique. |
| Consommation due aux doublons | Enregistrements répétés dans les exports ou dupliqués par des contournements du système source | Vérifier si des doublons consommeraient des points sans créer de valeur. |
La consommation liée aux doublons est importante. Si la boutique source contient des enregistrements répétés, d’anciennes données de test, des Customers ou Products en double ou du contenu inactif, ces éléments peuvent consommer de la capacité de migration sans améliorer la nouvelle boutique Shift4Shop. Les décisions de nettoyage et d’exclusion rendent donc la planification des Entity Points plus précise et réduisent les coûts évitables.
Comment les Additional Migration Options influencent l’approche
Les Additional Migration Options doivent être choisies selon ce qui a changé après le résultat de migration accepté. Pour Shift4Shop, la distinction essentielle consiste à déterminer si de nouveaux enregistrements peuvent suivre la configuration déjà acceptée ou si le traitement des Products, Customers, Orders, contenus, éléments SEO ou intégrations doit changer.
| Option actuelle | Utilisation propre à Shift4Shop | Revalidation requise |
|---|---|---|
| Continue the Migration with the Last Used Configuration | À utiliser lorsque de nouveaux Products, Customers, Orders ou Blog Posts éligibles doivent suivre les mêmes filtres, mises en correspondance, règles d’options Product, traitement des Customer Groups et règles de contenu déjà acceptés. | Examiner les nouveaux enregistrements et tout échantillon concerné en matière de stock, vente en gros, historique d’Orders ou URL prioritaire. |
| Continue the Migration with a New Configuration | À utiliser lorsque les filtres, l’interprétation des options, le traitement des Advanced Options, la logique des Customer Groups, le périmètre de contenu, les redirections ou la mise en correspondance des identifiants externes doivent changer. | Revalider les règles révisées ainsi que des enregistrements représentatifs précédemment acceptés avec l’ancienne configuration. |
| Perform a New Migration | À utiliser lorsque le projet nécessite un résultat de migration distinct sur le même parcours fixe acheté entre plateforme source et plateforme cible, et que le résultat précédent ne doit plus servir de base d’approbation. | Répéter l’ensemble des contrôles d’acceptation sur le catalogue, les Customers, les Orders, le contexte B2B/vente en gros, le contenu, les URLs et les intégrations. |
L’option reposant sur la dernière configuration utilisée est donc adaptée aux boutiques source encore actives, mais elle ne dispense pas de revoir les nouveaux Products complexes ou les Orders exceptionnels.
Les Additional Migration Options ne configurent pas les passerelles de paiement, méthodes de livraison, taxes, parcours de commande, thèmes, applications, flux ou intégrations externes de Shift4Shop. Lorsque des changements ultérieurs de la source affectent ces domaines, les responsables côté plateforme cible doivent les mettre à jour et les retester séparément.
Choisir le bon parcours avant la Full Migration
L’approche finale doit relier les constats de préparation à un parcours de migration clair. Le Standard Service peut suffire pour des données principales propres. Le Managed Service peut être préférable lorsque la coordination des revues est importante. Data Filter, Advanced Data Mapping ou Data Transformation peuvent couvrir un contrôle pris en charge et bien délimité. Le Custom Service peut être nécessaire pour une interprétation de champ sur mesure, des règles métier ou des enregistrements dépendant d’intégrations. Les Entity Points et Additional Migration Options permettent ensuite d’affiner le périmètre pratique.
Cette décision doit être prise avant la Full Migration, et non après qu’une Demo Migration a révélé des hypothèses non résolues. Une approche solide attribue à chaque type de données un plan de traitement clair et à chaque risque un parcours de validation précis.
| Question de décision | Choisir le parcours le plus simple lorsque | Choisir un parcours davantage accompagné lorsque |
|---|---|---|
| Les enregistrements principaux peuvent-ils migrer de manière prévisible ? | Products, Customers, Orders, Categories, Coupons, Reviews et contenus sont propres et conventionnels | Les enregistrements principaux contiennent des champs personnalisés, contournements source ou dépendances aux règles métier. |
| La revue est-elle facile à coordonner ? | Un responsable peut valider les principaux domaines à partir d’échantillons clairs | Plusieurs équipes doivent examiner catalogue, B2B, historique des Orders, SEO et intégrations. |
| Les Add-ons suffisent-ils ? | Une condition sur un type de données, une expression de valeur ou une destination de champ est prise en charge et clairement cadrée | Le besoin exige une interprétation personnalisée ou un traitement de champ sur mesure. |
| Le Custom Service est-il justifié ? | Les données peuvent être migrées et rester utiles sans traitement personnalisé | Le traitement standard ferait perdre du sens opérationnel ou un fonctionnement visible par le client. |
| Le périmètre est-il aligné sur la valeur ? | Les enregistrements inclus soutiennent le lancement, le service client, les ventes ou la continuité SEO | Le périmètre contient des enregistrements obsolètes, en double ou à faible valeur. |
Une approche de migration Shift4Shop bien choisie doit être facile à expliquer : ce qui passe par le parcours principal, ce qui reçoit un accompagnement supplémentaire, ce qui exige un traitement personnalisé, ce qui est exclu et comment le résultat sera validé avant le lancement.
Conclusion
La bonne approche de migration vers Shift4Shop dépend de l’adéquation métier, de la complexité des données et du risque de lancement. Le volume d’enregistrements compte, mais le fonctionnement des Products, les Customer Groups, la tarification de gros, l’historique des Orders, la continuité SEO, les intégrations, les champs personnalisés et les références héritées de 3dcart sont souvent plus déterminants.
Une approche solide commence par le périmètre, vérifie si le Standard Service suffit, identifie quand le Managed Service apporte de la valeur, sépare les Add-ons du Custom Service, tient compte des Entity Points et n’utilise les Additional Migration Options que lorsqu’elles répondent à un objectif de migration clair. Lorsque ces décisions sont prises avant la Full Migration, le projet est plus facile à valider et risque moins d’introduire des problèmes évitables au lancement.
Questions fréquentes
Comment une entreprise doit-elle choisir son approche de migration vers Shift4Shop ?
Commencez par examiner le périmètre de la boutique source, la complexité des Products, les Customer Groups, les besoins liés à l’historique des Orders, le SEO, les intégrations et les données personnalisées. Déterminez ensuite quels domaines correspondent au parcours standard et lesquels nécessitent un accompagnement ou un traitement personnalisé.
Quand le Standard Service suffit-il pour une migration vers Shift4Shop ?
Le Standard Service peut suffire lorsque les données principales sont propres, les options Product sont simples, les règles Customer sont limitées, l’historique des Orders sert principalement de référence et les exigences SEO sont claires.
Quand faut-il envisager des Add-ons ?
Envisagez un Add-on lorsque le besoin correspond à un contrôle de données pris en charge et clairement délimité : Data Filter pour sélectionner des enregistrements à partir de conditions sur les champs, Advanced Data Mapping pour remapper un champ source pris en charge vers un champ cible Shift4Shop compatible, ou Data Transformation pour modifier des valeurs de champs pris en charge au moyen d’expressions. Le routage SEO, l’activité proche du lancement, la prise en charge des entités et la conception des échantillons restent des sujets distincts sauf si l’un de ces contrôles répond directement au besoin.
Quand le Custom Service est-il nécessaire ?
Le Custom Service est nécessaire lorsque les données source exigent une interprétation de champ sur mesure, une interprétation de règles métier, un traitement de champs personnalisés, un traitement dépendant d’intégrations ou une restructuration qui ne peut pas être prise en charge par le parcours standard ou les trois Standard Add-ons.
Que doit démontrer la Demo Migration pour Shift4Shop ?
Elle doit démontrer que les enregistrements ordinaires comme complexes restent exploitables, notamment les Products avec options ou Advanced Options, les Customers de gros ou groupés, les Orders exceptionnels, les contenus et URLs importants ainsi que les identifiants liés aux intégrations. Le résultat doit confirmer le parcours de service avant la Full Migration.
Quelle Additional Migration Option choisir pour une opération de suivi Shift4Shop ?
Utilisez la dernière configuration lorsque les règles déjà acceptées restent valables pour les nouveaux enregistrements. Utilisez une nouvelle configuration lorsque les mises en correspondance, filtres, règles d’options, logique Customer, contenus ou redirections changent. Utilisez Perform a New Migration lorsque la plateforme cible doit recevoir un résultat distinct avec un périmètre sensiblement différent, tout en restant sur le même parcours acheté entre plateforme source et plateforme cible.