Les besoins de migration non standard sont difficiles pour une raison que les simples volumes d’enregistrements ne montrent pas : les données portent souvent une signification qui n’apparaît pas dans le nom du champ. Une valeur Product personnalisée peut piloter la recherche, la tarification ou le traitement des commandes. Un identifiant externe d’Order peut relier la boutique à la comptabilité. Un enregistrement géré par une application peut représenter un abonnement, un solde de fidélité, un vendeur marketplace ou un processus opérationnel.
Déplacer la valeur sans comprendre ce rôle peut produire une boutique cible qui semble complète mais qui ne soutient plus l’activité. Dans les services de migration Next-Cart, Custom Service comble cet écart en transformant un besoin non standard en résultat de migration convenu, avec des éléments source définis, une représentation cible, un travail adapté et des critères d’acceptation.
L’objectif n’est pas de qualifier tout le projet de Custom. Il consiste à identifier les domaines précis où le fonctionnement pris en charge et les Standard Add-ons ne suffisent pas, puis à définir ce qu’un résultat migré exploitable doit signifier.
Identifier pourquoi le besoin est non standard
Un besoin peut relever de Custom Service en raison de sa source, de sa structure, de sa logique, de ses relations ou de sa destination cible.
| Origine de la difficulté | Question sous-jacente |
|---|---|
| Custom Platform | Comment comprendre et accéder au modèle de données source ou cible ? |
| Champs ou tables personnalisés | Quelle signification métier portent les valeurs et quels enregistrements en sont propriétaires ? |
| Données d’application, plugin, module ou extension | Ces données font-elles autorité et quel processus futur en a besoin ? |
| Identifiants externes | Quelle relation avec un autre système doit rester intacte après la migration ? |
| Transformation sur mesure | Comment les valeurs ou enregistrements doivent-ils être combinés, séparés, normalisés ou restructurés ? |
| Relations non standard | Comment représenter la propriété et les références dans la plateforme cible ? |
| Add-on modifié ou nouveau | Pourquoi le Standard Add-on disponible ne peut-il pas produire le résultat requis ? |
| Limite de la cible | Quelle est la représentation exploitable la plus proche et quelle implémentation reste séparée ? |
Ces questions permettent de définir clairement le périmètre de Custom Service. « Migrer toutes les données personnalisées » ne le rend pas. Un besoin exploitable identifie les enregistrements concernés, le rôle métier qui doit continuer, le résultat attendu dans la boutique cible et les éléments qui prouveront la réussite.
Le travail sur une Custom Platform commence par son modèle de données
Une Custom Platform peut être la plateforme source, la plateforme cible ou les deux. Le défi ne consiste pas uniquement à établir l’accès. La migration doit déterminer comment la boutique représente Products, Customers, Orders, contenu, relations et structures associées.
Les éléments source utiles peuvent inclure :
- des descriptions du schéma ou des exports ;
- des Products, Customers, Orders et contenus représentatifs ;
- les clés primaires et étrangères ;
- les relations de Categories et de navigation ;
- les valeurs de statut ou de type personnalisées ;
- les références vers les médias et fichiers ;
- les informations sur les systèmes externes ;
- des exemples des résultats métier qui doivent continuer à fonctionner.
La revue doit ensuite comparer cette signification source avec les possibilités de la plateforme cible. Certains enregistrements peuvent avoir un équivalent direct. D’autres peuvent nécessiter une transformation, un mapping de champs, une structure cible personnalisée ou une exclusion accompagnée d’une solution de remplacement documentée.
Custom Service ne rend pas toutes les représentations cibles possibles. Il fournit une méthode structurée pour déterminer ce qui peut être migré, ce qui doit changer et ce que le client doit attendre.
Traiter les données tierces comme un problème de propriété
Les boutiques dépendent souvent de données créées par des applications, plugins, modules, extensions ou services connectés. La présence d’une table ou d’un champ ne prouve pas qu’il faille le migrer. Certains enregistrements font autorité. D’autres sont des caches, journaux, valeurs dérivées ou restes de fonctionnalités abandonnées.
La revue Custom doit établir :
- quel système possède les données ;
- quel processus métier les utilise ;
- si elles font toujours autorité ;
- à quel enregistrement migré elles appartiennent ;
- ce que la boutique cible ou le système connecté doit en faire ;
- comment le résultat sera validé.
Ce test de propriété est plus fiable que la copie de tous les champs non standard. Des données sans propriétaire futur peuvent créer du bruit ou des conflits. Des données qui conservent un rôle opérationnel peuvent être critiques même lorsqu’elles n’occupent qu’un seul champ.
Exemples :
- identifiants d’abonnement associés aux Products ou Customers ;
- soldes de fidélité associés à l’identité Customer ;
- propriété d’un vendeur marketplace associée aux Products et Orders ;
- références de traitement logistique associées aux lignes d’Order ;
- identifiants PIM associés aux enregistrements Product ;
- classifications de reporting associées aux Products, Customers ou Orders.
Préserver les identifiants externes à travers leurs relations
Un identifiant externe n’est utile que si sa relation survit. Copier un identifiant Product ERP dans un champ texte arbitraire peut conserver les caractères tout en cassant le processus qui en dépend.
Le périmètre de Custom Service doit définir :
- le système propriétaire de l’identifiant ;
- l’enregistrement migré auquel il fait référence ;
- ses contraintes d’unicité et de format ;
- la possibilité ou non de modifier la valeur ;
- la destination cible compatible ;
- l’intégration ou le processus de reporting qui l’utilisera ;
- les éléments nécessaires pour confirmer la relation.
Par exemple, préserver une référence Order peut nécessiter plus que la migration de la valeur d’en-tête. Le service client, le traitement logistique ou la comptabilité peuvent avoir besoin que la référence reste reliée au bon Order, à ses lignes et à son contexte historique.
Le déploiement des intégrations reste séparé sauf s’il est expressément inclus. Custom Service peut préserver les données et la relation côté migration telles qu’elles sont définies dans le périmètre accepté. Il ne construit ni n’exploite automatiquement chaque système qui consommera ensuite ces données.
Définir une transformation sur mesure par sa signification
Une logique de migration Custom peut être nécessaire lorsque le fonctionnement standard ne peut pas produire le résultat attendu. Les modèles fréquents comprennent :
- combiner plusieurs champs source dans un champ cible ;
- répartir une valeur source entre plusieurs champs cibles ;
- normaliser des valeurs incohérentes ;
- convertir des statuts source en statuts cible ;
- restructurer des enregistrements gérés par une application ;
- préserver des relations non standard ;
- faire correspondre des enregistrements à l’aide d’identifiants propres au projet ;
- appliquer des règles indisponibles dans les Standard Add-ons.
La transformation doit être décrite sous forme de règle, avec des exemples et des exceptions.
Besoin trop faible :
Corriger les statuts des Orders.
Besoin plus précis :
Convertir chaque statut Order source approuvé vers le statut cible défini, conserver le statut source d’origine à des fins d’audit lorsqu’il est convenu de le faire, et valider des exemples d’Orders terminés, annulés, remboursés et partiellement traités.
Le besoin plus précis décrit la condition source, le résultat cible et la manière de le prouver. Il peut être défini, chiffré, implémenté et accepté.
Savoir quand un Add-on devient Custom
Les Standard Add-ons résolvent des besoins limités et pris en charge :
- Data Filter sélectionne les enregistrements à migrer en appliquant des conditions basées sur les champs de chaque type de données ;
- Advanced Data Mapping remappe des champs source pris en charge vers des champs cibles compatibles ;
- Advanced Database Mapping mappe des champs pris en charge et des colonnes de base de données sous-jacentes vers des champs ou colonnes cibles compatibles uniquement lorsque la plateforme source et la plateforme cible sont toutes deux Open-Source ;
- Data Transformation transforme les valeurs de champs cibles sélectionnées pendant la migration.
Custom Service devient pertinent lorsque :
- un Standard Add-on doit être modifié, ce qui crée un Tailored Add-on ;
- aucun Standard Add-on ne convient, ce qui crée un besoin de Custom Add-on ;
- les enregistrements ou relations sous-jacents ne sont pas pris en charge ;
- le besoin exige une logique sur mesure au-delà du fonctionnement disponible de l’Add-on.
Un Add-on peut rester intégré à un projet relevant de Custom Service. L’Add-on répond à une capacité ciblée, tandis que Custom Service définit le résultat non standard plus large.
Construire le périmètre autour d’éléments concrets
Une demande Custom Service doit fournir suffisamment d’éléments pour définir à la fois la faisabilité et l’acceptation.
| Élément | Pourquoi il compte |
|---|---|
| Détails de la plateforme source et de la plateforme cible | Établit le parcours de migration et le contexte des plateformes |
| Enregistrements source représentatifs | Montre les valeurs, structures et relations réelles |
| Propriétaire des données et usage métier | Explique pourquoi les données non standard doivent survivre |
| Résultat attendu dans la boutique cible | Définit la représentation requise |
| Règles de transformation ou de rapprochement | Rend la logique adaptée vérifiable |
| Applications ou systèmes externes associés | Révèle les dépendances hors des enregistrements standard de la plateforme |
| Exceptions et cas d’échec | Évite de limiter le périmètre aux enregistrements idéaux |
| Échantillons de validation et responsable | Définit comment l’acceptation sera décidée |
| Entity Points Plan et Add-ons achetés | Distingue la capacité et les améliorations existantes du nouveau travail Custom |
Les éléments fournis doivent inclure des cas difficiles, pas seulement des exemples propres. Une règle Custom qui fonctionne pour des Products ordinaires peut échouer avec des Products dépourvus d’identifiant, comportant des valeurs dupliquées ou des relations inhabituelles.
Le périmètre accepté doit préciser ce qui sera extrait, transformé, relié ou livré. Il doit également préciser ce qui est exclu, ce qui dépend des possibilités de la plateforme cible et quelles responsabilités d’implémentation restent séparées.
Séparer le traitement de migration de l’implémentation cible
Custom Service peut définir un traitement de migration adapté. Il n’inclut pas automatiquement :
- la conception du thème ou de la vitrine ;
- l’installation d’applications ou d’extensions ;
- le développement et le déploiement des intégrations ;
- la configuration des paiements, de la livraison, des taxes ou des e-mails ;
- la reconstruction complète des processus ;
- la configuration opérationnelle ;
- chaque fonctionnement de la source que la plateforme cible ne peut pas prendre en charge.
Cette séparation n’est pas seulement contractuelle. Elle protège la décision de migration. Un enregistrement peut être correctement migré alors que le processus cible qui l’utilise n’est pas encore implémenté. À l’inverse, une application cible peut être installée alors que la migration n’a pas préservé les données dont elle a besoin.
Le périmètre doit montrer le passage de relais. Par exemple, un identifiant externe peut être migré vers un champ cible convenu, tandis qu’un travail d’intégration séparé relie ensuite ce champ à l’ERP.
Définir des attentes réalistes face aux différences de plateforme
Custom Service ne peut pas forcer deux plateformes à fonctionner de manière identique. Les options Product, groupes Customer, états Order, hiérarchies de contenu, URL et données d’application peuvent ne pas avoir d’équivalent direct sur la cible.
Le résultat exploitable peut être :
- une conservation directe ;
- une transformation vers une structure prise en charge par la cible ;
- un mapping au niveau des champs ;
- une conservation partielle de la signification métier ;
- un export pour un usage séparé ;
- une exclusion accompagnée d’un plan de remplacement documenté.
Le bon résultat dépend de l’usage métier et des possibilités de la plateforme cible. Reproduire exactement le fonctionnement source n’est pas toujours l’objectif le plus solide. Une représentation cible plus simple peut être préférable lorsqu’elle préserve le résultat nécessaire sans transporter une logique source obsolète.
Comprendre séparément périmètre, exécution et prix
Custom Service définit le travail adapté. Expert Handle définit si l’exécution par des experts des actions de migration convenues est également incluse.
Un projet relevant de Custom Service peut donc être :
- piloté par le client, avec le travail adapté inclus et les actions de migration effectuées par le client ; ou
- piloté par des experts, avec Expert Handle inclus dans le périmètre accepté.
Le montant Custom Service affiché commence au prix Standard Service du Entity Points Plan sélectionné. Ce montant établit le plancher de capacité. Le total final ajoute le devis de personnalisation convenu, les Add-ons achetés le cas échéant, Expert Handle lorsqu’il est inclus et les autres coûts spécifiques au périmètre acceptés.
Lorsque du travail Custom est ajouté à une migration déjà achetée, le devis accepté modifie la valeur totale de la migration. Le montant déjà payé reste pris en compte et seule la différence supplémentaire est facturée. Le même principe s’applique aux Tailored et Custom Add-ons.
Le prix final ne peut pas être établi sérieusement tant que le résultat non standard n’est pas assez clair pour être défini. L’acceptation et l’achat de l’upgrade chiffré intègrent le travail à la même migration ; ils ne créent pas un nouveau parcours et ne prolongent pas la durée d’un an du service.
Valider le résultat adapté
Un travail Custom nécessite des éléments d’acceptation adaptés. Les simples contrôles de quantité sont insuffisants lorsque le besoin dépend de la signification, de la transformation ou des relations.
La validation doit comparer :
- l’exemple source ;
- la règle de transformation ou de traitement convenue ;
- la représentation dans la boutique cible ;
- les enregistrements reliés ou identifiants externes ;
- le fonctionnement métier attendu ;
- le traitement des exceptions ;
- la décision Pass, Watch ou Block.
Le client reste responsable de la vérification finale. Cela est particulièrement important pour le travail Custom, car le niveau d’acceptation dépend souvent de connaissances métier qui ne peuvent pas être déduites uniquement du schéma source.
Une décision Watch doit identifier l’incertitude restante, sa conséquence métier, les éléments encore nécessaires et la personne chargée de la résoudre. Sans cette interprétation, la validation Custom devient une liste d’observations plutôt qu’une décision d’acceptation défendable.
Conclusion
Next-Cart Custom Service prend en charge les parties d’une migration qui nécessitent une interprétation individuelle, une logique adaptée, des Add-ons modifiés, l’analyse d’une Custom Platform, des relations non standard ou une représentation cible conçue pour le projet.
Un périmètre de Custom Service bien défini part de la signification des données et d’éléments concrets. Il identifie le propriétaire des données, l’usage métier qui doit continuer, la manière dont la boutique cible doit représenter le résultat, le travail de migration nécessaire, l’implémentation qui reste séparée et la manière dont l’acceptation sera démontrée.
Custom Service n’est pas une promesse de recréer chaque fonctionnement de la source. C’est une méthode structurée pour obtenir le résultat exploitable et vérifiable le plus proche lorsque le fonctionnement pris en charge et les Standard Add-ons ne suffisent pas.
Questions fréquentes
Custom Service est-il réservé aux Custom Platforms ?
Non. Il s’applique également aux champs personnalisés, données tierces, identifiants externes, règles sur mesure, Tailored Add-ons, Custom Add-ons et autres besoins non standard.
Chaque champ personnalisé nécessite-t-il Custom Service ?
Pas automatiquement. La décision dépend de la prise en charge du champ, de sa signification métier, de l’endroit où il doit être représenté et du fait que le mapping disponible soit ou non suffisant.
Quelle est la différence entre Custom Service et un Standard Add-on ?
Un Standard Add-on répond à un besoin limité et pris en charge de filtrage, transformation ou mapping de champs. Custom Service traite les besoins modifiés, non pris en charge ou sur mesure qui nécessitent un périmètre adapté.
Custom Service inclut-il toujours Expert Handle ?
Non. Le projet peut rester piloté par le client. Expert Handle n’est inclus que lorsque l’exécution par des experts fait partie du périmètre accepté de Custom Service.
Custom Service peut-il reproduire exactement chaque fonctionnement de la source ?
Non. Le résultat dépend de l’état des données source, des possibilités de la plateforme cible, du périmètre accepté et des éléments requis pour l’approbation du client.
Quels éléments sont nécessaires pour une demande Custom Service ?
Des enregistrements représentatifs, la propriété et l’usage métier des données, la représentation cible attendue, les règles de transformation ou de relation, les exceptions, les systèmes associés et des exemples de validation sont nécessaires.
L’implémentation de la plateforme cible est-elle incluse automatiquement ?
Non. La conception, l’installation d’applications, le déploiement des intégrations et la configuration opérationnelle restent séparés, sauf s’ils sont expressément inclus dans le périmètre accepté.
Pourquoi le montant de Custom Service est-il un prix de départ ?
Il établit le plancher de capacité Standard Service du Entity Points Plan sélectionné. Le total final dépend du travail Custom convenu, des Add-ons, d’Expert Handle lorsqu’il est inclus et des autres coûts spécifiques au périmètre acceptés. Pour un travail accepté ultérieurement, le montant déjà payé reste reconnu et seule la différence supplémentaire est facturée.