Les migrations vers Gambio échouent le plus souvent lorsque des volumes de données apparemment complets sont confondus avec la préservation du fonctionnement commercial. La plateforme peut combiner des relations de catalogue, des règles liées aux groupes de Customers, du contenu multilingue, des Orders, des intégrations et des responsabilités d’exploitation différentes selon qu’elle est gérée ou auto-hébergée. Chaque piège ci-dessous décrit un schéma d’échec récurrent et les éléments à vérifier pour démontrer qu’il est réellement maîtrisé.
Piège 1 : choisir le modèle d’exploitation sans en assumer les conséquences
Ce qui pose problème
Gambio Cloud et une installation Gambio auto-hébergée peuvent représenter le même catalogue tout en répartissant très différemment la responsabilité de l’hébergement, des mises à jour, de l’accès au code, des extensions et des intégrations personnalisées. Une migration peut préserver les Products et les Orders tout en échouant sur le plan opérationnel si l’entreprise attend la souplesse d’un environnement auto-hébergé dans un environnement géré, ou attend une maintenance prise en charge tout en conservant du code personnalisé et des dépendances serveur.
Signaux d’alerte précoces
La cible est décrite uniquement comme « Gambio » sans préciser son modèle d’exploitation. Les tâches cron, personnalisations au niveau des fichiers, scripts serveur ou traitements directs en base de données existants n’ont aucun responsable futur. À l’inverse, une cible auto-hébergée ne dispose d’aucun responsable désigné pour les mises à jour, les sauvegardes, la supervision et la compatibilité des extensions.
| Signal | Hypothèse implicite probable | Conséquence pour l’entreprise |
|---|---|---|
| Du PHP personnalisé ou des tâches serveur doivent continuer | La cible doit offrir un contrôle du code et de l’infrastructure | Un environnement géré peut ne pas pouvoir reproduire cette dépendance |
| Aucun responsable technique n’est désigné | L’hébergement et la maintenance sont supposés inclus | L’exploitation auto-hébergée peut se retrouver sans gestion |
| Le choix de la cible repose uniquement sur la compatibilité des données | La responsabilité d’exploitation a été exclue de la décision | La boutique peut être alimentée en données sans pouvoir être exploitée durablement |
Prévention
Consignez le modèle d’exploitation de la cible avant de décider comment les fonctions personnalisées continueront. Séparez les données migrées de l’hébergement, de la maintenance, des mises à jour, de l’installation d’extensions, de l’accès aux fichiers, des tâches planifiées et des intégrations externes. Pour Gambio auto-hébergé, attribuez clairement la responsabilité de l’infrastructure et des mises à jour. Pour Gambio Cloud, identifiez chaque besoin dépendant d’un accès direct au code, au serveur ou à la base de données, puis vérifiez s’il existe une voie prise en charge équivalente.
Exemple de recommandation
Une entreprise utilise chaque nuit un script serveur pour enrichir les données Product avant publication. La migration préserve les champs Product, mais le script est traité comme une dépendance d’exploitation distincte. L’équipe l’affecte soit à une intégration prise en charge, soit à un environnement dans lequel ce traitement peut être maintenu volontairement.
Condition de réussite
Le modèle d’exploitation cible est clairement identifié, chaque dépendance d’infrastructure ou de code a un responsable, et aucun processus métier critique ne dépend d’un niveau d’accès ou d’une responsabilité de maintenance que l’environnement retenu ne fournit pas.
Piège 2 : aplatir les propriétés, options et différences entre variantes vendables
Ce qui pose problème
Les enregistrements Product de Gambio peuvent contenir des données descriptives ordinaires ainsi que des relations d’options ou de propriétés qui modifient ce que le client sélectionne et ce que l’entreprise traite. Transformer chaque option source en simple attribut textuel peut préserver les libellés tout en perdant l’identité de la combinaison, l’effet sur le prix, le stock, les images, le poids, le délai d’expédition ou encore le modèle Product utilisé par les systèmes connectés.
Signaux d’alerte précoces
Les Products simples semblent corrects, mais les Products comportant plusieurs dimensions de sélection produisent des choix en double, des combinaisons impossibles, une seule valeur de stock partagée ou des lignes d’Order qui n’identifient plus la variante achetée. Les SKU ou identifiants externes de la source existent à un niveau plus précis que le Product migré.
| Schéma observé | Signification menacée | Échec typique |
|---|---|---|
| Le choix modifie le SKU ou le stock | Identité de la combinaison vendable | Le mauvais article est traité ou expédié |
| Le choix ne modifie que la présentation | Option d’affichage ou valeur descriptive | Duplication inutile de Products |
| Une combinaison de propriétés possède son propre prix ou sa propre image | Données commerciales propres à la combinaison | Le prix ou l’image du panier ne correspond pas à la sélection |
Prévention
Classez les valeurs source par fonction : information descriptive, sélection par l’acheteur, combinaison vendable, personnalisation saisie par le client ou clé utilisée par un système externe. Préservez les relations entre Product parent et combinaisons ainsi que tous les effets commercialement significatifs. Ne déduisez pas l’identité d’une combinaison à partir du libellé seul lorsqu’un SKU stable, un numéro de modèle ou un identifiant source existe.
Exemple de recommandation
Un câble configurable utilise la longueur et le type de connecteur. Chaque combinaison valide possède un numéro de modèle, une quantité en stock et un prix distincts. Conservez un Product parent pour le merchandising, mais préservez l’ensemble des combinaisons valides et leurs identifiants opérationnels au lieu de créer des choix libres déconnectés du stock.
Condition de réussite
Chaque Product complexe représentatif n’affiche que les choix valides, ajoute au panier le prix et l’identité d’article attendus, conserve le bon responsable du stock et reste traçable jusqu’à l’identifiant utilisé par les systèmes de traitement des commandes ou de gestion des stocks.
Piège 3 : préserver les Categories tout en dégradant la découverte des Products
Ce qui pose problème
Une arborescence de Categories peut être numériquement complète alors que la découverte des Products s’est dégradée. Un Product peut appartenir à plusieurs Categories, les branches profondes peuvent porter un sens de navigation important, et le contenu ou les URL des Categories peuvent contribuer au merchandising et à la visibilité dans les moteurs de recherche. Aplatir la hiérarchie, ne conserver qu’une affectation ou recréer des noms sans leur contexte de routage peut rendre les Products difficiles à trouver.
Signaux d’alerte précoces
Le nombre de Categories correspond à la source, mais des Products représentatifs disparaissent des parcours de navigation attendus. Les fils d’Ariane changent de manière inattendue, des Categories en double apparaissent, des branches profondes deviennent vides ou des parcours de Category à forte valeur n’ont plus de destination claire.
| Vérification | Schéma d’échec | Pourquoi cela compte |
|---|---|---|
| Structure parent-enfant | Les niveaux sont aplatis ou dupliqués | Le sens de la navigation change |
| Affectations des Products | Une seule Category est conservée | Les parcours de cross-merchandising disparaissent |
| Parcours et contenu de Category | Le nom existe sans destination équivalente | Le SEO et les points d’entrée des clients se dégradent |
Prévention
Mappez séparément la hiérarchie et les affectations de Products. Identifiez les relations de Category principales et supplémentaires, les noms localisés, descriptions, images et parcours prioritaires. Ne retirez les branches obsolètes qu’avec une destination explicite. Utilisez des Products représentatifs des niveaux supérieur, intermédiaire et le plus profond pour vérifier que les parcours de navigation attendus restent possibles.
Exemple de recommandation
Un Product appartient à « Outdoor », « Camping » et à une Category promotionnelle saisonnière. Préservez l’identité stable du Product et toutes les affectations voulues, tout en définissant quel parcours doit être principal pour le fil d’Ariane et si le parcours saisonnier doit rester actif ou rediriger.
Condition de réussite
Les Products représentatifs sont accessibles par chaque parcours de Category prévu, la hiérarchie et les fils d’Ariane sont cohérents, les routes retirées ont une destination volontaire et aucun Product n’est exposé ou masqué à cause d’une affectation supprimée silencieusement.
Piège 4 : copier les groupes de Customers sans leurs autorisations et leurs prix
Ce qui pose problème
Gambio peut associer l’accès aux Products, les prix ou d’autres traitements commerciaux à des groupes de Customers. Migrer les Customers et les noms de groupes sans préserver les relations qu’ils contrôlent crée des comptes qui semblent correctement classés mais reçoivent une visibilité ou une tarification par défaut. Le risque est particulièrement élevé pour les populations grossistes, restreintes ou bénéficiant de conditions négociées.
Signaux d’alerte précoces
Les groupes de Customers existent dans l’administration, mais les Products affichent les mêmes prix et disponibilités à tous les acheteurs. Les champs d’autorisation de groupe, règles de remise ou identifiants externes de Customer sont absents ou réduits à de simples notes.
| Relation | Signal d’alerte | Effet potentiel |
|---|---|---|
| Customer → groupe | L’appartenance devient un simple libellé | Le traitement du compte revient aux valeurs par défaut |
| Groupe → visibilité Product | Les Products restreints deviennent largement visibles | Les limites du catalogue privé ne sont plus respectées |
| Groupe → prix ou remise | Tous les groupes reçoivent le même résultat | Les accords commerciaux sont perdus |
Prévention
Documentez le résultat contrôlé par chaque groupe, et pas seulement son nom. Préservez séparément l’appartenance du Customer, les autorisations Product, les relations de prix et la configuration cible. Regroupez les groupes obsolètes de manière volontaire et conservez les identifiants externes requis par l’ERP, le CRM ou les processus de gestion des comptes.
Exemple de recommandation
Un groupe de revendeurs peut acheter certains Products à des prix négociés. Préservez l’appartenance au groupe, la relation d’accès aux Products et le responsable de la tarification. N’approuvez pas le résultat au seul motif que le profil Customer affiche toujours « Dealer ».
Condition de réussite
Les Customers représentatifs entrent dans le bon contexte de groupe, voient uniquement les Products et conditions commerciales prévus et conservent les identifiants nécessaires aux systèmes de gestion des comptes, sans obtenir d’accès non prévu.
Piège 5 : réduire les Orders à leurs totaux et noms de statut
Ce qui pose problème
L’en-tête d’un Order peut être conservé alors que sa signification historique disparaît. Les attributs des lignes Product, remises, taxes, frais de livraison, références de paiement, numéros de suivi, commentaires et historique des statuts expliquent ce qui a été acheté et ce qui s’est produit ensuite. Copier uniquement les totaux et un statut visuellement similaire empêche le support et la finance de reconstruire correctement la transaction.
Signaux d’alerte précoces
Le nombre d’Orders et les totaux généraux semblent plausibles, mais les équipes ne peuvent plus identifier la propriété Product sélectionnée, expliquer une remise, retrouver une référence d’expédition ou distinguer correctement une annulation, un retour et un remboursement.
| Élément de l’Order | Perte | Impact opérationnel |
|---|---|---|
| Attributs de ligne | Le choix acheté n’est plus visible | Les décisions de remplacement et de support deviennent peu fiables |
| Composants du total | Remise, taxe ou livraison sont aplaties | Le rapprochement n’explique plus le total général |
| Historique et suivi | Seul le statut actuel subsiste | Les équipes ne peuvent plus reconstruire la chronologie de la transaction |
Prévention
Préservez les en-têtes d’Order, lignes, attributs sélectionnés, composants du total, adresses, dates, références source, notes historiques et relations de suivi lorsque la cible sait les représenter. Lorsqu’un fonctionnement source n’a pas d’équivalent, conservez un contexte historique lisible plutôt que d’inventer un état actif du processus cible.
Exemple de recommandation
Un Order retourné contient deux options Product, un coupon, une taxe de livraison et un numéro de suivi. L’historique migré conserve ces composants et rend le contexte du retour compréhensible, tandis que le fonctionnement actif des remboursements reste un processus propre à la cible plutôt qu’une conclusion tirée de l’ancien libellé de statut.
Condition de réussite
Les équipes peuvent ouvrir des Orders ordinaires et des cas d’exception représentatifs, identifier exactement ce qui a été acheté, rapprocher le total affiché, comprendre l’état historique et suivre les références conservées sans retourner dans la boutique source.
Piège 6 : traiter les URL multilingues et les métadonnées comme du simple texte décoratif
Ce qui pose problème
Les descriptions de Products et de Categories, mots-clés d’URL, métadonnées, textes alternatifs des images et informations de commande peuvent varier selon la langue. Choisir une langue comme source universelle ou copier les textes traduits sans leurs relations de routage peut écraser le sens propre à chaque marché, créer des chemins en double ou laisser des liens internes pointer vers d’anciennes URL.
Signaux d’alerte précoces
Une langue est complète tandis qu’une autre contient des contenus de secours, des métadonnées mélangées, des slugs manquants ou des liens internes cassés. Les parcours Product et Category à forte valeur n’ont aucun plan de destination propre à chaque langue.
| Couche de contenu | Schéma d’échec | Effet pour le client |
|---|---|---|
| Noms et descriptions | Une langue écrase une autre | Les pages localisées deviennent incomplètes |
| Mots-clés d’URL et métadonnées | Les routes sont régénérées sans mise en correspondance | Les entrées organiques et favoris cessent de fonctionner |
| Liens internes et texte des images | Les liens ou textes alternatifs gardent les chemins/langues source | Le contenu devient incohérent ou inaccessible |
Prévention
Inventoriez les langues actives et classez chaque champ traduisible. Mappez séparément les parcours Product, Category et contenu propres à chaque langue vers leur destination prévue. Préservez les identifiants de contenu stables lorsqu’ils existent et créez des relations de redirection pour les chemins prioritaires au lieu de dépendre uniquement de la génération automatique de slugs.
Exemple de recommandation
Une page Product allemande et son équivalent anglais utilisent des slugs et des métadonnées différents. Préservez les deux enregistrements linguistiques, mappez chaque parcours séparément et mettez à jour les liens internes afin que la page anglaise ne pointe pas vers l’ancien chemin source allemand.
Condition de réussite
Chaque langue active possède un contenu Product et Category complet, des métadonnées cohérentes, des liens internes fonctionnels et une destination définie pour chaque URL source prioritaire sans écrasement entre langues.
Piège 7 : déplacer des Pages CMS et informations de commande sans leur contexte d’affichage
Ce qui pose problème
Les Pages CMS, informations Product affichées pendant la commande, contenus de confiance et informations juridiques ou de service peuvent exister comme enregistrements tout en étant absents des endroits où les clients en ont besoin. Les positions du thème, menus, liens de pied de page, modèles Product et surfaces du parcours de commande sont distincts du contenu lui-même.
Signaux d’alerte précoces
Les pages existent dans l’administration mais ne sont accessibles depuis aucune navigation. Les informations de commande propres à un Product n’apparaissent plus sur le Product concerné, ou le contenu de politique est disponible sous une route générique sans son emplacement attendu.
| Type de contenu | Question de responsabilité distincte | Échec si elle est ignorée |
|---|---|---|
| Page CMS | Quel menu, pied de page ou parcours l’expose ? | La page existe mais reste inaccessible |
| Informations Product pour la commande | Quels Products et quelle étape d’achat les utilisent ? | Des instructions importantes disparaissent |
| Contenu de confiance ou de politique | Quel emplacement de la boutique le présente ? | Les clients ne trouvent plus l’information requise |
Prévention
Traitez l’enregistrement de contenu, son affectation, son parcours et sa présentation comme des relations distinctes. Préservez le contenu et son rattachement aux Products ou à la navigation, puis reconstruisez volontairement son emplacement sur la cible. Examinez les liens internes et références média dans le même parcours de contenu.
Exemple de recommandation
Une famille de Products comporte des instructions de commande pour des mesures personnalisées. Préservez le contenu de ces instructions et leur relation aux Products, puis vérifiez qu’elles apparaissent à l’étape d’achat prévue au lieu de devenir une Page CMS sans lien.
Condition de réussite
Les contenus prioritaires sont exacts, accessibles par le parcours de boutique prévu, rattachés aux bons Products ou zones de navigation et exempts de liens réservés à la source ou de dépendances de présentation non reconstruites.
Piège 8 : préserver les Products téléchargeables sans préserver le sens de leur livraison numérique
Ce qui pose problème
Un Product téléchargeable ne se résume pas à une référence de fichier. Le droit d’accès, le statut de l’Order, la disponibilité du téléchargement, l’expiration, le nombre de téléchargements, l’accès du Customer et la sécurité du fichier peuvent déterminer si l’achat est réellement utilisable. Copier uniquement le Product et le nom du fichier peut exposer des fichiers trop tôt ou empêcher des acheteurs légitimes d’y accéder.
Signaux d’alerte précoces
Les Products téléchargeables apparaissent dans le catalogue, mais les Customers historiques n’ont plus de contexte d’accès, les chemins de fichiers pointent vers le stockage source ou tous les statuts d’Order accordent le même droit de téléchargement.
| Composant numérique | Risque en cas d’aplatissement | Résultat |
|---|---|---|
| Relation avec le fichier | Le chemin source est copié comme texte | La ressource ne peut pas être livrée |
| Règle de droit d’accès | L’état de l’Order et la propriété Customer sont perdus | L’accès est accordé ou refusé à tort |
| Expiration ou nombre de téléchargements | Les valeurs de contrôle disparaissent | La politique du produit numérique change silencieusement |
Prévention
Identifiez chaque ressource numérique, sa relation au Product, les conditions d’accès, les besoins d’accès historique et les limites de sécurité. Déplacez les ressources via un emplacement de stockage approuvé et ne préservez que l’historique d’accès que la cible peut représenter de façon sûre. Séparez l’historique des règles actives de droit d’accès.
Exemple de recommandation
Un logiciel autorise trois téléchargements après paiement et expire après une période définie. Préservez le Product et l’achat historique, puis configurez explicitement le modèle d’accès de la cible au lieu de supposer que l’ancien chemin de fichier et le statut de l’Order recréent l’accès.
Condition de réussite
Les Customers autorisés peuvent accéder aux bonnes ressources dans les conditions prévues, les utilisateurs non autorisés ne le peuvent pas, les achats historiques restent compréhensibles et aucun chemin de fichier source n’est traité comme un mécanisme de livraison fonctionnel.
Piège 9 : supposer que les connexions de paiement, de livraison et de marketplace suivent les données
Ce qui pose problème
Les Products, Customers et Orders peuvent être migrés sans recréer les identifiants actifs de paiement, les services de livraison, les annonces de marketplace, les abonnements webhook ou l’état de synchronisation. Les références historiques peuvent être utiles, mais elles n’activent pas le service connecté dans Gambio.
Signaux d’alerte précoces
Le projet considère une passerelle, un transporteur, une marketplace ou un ERP comme « inclus » simplement parce que des Orders ou identifiants Product correspondants sont présents. Aucun responsable n’a confirmé les identifiants, l’accès au compte, la prise en charge de l’extension cible, les contrats de champs ou les flux d’événements.
| Dépendance | Données pouvant subsister | Fonctionnement nécessitant une responsabilité distincte |
|---|---|---|
| Prestataire de paiement | Nom du moyen et référence de transaction | Identifiants, callbacks, règlement, remboursements |
| Transporteur | Libellé du service et numéro de suivi | Tarifs, étiquettes, événements de suivi |
| Marketplace ou ERP | Identifiants externes et références historiques | Annonces, synchronisation, règles de conflit |
Prévention
Créez un registre des dépendances indiquant le système de référence actuel, les identifiants échangés, les accès, le sens des événements, la gestion des erreurs et le responsable côté cible. Ne conservez les identifiants externes que s’ils continuent à relier les enregistrements. Reconfigurez ou reconstruisez le fonctionnement actif séparément de l’historique migré.
Exemple de recommandation
Les Orders historiques conservent un identifiant d’Order marketplace et une référence de paiement. Le connecteur marketplace est ensuite configuré avec ses propres identifiants et règles de mise en correspondance ; la présence de ces identifiants historiques n’est pas considérée comme la preuve que la synchronisation est active.
Condition de réussite
Chaque connexion requise possède un responsable, des identifiants fonctionnels, des identifiants de données et des flux d’événements définis, et aucun fonctionnement métier actif n’est déduit uniquement des enregistrements migrés ou des libellés historiques.
Piège 10 : transporter les personnalisations auto-hébergées comme des données non examinées
Ce qui pose problème
Les boutiques Gambio auto-hébergées peuvent contenir des modèles modifiés, modules personnalisés, champs de base de données supplémentaires, tâches planifiées ou intégrations directes. Les exports standard peuvent omettre leurs données, tandis que copier des tables personnalisées sans comprendre le code qui les consomme peut préserver des fragments inutilisables ou créer des responsabilités contradictoires dans la cible.
Signaux d’alerte précoces
La source contient des colonnes inconnues, des tables personnalisées, des fichiers modifiés ou des rapports dépendant de valeurs absentes des enregistrements Product, Customer ou Order ordinaires. Personne ne sait quel processus lit ou écrit ces données.
| Élément de personnalisation | Question à résoudre | Hypothèse dangereuse |
|---|---|---|
| Champ ou table personnalisé | Quel processus métier le consomme ? | Toute valeur stockée doit être copiée |
| Modèle/module modifié | Ce fonctionnement doit-il encore exister dans la cible ? | Le code peut être déplacé avec les données |
| Intégration planifiée | De quels identifiants et événements de changement dépend-elle ? | La tâche continuera sans modification |
Prévention
Retracez chaque personnalisation depuis la valeur stockée jusqu’à son usage métier. Classez-la comme donnée à conserver, configuration cible, état d’intégration, logique de présentation, référence historique ou fonctionnement devenu obsolète. Préservez les clés stables lorsqu’un système encore utilisé en dépend et excluez les résidus techniques sans propriétaire au lieu de les copier automatiquement.
Exemple de recommandation
Un champ Product personnalisé contrôle l’emballage en entrepôt et est lu par un export ERP. Préservez la valeur et la clé Product externe dans un champ géré par la cible ou dans un contrat d’intégration. Ne copiez pas l’ancienne table du module si le processus cible ne la lira jamais.
Condition de réussite
Chaque champ, table, module et processus planifié personnalisé a un objectif documenté et un responsable côté cible ; les valeurs encore utiles restent exploitables, les résidus retirés le sont volontairement et aucun processus critique ne dépend de code source non identifié.
Priorités de prévention communes aux différents pièges
La séquence de prévention la plus solide commence par la responsabilité du modèle d’exploitation, puis traite l’identité des Products vendables, la découverte, le traitement des Customers, l’historique des Orders, les parcours de contenu, la livraison numérique, les intégrations et les données personnalisées. Ces domaines doivent rester reliés par des identifiants stables et des responsabilités explicites. Un Product ne peut pas être approuvé isolément si sa Category, son autorisation de groupe, sa clé externe ou son droit d’accès numérique n’a toujours pas de relation de destination.
Les tableaux précédents mettent en évidence des schémas d’alerte, mais la décision doit rester fondée sur les enregistrements concernés. L’équipe doit pouvoir expliquer non seulement que les données existent, mais aussi comment la boutique cible les utilisera et quel système ou quelle configuration distincte prend en charge tout fonctionnement qui ne réside pas dans l’enregistrement migré.
Conclusion
Une migration Gambio fiable préserve les relations qui rendent les enregistrements commercialement exploitables. Elle distingue les responsabilités de Gambio Cloud et de l’auto-hébergement, conserve la traçabilité opérationnelle des choix Product, maintient la découverte multilingue et les parcours de contenu, préserve le contexte utile des Customers et des Orders et attribue chaque intégration ou personnalisation à un responsable réel. Des totaux d’enregistrements corrects ne suffisent pas si ces relations ne sont pas conservées.
Questions fréquentes
Pourquoi Gambio Cloud et Gambio auto-hébergé doivent-ils être traités différemment ?
Ils peuvent contenir des données commerciales similaires, mais l’hébergement, les mises à jour, l’accès au code, les extensions personnalisées et la responsabilité de l’infrastructure diffèrent. Ces différences déterminent si les personnalisations et processus d’exploitation de la source disposent d’un responsable viable dans la cible.
Quel échantillon de Product Gambio présente le plus de risques ?
Utilisez un Product dont les choix modifient le SKU, le prix, le stock, l’image ou le traitement des commandes. Un Product simple ne permet pas de vérifier si les relations de propriétés et de combinaisons restent commercialement exploitables.
Les noms de groupes de Customers prouvent-ils que leur fonctionnement a été préservé ?
Non. L’appartenance, les autorisations Product, la tarification, les remises et les relations fiscales doivent encore produire l’expérience Customer prévue. Un libellé sans les résultats qu’il doit contrôler est incomplet.
Comment faut-il examiner les Orders historiques de Gambio ?
Examinez les attributs de ligne, composants du total, adresses, historique des statuts, suivi, commentaires et références externes. L’Order doit permettre de comprendre la transaction sans laisser penser qu’un ancien état de processus reste actif dans la cible.
Les données de paiement et de marketplace recréent-elles leurs intégrations ?
Non. Les noms de moyens de paiement et les identifiants externes historiques peuvent être conservés, mais les identifiants d’accès, extensions, flux d’événements, synchronisations et traitements d’erreur doivent être reconstruits séparément sur la cible.
Quand un champ Gambio personnalisé doit-il être exclu ?
Excluez-le lorsqu’aucun processus encore utilisé ne le lit et qu’il ne possède aucune valeur historique ou de rapprochement. Ne le préservez que lorsque son objectif métier et son responsable côté cible sont explicites.