Mapping des données lors d’une migration e-commerce : comment garder les champs personnalisés, variantes et SKU correctement reliés

Le mapping des données lors d’une migration e-commerce définit où les données source doivent être placées sur la nouvelle plateforme, comment leur sens est préservé et quels enregistrements doivent rester reliés. Lorsqu’il est bien préparé, une variante reste rattachée au bon produit, un SKU au bon article vendable et une commande au bon client.

Pour un marchand, cela apporte une tranquillité très concrète : le client peut choisir la bonne taille, l’entrepôt reçoit le bon code article et le service client peut comprendre une ancienne commande. Un catalogue peut sembler complet alors qu’un de ces liens est incorrect. C’est pourquoi le mapping mérite une vérification attentive avant la Full Migration.

Que relie réellement le mapping des données ?

Chaque plateforme possède un schema, c’est-à-dire une structure utilisée pour organiser les produits, les clients, les commandes et leurs champs. Deux boutiques peuvent afficher la même page produit tout en stockant les informations différemment en arrière-plan. Le mapping relie ces structures en fonction du résultat attendu.

Trois notions permettent de mieux suivre le processus :

Mapping des champs : choisir où une valeur doit être enregistrée dans la cible, par exemple une référence fournisseur ou un identifiant fiscal client.

Mapping des relations : préserver les liens entre les enregistrements, par exemple entre un produit et ses variantes ou entre un client et ses commandes.

Transformation des données : modifier une valeur selon une règle convenue, par exemple convertir un poids de grammes en kilogrammes.

Ces décisions appartiennent au même plan de migration, mais elles remplissent des rôles différents. Déplacer « 500 » dans un champ de poids ne le transforme pas automatiquement en 0,5 kilogramme. De même, copier un ID produit dans une commande ne crée pas une relation valide si la plateforme cible attribue des IDs différents.

Suivez un produit tout au long de la migration

Imaginez une boutique outdoor qui vend une Trail Jacket en deux couleurs et trois tailles. La veste bleu marine, taille M, porte le SKU TJ-NV-M, possède son propre stock et son propre code-barres. Le produit contient également un champ d’instructions d’entretien, tandis que chaque variante possède un code fournisseur distinct.

La migration doit préserver quelles informations appartiennent au produit dans son ensemble et lesquelles concernent uniquement une combinaison précise. Déplacer un code fournisseur propre à une variante vers le produit parent pourrait faire pointer toutes les tailles vers le même article fournisseur.

Voici un exemple de plan de mapping. Les libellés décrivent le résultat attendu et ne garantissent pas que ces champs soient disponibles sur chaque Migration Path.

Pour une migration de WooCommerce vers Shopify, commencez par les données prises en charge pour cette combinaison précise. WooCommerce documente des variations avec leurs propres paramètres de prix, de stock et d’image ; le modèle de variantes de Shopify relie lui aussi une combinaison vendable aux informations de produit et d’inventaire. Un comportement similaire en storefront nécessite malgré tout des vérifications précises des champs et des relations.

Comment les variantes et les SKU restent-ils reliés ?

Une variante représente une combinaison vendable. Un SKU est un identifiant métier associé à un article. Un internal ID identifie un enregistrement dans un système donné. Considérer ces éléments comme interchangeables entraîne des erreurs de correspondance évitables.

Gardez distincts le produit parent et chaque combinaison vendable

Pour la Trail Jacket, « Navy / Medium » doit rester rattachée au bon produit parent, avec le bon prix, le bon stock, la bonne image et le bon code-barres. Une bonne validation suit la combinaison sélectionnée depuis le storefront jusqu’à la commande. Compter six variantes importées ne suffit pas à démontrer que leurs attributs sont corrects.

Il faut aussi distinguer les variantes des champs de personnalisation. Un texte de gravure ou une note de livraison peut décrire un achat sans représenter un article stocké séparément. Transformer chaque option en variante peut modifier la structure du catalogue et créer des combinaisons que la boutique n’a jamais vendues.

Vérifiez si vos SKU sont des clés de correspondance fiables

Les SKU peuvent aider à faire correspondre les enregistrements lorsqu’ils sont renseignés, uniques dans le périmètre convenu et stables. Ils sont moins fiables lorsqu’un produit parent et ses variantes partagent le même SKU, lorsque plusieurs boutiques sources réutilisent les mêmes codes ou lorsque d’anciens produits ont des valeurs vides.

• Repérez les SKU manquants ou en double au niveau des produits et des variantes.
• Conservez les formats significatifs, notamment les zéros initiaux, la ponctuation et la casse.
• Définissez comment les enregistrements source doivent correspondre aux articles déjà présents dans la cible.
• Documentez les exceptions au lieu de renommer automatiquement des codes utilisés par les systèmes d’inventaire ou de fulfillment.

Lorsqu’un SKU n’est pas une clé sûre, la migration nécessite une autre méthode de correspondance prise en charge ou une règle personnalisée convenue. Une table de correspondance entre IDs source et cible peut préserver la relation même si la plateforme cible génère de nouveaux internal IDs.

Important : Conserver un SKU ne reconnecte pas automatiquement un ERP, un système d’entrepôt ou un flux marketplace. Vérifiez quel identifiant chaque intégration utilise et testez la connexion séparément.

Où doivent aller les champs personnalisés ?

Commencez par la finalité du champ, puis choisissez sa destination. Une instruction d’entretien est un texte lisible. Un code fournisseur est un identifiant. Un numéro fiscal client peut soutenir un processus métier. Placer ces trois éléments dans un champ de description peut conserver les caractères, mais rendre les données plus difficiles à utiliser.

Pour chaque champ personnalisé, vérifiez quatre points :

• Appartenance : ce champ appartient-il à un produit, une variante, un client, une commande ou une ligne de commande ?
• Type : la cible doit-elle l’enregistrer sous forme de texte, nombre, date, valeur vrai/faux ou référence ?
• Sens : les unités, valeurs autorisées, valeurs vides et formats sont-ils interprétés de manière cohérente ?
• Usage : quel theme, quelle app, quel filtre ou quelle intégration doit le lire ?

Par exemple, stockez un code fournisseur tel que 00127 comme un identifiant plutôt que comme une quantité. Sinon, une conversion numérique peut supprimer les zéros initiaux. Si un champ source contient plusieurs valeurs, vérifiez si la cible accepte une liste ou nécessite une autre structure prise en charge.

Un champ peut également être migré avec succès sans apparaître dans le storefront. Le stockage, l’affichage, le filtrage et le comportement des apps nécessitent des contrôles séparés. Notre guide sur les metadata, champs personnalisés et extensions explique ces différences, tandis que l’article sur la structuration des champs personnalisés et des workflows de compte montre leur importance pour les boutiques de gros.

Avant de valider la conception d’un champ, partagez avec Next-Cart un enregistrement courant et un cas difficile. Montrer la valeur source à côté du résultat attendu est beaucoup plus utile qu’une demande générale comme « migrer tous les champs personnalisés ».

Les catégories, les clients et les commandes ont aussi besoin d’un mapping

Catégories : préserver le placement et la navigation souhaitée

Une veste peut appartenir à la fois à Outerwear et à Winter Essentials. Décidez comment ces appartenances et toute structure parent-enfant des catégories doivent apparaître dans la cible. Vérifiez à la fois le placement du produit et l’existence de chaque catégorie. Si la cible organise les collections autrement, une règle explicite est plus utile qu’une simple correspondance des noms.

Clients : protéger l’identité et le contexte métier

L’adresse e-mail, l’adresse de facturation, l’identifiant fiscal et la classification de compte d’un client servent des objectifs différents. Définissez la politique de correspondance avant de fusionner des enregistrements. Une adresse e-mail partagée entre plusieurs boutiques ne justifie pas, à elle seule, la fusion de leurs comptes professionnels.

Pour les clients de gros, une étiquette de groupe ou un champ fiscal migré doit également être validé par rapport à la configuration des comptes et des prix dans la cible. Stocker la valeur ne recrée pas automatiquement le workflow qui l’utilisait.

Commandes : conserver le sens de la transaction d’origine

Une commande relie un client aux articles achetés, quantités, prix, taxes, remises et informations de livraison. Ses valeurs historiques doivent refléter la transaction initiale plutôt que d’être recalculées silencieusement à partir du catalogue actuel.

Prévoyez les commandes invitées, les produits supprimés et les variantes abandonnées. Lorsqu’une relation avec un produit actif ne peut pas être recréée, définissez comment conserver les détails historiques pris en charge des lignes de commande. Testez la commande comme le ferait un collègue du service client : pouvez-vous identifier ce qui a été acheté et comprendre le total ?

Comment valider le mapping avant la mise en ligne ?

Utilisez Demo Migration pour examiner des enregistrements représentatifs, puis répétez les contrôles pertinents après Full Migration et après toute exécution de suivi approuvée. Si l’échantillon de démonstration n’inclut pas un edge case critique, organisez une validation supplémentaire avant de considérer l’exigence comme démontrée.

Constituez un petit jeu de test comprenant volontairement des enregistrements difficiles :

• Un produit avec plusieurs variantes, des images différentes et des champs personnalisés propres aux variantes.
• Un SKU manquant ou en double et un identifiant contenant des zéros initiaux.
• Un produit affecté à plusieurs catégories et un client comportant des champs métier.
• Une commande remisée, une commande invitée et une commande contenant un article abandonné.

Pour chaque exemple, notez la valeur source, le résultat cible attendu, le résultat réel et toute différence. Comparez trois niveaux : le nombre d’enregistrements, les valeurs des champs et les relations. Expliquez les écarts de comptage liés à un filtrage, une fusion ou une restructuration approuvés ; ne supposez pas que des totaux identiques prouvent l’exactitude.

Terminez par des tests de comportement. Sélectionnez une variante, vérifiez les informations affichées, ajoutez-la au panier et contrôlez l’article obtenu. Consultez l’historique des commandes du client lorsque cela s’applique et testez les intégrations qui utilisent les identifiants migrés. Ces contrôles relient la précision de la base de données aux opérations quotidiennes de la boutique.

Avant validation finale : corrigez les écarts critiques, retestez les enregistrements concernés et conservez les règles de mapping approuvées dans les notes du projet. Si les règles changent ensuite, vérifiez leur effet sur les données déjà migrées avant de relancer la migration.

Quand le mapping nécessite-t-il une Custom Migration ?

La présence de champs personnalisés ne signifie pas automatiquement que chaque projet nécessite du développement sur mesure. La question décisive est de savoir si le résultat attendu correspond au comportement pris en charge par la Migration Path sélectionnée et les Add-ons applicables.

Advanced Data Mapping de Next-Cart dirige les champs source pris en charge vers des destinations compatibles. Data Transformation gère les modifications de valeurs prises en charge. Les champs et opérations disponibles dépendent de la migration active ; confirmez donc précisément le besoin avant de sélectionner un Add-on.

Standard Migration convient aux travaux pris en charge que vous souhaitez gérer vous-même. Managed Migration ajoute une exécution pilotée par Next-Cart dans le périmètre pris en charge. Ni l’une ni l’autre ne doit être considérée comme une promesse de reproduire n’importe quel comportement personnalisé d’une app ou d’une base de données.

Custom Migration mérite d’être étudiée lorsque votre projet nécessite une extraction non prise en charge, une correspondance spécifique, des relations inhabituelles ou une logique sur mesure. Par exemple, fusionner plusieurs catalogues sources selon des règles propres au métier ou déplacer des données gérées par une app vers une structure cible différente.

Préparez des enregistrements exemples, le résultat cible attendu, les règles de correspondance et de transformation, les systèmes liés ainsi que des critères d’acceptation clairs. L’équipe disposera ainsi d’une base concrète pour évaluer la faisabilité et définir le travail.

Donnez à votre nouvelle boutique une base de données claire

Un bon mapping préserve le sens de votre catalogue et de votre historique client pendant le changement de plateforme. Lorsque la structure produit, les identifiants, les champs personnalisés et les relations de transaction sont examinés ensemble, l’équipe peut plus facilement repérer les problèmes et valider le résultat.

Prêt à vérifier les données de votre boutique ? Demandez une Demo à Next-Cart et apportez des enregistrements représentatifs à examiner. Pour mieux comprendre les systèmes derrière une migration, découvrez nos articles sur les Technologies e-commerce.