Dans les services de migration Next-Cart, les Additional Migration Options répondent aux projets qui se poursuivent après le premier résultat de migration à grande échelle. La boutique source peut rester active pendant que la boutique cible est examinée. De nouveaux Orders et Customers peuvent apparaître. La validation peut montrer qu’un mapping ou un filtre doit évoluer. Un résultat de test peut devoir être remplacé avant le lancement.
Ces situations se ressemblent parce qu’elles nécessitent toutes une nouvelle activité de migration. Pourtant, le résultat attendu n’est pas le même. L’une préserve la continuité avec une configuration considérée comme fiable. Une autre poursuit le projet tout en modifiant la configuration. La troisième produit un résultat de migration distinct et entièrement nouveau.
Les Additional Migration Options Next-Cart doivent donc être choisies selon l’intention du projet, et non par simple commodité. Un mauvais choix peut réutiliser des hypothèses qui ne sont plus valides, remplacer un résultat qui devait être conservé ou créer de fausses attentes sur les enregistrements source qui seront lus.
Définir le prochain résultat avant de choisir l’action
La première question n’est pas « quelle option est disponible ? », mais « qu’est-ce qui doit rester vrai après la prochaine activité de migration ? »
Trois intentions doivent être distinguées :
- Continuité : le résultat précédent reste utile et la même configuration doit continuer à s’appliquer.
- Changement contrôlé : le résultat précédent reste utile, mais les filtres, mappings, types de données sélectionnés, Add-ons ou autres paramètres doivent changer.
- Nouveau résultat : le résultat migré précédent ne doit plus servir de base au projet.
Ces intentions correspondent à trois actions exactes :
| Résultat attendu | Action de migration | Conséquence principale |
|---|---|---|
| Continuer à partir d’une configuration considérée comme fiable | Continue the Migration with the Last Used Configuration | La configuration enregistrée est réutilisée |
| Continuer tout en modifiant la configuration | Continue the Migration with a New Configuration | La configuration est revue ou modifiée avant l’exécution |
| Produire un résultat distinct et entièrement nouveau | Perform a New Migration | L’activité de migration antérieure ne sert pas de base au nouveau résultat |
Une première migration ne possède aucune configuration antérieure à réutiliser. La disponibilité d’actions ultérieures dépend de l’historique de migration applicable et d’une durée de service active. Si la durée d’un an a expiré, la migration doit être prolongée avant qu’une action ultérieure éligible puisse être exécutée.
Réutiliser la dernière configuration uniquement si ses hypothèses restent valides
Continue the Migration with the Last Used Configuration convient lorsque la configuration précédente reste valable et que le résultat existant dans la boutique cible reste utile.
Cette action peut réduire le travail de décision répété, mais son efficacité dépend d’une hypothèse forte : la dernière configuration représente toujours le résultat attendu.
Avant de la réutiliser, confirmez que :
- les types de données sélectionnés restent appropriés ;
- les décisions de mapping restent adaptées à la cible ;
- les règles de filtrage décrivent toujours le périmètre d’enregistrements attendu ;
- la configuration des Add-ons reste pertinente ;
- les structures source et cible n’ont pas changé de manière significative ;
- la validation précédente n’a pas révélé de défaut de configuration non résolu ;
- la fenêtre d’enregistrements source visée reste correcte.
Le fait qu’une configuration ait fonctionné une fois ne suffit pas à justifier sa réutilisation. Le contexte du projet peut avoir changé. Un nouveau champ source, une structure cible modifiée ou un périmètre de lancement différent peut rendre l’ancienne configuration inadéquate même si le parcours de migration n’a pas changé.
La validation après cette action doit démontrer à la fois la continuité et la bonne prise en compte des nouveaux traitements. Le résultat existant dans la boutique cible doit rester exploitable, et les enregistrements nouvellement traités doivent suivre les mêmes règles acceptées.
Poursuivre avec une nouvelle configuration lorsque l’objectif a changé
Continue the Migration with a New Configuration convient lorsque les activités de migration précédentes restent utiles mais que l’exécution suivante nécessite des paramètres pris en charge différents.
Les raisons fréquentes comprennent :
- le filtrage doit inclure ou exclure un ensemble différent d’enregistrements ;
- les mappings standard doivent être revus ;
- les types de données sélectionnés ont changé ;
- un Add-on doit utiliser d’autres paramètres ;
- la validation a révélé un problème de configuration ;
- l’étape suivante du projet possède un périmètre différent ;
- les attentes envers la cible ont changé sans nécessiter un résultat totalement nouveau.
Le principal avantage est l’adaptation contrôlée. Le projet peut préserver le travail précédent encore utile tout en modifiant les décisions qui gouvernent l’activité suivante.
Le risque réside dans la coexistence non maîtrisée. Des enregistrements produits avec l’ancienne configuration peuvent rester présents aux côtés d’enregistrements produits avec la nouvelle. La validation doit donc vérifier si les deux configurations créent des doublons, des mappings contradictoires, une utilisation incohérente des champs ou des différences de signification métier.
Par exemple, modifier un mapping de groupe Customer doit conduire à examiner les Customers migrés sous les deux configurations. La question n’est pas seulement de savoir si le nouveau mapping fonctionne, mais si l’ensemble de la boutique cible reste cohérent.
Effectuer une nouvelle migration lorsque le résultat précédent ne doit pas continuer
Perform a New Migration convient lorsque le projet a besoin d’un résultat de migration distinct et entièrement nouveau plutôt que d’une continuation du travail précédent.
Cette action peut être justifiée lorsque :
- le résultat migré précédent avait été créé pour des tests ;
- l’ancienne configuration ne correspond plus au périmètre prévu ;
- la validation a révélé des défauts coordonnés qui rendent une simple continuation peu fiable ;
- la préparation de la cible nécessite une base de migration propre ;
- le projet veut redéfinir le périmètre et la configuration depuis le début.
Une nouvelle migration doit être choisie parce que le résultat doit être nouveau, et non simplement parce qu’une nouvelle exécution est possible.
Les décisions de remplacement et de suppression nécessitent de la prudence. Cette action peut affecter des enregistrements créés précédemment par la migration dans le périmètre sélectionné, mais elle n’autorise pas à elle seule la suppression de tous les enregistrements de la boutique cible. Les enregistrements créés manuellement, créés par des applications, utilisés pour les tests ou issus de l’activité opérationnelle doivent être identifiés avant toute décision de suppression ou de remplacement.
Le niveau de validation doit être plus large que pour une continuation. Le projet doit confirmer la nouvelle configuration, l’ensemble de données obtenu, le traitement des enregistrements migrés antérieurement et la protection des enregistrements situés hors du périmètre de remplacement approuvé.
Séparer l’action de migration de la fenêtre d’enregistrements source
Les trois actions définissent la relation avec la configuration et le résultat antérieurs. Elles ne déterminent pas à elles seules quels enregistrements source seront lus.
Le comportement de lecture de la source répond à une autre question :
- faut-il reprendre un traitement interrompu à l’endroit où il s’est arrêté ;
- faut-il lire uniquement les enregistrements ajoutés après la dernière migration réussie ;
- faut-il relire le périmètre source sélectionné sous la configuration choisie.
Cette distinction évite une erreur courante. Continuer avec la dernière configuration ne signifie pas automatiquement que seuls les nouveaux enregistrements seront traités. Perform a New Migration ne définit pas automatiquement la manière dont la fenêtre source est sélectionnée.
Un enregistrement existant modifié après l’activité précédente est également différent d’un nouvel enregistrement. Si les enregistrements existants modifiés doivent être réexaminés, les décisions de lecture de la source et de configuration doivent exprimer ce besoin explicitement.
L’action et la fenêtre d’enregistrements source doivent être planifiées ensemble, mais elles ne doivent pas être traitées comme un seul paramètre.
Appliquer les Entity Points selon le statut des enregistrements
Une activité de migration supplémentaire ne consomme pas d’Entity Points simplement parce qu’une nouvelle action a lieu. La consommation dépend des enregistrements comptabilisés concernés.
| Situation de l’enregistrement comptabilisé | Effet sur les Entity Points |
|---|---|
| Un enregistrement Product, Customer, Order ou Blog Posts est migré avec succès pour la première fois | Les points sont consommés selon le poids verrouillé applicable |
| Le même enregistrement comptabilisé a déjà été compté dans la migration achetée et son parcours fixe | Il ne consomme pas de nouveau des points simplement parce qu’une autre action le traite |
| Un nouvel enregistrement éligible est ajouté puis migré ultérieurement | Les points sont consommés lorsqu’il est migré avec succès pour la première fois |
| Une nouvelle migration inclut des enregistrements éligibles déjà comptés | Ces enregistrements ne consomment pas de points une seconde fois |
Cette règle s’applique aux trois actions. Perform a New Migration ne recompte pas automatiquement chaque Product, Customer, Order et Blog Posts déjà enregistré.
La planification de capacité doit se concentrer sur les nouvelles données réellement comptabilisées. Si la boutique source reste active, la croissance attendue de Products, Customers, Orders et Blog Posts doit être comparée à la capacité Entity Points restante avant l’action suivante.
Séparer les actions de migration des changements commerciaux
Une Additional Migration Option détermine comment la prochaine activité de migration se rapporte au résultat précédent. Un upgrade modifie le package acheté, tandis qu’une extension restaure une migration expirée. Ces décisions sont liées, mais elles ne sont pas interchangeables.
Par exemple, acheter davantage d’Entity Points augmente la capacité sans décider si l’activité suivante réutilisera la dernière configuration, modifiera la configuration ou produira un nouveau résultat. Upgrader de Standard vers Managed modifie la responsabilité d’exécution sans choisir l’action de migration. Prolonger une migration expirée restaure le service depuis le dernier package conservé ; l’action appropriée dépend ensuite toujours du résultat attendu.
Maintenir ces décisions distinctes évite de prendre une commande commerciale pour une instruction de migration. Cela préserve également le parcours de migration fixe : les upgrades et extensions concernent la même migration achetée au lieu de créer une autre direction plateforme source -> plateforme cible.
Maintenir la responsabilité liée au service de migration visible
Une Additional Migration Option ne remplace pas le service de migration acheté.
Avec une exécution pilotée par le client, celui-ci effectue l’action sélectionnée et valide le résultat. Avec une exécution pilotée par des experts, l’action convenue est effectuée dans le périmètre de service accepté, tandis que le client fournit les informations nécessaires et approuve le résultat.
Si l’activité ultérieure introduit des besoins adaptés, le périmètre de service peut devoir évoluer. Un nouveau champ personnalisé, un Add-on modifié ou une transformation sur mesure ne doit pas être dissimulé dans une action de continuation simplement parce que le parcours de migration existe déjà.
Le projet doit donc examiner séparément deux questions :
- Quelle action correspond à la relation attendue avec le résultat précédent ?
- Le service de migration actuel couvre-t-il toujours le périmètre et la responsabilité d’exécution nécessaires ?
Adapter la validation à l’objectif de l’action
Chaque action exige une validation, mais les éléments examinés doivent correspondre à son intention.
| Action | Principal objectif de validation |
|---|---|
| Continue the Migration with the Last Used Configuration | La configuration est restée valide, la fenêtre source attendue a été traitée et la continuité a été préservée |
| Continue the Migration with a New Configuration | Les paramètres révisés ont produit le résultat attendu sans créer d’incohérence avec les enregistrements migrés antérieurement |
| Perform a New Migration | Le nouveau résultat reflète le périmètre approuvé, les données migrées antérieurement ont été traitées correctement et les enregistrements protégés de la boutique cible restent intacts |
La revue représentative doit inclure, selon le contexte, les Products, Customers, Orders, Blog Posts, CMS Pages, Reviews, Coupons et URL critiques pour l’activité, ainsi que les enregistrements filtrés, les valeurs mappées, les résultats des Add-ons et les données relevant d’un périmètre personnalisé.
L’action sélectionnée n’est réussie que lorsque la boutique cible permet l’étape métier suivante attendue. La fin de l’action ne constitue pas une acceptation.
Éviter les erreurs d’intention
Réutiliser une configuration alors que le besoin a changé
La dernière configuration peut être familière tout en n’étant plus valable. Sa réutilisation doit s’appuyer sur des éléments montrant que les mappings, filtres, Add-ons et attentes envers la cible restent adaptés.
Choisir une nouvelle migration alors qu’une modification de configuration suffit
Un résultat entièrement nouveau peut introduire un risque de remplacement inutile. Si le travail précédent reste utile et que seuls des paramètres pris en charge doivent changer, poursuivre avec une nouvelle configuration peut être plus précis.
Supposer qu’une continuation ne lit que les nouveaux enregistrements
L’action et la fenêtre source sont distinctes. Le comportement de lecture doit être planifié explicitement.
Traiter une nouvelle migration comme une autorisation de supprimer tous les enregistrements de la boutique cible
Le remplacement doit rester dans le périmètre approuvé. Les enregistrements créés manuellement ou par des applications doivent faire l’objet de décisions distinctes de protection et de propriété.
Omettre la validation parce que le résultat précédent avait été accepté
Les nouveaux enregistrements source, une configuration modifiée et un résultat entièrement nouveau créent chacun de nouvelles exigences de validation. L’acceptation antérieure ne peut pas être transférée automatiquement.
Conclusion
Les Additional Migration Options Next-Cart correspondent à trois intentions de projet différentes. Continue the Migration with the Last Used Configuration préserve la continuité lorsque la configuration antérieure reste valide. Continue the Migration with a New Configuration conserve le travail précédent encore utile tout en autorisant un changement contrôlé. Perform a New Migration crée un résultat distinct et entièrement nouveau lorsque le résultat antérieur ne doit plus servir de base au projet.
L’action doit être coordonnée avec la sélection des enregistrements source, la capacité Entity Points, la responsabilité du service de migration, les limites de remplacement et une validation adaptée à l’objectif. Choisir à partir du résultat attendu permet de garder les activités de migration ultérieures sous contrôle et évite qu’une action disponible ne remplace le raisonnement du projet.
Questions fréquentes
Quand faut-il réutiliser la dernière configuration ?
Réutilisez-la lorsque la configuration précédente, l’intention concernant les enregistrements source, les Add-ons, les mappings et les attentes envers la cible restent valides.
Quand une nouvelle configuration est-elle plus adaptée ?
Utilisez une nouvelle configuration lorsque le travail de migration antérieur reste utile mais que les filtres, mappings, types de données sélectionnés, Add-ons ou autres paramètres pris en charge doivent changer.
Quand faut-il effectuer une nouvelle migration ?
Utilisez Perform a New Migration lorsque le projet a besoin d’un résultat distinct et entièrement nouveau et que le résultat migré antérieur ne doit plus servir de base.
Les actions de continuation lisent-elles automatiquement uniquement les enregistrements nouvellement ajoutés ?
Non. L’action de migration et la fenêtre d’enregistrements source sont deux décisions distinctes.
Les enregistrements déjà comptabilisés consomment-ils de nouveau des Entity Points ?
Non. Les enregistrements déjà comptabilisés dans la migration achetée et son parcours fixe ne consomment pas de points supplémentaires simplement parce qu’une autre action les traite.
Perform a New Migration supprime-t-il tous les enregistrements de la boutique cible ?
Non. La suppression et le remplacement doivent respecter le périmètre approuvé, en identifiant séparément les enregistrements créés manuellement, créés par des applications et les autres enregistrements protégés.
Une Additional Migration Option modifie-t-elle le service de migration ?
Non. Un upgrade du service de migration constitue un changement commercial séparé. Il peut modifier le périmètre ou la responsabilité d’exécution, mais ne décide pas quelle Additional Migration Option correspond au résultat suivant.
Que faut-il valider après une action ultérieure ?
La validation doit confirmer la fenêtre source prévue, le fonctionnement de la configuration, l’effet sur les Entity Points, le traitement des résultats antérieurs, les enregistrements protégés et l’utilité métier de la boutique cible.