Il est facile de sous-estimer un service de migration Next-Cart si on le résume à un paiement et à un transfert. Le client achète une migration qui reste l’unité de référence du service. Son parcours de migration fixe, sa durée d’un an, sa capacité comptabilisée, la responsabilité d’exécution, les améliorations prises en charge et les éventuels besoins adaptés se combinent pour façonner le résultat.
Ces décisions sont liées, mais elles ne sont pas interchangeables. Une grande boutique peut avoir des données prévisibles et convenir à une migration pilotée par le client. Une boutique plus petite peut dépendre de champs personnalisés ou d’enregistrements tiers dont le traitement requis dépasse le périmètre de migration pris en charge ou celui des Standard Add-ons. Un Add-on peut résoudre un besoin de mise en correspondance limité sans changer l’ensemble du service de migration. Les Entity Points peuvent couvrir le volume de données comptabilisé sans prouver que leur représentation sur la cible sera utilisable.
La meilleure manière de comprendre les services de migration Next-Cart consiste donc à considérer la migration achetée comme un ensemble de composantes coordonnées. Chacune répond à une question différente du projet. Les upgrades ultérieurs sont intégrés à cette même migration au lieu de créer des services indépendants, de sorte que la migration reste le contexte stable pour la planification, l’exécution et la validation.
Commencer par le résultat attendu de la migration
Le parcours de migration définit une direction fixe et à sens unique, d’une plateforme source vers une plateforme cible. Cette direction ne constitue pas un simple détail d’acheminement. Elle détermine les structures de plateforme à interpréter, les exigences de connexion à préparer et les limites de la cible susceptibles d’affecter le résultat.
Avant d’examiner la capacité ou le prix, le résultat attendu doit être clair. Le projet peut exiger que les produits restent achetables, que les historiques clients restent utiles, que les commandes conservent le contexte nécessaire au service client, que le contenu préserve sa valeur SEO ou que les identifiants externes restent reliés à un autre système. Ces résultats déterminent ce que la migration doit préserver et les éléments qui devront ensuite être validés.
Une migration achetée couvre un seul parcours de la plateforme source vers la plateforme cible. Ce parcours ne peut pas être modifié après l’achat. Le service reste disponible pendant un an à compter de l’achat initial, sous réserve de la capacité choisie, du service de migration, des Add-ons achetés, du périmètre personnalisé convenu et des responsabilités de validation.
L’upgrade d’un composant ne crée pas un nouveau parcours et ne redémarre pas la durée d’un an. Il modifie la migration existante, tandis que la date d’achat initiale continue de définir la période de service. Une migration expirée doit être prolongée avant de pouvoir reprendre toute activité éligible.
Séparer les décisions au sein d’une même migration achetée
Une migration achetée rassemble généralement plusieurs décisions de planification. Le tableau suivant est particulièrement utile une fois le résultat attendu et le parcours de migration compris, car il montre la question à laquelle chaque composant doit répondre.
| Composant | Question du projet à laquelle il répond | Ce qu’il ne détermine pas |
|---|---|---|
| Parcours de migration | Quelle direction fixe de la plateforme source vers la plateforme cible est couverte ? | Si le modèle de données est simple ou si le résultat est acceptable |
| Durée du service | Pendant combien de temps la migration achetée reste-t-elle active à compter de son achat initial ? | Si un upgrade modifie le parcours ou redémarre la durée |
| Entity Points Plan | Quelle capacité comptabilisée est disponible pour produits, clients, commandes et articles de blog ? | Si le projet nécessite Managed Service ou Custom Service |
| service de migration | Qui est responsable de l’exécution, et le besoin reste-t-il dans le périmètre pris en charge ou exige-t-il un traitement adapté ? | Quelle capacité comptabilisée est nécessaire |
| Add-ons | Un besoin limité de filtrage, de mise en correspondance de champs ou de colonnes de base de données, ou de transformation de valeurs cibles peut-il être pris en charge par une amélioration disponible ? | Si des travaux plus larges, non pris en charge ou sur mesure sont couverts |
| Périmètre personnalisé convenu | Quelles données, règles, relations ou sorties non standard nécessitent un travail adapté ? | La mise en œuvre sur la plateforme cible, sauf inclusion explicite |
La confusion apparaît souvent lorsqu’une ligne du tableau est utilisée pour répondre à la question d’une autre. La taille de la boutique sert de substitut à l’adéquation du service. Une faible estimation d’Entity Points est interprétée comme une preuve de simplicité. On attend d’un Add-on qu’il résolve un modèle de données personnalisé. On suppose que Managed Service inclut tous les besoins non standard. Aucun de ces raisonnements ne découle du composant concerné.
La capacité décrit le volume, pas la complexité
Les Entity Points convertissent quatre types de données comptabilisés en capacité pondérée :
- produit ;
- client ;
- commande ;
- articles de blog.
L’Entity Points Plan choisi doit fournir suffisamment de capacité pour le besoin comptabilisé réaliste. Il s’agit d’une décision de volume. La complexité peut néanmoins provenir de produits dotés de structures d’options inhabituelles, d’enregistrements appartenant à des applications, d’attributs clients personnalisés, d’identifiants commandes externes, de relations multilingues ou de limites propres à la cible.
Prenons deux boutiques ayant la même estimation d’Entity Points. La première utilise des enregistrements standard de plateforme et des relations prévisibles. La seconde stocke des prix contractuels dans des tables personnalisées et dépend d’un identifiant externe pour relier les commandes à un ERP. Leur capacité comptabilisée peut être identique alors que leurs besoins de migration ne le sont pas. La planification de la capacité doit donc accompagner l’analyse structurelle, et non la remplacer.
Le calcul détaillé des pondérations et les règles de consommation sont expliqués dans Entity Points. Les capacités des plans, les prix d’upgrade et les prix d’extension sont expliqués dans Plan Entity Points et tarification de la migration.
La responsabilité d’exécution et le périmètre sont deux dimensions distinctes
Le choix du service de migration combine deux questions différentes :
- Le résultat attendu reste-t-il dans le fonctionnement de migration pris en charge, ou nécessite-t-il un travail adapté ?
- Qui doit effectuer les actions de migration convenues ?
Standard Service et Managed Service couvrent tous deux des besoins de migration pris en charge. Leur principale différence est la responsabilité d’exécution. Standard Service suit une approche pilotée par le client. Managed Service inclut une exécution par des experts des actions de migration convenues dans le périmètre pris en charge.
Custom Service couvre les besoins adaptés ou non standard. Il peut rester piloté par le client, ou inclure Expert Handle lorsque l’exécution des actions convenues doit elle aussi faire partie du périmètre personnalisé.
Cette distinction évite une erreur fréquente : considérer Managed Service comme la réponse à des données non prises en charge. Une exécution par des experts ne transforme pas une structure personnalisée en structure standard. Inversement, un besoin personnalisé ne signifie pas automatiquement qu’une exécution par des experts est nécessaire.
Standard Service, Managed Service et Custom Service détaille ces définitions. Choisir le service de migration adapté explique comment choisir à partir des éléments concrets du projet.
Considérer la migration comme l’enregistrement de référence du service
La migration achetée et les paiements qui lui sont liés répondent à des questions différentes. La migration représente l’état actuel du service : son parcours fixe, le service de migration sélectionné, l’Entity Points Plan, les Add-ons, les travaux personnalisés acceptés, la durée du service et l’historique de migration. Les commandes constituent l’enregistrement commercial de la manière dont cet état a été acheté, mis à niveau ou prolongé.
L’achat initial crée la migration. Un upgrade ultérieur de plan, de service, d’Add-on ou de travaux personnalisés est intégré à cette même migration une fois acheté. Cette distinction explique pourquoi une migration peut avoir plusieurs commandes associées sans devenir plusieurs services de migration indépendants.
Elle clarifie également la tarification ultérieure. Un upgrade est calculé par rapport à la valeur déjà payée pour la migration : le client paie donc uniquement la différence supplémentaire au lieu de racheter l’ensemble du forfait. La prolongation d’une migration expirée est différente : elle rétablit le service à partir du dernier état conservé de la migration, y compris les composants applicables déjà intégrés.
Cette distinction est importante pour la planification du service, car la continuité suit la migration achetée, tandis que chaque paiement reste rattaché au changement commercial qu’il enregistre.
Utiliser les Add-ons pour des besoins bien délimités
Les Add-ons sont particulièrement utiles lorsque le parcours de migration est pris en charge mais qu’une partie définie du résultat nécessite un contrôle supplémentaire. Les quatre Standard Add-ons répondent à différents types de besoins délimités :
- Data Filter sélectionne les enregistrements à migrer en appliquant des conditions fondées sur des champs pour 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, y compris des champs propres à une plateforme ou personnalisés, uniquement lorsque la plateforme source et la plateforme cible sont toutes deux Open-Source.
- Data Transformation transforme les valeurs de certains champs cibles pendant la migration des enregistrements de la boutique source vers la boutique cible.
La limite est importante. Les Standard Add-ons sont compatibles avec les trois services de migration lorsqu’un Add-on disponible correspond déjà au besoin. Si l’Add-on lui-même doit être modifié, le besoin devient un Tailored Add-on sous Custom Service. Si aucun Standard Add-on ne correspond, un Custom Add-on ou une revue plus large sous Custom Service peut être nécessaire.
La décision doit commencer par le résultat attendu, pas par le nom d’un Add-on. « Migrer uniquement les commandes postérieurs à une date approuvée » décrit un résultat qui peut être filtré. « Préserver un moteur de tarification propriétaire » décrit un problème personnalisé plus large dont il faut d’abord définir le sens métier, les relations et le fonctionnement cible.
Transformer les premiers résultats en éléments de décision
Demo Migration peut fournir des résultats représentatifs en amont avant une activité de migration plus large. Sa valeur tient moins au fait de voir apparaître des enregistrements qu’au choix d’échantillons capables de révéler des différences significatives.
Un bon échantillon peut inclure un produit avec des variantes et des attributs particuliers, un commande avec un historique de statuts inhabituel, un client utilisé dans un véritable processus de segmentation ou un contenu dont les URL ont une valeur importante. Les enregistrements simples peuvent montrer qu’un parcours de base fonctionne. Les enregistrements difficiles montrent si les hypothèses de migration sont suffisamment solides.
Demo Migration comporte des limites définies, et les Add-ons ainsi que la Customization n’y sont pas disponibles. Le résultat peut révéler un besoin probable d’amélioration prise en charge ou de travail adapté, mais il ne peut pas prouver comment cette configuration ultérieure se comportera. Demo Migrationexplique comment choisir les éléments à tester et interpréter ces limites.
Distinguer l’exécution de l’acceptation
L’exécution produit un résultat de migration. La validation détermine si ce résultat est exploitable pour l’entreprise.
La revue finale doit aller au-delà de la présence des enregistrements. Elle doit confirmer que les produits importants conservent le sens nécessaire à l’achat, que les clients et commandes restent utiles, que le contenu et les URL soutiennent le parcours prévu, que les relations relient toujours les bons enregistrements et que toute sortie issue d’un Add-on ou d’un travail personnalisé correspond au périmètre accepté.
Le client reste responsable de la vérification finale quel que soit le service de migration. Cela ne signifie pas que la responsabilité d’exécution lui est retransférée. Il s’agit d’une autre forme de responsabilité : seule l’entreprise peut confirmer que la boutique cible répond aux résultats commerciaux, opérationnels, SEO et de conformité attendus.
La configuration de la plateforme cible, les travaux de thème, l’installation d’applications, le déploiement d’intégrations et les autres travaux de mise en œuvre doivent être identifiés séparément, sauf s’ils sont expressément inclus dans le périmètre convenu. Le fait qu’un enregistrement soit correctement migré ne configure pas à lui seul le système qui l’utilisera.
Utiliser cette section comme un système de décision
Les articles consacrés aux services répondent à des questions différentes :
| Décision à résoudre | Article |
|---|---|
| Comment la migration passe-t-elle de la préparation à un résultat validé ? | Fonctionnement du processus de migration |
| Que peuvent prouver des résultats représentatifs obtenus tôt ? | Demo Migration |
| Comment la capacité comptabilisée est-elle calculée et consommée ? | Entity Points |
| Quel plan et quel prix s’appliquent ? | Plan Entity Points et tarification de la migration |
| Un besoin pris en charge et bien délimité peut-il être traité par un Add-on ? | Add-ons |
| En quoi les trois services de migration diffèrent-ils ? | Standard Service, Managed Service et Custom Service |
| Quels besoins adaptés relèvent de Custom Service ? | Ce que prend en charge Custom Service |
| Quel service de migration correspond aux éléments du projet ? | Choisir le service de migration adapté |
| Quelle action ultérieure correspond à la continuité, à une configuration différente ou à un nouveau résultat ? | Additional Migration Options |
Ce parcours de lecture n’est pas une séquence obligatoire. Il sert à isoler la décision qui reste incertaine sans mélanger capacité, responsabilité d’exécution, périmètre personnalisé et validation en une seule question.
Conclusion
Une migration Next-Cart se comprend mieux comme un service acheté et durable que comme un simple transfert ou paiement. Son parcours de migration fixe et sa durée d’un an en définissent les limites. Les Entity Points fournissent la capacité comptabilisée. Le service de migration définit le périmètre pris en charge ou adapté ainsi que la responsabilité d’exécution. Les Add-ons répondent à des besoins pris en charge et bien délimités. Custom Service couvre les besoins non standard. Les commandes associées enregistrent les achats, upgrades et extensions sans fragmenter la migration elle-même. La validation détermine si le résultat convient à l’usage métier.
Maintenir ces dimensions séparées permet d’obtenir des estimations plus claires, des choix de service mieux justifiés et de meilleurs éléments d’acceptation. Cela évite également une erreur de planification fréquente : supposer qu’un seul composant, comme la taille de la boutique, le prix ou un Add-on, peut expliquer l’ensemble de la migration.
Questions fréquentes
Que définit le parcours de migration ?
Il définit la direction fixe et à sens unique de la plateforme source vers la plateforme cible couverte par la migration achetée.
Un upgrade crée-t-il une nouvelle migration ou redémarre-t-il la durée du service ?
Non. Un upgrade acheté est intégré à la même migration. Le parcours fixe reste inchangé et la durée d’un an continue à courir à partir de la date de l’achat initial.
Pourquoi une migration peut-elle avoir plusieurs commandes associées ?
La commande initiale crée la migration. Des commandes ultérieures peuvent enregistrer des upgrades ou une extension tandis que la migration reste le service géré.
Un Entity Points Plan plus important impose-t-il Managed Service ou Custom Service ?
Non. Les Entity Points déterminent la capacité comptabilisée. Le choix du service de migration dépend du périmètre pris en charge, de la responsabilité d’exécution, des besoins en Add-ons et des exigences adaptées.
Un Add-on peut-il être utilisé avec Standard Service ?
Oui. Un Standard Add-on peut accompagner Standard, Managed ou Custom Service lorsque son fonctionnement disponible correspond au besoin délimité.
Custom Service inclut-il toujours Expert Handle ?
Non. Custom Service peut rester piloté par le client. Expert Handle n’est inclus que lorsque l’exécution par des experts des actions de migration convenues fait partie du périmètre personnalisé accepté.
Pourquoi la validation par le client reste-t-elle nécessaire après une exécution par des experts ?
L’exécution confirme que les opérations de migration ont été réalisées dans le périmètre convenu. La validation par le client confirme que les produits, clients, commandes, contenus, relations et résultats métier obtenus sont acceptables pour la boutique cible.