Le choix de l’approche de migration vers ShopWired doit dépendre de la manière dont la boutique devra fonctionner après le lancement. Le volume d’enregistrements compte, mais il ne doit pas être le seul facteur de décision. Une petite boutique source peut nécessiter une prise en charge attentive si elle dépend d’options Product complexes, de tarification B2B, de champs personnalisés, d’intégrations ou de fonctionnements appartenant à des applications. Une boutique plus volumineuse peut au contraire suivre une approche plus simple si ses structures de données sont prises en charge et si la responsabilité de validation est claire.
La bonne approche doit expliquer cinq éléments : ce qui peut être migré comme enregistrements pris en charge, ce qui doit être configuré dans ShopWired, ce qui nécessite des Add-ons, ce qui doit être examiné dans le cadre de Custom Service, et ce que Demo Migration doit démontrer avant Full Migration. Lorsque ces décisions sont prises tôt, la planification d’une migration ShopWired devient une décision de périmètre contrôlée plutôt qu’un exercice de dépannage tardif.
Dans les services de migration Next-Cart, les éléments propres à ShopWired doivent déterminer le parcours de données pris en charge, la responsabilité d’exécution, l’adéquation des Add-ons et les éventuels besoins personnalisés liés au B2B, aux applications ou aux intégrations.
Ce que doit contrôler la décision d’approche
L’approche d’une migration ShopWired doit contrôler la responsabilité d’exécution, le niveau d’accompagnement, les hypothèses de périmètre, les besoins de configuration et la profondeur de validation. Elle ne doit pas être choisie uniquement pour des raisons de commodité ou de nombre d’enregistrements.
| Domaine de décision | Ce qu’il faut évaluer | Pourquoi c’est important |
|---|---|---|
| Adéquation des données prises en charge | Products, Categories, marques, Customers, Orders, Reviews, Coupons, CMS Pages et autres enregistrements éligibles. | Confirme si un périmètre de migration ordinaire est réaliste. |
| Complexité du catalogue | Variations, Choices, Extras, bundles, Products numériques, précommandes, abonnements, stock, tarification, fiscalité et champs SEO. | Détermine si le catalogue nécessite un transfert simple, une mise en correspondance, de la configuration ou un examen personnalisé. |
| Fonctionnement B2B | Customer Groups, comptes B2B, tarification, Products restreints, Quotes, conditions de compte et parcours de commande. | Détermine si la configuration cible et une validation spécifique sont nécessaires. |
| Dépendances aux applications et intégrations | Applications, champs personnalisés, connexions API, webhooks, flux, ERP, POS, comptabilité, CRM, traitement des commandes et marketplaces. | Identifie les données qui peuvent ne pas appartenir aux données standard de la boutique. |
| Responsabilité du lancement | Qui prépare, configure, examine, exécute les actions disponibles et valide les résultats finaux. | Évite la confusion sur le parcours de service pendant Demo Migration et Full Migration. |
L’approche pratique est la plus légère qui protège encore le résultat. Un accompagnement insuffisant peut exposer le marchand à des risques de lancement évitables. Un accompagnement excessif peut ralentir le projet sans apporter de valeur supplémentaire.
Quand Standard Service peut suffire
Standard Service peut convenir lorsque la migration reste dans un périmètre pris en charge et que le marchand peut préparer, examiner, configurer et valider la boutique cible avec assurance. Pour ShopWired, cela signifie généralement que la structure du catalogue est claire, que les options Product ne nécessitent pas de transformation inhabituelle, que l’identité Customer est suffisamment propre, que les Orders historiques restent lisibles et que les paramètres du parcours de commande cible peuvent être configurés par le marchand.
| Signal d’adéquation à Standard Service | Ce que cela signifie généralement |
|---|---|
| Les Products utilisent des structures simples. | Noms Product, descriptions, images, prix, stock, Categories, marques et champs SEO peuvent être vérifiés sans interprétation particulière. |
| Les variations sont ordinaires et restent dans les limites attendues. | Noms d’options, valeurs, combinaisons, SKU, stocks, images et prix peuvent être validés à partir d’échantillons représentatifs. |
| Les Customers sont suffisamment propres pour être contrôlés à partir de l’identité e-mail. | Les cas d’e-mail dupliqué, partagé ou modifié ne sont pas centraux pour les opérations. |
| Les Orders historiques servent surtout de référence et non à continuer des processus complexes. | Les champs de paiement, livraison, remise, remboursement, fiscalité et notes restent lisibles sans transformation avancée. |
| La configuration cible appartient au marchand. | Paiements, livraison, fiscalité, e-mails, thème, applications et paramètres de compte peuvent être configurés séparément par le marchand. |
Standard Service n’est pas une approche de moindre qualité. C’est l’approche correcte lorsque le périmètre est pris en charge et que le marchand peut gérer la préparation et la validation. Elle devient risquée uniquement lorsque des fonctionnements non pris en charge sont traités comme des données ordinaires ou lorsque le marchand attend de Next-Cart qu’il prenne en charge des décisions hors du périmètre sélectionné.
Quand Managed Service constitue l’approche la plus sûre
Managed Service est utile lorsque la migration reste dans les capacités prises en charge mais que le marchand a besoin d’une coordination opérationnelle plus forte. Cela peut être pertinent lorsque le périmètre n’est pas personnalisé, mais que l’entreprise a besoin d’accompagnement pour la sélection des échantillons, le calendrier, les dépendances de configuration et l’examen des résultats.
| Signal en faveur de Managed Service | Pourquoi une coordination supplémentaire aide |
|---|---|
| Les enregistrements catalogue sont pris en charge mais nombreux ou variés. | Un examen plus structuré est nécessaire pour maintenir Products, Categories, marques, images, stock et SEO alignés. |
| Le fonctionnement B2B est important mais dépend surtout de la configuration cible. | Le marchand a besoin d’une séparation plus claire entre les données Customer migrées et le fonctionnement B2B configuré. |
| Demo Migration doit tester plusieurs catégories de risque. | La sélection et l’examen des échantillons doivent être coordonnés entre Products, Customers, Orders, SEO et intégrations. |
| Le calendrier de lancement est serré. | Le calendrier des actions de migration, les changements dans la boutique source et les responsabilités de validation doivent être contrôlés. |
| Le marchand dispose de peu de capacité pour examiner la migration. | Un processus guidé réduit le risque de découvrir des problèmes trop tard. |
Managed Service ne doit pas servir à masquer des exigences non prises en charge. Si la boutique dépend de données appartenant à des applications, de transformations personnalisées, de fonctionnements Product non standard, d’identifiants externes ou d’une analyse de Custom Platform, l’exigence doit être cadrée via Custom Service.
Quand envisager des Add-ons
Les Add-ons sont utiles lorsque la migration reste dans les capacités prises en charge mais nécessite un filtrage d’enregistrements propre à un type de données, une transformation des valeurs de champs à partir d’expressions ou une nouvelle mise en correspondance de champs source. Ils ne doivent pas être utilisés comme solution générique pour des données d’application non prises en charge ou une logique sur mesure.
| Besoin d’Add-on | Exemple ShopWired | Interprétation correcte |
|---|---|---|
| Data Filter | Appliquer des conditions sur des champs pris en charge de Product, Customer, Order, Coupon, Review ou CMS Page afin que seuls les enregistrements correspondants soient migrés. | Le marchand définit l’entité, le champ, la condition et la règle d’inclusion ou d’exclusion. |
| Data Transformation | Appliquer des expressions pour transformer les valeurs de champs pris en charge pendant la migration. | L’expression, les valeurs d’entrée et les sorties compatibles avec la cible restent dans les capacités prises en charge. |
| Advanced Data Mapping | Mettre en correspondance des champs source pris en charge avec des champs cible ShopWired compatibles. | Les significations source et destination sont claires et aucun fonctionnement non pris en charge n’est sous-entendu. |
Pour ShopWired, les Add-ons sont particulièrement utiles lorsque des enregistrements pris en charge doivent être inclus sélectivement, lorsque des valeurs de champs doivent être transformées selon une règle définie ou lorsque des champs source doivent aller vers d’autres destinations. Ils conviennent moins lorsque le problème appartient à une logique d’application, à une dépendance de système externe ou à un fonctionnement Product non pris en charge.
Quand examiner Custom Service
Custom Service doit être envisagé lorsque la migration dépend de structures non prises en charge, de données appartenant à des applications, de champs personnalisés dont le traitement requis dépasse le périmètre de mise en correspondance pris en charge, d’identifiants externes, d’une transformation sur mesure, d’une Custom Platform ou d’un ajustement personnalisé de la logique de migration. Il ne s’agit pas simplement d’une version plus coûteuse d’une migration ordinaire : c’est un parcours d’examen pour les exigences nécessitant une analyse directe.
| Signal de Custom Service | Pourquoi la prise en charge standard peut être insuffisante |
|---|---|
| Les options Product ne correspondent pas aux variations, Choices, Extras ou configurations ordinaires prises en charge. | La logique d’achat peut nécessiter une transformation ou des recommandations de reconstruction. |
| Bundles, kits, abonnements, précommandes ou Products personnalisés portent des règles métier critiques. | Les enregistrements Product standard peuvent ne pas préserver le fonctionnement opérationnel. |
| Les règles Customer, B2B ou tarifaires dépendent de champs personnalisés ou de systèmes externes. | Les données peuvent nécessiter une mise en correspondance, un enrichissement ou un traitement spécifique. |
| Les Orders contiennent des identifiants externes, références comptables, références de traitement des commandes ou données de processus marketplace. | La lisibilité historique peut dépendre de champs non gérés comme des données d’Order ordinaires. |
| Des applications créent des enregistrements ou une logique que le marchand veut préserver. | Les données appartenant aux applications ne sont pas automatiquement équivalentes aux données natives de la plateforme. |
| Une Custom Platform intervient dans le parcours. | Les structures de données doivent être inspectées avant de pouvoir faire confiance au périmètre et à la mise en correspondance. |
Les décisions de Custom Service doivent partir d’exemples. Le marchand doit fournir des Products représentatifs, des enregistrements Customer, des Orders, exports d’applications, champs personnalisés dont le traitement dépasse la mise en correspondance prise en charge, identifiants externes et résultat attendu. Sans exemples, la discussion reste trop abstraite pour décider du périmètre de manière fiable.
Comment Demo Migration doit déterminer l’approche
Demo Migration doit vérifier si l’approche choisie est suffisamment robuste. Elle ne doit pas être jugée uniquement sur le fait que quelques enregistrements apparaissent dans ShopWired. Elle doit montrer si la boutique cible peut représenter le véritable modèle métier.
| Échantillon de Demo Migration | Décision qu’il doit permettre |
|---|---|
| Product simple | Confirme le traitement de base du Product, de l’image, de la Category, de la marque, du prix, du stock et du SEO. |
| Product riche en variations | Confirme noms d’options, valeurs, combinaisons, SKU, stocks, images, poids, GTIN, MPN et comportement fiscal. |
| Product avec Choices, Extras ou personnalisation | Montre si le Product peut être configuré, mis en correspondance ou nécessite un examen via Custom Service. |
| Customer B2B | Confirme l’identité Customer, les attentes de compte, les hypothèses de tarification et la visibilité de l’historique des Orders. |
| Order historique complexe | Confirme que remises, remboursements, libellés de paiement et livraison, taxes, notes, traitement des commandes et références externes restent lisibles. |
| Page de contenu ou SEO | Confirme que les hypothèses liées aux CMS Pages, Blog Posts, métadonnées, menus et redirections sont réalistes. |
| Enregistrement dépendant d’une application ou intégration | Montre si les identifiants externes, champs personnalisés, relations API ou données appartenant aux applications sont dans le périmètre. |
Si Demo Migration révèle une incompatibilité, la bonne réponse consiste à ajuster le périmètre avant Full Migration. Le parcours sélectionné doit évoluer lorsque les éléments observés évoluent.
Entity Points et planification du périmètre
Les Entity Points aident à estimer le volume de migration éligible. Ils ne déterminent pas si une migration ShopWired est simple ou complexe. Pour ShopWired, les enregistrements Product, Customer, Order et Blog Posts éligibles peuvent consommer des Entity Points lors de leur première migration, tandis que les enregistrements déjà comptabilisés sur le même parcours restent comptés une seule fois ; la complexité liée à la tarification B2B, aux Product Choices, applications et intégrations est évaluée séparément. Les nouveaux enregistrements éligibles peuvent consommer des Entity Points lorsqu’ils sont migrés pour la première fois.
Pour ShopWired, les Entity Points doivent être examinés avec la structure et la complexité.
| Signal de périmètre | Ce que les Entity Points aident à estimer | Ce qu’ils ne prouvent pas |
|---|---|---|
| Nombre de Products | Volume potentiel de Products éligibles. | Si variations, Choices, Extras, bundles, images, stock, fiscalité et sens SEO sont adaptés. |
| Nombre de Customers | Volume potentiel de Customers éligibles. | Si identité e-mail, comptes B2B, champs personnalisés et relations avec les Orders sont propres. |
| Nombre d’Orders | Volume potentiel d’Orders éligibles. | Si le contexte de paiement, livraison, fiscalité, remboursement, remise, notes et systèmes externes reste utile. |
| Nombre de Blog Posts | Volume potentiel de contenu éligible lorsque pertinent. | Si URL, redirections, métadonnées, placement dans le thème et présentation du contenu sont prêts pour le lancement. |
Une boutique avec peu d’enregistrements peut nécessiter Custom Service si ses données sont structurellement inhabituelles. Une boutique très volumineuse peut suivre un parcours pris en charge si ses données sont propres et si la validation est bien préparée.
Additional Migration Options pour ShopWired
Un lancement ShopWired peut nécessiter une activité de migration supplémentaire lorsque la plateforme source continue d’évoluer après Demo Migration ou une première Full Migration. L’action correcte doit être choisie selon le résultat attendu, et non par commodité. Products, variations, Choices, Extras, Customers B2B, Orders, Blog Posts, stock, contenu et identifiants liés aux intégrations peuvent nécessiter des validations différentes selon que la configuration précédente est conservée ou modifiée.
| Additional Migration Option | Quand elle convient à ShopWired | Ce qui doit être revalidé |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Les filtres, mises en correspondance et configurations de données prises en charge précédents restent corrects, et la boutique a principalement besoin de nouveaux enregistrements éligibles ou de changements source ultérieurs. | Nouveaux Products, variations, Choices, Extras, Customers, Customers B2B, Orders, contenus et un échantillon de régression des données déjà migrées. |
| Continue the Migration with a New Configuration | Demo Migration ou l’examen métier montre que le filtrage, la mise en correspondance de champs prise en charge, le périmètre de contenu, la gestion des Customers ou la configuration Product doivent changer. | Chaque structure de sélection Product, entrée de tarification B2B, champ personnalisé, type de Customer, champ d’Order, URL et domaine de contenu affecté par la nouvelle configuration. |
| Perform a New Migration | Le résultat cible précédent ne doit plus servir de base de travail, l’environnement cible a été réinitialisé ou le périmètre a changé de manière importante. | Tout le périmètre accepté, le fonctionnement de remplacement, l’utilisabilité Product, les relations Customer et B2B, l’historique des Orders, les contenus, URL et limites de configuration côté cible. |
Les Entity Points doivent être vérifiés avant l’action, mais ils ne doivent pas être confondus avec la complexité de ShopWired.
L’action choisie détermine aussi la charge de validation. Une continuation avec la même configuration nécessite un examen ciblé des nouveaux enregistrements ainsi que des échantillons de régression. Une continuation avec une nouvelle configuration nécessite des éléments montrant que la règle modifiée améliore le résultat attendu sans détériorer les données non concernées. Une nouvelle migration exige une revalidation plus large puisque le résultat cible est reconstruit. Implémentation du thème, paiements, livraison, fiscalité, configuration B2B, applications, identifiants API et processus des systèmes externes restent des responsabilités côté cible ou faisant l’objet d’un périmètre séparé.
Critères de décision du parcours de service ShopWired
Le parcours de service final ne doit être approuvé qu’après quatre contrôles propres à ShopWired. Premièrement, le contrôle Product doit démontrer que variations, Choices, Extras, bundles, stocks, images et tarification restent utilisables. Deuxièmement, le contrôle Customer doit distinguer acheteurs ordinaires et Customers B2B et confirmer si les relations de compte, groupe et tarification sont prises en charge. Troisièmement, le contrôle opérationnel doit séparer les Orders historiques de la configuration des paiements, de la livraison, de la fiscalité, du thème, des applications et intégrations. Quatrièmement, le contrôle de responsabilité doit identifier qui configurera la cible, validera le résultat migré et rétablira les processus externes.
| Contrôle de décision | Éléments Standard ou Managed | Signal de périmètre Custom |
|---|---|---|
| Structure Product | Des Products représentatifs restent vendables via les structures ShopWired prises en charge. | La logique source dépend de builders non pris en charge, d’enregistrements appartenant à des applications ou d’une transformation sur mesure. |
| Commerce B2B | Les Customers B2B et entrées tarifaires prises en charge ont un sens cible clair. | La logique contractuelle, la hiérarchie de compte ou les données tarifaires personnalisées n’ont pas de destination prise en charge. |
| Opérations | Les Orders historiques sont lisibles et la configuration cible a un responsable distinct. | Des identifiants externes ou enregistrements de processus sont nécessaires au traitement des commandes, à la comptabilité ou au support. |
| Capacité de validation | Le marchand peut approuver des échantillons représentatifs et contrôles de régression. | L’acceptation ne peut pas être définie sans analyse sur mesure ou Expert Handle. |
Ces contrôles empêchent Managed Service d’être utilisé comme substitut à un périmètre mal défini et Custom Service d’être sélectionné simplement parce que la boutique semble complexe. Le parcours pratique est l’organisation de service la plus légère qui peut satisfaire les quatre contrôles avec des éléments concrets.
Choisir entre les principaux parcours
La décision doit rester pratique. Elle doit protéger le marchand contre les risques évitables sans alourdir inutilement le service. Utilisez la carte suivante comme contrôle final.
| Si la migration ShopWired ressemble à ceci | Parcours plus adapté à envisager |
|---|---|
| Enregistrements pris en charge, catalogue propre, Customers ordinaires, historique d’Orders lisible et configuration pilotée par le marchand. | Standard Service. |
| Enregistrements pris en charge mais pression plus forte sur la coordination, le calendrier de lancement ou capacité de validation limitée. | Managed Service. |
| Les enregistrements pris en charge nécessitent des conditions propres à certains types de données, des transformations de valeurs par expression ou des destinations de champs cible compatibles. | Data Filter, Advanced Data Mapping ou Data Transformation. |
| Des exigences non prises en charge, personnalisées, appartenant à des applications, liées à des systèmes externes, à une Custom Platform ou à des transformations sur mesure existent. | Custom Service. |
| Le périmètre est incertain parce que les échantillons sont faibles. | Renforcer les échantillons de Demo Migration avant de s’engager sur Full Migration. |
Un choix fiable peut être résumé en quatre déclarations : quels enregistrements seront migrés, quels paramètres ShopWired doivent être configurés séparément, quels besoins d’Add-ons ou de Custom Service sont inclus et quels résultats d’échantillons doivent être validés avant Full Migration.
Signaux indiquant que l’approche choisie est trop légère
Une approche ShopWired est trop légère lorsqu’elle traite la logique métier comme un simple mouvement d’enregistrements. Les signaux apparaissent généralement dans les options Product, le fonctionnement B2B, l’identité Customer, les dépendances aux applications, les identifiants externes ou la configuration cible.
| Signal d’alerte | Réponse probable |
|---|---|
| Les Products complexes n’ont pas été inclus dans Demo Migration. | Ajouter des échantillons de variations, Choices, Extras, bundles, stocks, fiscalité, images et SEO. |
| Les règles B2B sont décrites de manière générale mais pas échantillonnées. | Fournir des Customers B2B, exemples de tarification, conditions de compte, Products restreints et Orders associés. |
| Les champs personnalisés sont importants mais non classés. | Déterminer s’ils relèvent de la mise en correspondance prise en charge, de données appartenant à une application, de références externes ou du périmètre Custom Service. |
| La configuration des paiements, livraisons et taxes est supposée provenir de l’historique des Orders. | Séparer la lisibilité historique de la configuration cible. |
| Les dépendances API, webhook, flux, ERP, POS ou marketplace ne sont pas documentées. | Construire une carte d’intégration et examiner les besoins d’identifiants externes. |
| Les Entity Points sont utilisés comme seule mesure de périmètre. | Examiner le sens des données et la complexité structurelle en plus du volume. |
Ces signaux doivent être traités avant Full Migration. Le lancement est le mauvais moment pour découvrir que l’approche choisie ne correspond pas au modèle opérationnel de la boutique.
Conclusion
La bonne approche de migration vers ShopWired est celle qui correspond à la structure métier réelle de la boutique. Standard Service peut suffire aux migrations prises en charge et pilotées par le marchand. Managed Service est utile lorsque la pression de coordination est plus forte mais que le périmètre reste pris en charge. Les Add-ons aident lorsque des enregistrements éligibles nécessitent un filtrage, une transformation de valeurs ou une nouvelle mise en correspondance de champs. Custom Service est nécessaire lorsque des exigences non prises en charge, personnalisées, appartenant à des applications, liées à des systèmes externes ou nécessitant une transformation sur mesure influencent le résultat.
Une décision solide dépend des éléments observés. Le marchand doit utiliser la préparation et les échantillons de Demo Migration pour démontrer le fonctionnement des options Product, du B2B, de l’identité Customer, la lisibilité des Orders historiques, la continuité SEO, les dépendances applicatives, la planification des Entity Points et le calendrier de lancement avant de s’engager sur Full Migration.
Questions fréquentes
Quand Standard Service suffit-il pour une migration ShopWired ?
Standard Service peut suffire lorsque la migration reste dans le périmètre pris en charge, que les structures Product sont claires, que les données Customer et Order sont maîtrisables, que les paramètres cible peuvent être configurés par le marchand et que celui-ci peut valider les résultats avec assurance.
Quand envisager Managed Service pour une migration ShopWired ?
Managed Service est utile lorsque le périmètre reste pris en charge mais que le marchand a besoin d’une coordination plus forte, d’un examen des échantillons, d’un soutien à l’exécution, d’un contrôle du calendrier ou d’aide pour organiser la validation du catalogue, des Customers, Orders, du SEO et des intégrations.
En quoi les Add-ons diffèrent-ils de Custom Service dans une migration ShopWired ?
Les Add-ons ajustent le filtrage d’enregistrements pris en charge, la transformation des valeurs de champs ou la mise en correspondance de champs. Custom Service couvre les structures non prises en charge, données appartenant aux applications, champs personnalisés dont le traitement requis dépasse la mise en correspondance prise en charge, identifiants externes, Custom Platform, transformations sur mesure ou ajustements personnalisés de logique de migration.
Comment les Additional Migration Options doivent-elles influencer l’approche sélectionnée ?
Utilisez l’option correspondant au résultat requis. Conservez la configuration précédente lorsqu’elle reste correcte, utilisez une nouvelle configuration lorsque les règles de migration prises en charge doivent changer, et utilisez Perform a New Migration lorsque le résultat cible doit repartir sur une nouvelle base. Revalidez les enregistrements et relations affectés par ce choix.
La migration configure-t-elle la tarification B2B, la livraison, les paiements et le fonctionnement du thème dans ShopWired ?
Pas automatiquement. Les enregistrements Customer et Product peuvent être migrés dans le périmètre convenu, mais les paramètres B2B actifs, tarifs de livraison, identifiants de paiement, configuration fiscale, applications et fonctionnement du thème restent des responsabilités côté cible sauf s’ils sont explicitement inclus.