Si ShopWired est retenue comme plateforme cible, la préparation doit distinguer les enregistrements qui paraissent similaires dans un export mais se comportent différemment dans la boutique. Variations Product, Product Choices, extras, champs de personnalisation, livraison numérique, Customers B2B, Categories, marques, filtres et données appartenant à des applications peuvent tous modifier le sens d’un Product ou d’un Customer. Une liste Product à plat ne peut pas expliquer ces relations à elle seule.
L’objectif de préparation est de constituer un ensemble d’éléments source qui attribue un responsable, un artefact et une condition de préparation à chaque domaine important. Cet ensemble doit décrire comment les Products sont vendus, en quoi les Customers B2B diffèrent des Customers ordinaires, comment les Orders préservent les options choisies et quelles applications ou quels systèmes externes possèdent des données au-delà des enregistrements ShopWired habituels.
Établir les accès et documenter l’environnement ShopWired
Commencez par documenter le compte ShopWired exact, le domaine principal, le thème actif, les applications installées, les rôles du personnel, le contexte fiscal et de devise, les capacités d’export Product et Order ainsi que les systèmes externes. Identifiez les responsables du catalogue, des comptes B2B, des Orders, du SEO, du code du thème, de la finance, du traitement des commandes et des intégrations.
Préparez les accès pris en charge pour le parcours de migration sélectionné. Les accès à une plateforme hébergée, les exports et les identifiants API ou d’intégration autorisés ne doivent pas être présentés comme interchangeables. Le responsable des accès doit fournir la méthode applicable à la boutique actuelle et rester disponible pour les questions de permissions ou de périmètre des données.
| Action | Responsable | Élément attendu | Condition de préparation |
|---|---|---|---|
| Confirmer le compte et le domaine | Administrateur de la boutique | Détails du compte, liste des domaines, statut de la boutique | La boutique source correcte ne prête à aucune ambiguïté. |
| Inventorier les applications installées | Responsable de la plateforme | Liste des applications, finalité, données créées, état actuel | Les données appartenant aux applications peuvent être séparées des enregistrements natifs. |
| Documenter la propriété du thème et du code | Responsable du thème ou agence | Version du thème, note sur le code personnalisé, dépôt ou emplacement de sauvegarde | Les dépendances de présentation et de code ont un responsable nommé. |
| Confirmer les exports et accès source | Responsable données ou technique | Permissions d’export, détails API ou flux lorsque pertinent | Les éléments source requis peuvent être collectés. |
| Ouvrir un journal des changements | Responsable projet | Modifications datées des Products, Customers, Orders, applications et URL | L’ensemble d’éléments préparé ne deviendra pas obsolète silencieusement. |
Préparer les Products selon leur fonctionnement commercial
ShopWired sépare variations Product, Product Choices et Product Extras. Les variations peuvent posséder leur propre prix, SKU, quantité en stock, image, poids, GTIN, MPN, traitement fiscal et autres attributs. Les Choices sont des ensembles d’options réutilisables affectés aux Products et peuvent ajouter un coût, mais ils ne représentent pas des variantes avec stock indépendant. Les Extras sont des ajouts facultatifs et peuvent parfois référencer un autre Product pour la gestion du stock. Les champs de personnalisation et envois de fichiers peuvent capturer des informations propres à l’acheteur.
Préparez les Products en fonction de leur comportement plutôt que de leur nombre. Incluez l’ID Product, le titre, le SKU, le statut, le prix, le prix promotionnel, le traitement fiscal, le stock, le poids, les Categories, la marque, les filtres, les images, le contenu, les champs SEO, les structures de variations, les Choices, Extras, champs de personnalisation, références de livraison numérique et identifiants externes.
| Modèle Product | Action de préparation | Élément attendu | Condition de préparation |
|---|---|---|---|
| Variations | Documenter noms d’options, valeurs, combinaisons, état de publication, attributs de variation et héritage du parent | Export des variations et exemples de Products | Les combinaisons ayant un sens indépendant sont documentées. |
| Product Choices | Documenter ensemble de choix global, options, coût supplémentaire, affectation Product, caractère obligatoire et affichage conditionnel | Inventaire des ensembles de choix et Products affectés | Les choix réutilisables de l’acheteur ne sont pas confondus avec des variantes. |
| Product Extras | Documenter finalité de l’extra, prix, Product lié le cas échéant et hypothèse de stock | Liste des extras et Products représentatifs | Les ajouts facultatifs ont une responsabilité claire. |
| Personnalisation ou envoi de fichier | Documenter libellé du champ, caractère obligatoire, entrée acceptée et affichage sur la ligne d’Order | Exemples de Products et Orders | Les informations propres à l’acheteur restent liées à l’achat. |
| Product numérique ou service | Documenter mode de livraison, fichier ou responsable d’accès et statut Product | Liste Product et ressources source | Les éléments de livraison non physique sont disponibles. |
| Product en précommande ou planifié | Documenter date d’expédition ou de disponibilité et responsable opérationnel | Exemples de Products et règles de date | Le fonctionnement dépendant du temps est documenté. |
Ne convertissez pas les Choices ou Extras en variations uniquement parce que leurs libellés se ressemblent. Leur gestion du stock, tarification, réutilisation et comportement dans les Orders diffèrent.
Préparer Categories, marques, filtres et découverte dans la boutique
Un Product peut être complet comme enregistrement tout en devenant difficile à trouver si les éléments liés aux Categories, marques, filtres, recherche ou navigation sont incomplets. Préparez la hiérarchie des Categories, les affectations Product, les marques, valeurs utilisées pour les filtres, menus, landing pages et routes importantes comme des structures distinctes mais reliées.
| Domaine de découverte | Responsable | Élément attendu | Condition de préparation |
|---|---|---|---|
| Categories | Responsable catalogue | Hiérarchie, affectations Product, statut, contenu de landing page | Chaque Category conservée a une finalité connue. |
| Marques | Responsable merchandising | Liste des marques, relations Product, URL, métadonnées | La découverte par marque est séparée des simples libellés descriptifs. |
| Filtres | Responsable catalogue ou recherche | Noms de filtres, valeurs, couverture Product, exceptions de nettoyage | Les valeurs utilisées par les acheteurs sont suffisamment cohérentes pour être mises en correspondance. |
| Menus et landing pages | Responsable de la boutique | Carte de navigation, captures d’écran, Categories et pages liées | Les parcours de présentation sont documentés indépendamment de l’export Category. |
| URL prioritaires | Responsable SEO | Routes Product, Category, marque, page et campagne | Les routes de forte valeur ont une décision cible planifiée. |
Documentez également les Products affectés à plusieurs Categories, les Categories masquées ou saisonnières, les zones réservées au B2B et les parcours de campagne. Ces cas révèlent des règles de découverte qu’une simple hiérarchie ne montre pas.
Préparer Customers, comptes B2B et éléments d’adresse
ShopWired peut prendre en charge des Customers ordinaires et des Customers B2B avec des comportements de compte distincts. Les fonctions B2B peuvent inclure tarification B2B, Products ou Categories réservés, comptes de crédit, promotions restreintes et état d’activation du compte. La préparation doit montrer quels Customers sont des comptes ordinaires et lesquels dépendent de relations B2B.
Préparez ID Customer, nom, e-mail, état du compte, adresses, préférences marketing, champs personnalisés, état B2B, contexte de crédit ou de paiement, notes internes et identifiants externes. Examinez les e-mails dupliqués ou partagés, car l’e-mail peut jouer un rôle important dans les relations de compte et d’Order.
| Modèle Customer | Action de préparation | Élément attendu | Condition de préparation |
|---|---|---|---|
| Customer enregistré standard | Documenter identité, adresses, état du compte et relation avec les Orders | Exemples Customer et Order | L’identité du compte est claire. |
| Acheteur invité | Documenter e-mail, historique d’Orders et éventuelle relation avec un compte créé plus tard | Échantillons d’Orders invités | L’historique invité n’est pas supposé être un compte enregistré. |
| Customer B2B | Documenter état actif, tarification B2B, Products ou Categories restreints, contexte de crédit et champs personnalisés | Registre des Customers B2B | Le sens B2B est rattaché aux Customers réels. |
| E-mail dupliqué ou partagé | Identifier les enregistrements, la raison métier et la décision prévue | Liste des exceptions d’identité | L’ambiguïté d’identité a un responsable. |
| Customer lié à un système externe | Documenter identifiants CRM, comptabilité, ERP ou support | Dictionnaire des champs d’intégration | Les clés de recherche en aval restent disponibles. |
Préparer les Orders historiques et les sélections Product
Les Orders historiques doivent préserver les informations nécessaires au service Customer, à la finance et aux opérations. Les Orders ShopWired peuvent inclure variations, Choices, Extras, texte de personnalisation, références de fichiers envoyés, tarification B2B, libellés de livraison, contexte fiscal, remises, remboursements et notes. Sélectionnez des Orders qui exposent chacun de ces modèles.
| Domaine d’Order | Action | Élément attendu | Condition de préparation |
|---|---|---|---|
| Configuration Product | Inclure variations, Choices, Extras et sélections de personnalisation | Lignes d’Orders représentatives | La configuration achetée est interprétable. |
| Identité Customer | Distinguer Orders enregistrés, invités et B2B | Échantillons couvrant plusieurs scénarios | La propriété de l’Order est claire. |
| Tarification et remises | Inclure prix B2B, prix promotionnel, voucher, ajustement manuel et cas fiscaux | Échantillons des composantes du total | Le contexte commercial historique est documenté. |
| Livraison et traitement des commandes | Documenter mode de livraison, statut, suivi, retrait et traitements inhabituels | Exemples d’Orders et expéditions | L’historique de traitement des commandes possède un sens connu. |
| Remboursements et annulations | Inclure montant, statut, notes et Order associé | Ensemble d’Orders d’exception | L’historique financier et de service reste compréhensible. |
| Références externes | Documenter identifiants de comptabilité, ERP, marketplace, traitement des commandes ou support | Orders sensibles aux intégrations | Les valeurs de recherche requises sont identifiées. |
Les éléments des Orders historiques doivent décrire ce qui s’est passé. Ils ne doivent pas remplacer la configuration active des paiements, de la livraison, de la fiscalité, des e-mails ou du parcours de commande dans la nouvelle boutique.
Inventorier applications, API, webhooks, flux et code personnalisé
Créez un registre de dépendances pour chaque application ShopWired, flux Product, connexion marketplace, outil comptable, CRM, ERP, service de traitement des commandes, système d’entrepôt, intégration d’analyse, processus API, webhook et personnalisation de thème. Indiquez si la dépendance crée des données, en lit, modifie le parcours de commande ou l’affichage, change le stock ou utilise des identifiants qui doivent rester recherchables.
| Champ de dépendance | Détail requis | Condition de préparation |
|---|---|---|
| Responsable et finalité | Responsable métier, responsable technique, processus pris en charge | La responsabilité est explicite. |
| Objets de données | Products, Customers, Orders, stock, Categories, contenu ou champs personnalisés utilisés | Les enregistrements concernés sont connus. |
| Sens et fréquence | Lecture, écriture, bidirectionnel, planifié, événementiel ou manuel | L’autorité source est documentée. |
| Identifiants | SKU, ID Product, e-mail Customer, numéro d’Order, clé externe | Les dépendances de recherche sont préservées. |
| Décision de transition | Reconnecter, reconstruire, retirer, remplacer ou examiner | Aucune dépendance n’est supposée continuer automatiquement. |
Incluez le code du thème lorsqu’il modifie les options Product, la visibilité B2B, la navigation, l’affichage du contenu ou la capture d’informations d’Order. Le code uniquement visuel et le code portant des données ne doivent pas être traités comme un même risque.
Préparer contenu, médias, URL et éléments liés au thème
Préparez pages, contenus de blog ou guides, politiques, formulaires, médias, fichiers téléchargeables, descriptions Product et Category, pages de marque, métadonnées, liens internes, attentes canoniques et redirections. Indiquez quel contenu est natif, appartient à une application ou est intégré dans le code du thème.
| Domaine de contenu | Responsable | Élément attendu | Condition de préparation |
|---|---|---|---|
| Contenu Product et Category | Responsable catalogue ou marketing | Exports, chemins média, pages représentatives | Le contenu commercial peut être relié aux enregistrements. |
| Pages et politiques | Responsable contenu | Inventaire des pages, statut, route, liens internes | Les décisions conserver, reconstruire, fusionner ou exclure sont enregistrées. |
| Ressources numériques | Responsable opérations ou contenu | Fichiers d’origine, relation Product, règles d’accès | Les fichiers source sont disponibles. |
| Routes SEO | Responsable SEO | URL prioritaires, métadonnées, redirections, parcours de campagne | Les entrées de continuité des routes sont complètes. |
| Contenu dépendant du thème | Responsable du thème | Emplacements de template, sections personnalisées, captures d’écran | Le contenu masqué dans le code de présentation est identifié. |
Préparer exports, sauvegardes et contrôle des changements source
Créez une archive datée contenant les exports Product, Customer, Customer B2B, Order, Category, marque, filtre, contenu et données liées aux applications, ainsi que les médias, captures d’écran, documentation API ou flux, sauvegarde du thème et notes explicatives. Conservez les exports d’origine inchangés et effectuez le nettoyage dans des copies de travail.
| Ensemble d’éléments | Contenu requis | Condition de préparation |
|---|---|---|
| Exports principaux | Fichiers, date d’export, ensemble de champs, contexte du compte, checksum | Les enregistrements sont complets et attribuables. |
| Éléments liés aux options | Variations, Choices, Extras, champs de personnalisation, affectations Product | Le comportement commercial n’est pas perdu dans un export Product seul. |
| Thème et médias | Sauvegarde du thème ou trace du code, images, téléchargements, ressources envoyées | La présentation et les fichiers source peuvent être retrouvés. |
| Registre des dépendances | Liste des applications, flux, notes API ou webhook, identifiants externes | La propriété des intégrations est documentée. |
| Journal des changements | Nouveaux ou modifiés Products, Customers, Orders, URL, applications et règles B2B | Les changements source ultérieurs peuvent être rapprochés. |
Sélectionner des enregistrements représentatifs pour la migration
Sélectionnez des échantillons qui révèlent les structures ShopWired distinctes plutôt que seulement des enregistrements ordinaires. Chaque échantillon doit comporter une courte attente source expliquant pourquoi il est inclus et quels champs ou relations sont importants.
| Groupe d’échantillons | Inclure | Objectif de préparation |
|---|---|---|
| Products | Product simple, Product multi-variations, Product riche en Choices, extra, Product avec personnalisation ou envoi de fichier, Product numérique, Product réservé au B2B | Exposer différents fonctionnements de vente. |
| Customers | Enregistré, invité, B2B, contexte de crédit, exception d’e-mail dupliqué, Customer avec identifiant externe | Représenter les différences d’identité et B2B. |
| Orders | Variation, Choices, personnalisation, prix B2B, remise, remboursement, livraison inhabituelle, référence externe | Préserver le contexte historique. |
| Découverte | Category prioritaire, marque, ensemble de filtres, parcours de menu, landing page | Préparer les éléments de structure de la boutique. |
| Contenu et intégrations | Page sensible au SEO, ressource numérique, champ appartenant à une application, flux ou enregistrement API | Représenter les dépendances hors cœur. |
L’ensemble d’échantillons est prêt lorsque chaque enregistrement sélectionné possède une attente source, des éléments reliés, les identifiants pertinents et un reviewer nommé.
Valider la préparation de ShopWired
| Contrôle final | Condition de préparation |
|---|---|
| Accès | Compte correct, exports, applications, propriété du thème et contacts techniques sont confirmés. |
| Products | Variations, Choices, Extras, personnalisation, livraison numérique, visibilité B2B et identifiants sont documentés. |
| Découverte | Categories, marques, filtres, menus et routes prioritaires sont préparés. |
| Customers | Cas standard, invité, B2B, dupliqué, adresse et identifiant externe sont compris. |
| Orders | Sélections Product, totaux, livraison, remboursements, notes et références externes sont interprétables. |
| Dépendances | Applications, API, webhooks, flux, code de thème et systèmes externes ont une décision de transition. |
| Entrées | Exports, ressources, sauvegardes, checksums et journal des changements sont disponibles. |
| Échantillons | Les enregistrements représentatifs couvrent des modèles source ordinaires et complexes. |
Conclusion
La préparation d’une migration vers ShopWired doit préserver les différences entre variations, Choices, Extras, personnalisation, fonctionnement B2B et données appartenant aux applications. Ces distinctions déterminent si un Product, Customer ou Order reste compréhensible une fois sorti de la boutique source.
Lorsque les accès, relations source, exports, ressources, dépendances et enregistrements représentatifs sont documentés, la configuration de migration peut avancer à partir d’une compréhension stable et testable de la source vers ShopWired.
Questions fréquentes
Pourquoi variations, Choices et Extras doivent-ils être inventoriés séparément ?
Ils ont des fonctionnements différents en matière de tarification, stock, réutilisation et Orders. Les traiter comme une structure d’option générique unique peut supprimer un sens commercial important.
Quels Products ShopWired doivent figurer dans l’ensemble d’échantillons ?
Incluez des Products simples, variations, Choices, Extras, Products avec personnalisation ou envoi de fichier, Products numériques ou de service, Products réservés au B2B et enregistrements avec identifiants externes.
Comment préparer les Customers B2B ?
Documentez état actif, tarification B2B, Products ou Categories restreints, contexte de crédit, champs personnalisés, adresses, historique d’Orders et éventuels identifiants de systèmes externes.
Les Orders invités doivent-ils être reliés à des Customers enregistrés pendant le nettoyage ?
Uniquement lorsque l’entreprise a validé la relation d’identité. Les adresses e-mail partagées ou réutilisées peuvent rendre une consolidation automatique peu fiable.
Quelles informations sur les applications sont nécessaires avant migration ?
Documentez ce que fait l’application, quels enregistrements elle lit ou crée, ses identifiants, son responsable, son rythme d’intégration et la décision de la reconnecter, reconstruire, retirer ou remplacer.
Comment contrôler les changements après la date d’export ?
Maintenez un journal daté des Products, Customers, Orders, URL, applications, code de thème et règles B2B afin que les changements ultérieurs puissent être rapprochés avec les éléments préparés.