Si Shift4Shop est choisi comme plateforme cible, la préparation doit documenter comment la boutique source sera représentée au moyen des Products, options ordinaires, Advanced Options, Product extra fields, Categories, SmartCategories, Customer Groups, Price Levels, Customers, Orders, contenus, modules et systèmes externes. Les boutiques établies peuvent également contenir des libellés, exports, champs personnalisés et intégrations hérités de l’époque 3dcart dont le sens actuel n’est pas évident à partir du seul nom de champ.
Le dossier de préparation doit combiner les accès, les éléments de vérification, la propriété et les conditions de préparation. Son objectif est de rendre explicite la logique de la source avant de constituer l’ensemble d’échantillons représentatifs de migration.
Consigner les hypothèses concernant la cible Shift4Shop
Commencez par les hypothèses d’exploitation cible qui modifient la préparation des données.
| Domaine | Décision à consigner | Élément de vérification |
|---|---|---|
| Identité Product | Quels enregistrements source deviennent des Products de base et quelles combinaisons d’options nécessitent une identité commerciale indépendante | Matrice des familles Product |
| Fonctionnement des options | Quels choix restent des options ordinaires et lesquels exigent des Advanced Options ou un autre propriétaire | Exemples d’options et de combinaisons |
| Découverte dans le catalogue | Quelles Categories source sont statiques, dynamiques, de navigation, de recherche ou obsolètes | Classification des Categories et SmartCategories |
| Traitement Customer | Quels Customer Groups, Price Levels, règles d’accès et champs personnalisés restent | Inventaire des groupes et de la tarification |
| Orders historiques | Quels détails de ligne, statuts, remises, récompenses, affiliations et références externes sont nécessaires aux équipes | Dossier d’Orders représentatifs |
| Données héritées et personnalisées | Quels champs de l’époque 3dcart, modules, applications ou identifiants externes restent actifs | Registre de lignée et des dépendances |
Une Product Option source ne doit pas être affectée à Advanced Options uniquement parce qu’elle possède plusieurs valeurs. La décision doit être fondée sur le fait que la combinaison détient ou non un SKU, un stock, un GTIN, un poids, un prix, une image, une disponibilité ou une autre valeur gérée indépendamment. Consignez cette règle au niveau de la famille Product afin que des Products similaires suivent une même règle contrôlée au lieu d’être interprétés différemment pendant la migration.
Préparer les accès, exports et un instantané de la source
Rassemblez les accès et éléments nécessaires pour comprendre la boutique source et préparer Shift4Shop.
Incluez :
- les accès administrateur à la source et à Shift4Shop avec les permissions adaptées ;
- les exports Products, options, Customers, Orders, Categories, contenus et redirections lorsqu’ils sont disponibles ;
- les archives de médias et fichiers lorsque les liens source sont protégés ou temporaires ;
- les définitions des Customer Groups et Price Levels ;
- les définitions des Product extra fields et des exemples ;
- les règles des SmartCategories et les affectations aux Categories ordinaires ;
- les enregistrements de modules, applications, affiliation, récompenses, CRM, listes d’attente et Reviews lorsqu’ils sont inclus dans le périmètre ;
- les identifiants externes utilisés par ERP, comptabilité, traitement, marketplace ou CRM ;
- des sauvegardes source datées et un relevé des données susceptibles de changer avant la fenêtre de migration.
| Élément de vérification | Condition de préparation |
|---|---|
| Journal des accès | Les zones d’administration nécessaires sont accessibles et les responsables sont connus |
| Archive d’exports | Les fichiers s’ouvrent, contiennent les enregistrements attendus et possèdent une date d’export claire |
| Dictionnaire des champs et modules | Les valeurs personnalisées ou héritées importantes ont une fonction et un propriétaire |
| Liste d’échantillons Product | Les structures d’options ordinaires et exceptionnelles sont représentées |
| Liste d’échantillons Order | Les statuts historiques, ajustements et références externes sont représentés |
Préparer Products, options et Advanced Options
Les options ordinaires de Shift4Shop peuvent modifier les choix acheteurs ainsi que le prix ou le poids, tandis que les Advanced Options peuvent donner à certaines combinaisons leurs propres champs commerciaux. Préparez des exemples Product qui rendent cette distinction visible.
Incluez :
- des Products simples ;
- des Products avec listes déroulantes, boutons radio, images, texte ou autres options ordinaires ;
- des Products avec Advanced Options et code, GTIN, stock, poids, prix, image ou disponibilité au niveau de la combinaison ;
- des Products utilisant l’héritage d’options au niveau Category ;
- des Products avec extra fields, identifiants fabricant, mots-clés de recherche ou métadonnées spécialisées ;
- des kits, bundles, Products numériques, listes d’attente, abonnements ou configurations détenues par des applications ;
- des Products dont le prix ou la visibilité diffère selon Customer Group ou Price Level ;
- des Products synchronisés avec un système externe de stock ou de catalogue.
| Fonctionnement source | Décision de préparation Shift4Shop | Éléments requis |
|---|---|---|
| L’option change la sélection mais ne crée pas de stock indépendant | Product Option ordinaire | Type d’option, valeurs, effet sur prix/poids et exemple de ligne d’Order |
| La combinaison possède un SKU, stock, GTIN, poids ou image indépendants | Advanced Option | Matrice de combinaisons et identifiants source |
| La valeur décrit le Product | Extra field, description, champ de recherche ou métadonnée externe | Fonction du champ, type de données et système ou personne qui le consomme |
| Le choix est saisi une seule fois par l’acheteur | Relation texte ou saisie personnalisée | Exemple dans la boutique et élément de ligne d’Order |
| La logique est créée par une application ou du code personnalisé | Propriétaire applicatif ou externe | Description de la règle, enregistrements liés et identifiants externes |
Normalisez les noms d’options, codes Product, identifiants fabricant et le sens des extra fields avant la migration. Un libellé d’export hérité de 3dcart doit être rattaché au processus actuel réel plutôt que conservé uniquement parce qu’il existe.
Préparer Categories, SmartCategories, recherche et URL
Les Categories ordinaires de Shift4Shop contiennent des Products affectés, tandis que les SmartCategories peuvent être alimentées dynamiquement à partir de règles telles que l’état promotionnel, la date de sortie, le traitement de l’expédition ou des mots-clés. Préparez-les comme deux structures distinctes.
| Regroupement source | Question de destination | Élément de préparation |
|---|---|---|
| Category stable | L’appartenance Product doit-elle être conservée directement ? | Hiérarchie Category et affectations Product |
| Collection dynamique | Une SmartCategory ou une autre règle de merchandising est-elle appropriée ? | Règle source et propriétaire prévu |
| Regroupement par marque ou fabricant | Doit-il rester une Category, un champ fabricant, un filtre ou une Page ? | Exemples de marque et objectif de découverte |
| Valeur utilisée uniquement pour la recherche | Doit-elle rester un mot-clé, extra field, code Product ou autre champ recherchable ? | Inventaire des termes et des champs |
| Lien présent uniquement dans un menu | Vers quelle Category, Page, Product ou route externe pointe-t-il ? | Plan de navigation |
| URL héritée | Quel Product, quelle Category ou quelle Page doit devenir la destination ? | Inventaire prioritaire des redirections |
Préparez les URL Product, Category, Extra Page, Blog ou autres contenus, fabricant, campagne et politique. Consignez le chemin source, la destination prévue, le responsable du contenu, les métadonnées, les liens internes et le besoin de redirection. Pour les SmartCategories, conservez la règle qui génère l’appartenance comme élément séparé de l’URL publique : un groupe dynamique ne peut pas être reconstruit de manière fiable à partir d’une simple liste ponctuelle de Products.
Préparer Customer Groups, Price Levels et enregistrements Customer
Les Customer Groups de Shift4Shop peuvent relier des Customers à des Price Levels, minimums de commande, règles de visibilité Product/Category et moyens de paiement ou d’expédition disponibles. Préparez le groupe avec ses règles associées.
Rassemblez :
- les noms et fonctions des Customer Groups ;
- les affectations de Price Level et prix au niveau Product ;
- les restrictions de visibilité Product ou Category ;
- les minimums de commande ;
- les champs personnalisés Customer et adresses ;
- les relations d’exonération fiscale, gros, affiliation, récompenses, CRM, Review, liste d’attente ou marketing ;
- les identifiants de compte externes et références d’entreprise ;
- des exemples de Customers dupliqués et de commandes invitées.
| Question de préparation | Élément | Condition de préparation |
|---|---|---|
| Quels groupes restent commercialement actifs ? | Liste des groupes et propriétaire | Les groupes obsolètes sont exclus ou archivés |
| Quels Price Levels appartiennent à chaque groupe ? | Exemples Product et groupe | Les relations Product, Price Level et Customer Group sont explicites |
| Quelles règles d’accès dépendent des groupes ? | Exemples de Products/Categories restreints | Les règles de visibilité ont un propriétaire cible |
| Quels enregistrements d’application appartiennent aux Customers ? | Échantillons récompenses, affiliation, CRM ou Reviews | Le propriétaire applicatif ou externe pour la suite est documenté |
| Comment gérer les Customers dupliqués ? | Exemples de clés de rapprochement | Les règles de fusion et de conservation séparée sont définies |
Préparer les Orders historiques et références opérationnelles
Préparez des Orders qui exposent la structure historique plutôt que seulement des Orders payés ordinaires.
Incluez :
- des Orders avec options ordinaires et Advanced Options ;
- le contexte Customer Group ou Price Level ;
- Coupons, promotions, Gift Certificates, récompenses, affiliation, taxes et frais d’expédition ;
- Orders en attente, annulés, remboursés, partiellement remboursés, expédiés et partiellement traités ;
- tickets CRM, contexte de liste d’attente, Reviews, notes et ajustements manuels lorsque cela est pertinent ;
- références ERP, comptabilité, marketplace, traitement ou paiement ;
- anciens libellés de statut encore utilisés par les équipes.
Pour chaque échantillon, expliquez quelle ligne, quel total, quel statut ou quelle référence externe soutient le service Customer, la finance, le traitement ou le reporting. La configuration actuelle des paiements, expédition, taxes et notifications doit être documentée séparément des éléments historiques des Orders.
Inventorier modules, applications, champs personnalisés et données héritées
Créez un registre des dépendances pour les modules Shift4Shop, applications optionnelles, champs personnalisés, scripts, intégrations et enregistrements hérités de l’époque 3dcart.
Pour chaque élément, consignez :
- l’objectif métier ;
- le propriétaire source ;
- les Products, Customers, Orders, Categories ou Pages liés ;
- des enregistrements d’exemple ;
- les éléments disponibles via export ou API ;
- les identifiants externes ;
- si la fonction continue, sera remplacée ou retirée ;
- quelles données doivent rester pour l’historique ou le rapprochement.
Accordez une attention particulière à la recherche, la tarification Advanced Options, les récompenses, l’affiliation, le CRM, les Reviews, listes d’attente, abonnements, Products numériques, marketplaces, ERP, comptabilité, fiscalité, expédition et paiements. Le registre est prêt lorsque chaque champ actif hors cœur possède un enregistrement parent, un responsable métier, une voie d’export, un identifiant externe et une décision de continuité ou retrait.
Sélectionner des échantillons représentatifs pour tester la migration Shift4Shop
| Échantillon | Objectif de préparation |
|---|---|
| Product simple | Établir le traitement ordinaire du Product, de la Category, des médias, du prix et du stock |
| Product avec options ordinaires | Exposer les valeurs d’option et leur sens sur les lignes d’Order sans stock indépendant |
| Product avec Advanced Options | Exposer code, stock, GTIN, poids, image et prix au niveau de la combinaison |
| Product avec extra fields ou métadonnées recherchables | Exposer les champs descriptifs et ceux détenus par des intégrations |
| Product dans une SmartCategory | Exposer le regroupement dynamique par rapport à une affectation Category directe |
| Customer dans un groupe commercial | Exposer Customer Group, Price Level, accès et relations de champs personnalisés |
| Order historique complexe | Exposer options, montants, statuts, récompenses, remboursements et références externes |
| Route de contenu prioritaire | Exposer Extra Page, Product, Category, métadonnées et décisions de redirection |
| Enregistrement hérité ou détenu par une application | Exposer la propriété actuelle de données de l’époque 3dcart ou créées par une extension |
Joignez les identifiants source, l’objectif métier, le propriétaire cible attendu, les identifiants externes associés et les exclusions connues. Le registre d’échantillons doit expliquer pourquoi chaque enregistrement a été choisi et quelle relation source il représente, sans définir à ce stade les critères ultérieurs de réussite ou de lancement. Utilisez des échantillons séparés pour options ordinaires, Advanced Options, SmartCategories, prix par Customer Group et données applicatives héritées lorsqu’un seul enregistrement ne peut pas représenter fidèlement toutes ces structures.
Finaliser la vérification de préparation à Shift4Shop
| Question de préparation | Élément requis | Condition de préparation |
|---|---|---|
| Les accès requis sont-ils disponibles ? | Journal des accès | Les zones source et cible nécessaires sont accessibles |
| Options ordinaires et Advanced Options sont-elles distinguées ? | Matrice des familles Product | Chaque modèle d’option important possède un propriétaire documenté |
| Categories et SmartCategories sont-elles classées ? | Inventaire Category | Appartenance statique et dynamique ne sont pas confondues |
| Les règles Customer Group et Price Level sont-elles documentées ? | Matrice des relations commerciales | Groupes, Products, prix et restrictions sont reliés |
| Les Orders historiques sont-ils représentés ? | Dossier d’échantillons Order | Statuts, ajustements et références externes importants sont expliqués |
| Les modules et champs hérités ont-ils un propriétaire ? | Registre des dépendances | Chaque enregistrement personnalisé actif possède un responsable pour la suite |
| Sauvegardes et exports sont-ils à jour ? | Archive source datée | Les éléments peuvent être récupérés indépendamment de la boutique en production |
| Les échantillons représentatifs sont-ils sélectionnés ? | Registre d’échantillons | Structures ordinaires et exceptionnelles sont couvertes |
La préparation est terminée lorsqu’aucune décision critique concernant Product, Customer, Order, Category ou intégration ne dépend d’un ancien libellé inexpliqué ou d’un module non documenté. Chaque point restant doit identifier le responsable métier, les éléments encore nécessaires et la structure ou le système cible qui prendra la décision finale.
Conclusion
La préparation de Shift4Shop doit exposer les relations derrière Products, options ordinaires, Advanced Options, Categories, SmartCategories, Customer Groups, Price Levels, Orders, contenus et données héritées. Le travail le plus important consiste à distinguer les structures natives des données détenues par des modules et des données de l’époque 3dcart, tout en préservant les identifiants encore utilisés par les équipes et systèmes externes.
Un dossier d’éléments bien documenté donne aux tests représentatifs un ensemble d’échantillons avec des attentes source et une propriété clairement définies.
Questions fréquentes
Quelle est la première décision catalogue à préparer pour Shift4Shop ?
Déterminez quels choix source sont des Product Options ordinaires et quelles combinaisons nécessitent une identité Advanced Option. Cette distinction affecte SKU, stock, GTIN, poids, prix, images et sens de la ligne d’Order.
Chaque Category source doit-elle devenir une Category Shift4Shop ?
Non. Certains regroupements source sont des campagnes dynamiques, collections de recherche, vues fabricant, liens de menu ou classifications internes. Préparez d’abord leur objectif de découverte avant d’attribuer une destination.
Pourquoi Customer Groups et Price Levels doivent-ils être préparés ensemble ?
Le groupe identifie le contexte Customer, tandis que le Price Level et les restrictions associées définissent le comportement commercial. Un nom de groupe sans ses prix Product ni ses règles d’accès est incomplet.
Quels Orders doivent faire partie de l’ensemble d’échantillons représentatifs ?
Incluez des Orders avec options ordinaires, Advanced Options, remises, taxes, expédition, différents statuts, remboursements, contexte de récompense ou d’affiliation et références de systèmes externes.
Quels éléments faut-il recueillir pour les champs hérités de 3dcart ?
Reliez chaque champ à son objectif métier actuel et à son consommateur. Ne le conservez que si une structure Shift4Shop, un module actif ou un système externe détient encore cette valeur.
Quand la préparation de Shift4Shop est-elle terminée ?
Elle est terminée lorsque les accès et exports sont prêts, les modèles d’options Product classés, les groupes commerciaux et prix documentés, les routes prioritaires cartographiées, les dépendances attribuées et les échantillons représentatifs sélectionnés.