Les échecs d’une migration vers BigCommerce viennent souvent du fait que les enregistrements sont préservés tandis que la relation qui leur donne leur sens dans la vitrine ou dans les opérations disparaît. Les variantes Product et les modifiers peuvent sembler similaires dans la source tout en se comportant différemment dans le traitement des commandes. Les groupes de Customers et les listes de prix peuvent tous deux influencer ce qu’un acheteur voit, mais ils ne constituent pas un seul champ de prix. Les canaux, sites, arborescences de Categories, contenus, emplacements de stock et frameworks de vitrine ajoutent encore d’autres contextes.
Les erreurs ci-dessous concernent des situations récurrentes où une boutique BigCommerce est remplie de données mais reste commercialement incohérente. Chaque mesure préventive nomme la relation qui doit survivre et la condition précise permettant de considérer le risque comme maîtrisé.
Erreur 1 : traiter variantes, modifiers et champs Product comme un seul modèle de choix
Ce qui se passe mal
Les options de la source sont mappées vers le champ BigCommerce qui paraît le plus pratique. Des SKU enfants suivis en stock deviennent des modifiers, des personnalisations deviennent des variantes et des spécifications techniques deviennent des choix sélectionnables par l’acheteur.
Les variantes BigCommerce sont des combinaisons de valeurs d’options de variantes et peuvent porter des données commerciales de premier niveau. Les modifiers représentent des choix de l’acheteur qui personnalisent ou complètent l’article traité sans changer la variante sélectionnée dans le stock. Les champs personnalisés Product et les metafields servent encore d’autres fonctions descriptives ou opérationnelles.
Signaux d’alerte précoces
| Signal d’alerte | Ce qu’il indique |
|---|---|
| Des combinaisons taille/couleur avec stock distinct sont créées comme modifiers. | Les choix portant du stock sont détachés de l’identité de variante. |
| Des choix de gravure, date, téléversement ou garantie sont créés comme variantes. | Une personnalisation sans stock est transformée en SKU artificiels. |
| Des SKU enfants de la source disparaissent parce que le Product parent est traité comme seule unité de stock. | La continuité du traitement et du stock sera rompue au niveau de la variante. |
| Les spécifications Product ne sont visibles que dans les descriptions ou choix de l’acheteur. | Les attributs structurés sont mélangés aux contrôles de vente. |
Prévention
Classifiez chaque valeur source selon son comportement lors du traitement des commandes. Utilisez les variantes pour les combinaisons vendables identifiables indépendamment, les modifiers pour la personnalisation propre à l’achat qui ne sélectionne pas une autre variante suivie en stock, et les champs personnalisés ou metafields pour les données descriptives ou opérationnelles.
Préservez comme une seule relation les valeurs d’options de variante, SKU, stock, prix, poids, images et identifiants externes. Préservez les sélections de modifiers avec la ligne d’Order et n’affectez pas de stock aux combinaisons de modifiers.
Exemple de recommandation
Pour un pantalon sur mesure, représentez la taille et la longueur d’entrejambe comme variantes lorsque chaque combinaison est stockée et traitée séparément. Conservez le texte du monogramme comme modifier et les consignes d’entretien du tissu comme donnée personnalisée Product.
Condition Pass
Chaque choix échantillonné aboutit à la bonne variante traitée, les sélections de modifiers restent visibles sur la ligne d’Order et les champs descriptifs ne créent ni fausses variantes ni faux enregistrements de stock.
Erreur 2 : préserver les Categories tout en cassant les arborescences et la découverte dans les vitrines
Ce qui se passe mal
Les Categories source sont importées dans une hiérarchie unique, plate ou globale sans tenir compte des arborescences BigCommerce, du contexte des canaux, des menus, de la recherche à facettes, du tri ou du framework de vitrine. Les Products restent affectés aux Categories, mais les clients rencontrent des branches manquantes, des filtres sans pertinence ou la mauvaise arborescence sur une vitrine.
Une Category source peut aussi représenter une marque, une campagne, un regroupement interne ou une page d’atterrissage SEO plutôt qu’une hiérarchie durable du catalogue.
Signaux d’alerte précoces
- Une seule arborescence de Categories est supposée convenir à toutes les vitrines ou canaux.
- Les affectations Product sont revues sans vérifier quelle arborescence la vitrine utilise.
- Marques, attributs et valeurs de campagne sont tous convertis en Categories.
- Navigation et recherche à facettes sont supposées se déduire automatiquement des lignes de Categories importées.
Prévention
Classifiez les regroupements source selon leur fonction. Construisez ou affectez l’arborescence de Categories prévue pour chaque contexte de vitrine, préservez les relations Product-to-Category et gardez séparés le sens des marques, filtres, campagnes et éléments de navigation.
Définissez quelles valeurs alimentent la recherche à facettes et quelles Categories nécessitent du contenu, un tri, des images ou des redirections. Considérez les vitrines Stencil, Catalyst et headless comme des implémentations qui consomment les relations du catalogue, et non comme des résultats automatiques de l’import des Categories.
Exemple de recommandation
Pour un marchand ayant des vitrines retail et wholesale, utilisez des arborescences adaptées à chaque canal lorsque les parcours d’achat diffèrent, conservez une identité Product partagée et préservez les attributs Product ou données personnalisées utilisés par les filtres plutôt que de les dupliquer en Categories.
Condition Pass
Chaque vitrine utilise l’arborescence prévue, les Products apparaissent dans les bonnes branches, la navigation atteint ces branches et les filtres s’appuient sur des données cohérentes plutôt que sur une duplication accidentelle de Categories.
Erreur 3 : séparer les groupes de Customers des listes de prix qui leur donnent leur sens
Ce qui se passe mal
Les groupes de Customers migrent comme de simples libellés tandis que les listes de prix, enregistrements de prix au niveau des variantes, accès aux Categories ou affectations de canaux sont traités séparément. Les acheteurs apparaissent dans le bon groupe mais reçoivent encore les prix catalogue, la mauvaise devise ou le mauvais assortiment.
Les listes de prix BigCommerce peuvent remplacer la tarification des variantes et être affectées au moyen de groupes de Customers, canaux ou d’une combinaison groupe de Customers/canal. Une liste de prix sans son affectation ne constitue pas un modèle tarifaire complet.
Signaux d’alerte précoces
| Signal d’alerte | Ce qu’il indique |
|---|---|
| La migration du groupe est considérée terminée lorsque les Customers affichent le bon nom de groupe. | Le sens commercial du groupe n’a pas été préservé. |
| Les prix ne sont mappés qu’au niveau Product alors que les variantes ont des prix distincts. | La couverture de la liste de prix sera incorrecte pour certains articles vendables. |
| Les affectations de listes de prix omettent le contexte du canal. | Un prix valide peut apparaître dans la mauvaise vitrine ou manquer là où il est requis. |
| Tarification dégressive et remplacements par liste de prix sont combinés sans règles de priorité. | Des mécanismes tarifaires concurrents peuvent produire des résultats incohérents. |
Prévention
Modélisez comme des structures liées le groupe, l’accès aux Categories, la liste de prix, l’enregistrement de prix de variante, la devise, le canal et l’affectation. Préservez exactement la relation qui détermine quel acheteur connecté reçoit quel prix de variante dans quelle vitrine.
Séparez les prix historiques des Orders des listes de prix actives. Conservez les identifiants de contrats ou de prix ERP externes lorsqu’un autre système continue à faire autorité.
Exemple de recommandation
Pour un groupe VIP achetant dans une vitrine régionale, préservez l’appartenance au groupe, l’accès aux Categories, la liste de prix, les enregistrements de prix au niveau des variantes, la devise et l’affectation qui relie ce groupe et ce canal.
Condition Pass
Un Customer connecté représentatif voit l’assortiment et les prix de variantes prévus dans le canal prévu, tandis que les Customers hors du groupe reçoivent le bon prix de repli.
Erreur 4 : traiter canaux, sites et vitrines comme de simples libellés
Ce qui se passe mal
Products, Categories, Customers, prix, devises, menus et contenus sont migrés sans préserver les relations de canaux et de sites qui définissent où ils apparaissent. La boutique possède une vitrine par défaut correcte tandis que des marques, régions, marketplaces ou expériences headless secondaires héritent d’un catalogue et d’une configuration incorrects.
Dans BigCommerce, un canal représente un contexte de vente, tandis qu’un site représente un site web contrôlé par le marchand et relié à un canal de vitrine. Les affectations et paramètres propres aux canaux influencent donc bien plus qu’un simple libellé d’affichage.
Signaux d’alerte précoces
| Signal d’alerte | Ce qu’il indique |
|---|---|
| Les enregistrements sont affectés au canal principal par défaut faute d’identifiant de canal. | La propriété des canaux manque dans les enregistrements migrés. |
| Les affectations de Products et listes de prix sont revues globalement au lieu de l’être par vitrine. | Les différences d’assortiment et de prix propres aux vitrines sont aplaties. |
| Domaines, sites, menus, devises et arborescences de Categories sont documentés séparément. | La relation complète de vitrine n’est pas gérée comme un seul système. |
| Les applications et intégrations supposent que chaque interaction Order ou Product appartient au canal par défaut. | Les systèmes en aval classeront mal l’origine et le contexte. |
Prévention
Définissez le modèle de canaux avant le mapping final. Identifiez chaque vitrine, marketplace, POS, canal marketing ou canal personnalisé, le site et le domaine liés à chaque vitrine ainsi que le contexte Product, arborescence de Categories, prix, devise, menu, Order et application qui lui appartient.
Préservez les identifiants de canaux et les références de canaux source dans les mappings d’intégration. N’utilisez pas le canal par défaut comme repli inexpliqué.
Exemple de recommandation
Pour deux vitrines de marques et un canal Amazon, conservez un catalogue Product partagé lorsque c’est pertinent, affectez Products et listes de prix aux bons canaux de vitrine, utilisez l’arborescence et le site prévus pour chaque marque et préservez séparément l’origine des Orders marketplace.
Condition Pass
Products, prix, menus, arborescences de Categories, Orders et intégrations se rattachent au canal et au site prévus. Aucune vitrine secondaire ne dépend par accident du comportement du canal par défaut.
Erreur 5 : importer le stock sans contexte d’emplacement et de canal
Ce qui se passe mal
Une seule quantité de stock est copiée sur le Product ou la variante alors que la source suit des entrepôts, magasins physiques, points de retrait, fournisseurs ou allocations par canal. Le total semble plausible mais la disponibilité pour le retrait, le traitement des commandes et la synchronisation externe utilisent le mauvais emplacement ou le mauvais article vendable.
Le problème devient plus grave lorsque la source possède un stock au niveau des variantes mais que le mapping cible utilise le Product parent, ou lorsqu’un WMS reste le système de référence après la migration.
Signaux d’alerte précoces
- Les fichiers de stock contiennent le SKU et la quantité mais aucun identifiant d’emplacement.
- La quantité du Product parent est utilisée pour des Products ayant de vraies variantes.
- Les emplacements BOPIS ou de retrait ne figurent pas dans la carte des emplacements.
- Les identifiants d’entrepôt externes sont abandonnés après l’import des quantités d’ouverture.
Prévention
Mappez le stock vers la variante Product exacte et l’emplacement BigCommerce qui le possède. Préservez les identifiants d’emplacements, SKU de variantes, clés de stock externes et toute relation de canal ou de retrait requise par le processus qui continue après migration.
Séparez le stock actuellement vendable des mouvements historiques, réservations, stocks endommagés, disponibilités fournisseur et autres états qui ne doivent pas faire partie de la quantité d’ouverture.
Exemple de recommandation
Pour un détaillant disposant d’un entrepôt central et de trois magasins de retrait, mappez chaque emplacement source vers l’emplacement BigCommerce correspondant, préservez les quantités au niveau des variantes et les clés d’entrepôt, et gardez les règles de disponibilité par canal ou retrait séparées de la quantité brute.
Condition Pass
Les variantes échantillonnées affichent la quantité prévue à chaque emplacement, les services de retrait ou de traitement des commandes reconnaissent le bon propriétaire du stock et le système de stock qui continue à faire autorité met à jour les mêmes enregistrements variante-emplacement sans doublons.
Erreur 6 : traiter les redirections comme un import technique final
Ce qui se passe mal
Les redirections sont générées après que les chemins des Products, Categories, pages et vitrines ont déjà été finalisés. Les anciennes URL sont mappées mécaniquement vers le chemin cible le plus proche sans préserver l’intention de l’utilisateur, le canal, le site, la locale ou la propriété du contenu.
BigCommerce peut gérer les redirections et les chemins des sites, mais un fichier de redirections ne résout pas les contenus manquants, arborescences de Categories incorrectes, différences de framework de vitrine ou destinations propres aux canaux.
Signaux d’alerte précoces
| Signal d’alerte | Ce qu’il indique |
|---|---|
| La planification des redirections couvre les URL de Products mais exclut Categories, pages, Blog Posts, chemins filtrés et contenus de campagnes. | L’inventaire de redirections ne représente pas toute la surface de trafic. |
| Une même destination est utilisée pour plusieurs vitrines alors que chaque site possède une structure de chemins différente. | Les parcours propres aux canaux sont fusionnés. |
| Les redirections pointent vers des pages non publiées ou absentes de la vitrine active. | Le mapping existe techniquement mais n’est pas utilisable par les clients. |
| Les paramètres de requête historiques et chemins générés par des applications sont ignorés. | Des routes non canoniques mais importantes peuvent échouer silencieusement. |
Prévention
Créez un inventaire des chemins lié à la propriété de destination. Mappez chaque URL source importante vers un Product, une Category, une page, un Blog Post, un chemin de site, une application de vitrine, un contenu de remplacement ou une décision volontaire de retrait.
Priorisez le chiffre d’affaires, le trafic organique, les backlinks, les favoris des Customers et les campagnes actives. Gardez le contexte du canal et du site explicite lorsque le même modèle source nécessite des destinations différentes.
Exemple de recommandation
Pour un marchand Multi-Storefront, mappez séparément les principales URL Product et Category pour chaque site de marque, reliez les anciennes pages de campagne à des contenus de remplacement pertinents et préservez les chemins d’applications headless lorsque la vitrine les détient hors du catalogue principal.
Condition Pass
Les URL prioritaires atteignent un contenu utile sur le site et le canal prévus, aucune redirection ne pointe vers une destination indisponible et les chemins omis possèdent une décision volontaire de retrait.
Erreur 7 : copier des champs personnalisés et metafields sans propriété applicative
Ce qui se passe mal
Les champs personnalisés source, données d’applications, indicateurs d’intégration, valeurs SEO et identifiants externes sont tous mappés vers des champs personnalisés Product ou des metafields. Les valeurs arrivent sans type, permissions, namespaces, consommateurs ou ressources parentes clairement définis.
BigCommerce prend en charge les metafields sur plusieurs ressources et les champs personnalisés Product pour les informations de vitrine, mais ces structures ne recréent pas automatiquement l’application, le thème, l’intégration ou le processus qui utilisait les données source.
Signaux d’alerte précoces
- La destination est choisie à partir du libellé du champ source plutôt que de son consommateur.
- Des valeurs au niveau de la variante sont attachées au Product parent.
- Des champs détenus par des applications sont recréés sous des namespaces sans rapport.
- Des identifiants source qui faisaient référence à Products, Customers, médias ou Orders sont copiés tels quels.
Prévention
Classifiez les données personnalisées selon leur propriétaire et leur fonction. Utilisez les champs personnalisés Product pour les informations Product adaptées à la vitrine, les metafields des ressources pour des données opérationnelles ou applicatives typées et les systèmes externes pour les enregistrements qu’ils continuent de gouverner.
Traduisez les références vers les identifiants de destination, préservez namespaces et permissions et documentez le thème, l’application, l’API ou l’intégration qui consomme chaque champ.
Exemple de recommandation
Stockez une spécification publique de matériau comme champ personnalisé Product lorsqu’elle doit être affichée en vitrine. Préservez un code d’entrepôt au niveau de la variante comme metafield de variante et conservez l’état d’abonnement dans l’application d’abonnement qui en reste propriétaire.
Condition Pass
Les données personnalisées apparaissent sur la bonne ressource, sont consommées par la vitrine ou le système prévu et ne contiennent aucun namespace orphelin, substitution au niveau parent ou identifiant source copié sans traduction.
Erreur 8 : confondre présence des Customers et Orders avec continuité opérationnelle
Ce qui se passe mal
Les nombres de Customers et Orders correspondent, mais l’identité, les adresses, l’affectation aux groupes, le consentement, les variantes de lignes d’Order, remises, taxes, expédition, remboursements, consignments, shipments, statuts et références externes sont incomplets. Les anciens libellés de paiement et d’expédition sont ensuite pris à tort pour la configuration actuelle du checkout et du traitement des commandes.
Cet échec affaiblit le support et la finance même lorsque la boutique peut créer de nouveaux Orders correctement.
Signaux d’alerte précoces
- L’identité Customer est rapprochée uniquement par adresse e-mail.
- L’affectation au groupe est revue sans vérifier les prix ni l’accès aux Categories.
- Les Orders sont échantillonnés uniquement par numéro et total.
- Les Orders multi-adresses, remboursés, partiellement expédiés ou provenant de canaux différents sont absents.
Prévention
Préservez l’identité Customer, les adresses, attributs, consentement, groupe et identifiants externes selon la fonction métier. Préservez les lignes d’Orders historiques, variantes, prix, ajustements, taxes, adresses de livraison, consignments, shipments, remboursements, statuts, notes, origine du canal et références externes au niveau exigé par le support et la finance.
Gardez les éléments historiques séparés de la configuration actuelle des paiements, du checkout, de l’expédition, des taxes et du traitement des commandes.
Exemple de recommandation
Pour un Order régional partiellement expédié, préservez le Customer et son groupe, les variantes achetées, le canal, les adresses de livraison, consignments, suivi de shipment, remise, taxes, éléments de remboursement et identifiant Order ERP. Configurez séparément le futur checkout régional et l’expédition.
Condition Pass
Les Customers restent identifiables et correctement classifiés commercialement, les Orders historiques restent compréhensibles pour le support et la finance, et les opérations actuelles ne reposent pas sur des libellés importés comme s’ils étaient des paramètres de configuration.
Priorités de prévention communes
| Priorité | Contrôle requis |
|---|---|
| Propriété des choix | Séparer variantes, modifiers, champs personnalisés, metafields et données d’applications selon leur fonctionnement. |
| Contexte de vitrine | Préserver les relations entre canal, site, arborescence de Categories, menu, chemin et prix. |
| Contexte commercial | Relier les groupes de Customers à l’accès aux Categories, listes de prix, prix de variantes et canaux. |
| Identité opérationnelle | Garder stables les identifiants de variantes, emplacements, Customers, Orders, canaux et systèmes externes. |
| Séparation de l’historique | Préserver les éléments des Orders sans les traiter comme configuration active du checkout ou du traitement des commandes. |
Examinez ces contrôles ensemble car les erreurs BigCommerce traversent souvent plusieurs couches. Une erreur de variante peut affecter simultanément les prix, le stock, le choix de vitrine, les éléments d’Order et les identifiants externes. Le dossier de prévention doit nommer le responsable et la preuve attendue pour chaque couche concernée.
Conclusion
Les erreurs de migration BigCommerce apparaissent lorsque des enregistrements liés sont importés indépendamment. Variantes, modifiers, arborescences de Categories, groupes de Customers, listes de prix, canaux, sites, emplacements de stock, redirections, données personnalisées, Customers et Orders portent tous un contexte qui doit rester connecté.
La meilleure prévention consiste à définir ces relations avant le mapping à grande échelle. Lorsque chaque enregistrement possède le bon propriétaire, le bon canal, le bon contexte commercial, la bonne identité externe et une condition Pass claire, la boutique migrée peut fonctionner de manière cohérente entre les vitrines et les systèmes.
Questions fréquentes
Quelle est la différence entre une variante et un modifier dans BigCommerce ?
Une variante représente la combinaison vendable qui peut porter SKU, prix, stock, images et autres données commerciales. Un modifier change ou personnalise l’article traité mais ne sélectionne pas une autre variante suivie en stock.
Pourquoi des Categories migrées peuvent-elles encore échouer dans une vitrine BigCommerce ?
Les enregistrements de Categories doivent aussi appartenir à la bonne arborescence et au bon contexte de vitrine. Navigation, recherche à facettes, tri, contenu et affectation au canal sont des relations distinctes.
Les groupes de Customers recréent-ils automatiquement les prix de groupe ?
Non. La tarification par groupe peut dépendre des listes de prix, des enregistrements de prix au niveau des variantes, de l’accès aux Categories, de la devise, du canal et des affectations de listes de prix. Le seul libellé du groupe ne suffit pas.
Comment Multi-Storefront influence-t-il le périmètre de migration ?
Products, arborescences de Categories, listes de prix, devises, menus, sites, chemins, Orders et applications peuvent avoir une signification propre à chaque canal. Le modèle de migration doit préserver ces affectations au lieu de tout envoyer par défaut vers la première vitrine.
Tous les champs personnalisés source doivent-ils devenir des champs personnalisés Product dans BigCommerce ?
Non. Certaines valeurs appartiennent aux metafields de ressources, variantes, applications, systèmes externes ou à l’implémentation de la vitrine. La destination dépend du propriétaire du champ, du consommateur, de sa visibilité et de la ressource parente.
Les Orders importés configurent-ils le checkout et le traitement des commandes BigCommerce ?
Non. Les Orders importés préservent les éléments historiques de transaction. Le checkout actuel, les paiements, l’expédition, les taxes, emplacements et processus de traitement des commandes exigent une configuration BigCommerce et des responsabilités d’intégration séparées.