Le processus de migration Next-Cart ne doit pas se limiter à déplacer des enregistrements d’une boutique à une autre. Il doit réduire progressivement les zones d’incertitude. Les hypothèses initiales concernant l’accès, le périmètre, la mise en correspondance et la représentation sur la cible doivent devenir des décisions vérifiables. L’exécution produit ensuite un résultat plus large, puis la validation détermine si ce résultat est réellement exploitable par l’entreprise.
Cette perspective modifie la manière de piloter le processus. La connexion n’est pas seulement un échange technique. La configuration n’est pas une simple formalité de paramétrage. Demo Migration ne constitue pas une validation définitive. Une Full Migration terminée ne vaut pas automatiquement autorisation de lancement. Chaque étape produit un type d’information différent, et la qualité de la décision finale dépend de la manière dont ces passages d’une étape à l’autre sont compris.
Dans les services de migration Next-Cart, le parcours acheté s’organise autour de la connexion, de la configuration et de la migration. Le projet complet comprend également la préparation en amont, la validation après l’exécution et les décisions de migration ultérieures lorsque la boutique source continue d’évoluer.
Définir le résultat attendu avant de déplacer les données
Le processus commence par un parcours de migration fixe entre une plateforme source et une plateforme cible. Ce parcours détermine les structures de plateforme, les exigences d’accès et les limites de la cible qui doivent être prises en compte.
Le projet doit ensuite définir ce qu’est un résultat exploitable. Les totaux d’enregistrements suffisent rarement. Les Products peuvent devoir conserver des variantes achetables. Les Customers peuvent devoir rester identifiables par groupe. Les Orders peuvent devoir conserver leur historique de statut et le contexte des lignes de commande. Le contenu peut devoir préserver des URL importantes. Les identifiants externes peuvent devoir rester reliés à un autre système.
Ces résultats deviennent des critères d’acceptation. Ils déterminent quels enregistrements doivent être échantillonnés, quelles décisions de configuration nécessitent une revue plus approfondie et quels résultats de la boutique cible doivent être classés comme Pass, Watch ou Block.
La préparation doit également identifier :
- les types de données et relations importants ;
- les enregistrements source appartenant à des applications, plugins, modules ou extensions ;
- les champs personnalisés, tables ou identifiants de systèmes externes ;
- les contenus et URL ayant une valeur commerciale ou SEO ;
- l’activité attendue de la boutique source pendant la fenêtre de migration ;
- les travaux d’implémentation de la plateforme cible qui restent distincts de la migration de données ;
- les responsables de la configuration, de l’exécution et de la validation finale.
Le processus devient fragile lorsque ces questions ne sont découvertes qu’après qu’une migration étendue a déjà été considérée comme faisant foi.
La connexion vérifie que les données sont accessibles
Les exigences de connexion prises en charge dépendent de la plateforme source et de la plateforme cible sélectionnées. En pratique, la connexion sert à vérifier si la migration peut atteindre les enregistrements et médias nécessaires au périmètre approuvé.
Une connexion KitConnect ou API peut être testée séparément pour la boutique source et la boutique cible. Cette séparation est importante pour le diagnostic. Un test réussi côté source confirme uniquement que les données source sont accessibles ; un test réussi côté cible confirme uniquement l’accès à la cible. Si un côté réussit et l’autre échoue, le projet peut se concentrer sur l’accès, les identifiants, le point de terminaison ou les conditions d’installation de la boutique en échec au lieu de traiter le parcours comme un problème de connexion unique et indifférencié.
Une connexion réussie ne prouve pas que tous les enregistrements métier importants sont disponibles. Certaines données peuvent se trouver dans des tables personnalisées, des structures gérées par une application, des fichiers exportés ou des systèmes externes. La préparation de la connexion doit donc comparer les données accessibles à l’inventaire du périmètre.
Cette comparaison peut faire apparaître très tôt une décision à prendre :
| Constat | Conséquence pour la migration |
|---|---|
| Les enregistrements requis sont accessibles via les méthodes prises en charge | La configuration peut avancer avec une meilleure confiance dans le périmètre |
| Des enregistrements importants se trouvent hors des structures de plateforme prises en charge | Une revue Custom Service ou une planification d’implémentation séparée peut être nécessaire |
| Des dépendances de médias ou de contenu sont incomplètes | La préparation doit être corrigée avant de considérer les éléments représentatifs comme fiables |
| L’accès à la cible fonctionne, mais la représentation cible requise reste incertaine | Les responsabilités de mapping et d’implémentation doivent être clarifiées avant l’exécution |
La valeur de cette étape ne tient donc pas simplement au fait que deux boutiques puissent communiquer. Elle permet de confirmer que les données réellement accessibles correspondent à ce que la migration doit prendre en charge.
La configuration transforme le périmètre en hypothèse vérifiable
La configuration traduit le plan de migration en décisions concrètes de traitement. Elle détermine les types de données pris en charge qui sont inclus, la manière dont les attributs standard s’alignent, les paramètres applicables et la nécessité éventuelle des Add-ons achetés.
À ce stade, le projet formule en pratique une hypothèse :
Si ces enregistrements sont sélectionnés, si ces mappings sont utilisés et si ces choix de configuration sont appliqués, la boutique cible devrait conserver la signification métier attendue.
Cette hypothèse doit être mise à l’épreuve avant de gouverner une exécution à grande échelle. Les questions importantes comprennent notamment :
- Les champs source et cible portent-ils la même signification ?
- Les options et variantes des Products resteront-elles achetables ?
- Les groupes Customers et les statuts Orders sont-ils correctement alignés ?
- Les valeurs de langue, localisation, inventaire, paiement ou traitement des commandes sont-elles correctement mappées ?
- Tous les enregistrements détectés doivent-ils migrer ou faut-il appliquer un filtre ?
- Une valeur prise en charge doit-elle être transformée ?
- Un champ source pris en charge doit-il être envoyé vers une autre destination compatible ?
- Une exigence dépasse-t-elle les possibilités des Add-ons disponibles ?
Les quantités saisies lors de l’achat servent à estimer les Entity Points et le prix. Elles ne constituent pas des filtres de migration. Par défaut, tous les enregistrements détectés dans les types de données sélectionnés et pris en charge sont migrés, sauf si un filtrage est configuré. Un périmètre sélectif doit donc être exprimé à l’aide de Data Filter avec des conditions basées sur les champs pour chaque type de données concerné, ou faire l’objet d’une revue comme besoin de filtrage personnalisé lorsque les possibilités standard sont insuffisantes.
La qualité de la configuration est déterminante, car un enregistrement peut être présent tout en restant inutilisable. Un Product dont les relations d’options sont erronées, un Order dont le statut n’a plus de sens ou un Customer affecté au mauvais groupe peut augmenter le nombre d’enregistrements sans améliorer le résultat de migration.
Demo Migration fournit des éléments précoces mais limités
Demo Migration constitue une source facultative d’informations précoces. Elle est surtout utile lorsque des enregistrements représentatifs sont choisis pour mettre à l’épreuve l’hypothèse de configuration.
Des enregistrements simples peuvent montrer le fonctionnement de base du transfert. Des cas difficiles peuvent révéler si la signification des données source est correctement conservée. Les échantillons utiles comprennent souvent des Products avec variantes, des Customers avec une logique de groupe importante, des Orders avec des historiques inhabituels, du contenu associé à des URL importantes ainsi que des enregistrements susceptibles de révéler des besoins de filtrage, de mapping ou de données personnalisées.
Demo Migration possède des limites définies concernant les types de données et les quantités. Les Add-ons et la Customization n’y sont pas disponibles. Le résultat peut montrer que ces possibilités seront nécessaires, mais il ne peut pas valider leur fonctionnement une fois configurées.
Après Demo Migration, la question ne doit donc pas être « les enregistrements sont apparus, le projet est prêt ». Il faut plutôt déterminer :
- quelles hypothèses ont été confortées ;
- quelles relations ou valeurs restent incertaines ;
- quelle exigence nécessite une revue d’Add-on ou de Custom Service ;
- quels échantillons doivent être retestés lors de la migration payante ;
- si le service de migration sélectionné reste adapté aux résultats observés.
L’article Demo Migration détaille ces décisions liées aux éléments de validation et à la sélection des échantillons.
Full Migration produit le résultat à plus grande échelle
Full Migration applique la configuration acceptée au périmètre sélectionné et pris en charge. C’est à ce stade que la planification et les premiers éléments de validation deviennent un résultat plus complet dans la boutique cible.
Les données de la boutique sont traitées selon une séquence fixe de types de données :
Taxes -> Manufacturers -> Categories -> Products -> Customers -> Orders -> Reviews -> Coupons -> CMS Pages -> Blog Posts
Dans chaque type de données, les enregistrements sont traités du plus ancien au plus récent selon la base de données source. Cette séquence reflète les dépendances entre données. Les Categories précèdent par exemple les Products, car le positionnement d’un Product dépend de la structure du catalogue.
La séquence de traitement des types de données ne doit pas être confondue avec la consommation d’Entity Points. Les Entity Points s’appliquent uniquement à la capacité liée aux Products, Customers, Orders et Blog Posts. Taxes, Manufacturers, Categories, Reviews, Coupons et CMS Pages peuvent faire partie de la migration sans consommer indépendamment des Entity Points.
L’exécution peut malgré tout produire des enregistrements Failed ou Skipped, des différences de mapping ou un fonctionnement de la cible qui nécessite une interprétation. Une exécution terminée signifie que le traitement est arrivé à son terme. Elle ne prouve pas que tous les résultats attendus sont satisfaisants.
La validation transforme le résultat en décision d’acceptation
La validation doit comparer la boutique cible aux critères d’acceptation définis avant l’exécution. La question n’est pas uniquement de savoir si les données existent, mais si elles permettent l’étape métier suivante attendue.
Les domaines prioritaires comprennent souvent :
- l’identité des Products, leurs options, variantes, attributs, prix, images et capacité à être achetés ;
- les relations de Categories et de navigation ;
- l’identité des Customers, leurs groupes, adresses et attentes liées aux comptes ;
- les lignes, totaux, statuts, remboursements et contexte de service des Orders ;
- les Reviews, Coupons, CMS Pages et Blog Posts lorsque cela s’applique ;
- les URL, redirections, métadonnées et la continuité du contenu ;
- les résultats affectés par le filtrage, le mapping, la transformation de valeurs ou Custom Service ;
- les identifiants et relations externes nécessaires aux systèmes connectés.
Des éléments représentatifs sont plus utiles qu’un contrôle indiscriminé. Les exemples de forte valeur, structurellement complexes ou critiques pour l’activité doivent être examinés par les personnes qui comprennent leur signification attendue.
Le client reste responsable de la vérification finale quel que soit le service de migration. L’exécution peut être pilotée par le client ou par des experts, mais l’acceptation métier reste une décision distincte.
Les actions ultérieures tiennent compte de l’évolution de la boutique source
De nombreux projets ne se terminent pas après une seule exécution. La boutique source peut continuer à recevoir des Products, Customers, Orders ou du contenu pendant que la boutique cible est préparée et validée.
Toute activité ultérieure doit commencer par le résultat attendu :
- préserver la continuité en réutilisant une configuration toujours valide ;
- poursuivre la migration tout en modifiant la configuration ;
- produire un résultat de migration distinct et entièrement nouveau.
Ces intentions correspondent aux actions suivantes :
- Continue the Migration with the Last Used Configuration
- Continue the Migration with a New Configuration
- Perform a New Migration
L’action choisie ne détermine pas à elle seule quels enregistrements source seront lus. Le comportement de lecture de la source, par exemple reprendre un traitement interrompu ou migrer uniquement les enregistrements nouvellement ajoutés, constitue une décision de configuration distincte lorsqu’elle est prise en charge et pertinente.
Chaque action ultérieure exige une validation adaptée à son objectif. Réutiliser une configuration doit confirmer que les hypothèses précédentes restent valides. Modifier la configuration doit confirmer le nouveau fonctionnement. Une nouvelle migration doit confirmer que le nouveau résultat n’a remplacé que ce que le périmètre approuvé prévoyait.
La responsabilité modifie les passages de relais, pas le niveau de validation
Le même processus peut être piloté par le client ou inclure une exécution assurée par des experts. Ce qui change, c’est la personne chargée de préparer et d’exécuter les actions convenues. Le niveau d’éléments nécessaire pour obtenir un résultat fiable ne disparaît pas.
| Répartition des responsabilités | Responsabilité principale dans le processus | Rôle requis du client |
|---|---|---|
| Exécution pilotée par le client | Préparer les accès et la configuration, exécuter les actions et coordonner le traitement des constats | Valider la boutique cible et approuver le résultat |
| Exécution pilotée par des experts | Exécuter les actions de migration convenues dans le périmètre accepté | Fournir des exigences exactes, examiner les résultats et approuver le résultat final |
Des passages de relais clairs permettent d’éviter deux erreurs opposées. La première consiste à croire qu’une exécution assurée par des experts transfère également la responsabilité de l’acceptation métier. La seconde consiste à considérer que la validation par le client annule la valeur de l’exécution experte. Il s’agit de responsabilités différentes, et les deux sont nécessaires.
Conclusion
Le processus de migration Next-Cart transforme progressivement l’incertitude en éléments vérifiables. La préparation définit le résultat attendu. La connexion vérifie si les données nécessaires sont accessibles. La configuration transforme le périmètre en hypothèse vérifiable. Demo Migration peut tester cette hypothèse avec des cas représentatifs. Full Migration produit le résultat à plus grande échelle. La validation détermine si la boutique cible est exploitable, et les actions ultérieures maintiennent l’alignement du résultat lorsque les conditions du projet changent.
Traiter chaque étape comme un point de contrôle évite de confondre une exécution terminée avec un résultat de migration accepté. Cela facilite également le diagnostic, car le projet peut identifier si la faiblesse provient du périmètre, de l’accès, de la configuration, de l’exécution ou de la validation.
Questions fréquentes
Quelles sont les principales étapes du processus de migration ?
Le parcours acheté repose principalement sur la connexion, la configuration et la migration. Le projet complet comprend également la définition du résultat, la préparation, les éléments représentatifs, la validation et les décisions de migration ultérieures.
Les quantités de types de données saisies lors de l’achat limitent-elles ce qui migre ?
Non. Elles servent à estimer les Entity Points et à sélectionner le plan. Par défaut, tous les enregistrements détectés dans les types de données sélectionnés et pris en charge sont migrés, sauf si un filtrage est configuré.
Quelle est la séquence fixe de traitement des types de données ?
La séquence est Taxes, Manufacturers, Categories, Products, Customers, Orders, Reviews, Coupons, CMS Pages et Blog Posts.
La séquence de traitement des types de données correspond-elle à la consommation d’Entity Points ?
Non. La séquence de traitement définit l’ordre dans lequel les données prises en charge sont traitées. Les Entity Points ne concernent que la capacité comptabilisée pour Products, Customers, Orders et Blog Posts.
Une Full Migration terminée signifie-t-elle que la boutique cible est prête ?
Non. La fin de l’exécution signifie uniquement que le traitement est terminé. La validation doit encore confirmer que les enregistrements, les relations, le contenu et les résultats métier respectent les critères d’acceptation.
Pourquoi les actions de migration ultérieures sont-elles distinctes du comportement de lecture de la source ?
L’action détermine si la configuration est réutilisée, modifiée ou remplacée par un nouveau résultat. Le comportement de lecture détermine quels enregistrements sont lus, par exemple les nouveaux enregistrements ou ceux dont le traitement avait été interrompu, lorsque ces options sont prises en charge.