Los recuentos brutos de registros pueden hacer que la capacidad de una migración parezca más sencilla de lo que es. Un Product, un Customer, un Order y un Blog Post no contribuyen por igual al requisito contabilizado, y una tienda contiene muchas estructuras importantes que no consumen Entity Points de forma independiente.
Entity Points es el marco de capacidad ponderada utilizado en los Migration Services de Next-Cart. Resuelve un problema concreto de planificación: convertir cuatro tipos de datos contabilizados por Entity Points en un requisito de capacidad ponderada. No mide la complejidad, no garantiza la compatibilidad, no limita la migración a las cantidades introducidas durante la compra y no demuestra que la tienda de destino vaya a ser utilizable.
Este límite es esencial. Cuando Entity Points se interpreta como una medida completa del proyecto, una tienda con gran volumen pero estructura previsible puede parecer innecesariamente compleja, mientras que una tienda con poco volumen y relaciones personalizadas puede parecer engañosamente sencilla.
Distinga la capacidad de la dificultad de la migración
Entity Points contabiliza:
- Product;
- Customer;
- Order;
- Blog Posts.
Otros datos compatibles pueden seguir formando parte de la migración, incluidos Taxes, Manufacturers, Categories, Reviews, Coupons y CMS Pages. Estas estructuras pueden ser críticas para el resultado aunque no consuman Entity Points de forma independiente.
La dificultad de la migración también puede proceder de:
- relaciones entre opciones y variantes de Products;
- campos o tablas personalizados;
- datos de aplicaciones, plugins, módulos o extensiones;
- identificadores externos;
- limitaciones del modelo de datos de destino;
- requisitos de Add-ons o Custom Service;
- dependencias de validación y lanzamiento.
Dos tiendas pueden necesitar la misma capacidad de Entity Points y, aun así, requerir enfoques de migración distintos. La capacidad describe el volumen contabilizado. La complejidad describe el trabajo necesario para conservar el significado y obtener un resultado aceptable.
Convierta los registros elegibles en capacidad ponderada
Cada tipo de datos contabilizado por Entity Points tiene un peso fijo:
| Tipo de datos contabilizado | Peso |
|---|---|
| Product | 1.0 |
| Customer | 0.5 |
| Order | 0.8 |
| Blog Posts | 0.6 |
El cálculo es:
Entity Points
= (Product x 1.0)
+ (Customer x 0.5)
+ (Order x 0.8)
+ (Blog Posts x 0.6)
Suponga que una tienda de origen contiene las siguientes cantidades estimadas:
| Tipo de datos contabilizado | Registros estimados | Peso | Entity Points estimados |
|---|---|---|---|
| Product | 200 | 1.0 | 200 |
| Customer | 200 | 0.5 | 100 |
| Order | 150 | 0.8 | 120 |
| Blog Posts | 100 | 0.6 | 60 |
| Total | 480 |
El requisito estimado es de 480 Entity Points. Un plan de 500 puntos podría cubrir esa estimación con 20 puntos de margen. Un plan de 1,000 puntos dejaría 520 puntos de margen.
La aritmética es sencilla. La decisión de planificación consiste en determinar si las cantidades son realistas y cuánta actividad adicional puede generar la tienda de origen antes de completar la migración.
Trate la estimación de compra como una previsión
Las cantidades introducidas durante la compra sirven para estimar Entity Points y seleccionar el plan. No crean filtros automáticos de registros.
Si se introducen 200 Products pero el alcance seleccionado en el origen contiene 260 Products detectados, la migración no recibe la instrucción de detenerse en el registro 200 únicamente por la estimación. Los registros contabilizados que se migran correctamente consumen la capacidad disponible.
Esto produce tres cifras diferentes:
| Cifra | Significado |
|---|---|
| Requisito estimado | La previsión utilizada para elegir un plan |
| Capacidad del plan | La capacidad contabilizada máxima disponible en el plan adquirido |
| Consumo real | Entity Points utilizados por registros elegibles migrados correctamente |
Mantener estas cifras separadas evita dos errores habituales. El primero es asumir que la estimación constituye un límite rígido para la migración. El segundo es asumir que la capacidad no utilizada desaparece porque la estimación inicial era inferior.
Si solo deben migrarse registros seleccionados, el requisito debe definirse mediante Data Filter con condiciones basadas en campos para cada tipo de datos relevante, o revisarse como filtrado personalizado cuando el funcionamiento disponible no sea suficiente.
Planifique la variación y el crecimiento de la tienda de origen
Las estimaciones suelen diferir del consumo real porque el inventario de origen estaba incompleto, la tienda siguió operando o entraron en el alcance Blog Posts, Customers u Orders que se habían pasado por alto.
Suponga que se seleccionó un plan de 1,000 puntos para la estimación de 480 puntos anterior. Si el consumo real llega a 800 Entity Points, la migración sigue dentro del plan y quedan 200 puntos disponibles.
| Posición de capacidad | Entity Points |
|---|---|
| Capacidad del plan | 1,000 |
| Estimación de compra | 480 |
| Consumo real | 800 |
| Capacidad restante | 200 |
La estimación original no impidió migrar los registros elegibles adicionales. La capacidad del plan siguió siendo el límite práctico.
Contar con margen resulta especialmente útil cuando:
- la tienda de origen permanece activa durante la preparación;
- los recuentos de registros procedían de informes parciales;
- inicialmente se excluyeron datos históricos de la estimación;
- es fácil pasar por alto Blog Posts u Orders archivados;
- se prevé actividad de migración posterior antes del lanzamiento.
El margen debe seguir siendo intencionado. Comprar un plan mucho mayor no resuelve un alcance impreciso, datos personalizados ni una validación insuficiente.
Comprenda qué ocurre cuando se agota la capacidad
El consumo real sigue esta secuencia de tipos de datos contabilizados:
Product → Customer → Order → Blog Posts
Si se agotan los Entity Points disponibles antes de migrar todos los registros contabilizados, el procesamiento se detiene en el punto en el que se alcanza la capacidad. Después puede seleccionarse un Entity Points Plan superior para proporcionar la capacidad adicional necesaria.
Considere una tienda cuyo requisito contabilizado real sea de 1,175 Entity Points:
| Tipo de datos contabilizado | Registros reales | Peso | Entity Points necesarios |
|---|---|---|---|
| Product | 600 | 1.0 | 600 |
| Customer | 600 | 0.5 | 300 |
| Order | 250 | 0.8 | 200 |
| Blog Posts | 125 | 0.6 | 75 |
| Total | 1,175 |
Con un plan de 1,000 puntos, Products utiliza 600 puntos y Customers otros 300. Solo quedan 100 puntos para Orders, suficientes para 125 Orders a 0.8 puntos cada uno. Los 125 Orders restantes y los 125 Blog Posts necesitan capacidad adicional.
| Paso de consumo | Puntos utilizados | Total acumulado | Resultado dentro de 1,000 puntos |
|---|---|---|---|
| Product | 600 | 600 | 600 Products |
| Customer | 300 | 900 | 600 Customers |
| Order | 100 de 200 necesarios | 1,000 | 125 Orders |
| Blog Posts | 0 de 75 necesarios | 1,000 | Ningún Blog Post antes de agotar la capacidad |
El ejemplo muestra por qué la planificación de capacidad necesita tanto aritmética como conocimiento del origen. Una pequeña subestimación puede afectar a un tipo de datos posterior debido a la secuencia de consumo.
No confunda la secuencia de capacidad con la secuencia de migración
El proceso de migración trata los datos compatibles en este orden:
Taxes → Manufacturers → Categories → Products → Customers → Orders → Reviews → Coupons → CMS Pages → Blog Posts
El consumo de Entity Points se aplica únicamente a Product, Customer, Order y Blog Posts. Las dos secuencias describen aspectos diferentes de una misma migración:
- la secuencia de migración describe cómo se procesan los tipos de datos compatibles;
- la secuencia de Entity Points describe cómo se utiliza la capacidad contabilizada.
Esta distinción explica por qué Categories o Reviews pueden ser importantes para el resultado sin aparecer como cargos separados de Entity Points. Su importancia es estructural y no la define la fórmula de capacidad.
Aplique Entity Points a actividades de migración posteriores
Entity Points está vinculado a los registros contabilizados y a si ya fueron contabilizados dentro de la migración adquirida y su ruta fija.
| Situación del registro | Efecto sobre la capacidad |
|---|---|
| Un registro elegible se migra correctamente por primera vez | Consume Entity Points según su peso fijo |
| Un registro elegible ya fue contabilizado dentro de la migración adquirida y la ruta fija | El mismo registro no vuelve a consumir Entity Points únicamente porque otra acción de migración lo procese |
| Se añade un registro elegible nuevo y se migra más adelante | Consume Entity Points cuando se migra correctamente por primera vez |
| Una nueva acción de migración incluye registros elegibles ya contabilizados dentro de la migración adquirida y la ruta fija | Esos registros ya contabilizados no vuelven a consumir Entity Points |
La acción de migración en sí no determina el consumo. Continue the Migration with the Last Used Configuration, Continue the Migration with a New Configuration y Perform a New Migration pueden procesar una combinación de registros existentes y nuevos. El consumo depende de si cada registro elegible ya fue contabilizado dentro de la migración adquirida y su ruta fija.
Esta regla hace que la capacidad restante sea útil para la actividad posterior en el origen. También significa que el proyecto debe controlar los Products, Customers, Orders y Blog Posts nuevos cuando la tienda de origen sigue activa.
Utilice Entity Points en la decisión correcta
Entity Points debe orientar:
- la selección del plan;
- la planificación del margen;
- el seguimiento de la capacidad real;
- las mejoras de plan;
- el crecimiento posterior de registros elegibles.
No debe decidir:
- Standard, Managed o Custom Service;
- si se necesita un Add-on;
- si una estructura de datos personalizada es compatible;
- si la implementación de la plataforma de destino está incluida;
- si el resultado de la migración es aceptable.
Estas decisiones requieren evidencia de alcance, análisis de responsabilidades y validación. Un total preciso de Entity Points es necesario para el precio, pero no sustituye la comprensión de los datos.
Esta distinción evita dos errores de planificación opuestos. Una tienda puede necesitar un Entity Points Plan mayor y seguir siendo sencilla de migrar, o puede caber en un plan más pequeño y contener relaciones personalizadas que exijan una revisión más profunda. Por tanto, capacidad y complejidad deben evaluarse conjuntamente, pero nunca tratarse como la misma medida.
Conclusión
Dentro de los Migration Services de Next-Cart, Entity Points convierte las cantidades de Product, Customer, Order y Blog Posts en capacidad de migración ponderada. La estimación de compra ayuda a elegir el plan, la capacidad del plan define el límite disponible y los registros elegibles que se migran correctamente determinan el consumo real.
La disciplina central de planificación consiste en mantener las distinciones. Capacidad no es complejidad. Los recuentos estimados no son filtros. La secuencia de migración no es la secuencia de Entity Points. Una acción posterior no consume automáticamente puntos otra vez por registros que ya fueron contabilizados dentro de la migración adquirida y su ruta fija.
Con estas distinciones claras, Entity Points se convierte en una herramienta útil de planificación en lugar de una puntuación engañosa del proyecto completo.
Preguntas frecuentes
¿Qué registros cuentan para Entity Points?
Product, Customer, Order y Blog Posts son los cuatro tipos de datos contabilizados.
¿Cómo se calculan los Entity Points?
Product tiene un peso fijo de 1.0, Customer de 0.5, Order de 0.8 y Blog Posts de 0.6.
¿Las cantidades introducidas durante la compra limitan qué registros migran?
No. Sirven para la estimación y selección del plan. No actúan como filtros de registros.
¿Qué ocurre si el consumo real es mayor que la estimación?
La migración puede continuar mientras exista capacidad suficiente en el plan. Si se agota, el procesamiento se detiene hasta que haya capacidad adicional disponible.
¿Los Entity Points no utilizados pueden servir para actividad de migración posterior?
Sí. La capacidad restante puede utilizarse para registros elegibles que se migren más adelante dentro de la migración adquirida y la ruta fija.
¿Los registros vuelven a consumir Entity Points durante una acción posterior?
No cuando esos mismos registros contabilizados ya fueron registrados dentro de la migración adquirida y la ruta fija. Los registros elegibles nuevos consumen puntos cuando se migran correctamente por primera vez.
¿Categories, Reviews o CMS Pages consumen Entity Points?
No consumen Entity Points de forma independiente. Aun así, pueden ser partes importantes del alcance de migración compatible y de la validación.