Entity Points

Des nombres bruts d’enregistrements peuvent donner une vision trop simple de la capacité nécessaire à une migration. Un produit, un client, un commande et un article de blog ne contribuent pas de la même manière au besoin comptabilisé, et une boutique contient de nombreuses structures importantes qui ne consomment pas d’Entity Points de façon indépendante.

Les Entity Points constituent le cadre de capacité pondérée utilisé dans les services de migration Next-Cart. Ils répondent à un problème de planification précis : convertir quatre types de données comptabilisés en besoin de capacité pondérée. Ils ne mesurent pas la complexité, ne garantissent pas la compatibilité, ne limitent pas la migration aux quantités saisies lors de l’achat et ne prouvent pas que la boutique cible sera utilisable.

Cette limite est essentielle. Si les Entity Points sont interprétés comme une mesure complète du projet, une boutique prévisible mais volumineuse peut paraître inutilement complexe, tandis qu’une boutique de faible volume avec des relations personnalisées peut sembler trompeusement simple.

Distinguer la capacité de la difficulté de migration

Les Entity Points comptabilisent :

• produit ;
• client ;
• commande ;
• articles de blog.

D’autres données prises en charge peuvent également faire partie de la migration, notamment taxes, fabricants, catégories, avis, coupons et pages CMS. Ces structures peuvent être essentielles au résultat sans consommer d’Entity Points de manière indépendante.

La difficulté de migration peut également provenir :

• des relations entre options et variantes de produits ;
• de champs ou tables personnalisés ;
• de données appartenant à des applications, plugins, modules ou extensions ;
• d’identifiants externes ;
• de limites du modèle de données de la cible ;
• de besoins en Add-on ou Custom Service ;
• de dépendances de validation et de lancement.

Deux boutiques peuvent nécessiter la même capacité d’Entity Points tout en demandant des approches de migration différentes. La capacité décrit le volume comptabilisé. La complexité décrit le travail nécessaire pour préserver le sens métier et obtenir un résultat acceptable.

Convertir les enregistrements éligibles en capacité pondérée

Chaque type de données comptabilisé par les Entity Points possède une pondération fixe :

Le calcul est le suivant :

Entity Points
= (Product x 1.0)
+ (Customer x 0.5)
+ (Order x 0.8)
+ (Blog Posts x 0.6)

Supposons qu’une boutique source contienne les quantités estimées suivantes :

Le besoin estimé est de 480 Entity Points. Un plan de 500 points couvrirait cette estimation avec une marge de 20 points. Un plan de 1 000 points laisserait une marge de 520 points.

Le calcul arithmétique est simple. La décision de planification consiste à déterminer si les quantités sont réalistes et quelle activité supplémentaire la boutique source peut encore générer avant la fin de la migration.

Considérer l’estimation d’achat comme une prévision

Les quantités saisies lors de l’achat servent à estimer les Entity Points et à choisir un plan. Elles ne créent pas automatiquement des filtres d’enregistrements.

Si 200 produits sont saisis mais que le périmètre source sélectionné contient 260 produits détectés, la migration ne reçoit pas l’instruction de s’arrêter au 200e enregistrement simplement à cause de l’estimation. Les enregistrements comptabilisés qui sont effectivement migrés avec succès consomment la capacité disponible.

Il faut donc distinguer trois valeurs :

Séparer ces valeurs évite deux erreurs fréquentes. La première consiste à prendre l’estimation pour une limite stricte de migration. La seconde consiste à supposer que la capacité non utilisée disparaît parce que l’estimation initiale était plus faible.

Si seuls certains enregistrements doivent être migrés, le besoin doit être défini au moyen de Data Filter en appliquant des conditions fondées sur des champs pour chaque type de données concerné, ou faire l’objet d’une revue de filtrage personnalisé lorsque le fonctionnement disponible ne suffit pas.

Prévoir les écarts et la croissance de la boutique source

Les estimations diffèrent souvent de la consommation réelle parce que l’inventaire source était incomplet, que la boutique a continué à vendre ou que certains articles de blog, clients ou commandes avaient été oubliés dans le périmètre initial.

Supposons qu’un plan de 1 000 points ait été choisi pour l’estimation de 480 points ci-dessus. Si la consommation réelle atteint 800 Entity Points, la migration reste dans les limites du plan et 200 points demeurent disponibles.

L’estimation initiale n’a pas empêché la migration d’enregistrements éligibles supplémentaires. La capacité du plan reste la limite pratique.

Une marge de capacité est particulièrement utile lorsque :

• la boutique source reste active pendant la préparation ;
• les nombres d’enregistrements proviennent de rapports partiels ;
• des données historiques ont été exclues de l’estimation initiale ;
• les articles de blog ou commandes archivés peuvent facilement être oubliés ;
• une activité de migration ultérieure est prévue avant le lancement.

Cette marge doit toutefois être choisie de manière raisonnée. Acheter un plan beaucoup plus important ne résout pas un périmètre mal défini, des données personnalisées ou une validation insuffisante.

Comprendre ce qui se passe lorsque la capacité est épuisée

La consommation réelle suit cet ordre pour les types de données comptabilisés :

produit -> client -> commande -> articles de blog

Si les Entity Points disponibles sont épuisés avant la migration de tous les enregistrements comptabilisés, le traitement s’interrompt au moment où la capacité est atteinte. Un Entity Points Plan supérieur peut alors être choisi pour fournir la capacité supplémentaire nécessaire.

Prenons une boutique dont le besoin réel comptabilisé est de 1 175 Entity Points :

Avec un plan de 1 000 points, les produits utilisent 600 points et les clients 300 points supplémentaires. Il ne reste que 100 points pour les commandes, soit une capacité suffisante pour 125 commandes à 0,8 point chacun. Les 125 commandes restants et les 125 articles de blog nécessitent une capacité supplémentaire.

Cet exemple montre pourquoi la planification de la capacité exige à la fois un calcul et une bonne connaissance de la source. Une faible sous-estimation peut affecter un type de données traité plus tard en raison de l’ordre de consommation.

Ne pas confondre l’ordre de consommation de la capacité et l’ordre de migration

Le processus de migration traite les types de données pris en charge dans l’ordre suivant :

taxes -> fabricants -> catégories -> produits -> clients -> commandes -> avis -> coupons -> pages CMS -> articles de blog

La consommation des Entity Points ne s’applique qu’à produit, client, commande et articles de blog. Les deux séquences décrivent des aspects différents de la même migration :

• l’ordre de migration décrit la manière dont les types de données pris en charge sont traités ;
• l’ordre des Entity Points décrit la manière dont la capacité comptabilisée est consommée.

Cette distinction explique pourquoi catégories ou avis peuvent être importants pour le résultat sans apparaître comme des charges distinctes d’Entity Points. Leur importance est structurelle, et non définie par la formule de capacité.

Appliquer les Entity Points aux activités de migration ultérieures

Les Entity Points dépendent des enregistrements comptabilisés et du fait qu’ils aient déjà été comptés ou non dans la migration achetée et son parcours de migration fixe.

L’action de migration ne détermine pas à elle seule la consommation. Continue the Migration with the Last Used Configuration, Continue the Migration with a New Configuration et Perform a New Migrationpeuvent tous traiter un mélange d’enregistrements existants et nouveaux. La consommation dépend du fait que chaque enregistrement éligible ait déjà été compté ou non dans la migration achetée et son parcours fixe.

Cette règle rend la capacité restante utile pour l’activité ultérieure de la source. Elle implique également que le projet suive les nouveaux produits, clients, commandes et articles de blog lorsque la boutique source reste active.

Utiliser les Entity Points pour la bonne décision

Les Entity Points doivent guider :

• le choix du plan ;
• la planification de la marge de capacité ;
• le suivi de la consommation réelle ;
• les upgrades de plan ;
• la croissance ultérieure des enregistrements éligibles.

Ils ne doivent pas décider :

• entre Standard, Managed ou Custom Service ;
• si un Add-on est nécessaire ;
• si une structure de données personnalisée est prise en charge ;
• si la mise en œuvre sur la plateforme cible est incluse ;
• si le résultat de la migration est acceptable.

Ces décisions nécessitent des éléments sur le périmètre, une analyse des responsabilités et une validation. Un total précis d’Entity Points est nécessaire pour la tarification, mais il ne remplace pas la compréhension des données.

Cette distinction évite deux erreurs de planification opposées. Une boutique peut nécessiter un Entity Points Plan plus important tout en restant simple à migrer. À l’inverse, elle peut tenir dans un plan plus petit tout en comportant des relations personnalisées qui exigent une revue approfondie. Capacité et complexité doivent donc être évaluées ensemble sans jamais être traitées comme une même mesure.

Conclusion

Dans les services de migration Next-Cart, les Entity Points convertissent les quantités de produit, client, commande et articles de blog en capacité de migration pondérée. L’estimation à l’achat aide à choisir un plan, la capacité du plan définit la limite disponible et les enregistrements éligibles effectivement migrés avec succès déterminent la consommation réelle.

La discipline essentielle consiste à séparer les concepts. La capacité n’est pas la complexité. Les quantités estimées ne sont pas des filtres. L’ordre de migration n’est pas l’ordre de consommation des Entity Points. Une action ultérieure ne consomme pas automatiquement de nouveaux points pour des enregistrements déjà comptés dans la migration achetée et son parcours fixe.

Avec ces distinctions, les Entity Points deviennent un outil de planification utile plutôt qu’un score trompeur censé résumer toute la migration.

Questions fréquentes

Quels enregistrements comptent pour les Entity Points ?

produit, client, commande et articles de blog sont les quatre types de données comptabilisés.

Comment les Entity Points sont-ils calculés ?

produit a une pondération fixe de 1.0, client de 0.5, commande de 0.8 et articles de blog de 0.6.

Les quantités saisies lors de l’achat limitent-elles les enregistrements qui seront migrés ?

Non. Elles servent à l’estimation et au choix du plan. Elles ne fonctionnent pas comme des filtres d’enregistrements.

Que se passe-t-il si la consommation réelle dépasse l’estimation ?

La migration peut continuer tant que la capacité du plan reste suffisante. Si elle est épuisée, le traitement s’interrompt jusqu’à ce qu’une capacité supplémentaire soit disponible.

Les Entity Points non utilisés peuvent-ils servir à une activité de migration ultérieure ?

Oui. La capacité restante peut être utilisée pour des enregistrements éligibles migrés ultérieurement dans la migration achetée et son parcours fixe.

Les enregistrements consomment-ils de nouveaux Entity Points lors d’une action ultérieure ?

Pas lorsque les mêmes enregistrements comptabilisés ont déjà été enregistrés dans la migration achetée et son parcours fixe. Les nouveaux enregistrements éligibles consomment des points lorsqu’ils sont migrés avec succès pour la première fois.

catégories, avis ou pages CMS consomment-ils des Entity Points ?

Ils ne consomment pas d’Entity Points de manière indépendante. Ils peuvent néanmoins constituer des éléments importants du périmètre de migration pris en charge et de la validation.