Le choix entre les services de migration Next-Cart est souvent réduit à une échelle trop simple : Standard pour un petit projet, Managed pour un projet plus important et Custom pour le plus complexe. Ce raccourci n’est pas fiable. La taille d’une boutique décrit un volume, pas la structure du besoin. Le prix reflète la capacité et le travail inclus, pas un niveau de qualité automatique.
Ces trois services de migration Next-Cart deviennent plus clairs lorsque la décision est séparée selon deux axes. Le premier concerne le périmètre : le résultat attendu entre-t-il dans le fonctionnement de migration pris en charge, ou nécessite-t-il un traitement adapté ? Le second concerne l’exécution : le client effectuera-t-il les actions de migration convenues, ou faut-il inclure une exécution assurée par des experts ?
Standard, Managed et Custom Service occupent des positions différentes sur ces deux axes. Comprendre cette relation évite de placer des besoins non pris en charge dans Managed Service et d’escalader des migrations prévisibles vers Custom Service uniquement parce que la boutique est volumineuse.
Commencer par le périmètre, puis attribuer la responsabilité d’exécution
Un périmètre pris en charge signifie que le parcours de migration, les structures de données, la configuration disponible et les Standard Add-ons peuvent produire le résultat attendu sans logique de migration spécifique au projet. Un périmètre adapté signifie qu’une partie du besoin nécessite une analyse, une modification, une transformation ou un traitement individuel au-delà de ce fonctionnement pris en charge.
La responsabilité d’exécution répond à une autre question. Une migration prise en charge peut être pilotée par le client ou par des experts. Une migration Custom peut également être pilotée par le client ou inclure Expert Handle. La personne ou l’équipe qui exécute les actions ne change pas le fait que le besoin lié aux données soit pris en charge ou non.
Ce cadre produit quatre positions pratiques :
| Position de périmètre et d’exécution | Service de migration | Raison principale |
|---|---|---|
| Périmètre pris en charge avec exécution pilotée par le client | Standard Service | Le fonctionnement disponible suffit et le client peut coordonner les actions |
| Périmètre pris en charge avec exécution par des experts | Managed Service | Le fonctionnement disponible suffit, mais la responsabilité d’exécution doit être incluse |
| Périmètre adapté avec exécution pilotée par le client | Custom Service | Un travail non standard est nécessaire, tandis que le client peut exécuter les actions convenues |
| Périmètre adapté avec exécution par des experts | Custom Service avec Expert Handle | Le travail adapté et l’exécution par des experts sont tous deux nécessaires |
Ce tableau ne sélectionne pas automatiquement un service de migration ; ce n’est pas un formulaire de qualification. Il sert à éviter de mélanger deux décisions qui doivent être analysées séparément.
Standard Service : périmètre pris en charge avec responsabilité client
Standard Service convient lorsque le parcours de migration est pris en charge, que les structures source importantes sont prévisibles et que la configuration disponible ou les Standard Add-ons peuvent produire le résultat requis. Le client prépare les accès nécessaires, examine la configuration, exécute les actions de migration, coordonne le traitement des constats et valide la boutique cible.
Cela ne fait pas de Standard Service une option basique ou limitée en capacité. Une boutique comportant un grand nombre de Products et Orders peut parfaitement convenir si le modèle de données est bien compris et si l’équipe interne dispose des ressources nécessaires pour piloter l’exécution. Les Entity Points déterminent la quantité de données comptabilisées que le plan peut prendre en charge ; ils ne déterminent pas si Standard Service est approprié.
Un bon cas Standard Service présente généralement :
- un parcours plateforme source -> plateforme cible pris en charge ;
- une propriété claire des données et relations importantes ;
- aucune exigence de logique de migration sur mesure ;
- des besoins d’Add-ons limités qui correspondent au fonctionnement disponible ;
- une capacité interne suffisante pour coordonner l’exécution et la validation ;
- des critères d’acceptation applicables à des résultats représentatifs.
Le principal compromis concerne la responsabilité. Une exécution pilotée par le client donne un contrôle direct sur le calendrier et les décisions de configuration, mais exige également suffisamment d’attention pour interpréter les résultats et réagir lorsque les hypothèses s’avèrent fausses.
Managed Service : périmètre pris en charge avec exécution par des experts
Managed Service s’applique lorsque la migration reste dans le périmètre pris en charge mais que l’exécution des actions convenues doit être assurée par des experts. La différence de service concerne la responsabilité, et non une capacité de traitement des données plus large.
Cette option peut être utile lorsqu’une échéance fixe, des contraintes opérationnelles, une expérience limitée de la migration ou la nécessité de coordonner plusieurs parties prenantes limitent l’équipe interne. Les données peuvent être prévisibles, tout en justifiant un transfert de la charge d’exécution.
Managed Service n’absorbe pas les données d’application non prises en charge, les tables personnalisées, les transformations sur mesure ou la logique d’Add-on modifiée. Si ces besoins existent, le périmètre doit d’abord être traité comme Custom. Confier l’exécution à des experts ne transforme pas un besoin non standard en fonctionnement pris en charge.
Le client reste responsable de fournir des informations de projet exactes et de valider le résultat. L’exécution par des experts peut réduire la charge opérationnelle, mais elle ne peut pas décider si les enregistrements migrés conservent le sens métier requis par le merchandising, la finance, le service client, le SEO ou la conformité.
Managed Service ne retire pas au client l’accès à la migration. Le client peut toujours examiner, configurer et effectuer manuellement les activités de migration disponibles. L’exécution par des experts est une responsabilité incluse, pas un contrôle exclusif de la migration achetée.
Custom Service : un périmètre adapté défini par le résultat attendu
Custom Service devient pertinent lorsque le résultat de migration attendu ne peut pas être produit uniquement par le fonctionnement pris en charge et les Standard Add-ons disponibles. Le besoin doit être défini à partir des données ou du traitement qui nécessitent une prise en charge adaptée, et non par une affirmation vague selon laquelle la boutique serait inhabituelle.
Les signaux fréquents comprennent :
- une Custom Platform comme plateforme source ou plateforme cible ;
- des champs, tables ou structures de base de données personnalisés dont le traitement requis dépasse le périmètre de migration pris en charge ou celui des Standard Add-ons ;
- des données appartenant à des applications, plugins, modules ou extensions ;
- des enregistrements tiers situés hors du modèle de plateforme pris en charge ;
- des identifiants externes dont la relation avec un autre système doit être conservée ;
- une transformation ou restructuration sur mesure ;
- une logique non standard concernant Products, Customers, Orders, contenu ou relations ;
- un Add-on disponible qui doit être modifié ;
- un nouvel Add-on spécifique au projet.
Le périmètre de Custom Service doit identifier la signification des données source, la représentation cible attendue, les règles de transformation ou de relation, les enregistrements concernés et les éléments nécessaires pour l’acceptation. Sans ces informations, « Custom » reste une étiquette plutôt qu’une exigence de migration exploitable.
Expert Handle modifie l’exécution, pas la nature du travail Custom
Custom Service n’inclut pas automatiquement Expert Handle.
Custom Service piloté par le client
Le travail adapté convenu est inclus, tandis que le client effectue les actions de migration disponibles et valide le résultat. Cette formule peut convenir à une équipe qui a besoin de capacités sur mesure mais conserve les ressources opérationnelles nécessaires pour coordonner l’exécution.
Custom Service avec Expert Handle
Le travail adapté convenu et l’exécution par des experts des actions de migration acceptées sont inclus. Le client continue à fournir le contexte métier nécessaire et à effectuer la vérification finale.
Le périmètre accepté doit indiquer explicitement la responsabilité d’exécution. Sinon, le projet peut définir correctement le résultat Custom tout en laissant une zone d’incertitude évitable sur la personne chargée d’exécuter les actions nécessaires pour l’obtenir.
Le même principe d’accès s’applique à Custom Service. Que le projet soit piloté par le client ou qu’il inclue Expert Handle, le client peut toujours accéder à la migration et effectuer manuellement les activités disponibles. Le choix du service définit la responsabilité incluse et le périmètre adapté, et non une exclusion du client.
Les Add-ons ne constituent pas un quatrième service de migration
Les Standard Add-ons répondent à des besoins limités et pris en charge. Ils peuvent accompagner Standard, Managed ou Custom Service lorsque le fonctionnement disponible correspond au besoin.
Par exemple, sélectionner des Orders qui respectent une condition approuvée portant sur un champ Order peut relever de Data Filter. Mapper un champ source pris en charge vers un champ cible compatible peut relever de Advanced Data Mapping. Lorsque la plateforme source et la plateforme cible sont toutes deux Open-Source, le mapping de champs ou de colonnes de base de données pris en charge peut relever de Advanced Database Mapping. Transformer la valeur d’un champ cible sélectionné peut relever de Data Transformation. Plusieurs Standard Add-ons peuvent être combinés sans transformer la migration en Custom Service lorsque chaque opération reste dans ses limites prises en charge.
La limite change lorsque l’Add-on lui-même doit être modifié ou lorsqu’aucun Standard Add-on ne peut produire le résultat requis :
- un Standard Add-on modifié devient un Tailored Add-on dans Custom Service ;
- un Add-on spécifique au projet est examiné comme Custom Add-on dans Custom Service ;
- des données non prises en charge ou des relations sur mesure nécessitent une analyse Custom Service plus large, même si un filtrage ou un mapping intervient également.
Un Add-on décrit une capacité ciblée. Le service de migration décrit l’organisation plus large du périmètre et des responsabilités.
La validation client constitue une responsabilité distincte
Chaque service de migration se termine par une validation client. Cette règle est parfois comprise comme une limite de l’exécution assurée par des experts. Il est plus juste de la considérer comme une répartition des connaissances.
L’exécution peut être évaluée par rapport à la configuration et au périmètre de service acceptés. L’acceptation métier nécessite des connaissances détenues par le client : quels Products doivent rester vendables, comment les Orders doivent soutenir les opérations de service, quelles distinctions Customers sont importantes, si les parcours SEO sont acceptables et si la boutique cible est prête pour l’étape suivante prévue.
Un dossier d’acceptation utile identifie :
- le résultat critique examiné ;
- des enregistrements ou scénarios représentatifs ;
- le responsable de la décision ;
- le résultat attendu ;
- toute limite acceptée ;
- la décision Pass, Watch ou Block.
L’implémentation de la plateforme cible doit également rester visible comme couche distincte. La reconstruction du thème, l’installation d’applications, la configuration des paiements ou de la livraison, le déploiement des intégrations et la configuration opérationnelle ne sont pas automatiquement inclus simplement parce que les données migrées devront ensuite y participer.
Utiliser les résultats pour upgrader le service initial
Le service de migration initial peut devoir changer lorsque de nouvelles informations remettent en cause une hypothèse centrale. Demo Migration peut révéler des structures non prises en charge. Un inventaire de données peut faire apparaître des identifiants externes ou des tables personnalisées. Un Standard Add-on peut se révéler trop limité. Les ressources internes peuvent devenir insuffisantes pour une exécution pilotée par le client.
Après l’achat, les changements de service ne peuvent se faire que vers le haut :
| Service acheté | Service ultérieur autorisé |
|---|---|
| Standard Service | Managed Service ou Custom Service |
| Managed Service | Custom Service |
| Custom Service | Aucun downgrade de service |
Un upgrade de service est approprié lorsque les informations disponibles changent. Passez de Standard à Managed lorsque le périmètre pris en charge reste approprié mais que la responsabilité d’exécution doit changer. Passez de Standard ou Managed à Custom Service lorsqu’un travail adapté est requis. Dans Custom Service, Expert Handle peut être ajouté lorsque le périmètre adapté est correct mais que l’exécution par des experts doit également faire partie du travail accepté.
La migration ne peut pas passer de Managed à Standard ni de Custom à Managed ou Standard. Cette asymétrie rend le choix initial important, même si une correction vers le haut reste possible. Un Standard Add-on limité qui résout entièrement le besoin ne nécessite pas, à lui seul, un upgrade de service.
L’upgrade de service est intégré à la même migration achetée et facturé uniquement sur la différence. Il ne crée pas de nouveau parcours et ne prolonge pas la durée d’un an du service. Cette approche fondée sur les résultats est plus fiable que de traiter les trois services comme des niveaux réversibles de taille ou de qualité croissante.
Conclusion
Les services de migration Next-Cart se distinguent par le périmètre et la responsabilité d’exécution. Standard Service est piloté par le client dans le périmètre pris en charge. Managed Service inclut une exécution assurée par des experts dans ce même périmètre. Custom Service répond aux besoins adaptés ou non standard et peut rester piloté par le client ou inclure Expert Handle.
Les Entity Points servent à la capacité, les Add-ons aux améliorations limitées prises en charge et la validation client à l’acceptation métier. Une fois ces décisions séparées, le choix du service devient une décision de projet argumentée plutôt qu’un raccourci basé sur la taille de la boutique, le prix affiché ou une perception du niveau de service.
Questions fréquentes
Standard Service convient-il uniquement aux petites boutiques ?
Non. Standard Service peut prendre en charge une migration volumineuse lorsque le parcours et les besoins restent pris en charge et que le client peut coordonner l’exécution et la validation.
Quelle est la principale différence entre Standard Service et Managed Service ?
Les deux répondent à des besoins de migration pris en charge. Standard Service est piloté par le client, tandis que Managed Service inclut l’exécution par des experts des actions de migration convenues.
Managed Service couvre-t-il les champs personnalisés ou les enregistrements non pris en charge ?
Pas automatiquement. Managed Service modifie la responsabilité d’exécution dans le périmètre pris en charge. Le traitement adapté de besoins personnalisés ou non pris en charge relève de Custom Service.
Custom Service inclut-il toujours Expert Handle ?
Non. Custom Service peut être piloté par le client. Expert Handle est inclus lorsque l’exécution par des experts fait partie du périmètre accepté de Custom Service.
Un Standard Add-on peut-il être utilisé avec Managed Service ?
Oui. Les Standard Add-ons peuvent accompagner Standard, Managed ou Custom Service lorsque leur fonctionnement disponible correspond au besoin.
Qui approuve le résultat final de la migration ?
Le client reste responsable de la vérification finale dans chaque service de migration, car l’acceptation métier dépend des résultats commerciaux, opérationnels, SEO et de conformité attendus.
Les clients peuvent-ils toujours effectuer des activités de migration avec Managed ou Custom Service ?
Oui. Chaque service de migration reste accessible pour des actions manuelles du client. Managed Service et Expert Handle définissent une responsabilité d’exécution incluse ; ils ne retirent pas l’accès du client.
Un service de migration acheté peut-il être downgradé ?
Non. Standard peut être upgradé vers Managed ou Custom, et Managed peut être upgradé vers Custom. Un service de migration acheté ne peut pas évoluer vers le bas.