Les échecs de migration vers Shopify Plus surviennent souvent lorsque la complexité d’entreprise est assimilée à un simple volume de données supplémentaire. La difficulté ne consiste pas seulement à transférer davantage de Products, de Customers et d’Orders. Il faut préserver les relations entre les entreprises B2B et leurs emplacements, les catalogues, les Markets, la publication des variantes, les données personnalisées, le fonctionnement du parcours de commande, les responsabilités des équipes, les systèmes externes et les éléments historiques permettant d’expliquer les transactions.
Shopify Plus ne doit pas être abordé comme une boutique Shopify ordinaire dotée d’un catalogue plus volumineux. Sa valeur dépend d’une gouvernance délibérée. Les pièges ci-dessous portent sur les échecs qui reviennent lorsque les structures d’entreprise sont aplaties dans les enregistrements de base ou supposées réapparaître automatiquement grâce au niveau de service Shopify Plus.
Piège 1 : traiter Shopify Plus comme une simple boutique Shopify plus grande
Ce qui se passe mal
Le plan de migration reprend à plus grande échelle la même mise en correspondance des Products, Customers et Orders utilisée pour une boutique plus petite, sans définir la propriété des domaines d’entreprise. Les équipes régionales, les opérations B2B, la finance, le merchandising, le traitement des commandes et les responsables d’intégration supposent que leurs exigences sont incluses puisque la destination est Shopify Plus.
Les enregistrements arrivent, mais personne ne peut expliquer quel marché, emplacement d’entreprise, catalogue, emplacement de traitement des commandes, application ou système externe est responsable du fonctionnement obtenu.
Signaux d’alerte précoces
| Signal d’alerte précoce | Ce qu’il indique |
|---|---|
| Le périmètre est organisé par nombre d’enregistrements plutôt que par domaines opérationnels et responsables. | Les dépendances d’entreprise sont masquées dans des catégories génériques d’enregistrements. |
| Les cas B2B, régionaux et D2C utilisent un seul ensemble d’échantillons générique. | Le modèle de migration ne révélera pas les modes d’échec propres à chaque canal. |
| Les exigences relatives aux catalogues, entreprises, Markets, parcours de commande et intégrations n’apparaissent que comme des notes sous la migration Customer ou Product. | Les structures distinctes de Shopify Plus n’ont pas de propriétaire clairement défini. |
| Les décisions de gouvernance sont repoussées après la création des structures de données. | Le modèle cible peut être techniquement alimenté mais rester contesté sur le plan opérationnel. |
Prévention
Établissez une carte de propriété au niveau de l’entreprise avant de finaliser le modèle de données. Définissez les responsabilités pour la gouvernance des catalogues, les entreprises et emplacements B2B, les Markets, la publication des Products, la tarification, la personnalisation du parcours de commande, l’inventaire, le traitement des commandes, l’identité Customer, les Orders, les données personnalisées et les intégrations externes.
Séparez les enregistrements globaux partagés des relations propres à un marché, une entreprise, un canal ou un système. Un Product partagé peut participer à plusieurs contextes commerciaux sans devenir plusieurs Products sans relation entre eux.
Exemple de recommandation
Pour un fabricant vendant en D2C et en B2B dans plusieurs régions, définissez pour un même Product son identité globale, sa disponibilité régionale, ses catalogues B2B, la tarification par emplacement d’entreprise, le contenu de marché, la propriété du traitement des commandes et les identifiants ERP avant d’étendre ce modèle à l’ensemble du catalogue.
Condition de réussite
Chaque domaine d’entreprise possède un responsable de données nommé, une relation cible définie et un système de référence qui perdure. L’accès à Shopify Plus n’est jamais utilisé comme substitut à un modèle opérationnel défini.
Piège 2 : aplatir les entreprises, leurs emplacements et les acheteurs dans des enregistrements Customer
Ce qui se passe mal
Les comptes grossistes source, organisations, succursales, adresses de livraison, rôles d’acheteurs, identités fiscales, conditions de paiement, règles d’approbation et relations avec les commerciaux sont importés comme de simples Customers ou tags.
Shopify B2B distingue une entreprise, ses emplacements et les Customers individuels qui achètent pour ces emplacements. Aplatir ces niveaux peut rattacher la tarification, les catalogues, les conditions, les adresses, les paramètres fiscaux et le contexte des Orders à la mauvaise unité opérationnelle.
Signaux d’alerte précoces
| Signal d’alerte précoce | Ce qu’il indique |
|---|---|
| Un compte source est censé devenir un seul Shopify Customer quelle que soit la structure des succursales. | Les relations entre entreprise, emplacement et acheteur sont en train d’être fusionnées. |
| Les identifiants d’entreprise et d’emplacement ne sont stockés que dans des notes ou tags. | L’identité B2B ne pourra pas être utilisée de manière fiable par les catalogues, Orders ou intégrations. |
| Les acheteurs associés à plusieurs emplacements sont dupliqués au lieu d’être reliés. | Le contexte d’accès et d’achat se fragmentera entre plusieurs comptes. |
| Les Orders B2B historiques ne peuvent pas être rattachés à l’emplacement d’entreprise qui a acheté. | L’historique commercial a perdu son contexte organisationnel. |
Prévention
Modélisez explicitement la hiérarchie de l’organisation. Préservez l’identité de l’entreprise, ses emplacements, les contacts, les autorisations, le contexte de facturation et d’expédition, les informations fiscales, les conditions de paiement, les catalogues et les clés de compte externes comme des enregistrements distincts mais reliés.
Définissez les règles de fusion et de séparation pour les entreprises et les acheteurs. Distinguez un contact partagé d’un Customer dupliqué, et distinguez l’entreprise juridique de chaque emplacement d’achat ou de livraison.
Exemple de recommandation
Pour un distributeur composé d’une organisation mère, de quatre succursales et d’acheteurs pouvant commander pour plusieurs succursales, créez une seule entreprise, conservez quatre emplacements d’entreprise avec leur propre contexte commercial et reliez chaque acheteur aux emplacements qu’il est autorisé à représenter.
Condition de réussite
Les relations entre entreprise, emplacement et acheteur peuvent être expliquées sans dépendre de notes libres. La tarification B2B, les adresses, les conditions, le contexte fiscal, les catalogues et les Orders se rattachent à l’emplacement d’entreprise prévu.
Piège 3 : copier les prix B2B sans préserver la logique de catalogue et d’affectation
Ce qui se passe mal
Les prix de gros sont copiés comme valeurs Product, tags de remise ou liste de prix universelle sans conserver l’entreprise, l’emplacement, le marché, le Product, la variante, la plage de quantité ou la devise auxquels ils s’appliquent.
Les catalogues Shopify B2B contrôlent les relations de disponibilité et de tarification des Products. Sur Shopify Plus, ils peuvent aussi être affectés directement aux emplacements d’entreprise. Une valeur numérique sans son contexte d’affectation ne peut pas reproduire l’accord commercial source.
Signaux d’alerte précoces
| Signal d’alerte précoce | Ce qu’il indique |
|---|---|
| Les fichiers de prix ne contiennent pas les identifiants d’entreprise ou d’emplacement d’entreprise. | Les prix ne peuvent pas être affectés aux acheteurs auxquels ils s’appliquent. |
| Des prix au niveau Product sont utilisés alors que la source tarifait certaines variantes individuellement. | Les règles commerciales propres aux variantes sont aplaties. |
| La tarification par volume et les règles de quantité sont combinées en un seul pourcentage de remise. | Des mécanismes de tarification distincts deviendront ambigus ou incorrects. |
| Une tarification directe par client est convertie en tags Customer généraux. | Une tarification contractuelle est remplacée par une segmentation faible. |
Prévention
Traitez la tarification comme un modèle de relations. Définissez l’appartenance aux catalogues, la disponibilité des Products et variantes, les prix fixes, ajustements, tarifs par volume, règles de quantité, devises, affectations aux Markets et affectations directes aux emplacements d’entreprise lorsque nécessaire.
Séparez la tarification active de la plateforme cible des prix historiques des Orders. Conservez le contrat source ou la clé ERP externe lorsque l’accord commercial reste géré hors de Shopify.
Exemple de recommandation
Pour un compte B2B ayant des prix différents selon ses succursales, affectez le catalogue approprié à chaque emplacement d’entreprise, conservez dans ce catalogue les prix fixes et règles de quantité au niveau variante, et gardez l’identifiant de contrat ERP pour le rapprochement.
Condition de réussite
Un acheteur représentatif voit les Products, variantes, prix, règles de quantité et devise prévus pour le bon emplacement d’entreprise. Aucun résultat tarifaire ne dépend d’un tag inexpliqué ou d’une exception mémorisée manuellement.
Piège 4 : mélanger Markets, localisation et architecture des boutiques
Ce qui se passe mal
Les boutiques régionales, langues, devises, domaines, attentes fiscales, marchés B2B et assortiments régionaux sont compressés dans un contexte Shopify Plus par défaut. Le contenu est traduit, mais la disponibilité des Products, les catalogues, domaines, parcours de commande, prix, droits et adaptations de thème restent incohérents.
L’inverse peut également se produire : un catalogue partagé est inutilement dupliqué dans plusieurs boutiques parce que l’équipe de migration traite chaque différence régionale comme une identité Product distincte.
Signaux d’alerte précoces
- Le marché principal est entièrement défini alors que les marchés secondaires ne sont représentés que par des descriptions traduites.
- Les décisions de domaine et de redirection sont dissociées de la structure des Markets.
- Les restrictions régionales sur les Products sont stockées dans des tags sans responsable de marché ou de catalogue.
- La logique des marchés D2C et B2B est combinée sans résoudre l’héritage ni les affectations.
Prévention
Déterminez quelles différences relèvent des Markets, des catalogues, des emplacements d’entreprise, des adaptations de thème, des domaines, du contenu, de la tarification, de la configuration fiscale et des droits, de l’expédition ou de boutiques distinctes. Conservez une seule identité Product lorsque les différences régionales sont contextuelles plutôt que fondamentales.
Modélisez délibérément les relations entre marchés et sous-marchés. Identifiez les paramètres hérités et les exceptions afin qu’une expérience régionale ne soit pas assemblée à partir de règles contradictoires.
Exemple de recommandation
Pour des opérations D2C nord-américaines, D2C européennes et B2B mondiales, conservez une identité Product partagée, affectez la disponibilité et le contenu régionaux via les Markets prévus, reliez les emplacements d’entreprise B2B au bon marché B2B et aux catalogues appropriés, puis mappez chaque domaine source vers sa route cible.
Condition de réussite
Chaque marché de lancement dispose d’un contexte cohérent pour les Products, catalogues, contenus, devises, domaines et Customers. Les enregistrements réellement partagés le restent, tandis que les véritables exceptions régionales possèdent un responsable explicite.
Piège 5 : utiliser les metafields comme destination universelle pour les données Product d’entreprise
Ce qui se passe mal
Les attributs PIM, dossiers réglementaires, spécifications réutilisables, certificats, relations entre Products, contenus spécifiques aux marchés, états d’application et identifiants d’intégration sont tous copiés dans des metafields Product. Les définitions deviennent incohérentes, les structures répétitives sont dupliquées et les références vers les variantes, fichiers ou entités externes sont perdues.
Les metafields sont puissants, mais ils ne remplacent pas automatiquement les metaobjects, les ressources Shopify natives, la propriété des applications ni les systèmes externes. Transformer toutes les données d’entreprise en paires clé-valeur peut préserver du texte tout en supprimant la structure nécessaire au filtrage, à la réutilisation, aux validations, aux références et aux intégrations.
Signaux d’alerte précoces
- Des centaines de champs source sont affectés directement à des metafields Product sans être regroupés selon leur objectif.
- Des enregistrements réutilisables, comme des matériaux, ingrédients, auteurs ou documents de conformité, sont répétés sous forme de texte.
- Des clés appartenant à des applications sont recréées dans de nouveaux namespaces.
- Des valeurs propres aux variantes ou aux Markets sont rattachées au Product parent.
Prévention
Classez chaque domaine de données personnalisées avant de choisir sa destination. Utilisez des metafields pour étendre une ressource Shopify existante, des metaobjects pour des structures réutilisables comportant plusieurs champs, des ressources Shopify natives lorsqu’elles existent, et conservez la propriété dans le PIM, l’application ou le système externe lorsque cette autorité doit perdurer.
Préservez les définitions, types, règles de validation, références, droits d’accès, Markets, langues et systèmes consommateurs. Remplacez les identifiants source par les références cibles appropriées au lieu de copier des clés anciennes littéralement.
Exemple de recommandation
Pour des fiches réglementaires Product partagées entre plusieurs variantes et marchés, modélisez le dossier réutilisable comme une structure gouvernée, reliez les Products ou variantes correspondants et conservez l’identifiant réglementaire externe lorsque le PIM reste le système de référence.
Condition de réussite
Chaque donnée personnalisée possède un propriétaire, une structure, un type, une relation et un consommateur identifiables. Les metafields ne servent pas de stockage par défaut pour des informations qui appartiennent à une autre ressource ou à un autre système.
Piège 6 : supposer que les anciens Scripts et la logique historique du parcours de commande seront repris tels quels
Ce qui se passe mal
Les anciens Shopify Scripts, personnalisations de thème et automatisations historiques sont traités comme s’ils pouvaient être transférés avec les données. Des remises de lignes, restrictions de paiement ou d’expédition, règles B2B, validations, acomptes, approbations et expériences spécifiques aux marchés disparaissent ou continuent à dépendre de composants retirés ou non pris en charge.
Shopify Plus fournit aujourd’hui des points d’extension différents, notamment Shopify Functions, les extensions de parcours de commande, les applications, les API et la configuration. Préserver l’intention métier exige de reconstruire la fonction à l’aide d’un mécanisme actuellement pris en charge, et non de copier l’ancienne implémentation.
Signaux d’alerte précoces
| Signal d’alerte précoce | Ce qu’il indique |
|---|---|
| Un Script est inventorié par son nom de fichier mais pas par le résultat métier qu’il produit. | L’équipe risque de copier une implémentation sans comprendre sa fonction. |
| Les règles du parcours de commande sont supposées revenir parce que le plan Shopify Plus les autorise. | L’éligibilité au plan est confondue avec une implémentation effective. |
| Des restrictions de paiement, d’expédition ou de remise ne sont pas reliées aux Markets, catalogues ou emplacements d’entreprise concernés. | Le contexte commercial des règles est perdu. |
| Les dépendances de données des anciennes personnalisations ne sont pas répertoriées. | Les nouvelles extensions peuvent ne pas disposer des Products, Customers ou champs nécessaires. |
Prévention
Inventoriez chaque résultat métier plutôt que chaque ancien fichier. Pour chaque règle, identifiez la remise, la restriction de paiement ou d’expédition, la méthode de livraison, la validation, le bloc de contenu, l’upsell, l’acompte, la condition de paiement, la revue de draft order ou l’expérience spécifique au marché qu’elle produit. Affectez chaque résultat à une extension Shopify Plus actuelle, une Function, une application, une API, une configuration ou un retrait volontaire.
Traitez la reconstruction du parcours de commande comme un domaine d’implémentation distinct, tout en préservant les données Product, Customer, d’emplacement d’entreprise, de Market et de metafields auxquelles ces règles font référence.
Exemple de recommandation
Remplacez un ancien Script de ligne appliquant des remises contractuelles par la tarification de catalogue ou une Function prise en charge selon la règle attendue. Recréez une restriction de paiement au moyen d’une personnalisation de paiement et reliez-la au contexte B2B ou de Market concerné.
Condition de réussite
Chaque règle importante du parcours de commande possède un mécanisme actuel pris en charge et les références de données nécessaires. Aucun fonctionnement en production ne dépend de Scripts retirés, de code de thème copié ou d’un processus manuel non documenté.
Piège 7 : supposer que les applications et intégrations d’entreprise se reconnecteront automatiquement
Ce qui se passe mal
Les enregistrements Shopify principaux migrent correctement, mais les ERP, PIM, WMS, OMS, CRM, systèmes fiscaux, marketplaces, abonnements, programmes de fidélité, outils d’analyse et automatisations ne les reconnaissent plus. Les identifiants source sont supprimés, recréés de manière incohérente ou associés à la mauvaise ressource Shopify.
Les processus d’entreprise dépendent souvent des identifiants de variantes, emplacements, emplacements d’entreprise, Customers et Orders plutôt que des seuls noms de Products parents. Un catalogue visuellement correct peut donc rester déconnecté des opérations.
Signaux d’alerte précoces
| Signal d’alerte précoce | Ce qu’il indique |
|---|---|
| La mise en correspondance des intégrations repose sur les titres, e-mails ou SKU sans règles d’unicité. | L’identité entre systèmes peut entrer en collision ou dériver. |
| Les identifiants externes sont stockés dans des notes plutôt que dans des champs typés sur la bonne ressource. | Les intégrations ne disposeront pas de clés de recherche stables. |
| Un responsable d’intégration suppose qu’un autre système recréera les références croisées. | Aucune équipe ne possède la reconstruction de la relation. |
| Le périmètre des webhooks et synchronisations est défini après la création des enregistrements. | Le fonctionnement en aval est conçu trop tard. |
Prévention
Créez un registre d’identité des intégrations. Pour chaque système, définissez l’entité faisant autorité, son équivalent Shopify, la clé stable, la règle d’unicité, le sens de synchronisation et le responsable en cas d’échec.
Préservez séparément les identifiants Product et variante, mappez les emplacements d’inventaire, gardez distinctes les clés d’entreprise et d’emplacement d’entreprise, conservez les identifiants Customer du CRM et préservez les références d’Orders historiques nécessaires à la finance et au support.
Exemple de recommandation
Pour un flux PIM → Shopify → ERP, reliez la clé Product du PIM au Product Shopify, la clé article ERP à chaque variante, la clé d’entrepôt à chaque emplacement et le numéro d’Order ERP à l’Order Shopify historique ou nouveau représentant la même transaction.
Condition de réussite
Chaque système externe critique peut retrouver les bons enregistrements Shopify sans deviner à partir d’un titre, créer des doublons ni dépendre de feuilles de calcul manuelles de références croisées.
Piège 8 : confondre Orders historiques et préparation opérationnelle de l’entreprise
Ce qui se passe mal
Des Orders importés sont utilisés comme preuve que les conditions de paiement B2B, acomptes, paiements partiels, taxes, droits, traitement des commandes, retours, approbations et processus ERP sont prêts. Les Orders historiques peuvent conserver ces valeurs sous forme d’instantanés, mais ils ne configurent pas les processus actuels qui créent et gèrent de nouveaux Orders.
Dans le même temps, réduire les Orders au numéro et au total peut supprimer le contexte de l’emplacement d’entreprise, l’état du paiement, les détails de traitement, remises, remboursements et identifiants externes nécessaires à la finance et au service Customer.
Signaux d’alerte précoces
- Les Orders B2B et D2C sont vérifiés à partir des mêmes champs minimaux.
- Le contexte d’entreprise et d’emplacement est absent des Orders B2B historiques.
- Les conditions de paiement et acomptes sont déduits de libellés plutôt que de relations cibles structurées.
- Les Orders partiellement payés, partiellement traités, remboursés ou référencés dans des systèmes externes sont absents du modèle de migration.
Prévention
Préservez l’historique des Orders pour le support, la finance, la gestion des comptes B2B et le rapprochement. Conservez les lignes, variantes, contexte d’emplacement d’entreprise, Customers, adresses, prix, conditions, remises, taxes, droits, paiements, traitement des commandes, remboursements et références externes au niveau requis par ces équipes.
Définissez séparément les processus actuels de parcours de commande B2B, draft order, approbation, conditions de paiement, acompte, traitement des commandes, retour et intégration.
Exemple de recommandation
Pour un Order de gros passé par un acheteur pour une succursale, conservez le contexte de l’entreprise et de l’emplacement, la tarification contractuelle, la condition de paiement, le paiement partiel, les événements de traitement et la référence ERP. Configurez séparément les futurs achats de la succursale et leur fonctionnement de paiement selon le modèle B2B actuel.
Condition de réussite
Les Orders historiques restent compréhensibles pour le support, la finance et les équipes de compte, tandis que les nouveaux Orders suivent des règles B2B et opérationnelles Shopify Plus définies volontairement. Les instantanés historiques ne sont jamais confondus avec la configuration actuelle.
Piège 9 : laisser sans propriétaire les URL multi-marchés, les contenus et les dépendances de thème
Ce qui se passe mal
La planification des routes d’entreprise se concentre sur les redirections Product en ignorant les domaines régionaux, sous-dossiers, contenus traduits, pages de destination propres aux marchés, adaptations de thème, contenus CMS et routes générées par les applications. Une seule redirection ou destination de contenu globale est appliquée même lorsque l’intention régionale diffère.
Une page peut exister globalement tout en affichant le mauvais contenu de marché, le mauvais catalogue ou un contexte de parcours de commande incorrect. Les dépendances de thème et d’application peuvent également donner l’impression qu’un contenu est complet dans un marché tout en étant absent dans un autre.
Signaux d’alerte précoces
- Les cartes de redirection omettent le contexte de marché, de langue et de route B2B.
- Des pages régionales sont dupliquées sans règle de propriété canonique.
- Les sections de thème utilisent des champs présents uniquement dans le marché principal.
- Les pages de destination générées par des applications ou les routes de compte n’ont pas de décision de migration.
Prévention
Construisez la propriété des routes et contenus par marché. Mappez les domaines, sous-dossiers, handles Product et collection, CMS Pages, Blog Posts, expériences de destination B2B, routes d’application et dépendances de thème vers le marché ou la ressource partagée prévus.
N’utilisez une destination globale unique que lorsque l’intention Customer et le contenu sont réellement partagés. Conservez des redirections régionales ou pages de remplacement lorsque la destination diffère selon le marché.
Exemple de recommandation
Pour une campagne Product disposant de pages distinctes pour les États-Unis, l’Union européenne et le B2B, conservez une seule identité Product mais mappez chaque page source vers le contenu de marché, le contexte de catalogue, le chemin de domaine et le composant de thème ou d’application correspondants.
Condition de réussite
Les routes prioritaires mènent à l’expérience de marché prévue, le contenu partagé reste gouverné de manière centrale, les exceptions régionales sont explicites et aucune page ne dépend de champs ou d’applications disponibles uniquement dans un autre marché.
Priorités de prévention transversales
| Priorité | Contrôle requis |
|---|---|
| Propriété d’entreprise | Affecter chaque relation de catalogue, B2B, Market, parcours de commande et intégration à un responsable nommé. |
| Préservation du contexte | Conserver le contexte d’emplacement d’entreprise, de marché, de canal, de variante, d’emplacement et de système externe avec les enregistrements. |
| Implémentation prise en charge | Reconstruire le fonctionnement du parcours de commande et des processus avec les points d’extension Shopify Plus actuels. |
| Identité stable | Préserver des clés durables entre PIM, ERP, WMS, CRM, marketplace, Customer et Order. |
| Séparation historique | Garder les éléments transactionnels importés distincts de la configuration opérationnelle actuelle. |
La prévention à l’échelle de l’entreprise exige des éléments de validation coordonnés entre les équipes. Les responsables catalogue, B2B, Markets, parcours de commande, intégrations, finance, opérations et support doivent approuver les mêmes scénarios représentatifs au lieu de valider séparément des enregistrements isolés.
Conclusion
Les pièges d’une migration Shopify Plus apparaissent lorsque les relations d’entreprise sont aplaties dans les enregistrements Shopify de base. Entreprises, emplacements, catalogues, Markets, règles du parcours de commande, données personnalisées, intégrations, Orders et routes portent tous un contexte qui doit rester explicite.
Le modèle de prévention le plus robuste traite Shopify Plus comme un environnement opérationnel gouverné. Chaque enregistrement possède un responsable métier, un contexte commercial, une implémentation prise en charge, une identité stable et une condition de réussite précise.
Questions fréquentes
En quoi une migration Shopify Plus diffère-t-elle d’une migration Shopify standard ?
Le modèle e-commerce de base reste lié à Shopify, mais Shopify Plus implique généralement une gouvernance plus poussée des emplacements d’entreprise B2B, des affectations directes de catalogues, des personnalisations avancées du parcours de commande, des intégrations d’entreprise, des modèles opérationnels régionaux et des responsabilités des équipes.
Les groupes Customer source peuvent-ils devenir directement des entreprises Shopify B2B ?
Pas automatiquement. Un groupe source peut décrire une tarification, un accès, un usage marketing ou un type de compte. Shopify B2B exige des relations explicites entre entreprise, emplacement d’entreprise et Customer avec le bon contexte commercial.
Pourquoi la tarification B2B doit-elle être migrée comme un ensemble de relations plutôt que comme de simples valeurs ?
Un prix peut dépendre d’un catalogue, d’un Product ou d’une variante, d’un emplacement d’entreprise, d’un marché, d’une règle de quantité, d’une devise ou d’un contrat externe. Le nombre seul n’indique pas à qui ce prix doit s’appliquer.
Les metafields suffisent-ils pour les données PIM d’entreprise ?
Pas toujours. Les metafields étendent les ressources, les metaobjects représentent des structures réutilisables, et un PIM ou une application peut rester l’autorité. La propriété, le type, les références et les systèmes consommateurs déterminent la destination appropriée.
Les anciens Shopify Scripts peuvent-ils continuer à contrôler le parcours de commande ?
Non. Tout fonctionnement important assuré par un Script doit être traduit vers des Shopify Functions, extensions de parcours de commande, applications, API ou configurations actuellement prises en charge. Le résultat métier doit être préservé sans dépendre de l’exécution de Scripts retirés.
Des Orders importés prouvent-ils que les opérations B2B et de traitement des commandes sont prêtes ?
Non. Les Orders importés préservent des éléments historiques. Le parcours de commande par emplacement d’entreprise, les conditions de paiement, acomptes, approbations, paiements, traitements des commandes, retours et intégrations actuels nécessitent chacun une implémentation cible prise en charge.