Add-ons

Los requisitos de migración suelen situarse entre dos extremos. La migración compatible predeterminada puede ser estructuralmente adecuada y, aun así, el negocio puede necesitar mayor control sobre qué registros se trasladan, en qué destino se guarda un valor concreto o cómo deben modificarse determinados valores antes de llegar a la tienda de destino. Ese es el papel de los Add-ons dentro de los Migration Services de Next-Cart.

La decisión importante no consiste simplemente en determinar si el nombre de un Add-on parece relacionado con el requisito. Cada Add-on resuelve un tipo distinto de problema de tratamiento de datos, y varios Add-ons pueden trabajar juntos cuando un mismo requisito de migración incluye varias etapas. Comprender estas diferencias ayuda a separar las mejoras compatibles del trabajo más amplio que corresponde a Custom Service.

Los Add-ons resuelven problemas acotados de tratamiento de datos

Los Add-ons amplían el funcionamiento compatible de la migración sin cambiar la ruta de migración fundamental. Un buen requisito de Add-on parte del resultado empresarial que debe obtenerse y después identifica la operación concreta necesaria para alcanzarlo.

Cuatro preguntas permiten distinguir claramente los Standard Add-ons:

• ¿Qué registros deben continuar en la migración? Es una cuestión de Data Filter.
• ¿Qué campo compatible de destino debe recibir un campo de origen compatible? Es una cuestión de Advanced Data Mapping.
• ¿El requisito necesita mapeo compatible de campos o columnas de base de datos cuando tanto la plataforma de origen como la de destino son Open-Source? Es una cuestión de Advanced Database Mapping.
• ¿Cómo debe modificarse el valor de un campo de destino seleccionado durante la migración? Es una cuestión de Data Transformation.

Estas funciones están relacionadas, pero no son intercambiables. El filtrado cambia qué registros forman parte del alcance. El mapeo cambia el destino. El mapeo de base de datos puede trabajar en la capa subyacente de base de datos dentro de sus límites compatibles. La transformación cambia el valor seleccionado en destino.

Cuatro Standard Add-ons para cuatro decisiones distintas

La forma más clara de entender los cuatro Standard Add-ons es observar qué parte del resultado de migración controlan. No son cuatro versiones de la misma función. Uno controla qué registros participan, dos controlan dónde se representan valores compatibles y uno controla en qué se convierte el valor final de destino.

Standard Add-on	Función principal	Indicador de buen encaje	Función dentro de un flujo combinado	Precio fijo
Data Filter	Elegir qué registros migran aplicando condiciones compatibles basadas en campos a un tipo de datos.	El negocio necesita únicamente un subconjunto definido de registros que, de otro modo, serían elegibles.	Se ejecuta primero y establece la población de registros que recibirán todos los Add-ons posteriores.	$50
Advanced Data Mapping	Remapear un campo de origen compatible hacia un campo de destino compatible sin modificar el valor como parte de la operación de mapeo.	El valor de origen ya es correcto, pero debe guardarse en otro campo compatible de destino.	Se ejecuta después del filtrado y establece los destinos de campos compatibles antes del mapeo a nivel de base de datos.	$50
Advanced Database Mapping	Mapear campos compatibles y columnas subyacentes de base de datos hacia campos o columnas compatibles de destino, incluidos campos elegibles específicos de plataforma y personalizados.	El requisito depende de una representación a nivel de base de datos y no únicamente de la capa de campos compatibles.	Se ejecuta después de Advanced Data Mapping y puede establecer el valor o destino que Data Transformation recibirá a continuación. Solo está disponible cuando ambas plataformas son Open-Source.	$100
Data Transformation	Transformar valores seleccionados de campos de destino durante la migración.	El valor final en destino debe recalcularse, normalizarse, reformatearse o modificarse de otro modo mediante una regla compatible.	Se ejecuta al final y trabaja con el valor de destino disponible después de las etapas de mapeo.	$50

La tabla resulta útil porque un mismo requisito empresarial puede contener varias de estas señales a la vez. Una petición como «migrar solo estos Products, colocar un valor de origen en otro campo, usar un valor personalizado de base de datos como Price y después aplicar un margen» no es un único problema impreciso de personalización. Son cuatro operaciones distintas que pueden evaluarse por separado y después combinarse en el orden de procesamiento necesario.

Data Filter: controlar qué registros participan

Data Filter es el punto de partida adecuado cuando el negocio puede describir qué registros deben formar parte del resultado de la migración mediante condiciones compatibles basadas en campos.

Entre las preguntas habituales están:

• ¿Deben incluirse únicamente los Products activos?
• ¿Deben limitarse los Orders a un periodo comercial o una condición de estado definidos?
• ¿Deben continuar únicamente los Customers que cumplan una condición de campo acordada?
• ¿Debe limitarse un tipo de datos de contenido a los registros relevantes para la nueva tienda?

El límite importante es que Data Filter cambia la participación de los registros, no el campo de destino ni el valor del registro. Un Product excluido por el filtro nunca llega al procesamiento de Add-ons posteriores dentro de ese alcance de migración. Un Product que supera el filtro continúa con sus datos compatibles disponibles para las etapas posteriores de mapeo y transformación.

Esto hace que Data Filter sea especialmente importante en requisitos combinados. Si una regla posterior de mapeo o transformación debe afectar solo a una parte del catálogo, el filtrado establece esa población desde el principio, en lugar de pedir a un Add-on posterior que diferencie registros que no está diseñado para seleccionar.

Entity Points sigue siendo un concepto de capacidad independiente. Products, Customers, Orders y Blog Posts pueden consumir Entity Points según sus pesos contabilizados, pero una cantidad de Entity Points no identifica qué registros concretos deben migrar. Data Filter resuelve esa decisión de selección.

Casos de uso independientes de Data Filter

Caso de uso: migrar únicamente Products habilitados. Un comerciante está retirando registros de catálogo descatalogados y deshabilitados y quiere que el alcance incluya únicamente Products cuyo campo de estado compatible indique que están habilitados. Data Filter es el control pertinente porque la decisión empresarial se refiere a qué registros de Product participan, no a dónde se mapean sus valores ni a cómo se modifican. La condición exacta sigue dependiendo de los campos y operadores compatibles con la ruta de migración seleccionada.

Caso de uso: limitar Orders a un periodo comercial definido. Un negocio puede necesitar únicamente Orders creados después de una fecha acordada para el proyecto de migración, mientras que Orders históricos anteriores quedan fuera del alcance previsto. Cuando el campo de fecha y la comparación necesarios son compatibles, Data Filter puede establecer esa población antes de evaluar reglas posteriores de mapeo o transformación. La decisión de filtrado no cambia el significado de los Orders seleccionados; determina qué registros continúan.

Advanced Data Mapping: conservar el valor y cambiar su destino compatible

Advanced Data Mapping encaja cuando el valor de origen es correcto pero el destino compatible en la plataforma de destino no lo es.

El modelo mental es una reasignación directa:

supported source field -> compatible target field

Por ejemplo, si la ruta de migración seleccionada admite tanto Product Short Description como Description, un requisito puede indicar que el valor de origen Short Description debe pasar a ser el Description de destino. El valor no necesita recalcularse. La migración necesita un destino compatible distinto.

Esta distinción resulta útil en la práctica:

• «Coloque este valor de origen compatible en ese campo de destino compatible» apunta a Advanced Data Mapping.
• «Cambie este valor antes de que llegue a la tienda de destino» apunta a Data Transformation.
• «El valor está en una columna subyacente de base de datos que requiere tratamiento a ese nivel» puede apuntar a Advanced Database Mapping cuando la ruta de plataformas sea elegible.

En un flujo combinado, Advanced Data Mapping recibe únicamente los registros que han superado Data Filter. Establece los destinos de campos compatibles antes de que se ejecuten Advanced Database Mapping y Data Transformation. Cuando etapas posteriores afectan a un destino relacionado o idéntico, la secuencia determina qué valor queda disponible para el procesamiento siguiente.

Advanced Data Mapping también tiene límites. El campo de origen y el de destino deben ser compatibles y admitidos, y los datos de Tax quedan fuera del alcance Standard de mapeo. Cambiar el destino tampoco garantiza que aplicaciones, temas, extensiones o lógica empresarial del lado de destino vayan a utilizar ese valor de una manera concreta.

Casos de uso independientes de Advanced Data Mapping

Caso de uso: utilizar Product Short Description como Description de destino. El texto de origen ya es correcto, pero la tienda de destino necesita ese valor compatible en otro campo compatible. Advanced Data Mapping encaja porque el requisito es un cambio directo de destino: Short Description -> Description. La operación de mapeo conserva el valor en lugar de reescribirlo.

Caso de uso: reasignar un valor de contacto compatible de Customer. Una migración puede contener un campo compatible de contacto de Customer cuyo valor deba llegar a otro campo compatible de contacto en destino porque las dos plataformas organizan la información de Customers de forma diferente. Cuando ambos campos son compatibles y el destino puede representar correctamente el valor de origen, Advanced Data Mapping puede realizar la reasignación sin convertir un problema de destino de campo en un requisito de transformación o Custom Service.

Advanced Database Mapping: trabajar con una representación elegible a nivel de base de datos

Advanced Database Mapping cobra relevancia cuando el requisito no puede describirse únicamente como el traslado de un campo de aplicación compatible hacia otro campo compatible. Amplía el mapeo compatible a campos y columnas subyacentes de base de datos elegibles, incluidos campos específicos de plataforma y personalizados que permanezcan dentro de la capacidad Standard.

Su disponibilidad es deliberadamente más limitada porque el tratamiento a nivel de base de datos depende de la arquitectura de ambos extremos de la migración. Tanto la plataforma de origen como la plataforma de destino deben ser Open-Source. Si cualquiera de las dos es Non-Open-Source, Advanced Database Mapping no está disponible.

Esa condición arquitectónica responde únicamente a la primera pregunta de elegibilidad. Una ruta de plataformas elegible no hace que todos los campos o columnas sean mapeables automáticamente. El requisito concreto todavía debe comprobarse en cuanto a:

• participación compatible del campo o columna de base de datos de origen;
• existencia de un campo o columna de destino compatible;
• compatibilidad suficiente del tipo de valor;
• relaciones y significado de los datos compatibles;
• exclusión de los datos de Tax del alcance Standard de mapeo.

Por tanto, este Add-on resulta especialmente útil cuando el negocio puede identificar con claridad el valor a nivel de base de datos que debe conservarse, el lugar compatible que debe ocupar en la tienda de destino y la evidencia que demostrará que el resultado mapeado es útil.

Dentro de la secuencia, Advanced Database Mapping se ejecuta después de Advanced Data Mapping y antes de Data Transformation. Esta posición importa cuando el mapeo a nivel de base de datos establece un valor que después debe recalcularse o reformatearse. Data Transformation recibe el resultado disponible después de ambas etapas de mapeo, de modo que el mapeo de base de datos puede convertirse en la entrada directa de la regla final que modifica el valor.

El mapeo de base de datos también sigue siendo independiente de la implementación en destino. Guardar correctamente un valor en un campo o columna compatible no demuestra que un tema, extensión, flujo de aplicación, regla fiscal o función de la tienda online lo interprete o muestre como se espera. Esos resultados necesitan su propia validación.

Casos de uso independientes de Advanced Database Mapping

Caso de uso: utilizar una columna numérica personalizada y compatible de Product como valor de precio en destino. En una ruta elegible Open-Source hacia Open-Source, un comerciante puede tener una columna personalizada y compatible de base de datos, como regional_base_price, que debe rellenar un campo o columna de precio compatible en destino. Advanced Database Mapping es relevante porque el origen del valor se encuentra en la capa de base de datos. La condición arquitectónica no es suficiente por sí sola: también deben confirmarse la columna exacta de origen, el destino, la compatibilidad del Value Type y el alcance Standard.

Caso de uso: conservar un valor compatible de base de datos específico de la plataforma. Una plataforma de origen Open-Source puede almacenar un valor importante de Product en una columna específica de base de datos en lugar de hacerlo en la capa estándar de campos. Si la plataforma de destino Open-Source seleccionada dispone de un destino compatible y el requisito sigue siendo un mapeo directo que conserva el valor, Advanced Database Mapping puede trasladarlo al campo o columna de destino previsto. Esto no implica que todos los temas, aplicaciones, extensiones o flujos de trabajo de destino vayan a utilizar automáticamente el valor almacenado.

Data Transformation: cambiar el valor final de destino

Data Transformation encaja cuando el destino ya está definido pero el valor que debe existir allí necesita cambiar.

Entre los patrones habituales están:

• aplicar una regla aritmética a un valor numérico;
• añadir, eliminar o reestructurar texto mediante una expresión compatible;
• normalizar valores hacia una representación acordada en destino;
• calcular un valor final a partir de datos establecidos por una etapa de mapeo anterior.

La distinción más clara es sencilla: el mapeo responde ¿dónde debe ir este valor?. La transformación responde ¿en qué debe convertirse el valor resultante?.

Como Data Transformation se ejecuta al final, trabaja con el valor disponible en destino después de Advanced Data Mapping y, cuando corresponda, Advanced Database Mapping. Esto lo hace especialmente útil como etapa final de un requisito compuesto. Si el mapeo a nivel de base de datos establece el Price de destino, por ejemplo, una transformación posterior puede calcular el Price final a partir de ese valor mapeado en lugar de utilizar otro valor anterior de origen.

Data Transformation no elige qué registros participan y no decide qué campo o columna de destino debe recibir un valor de origen. Esas decisiones corresponden a las etapas anteriores. Por tanto, una transformación bien definida parte de un campo de destino conocido, un valor de entrada conocido después del mapeo y una regla compatible y clara para obtener el resultado previsto.

Casos de uso independientes de Data Transformation

Caso de uso: aumentar en un 12 por ciento el precio resultante en destino. Un comerciante puede querer que Regular Price en destino sea un 12 por ciento superior al valor establecido por la etapa de mapeo anterior. Data Transformation encaja porque el destino ya está definido y el valor resultante debe cambiar. Un cálculo compatible como Regular Price x 1.12 es, por tanto, una transformación y no una decisión de mapeo.

Caso de uso: normalizar un valor de texto en destino. El origen y el destino pueden representar el mismo valor empresarial mediante convenciones de texto distintas. Cuando una regla de transformación compatible puede normalizar el texto final de destino hacia la representación requerida, Data Transformation es el Add-on adecuado. La regla se aplica al valor disponible en destino después de las etapas de mapeo aplicables; no selecciona registros ni decide qué campo de destino debe recibir el valor de origen.

Por qué importa el orden de procesamiento de los Add-ons

Cuando se utilizan varios Add-ons juntos, se procesan en un orden fijo:

Data Filter → Advanced Data Mapping → Advanced Database Mapping → Data Transformation

La secuencia ofrece una forma útil de razonar sobre requisitos de migración compuestos:

1. Selección: ¿Qué registros pueden continuar?
2. Destino del campo: ¿Dónde deben representarse los campos de origen compatibles?
3. Destino a nivel de base de datos: ¿Una migración elegible Open-Source hacia Open-Source necesita mapeo compatible de campos o columnas más allá de la capa estándar de campos?
4. Valor final: ¿En qué debe convertirse el valor de destino una vez completado el mapeo?

Cada etapa aplicable trabaja con el resultado establecido por las etapas anteriores. Esto no significa que todas las migraciones necesiten los cuatro Add-ons ni que todos deban afectar al mismo campo. Significa que el requisito debe diseñarse como un recorrido ordenado de los datos y no como reglas independientes configuradas de forma aislada.

Combinaciones habituales de Add-ons

Muchos requisitos reales necesitan únicamente dos o tres etapas. Reconocer el patrón facilita evaluar el encaje antes de concluir que hace falta trabajo personalizado.

Patrón del requisito empresarial	Combinación probable de Add-ons	Por qué encaja la combinación
Migrar solo un subconjunto definido de registros y después modificar uno de sus valores de destino.	Data Filter + Data Transformation	El filtrado define qué registros participan; la transformación modifica el valor necesario únicamente para esos registros.
Enviar un campo de origen compatible a otro campo compatible de destino y después modificar el valor resultante.	Advanced Data Mapping + Data Transformation	El mapeo establece el destino; la transformación trabaja después sobre el valor disponible allí.
Utilizar un valor elegible a nivel de base de datos como valor de destino y después aplicar un cálculo o una regla de normalización.	Advanced Database Mapping + Data Transformation	El mapeo de base de datos establece el valor de destino; la transformación produce el valor final. Ambas plataformas deben ser Open-Source para la etapa de mapeo de base de datos.
Limitar los registros, redirigir campos compatibles y después modificar los valores resultantes de destino.	Data Filter + Advanced Data Mapping + Data Transformation	El flujo combina alcance de registros, control de destino y cambio del valor final sin necesitar mapeo a nivel de base de datos.
Limitar los registros, aplicar mapeo compatible de campos, utilizar mapeo elegible de base de datos y después transformar el resultado final.	Los cuatro Standard Add-ons	Cada etapa resuelve una parte distinta de un requisito compuesto y alimenta la siguiente etapa pertinente.

La presencia de varias etapas no convierte por sí sola el proyecto en un caso de Custom Service. Si cada operación permanece dentro del alcance Standard compatible de su Add-on, el requisito combinado puede seguir resolviéndose con Standard Add-ons. El tratamiento personalizado cobra relevancia cuando una de esas operaciones necesita modificación, interpretación de datos no compatibles, lógica a medida u otra capacidad fuera de los límites Standard.

Un método práctico de planificación consiste en trabajar hacia atrás desde el resultado previsto en la tienda de destino. Identifique primero el valor o la representación final y determine después si necesita transformación, mapeo de base de datos, mapeo de campos, filtrado de registros o una combinación de estos controles.

Ejemplo: los cuatro Add-ons se complementan para resolver un requisito real de migración

Considere una migración OpenCart hacia WooCommerce en la que los campos de Product necesarios son compatibles y la columna personalizada seleccionada supera las comprobaciones aplicables de mapeo y compatibilidad. Ambas son plataformas Open-Source, por lo que la ruta puede evaluarse para Advanced Database Mapping.

El comerciante quiere conseguir cuatro resultados relacionados:

• migrar únicamente Products habilitados y que todavía tengan stock;
• utilizar Short Description del origen como Description en destino;
• utilizar una columna numérica personalizada y compatible de base de datos de Product llamada regional_base_price como Regular Price de destino;
• aumentar ese Regular Price resultante en un 12 por ciento durante la migración.

Ningún Add-on por sí solo resuelve el requisito completo.

Etapa 1: seleccionar los registros de Product

Data Filter aplica las condiciones acordadas de Product, por ejemplo un estado habilitado y una cantidad de stock superior a cero. Los Products que no cumplen las condiciones no continúan por el procesamiento de los Add-ons restantes dentro de este alcance de migración.

El filtro resuelve únicamente el problema de selección. No decide cómo se representan las descripciones o los precios en la tienda de destino.

Etapa 2: redirigir el campo compatible de descripción

Advanced Data Mapping mapea el campo compatible de origen Short Description hacia el campo compatible de destino Description.

Esto cambia el destino del valor compatible y mantiene la operación de mapeo separada de cualquier modificación posterior del valor.

Etapa 3: establecer el precio desde un origen a nivel de base de datos

Advanced Database Mapping mapea el valor numérico personalizado y compatible regional_base_price de la base de datos hacia el destino compatible Regular Price.

Esta etapa solo es posible en el ejemplo porque ambos extremos de la ruta de migración son plataformas Open-Source y se presupone que el requisito concreto de campo o columna supera las comprobaciones de elegibilidad del Standard Add-on. No debe asumirse que una columna personalizada es elegible únicamente porque existe Advanced Database Mapping.

Etapa 4: calcular el precio final de destino

Data Transformation aplica después el cálculo requerido a Regular Price, por ejemplo:

Regular Price x 1.12

Como Data Transformation se ejecuta después de ambas etapas de mapeo, trabaja sobre el Regular Price establecido por Advanced Database Mapping y no sobre otro valor anterior de precio que ya no sea la entrada relevante.

El resultado final demuestra por qué los Add-ons deben evaluarse como una secuencia de procesamiento coordinada. Data Filter define qué Products participan, las etapas de mapeo establecen dónde se representa la información pertinente y Data Transformation produce el precio calculado final.

El resultado migrado todavía necesita validación. El ejemplo demuestra el tratamiento de datos, no garantiza que todas las reglas posteriores de precios, temas, extensiones, comportamiento fiscal o presentación de la tienda online queden configuradas automáticamente por la migración.

Cómo interactúan los Add-ons cuando afectan a los mismos datos

Los Add-ons combinados pueden interactuar de varias maneras. Comprender el patrón es más importante que limitarse a contar cuántos Add-ons participan.

Patrón de interacción	Qué ocurre conceptualmente	Implicación para el lector
Mismos registros, campos diferentes	Data Filter establece los registros participantes, mientras que reglas separadas de mapeo o transformación afectan a campos distintos dentro de esos registros.	Los Add-ons quedan coordinados por el alcance de registros aunque no afecten al mismo destino.
Etapas de mapeo diferentes, mismo destino	Advanced Data Mapping y Advanced Database Mapping pueden contribuir a cómo se establece un destino. La última etapa de mapeo aplicable determina el valor disponible para el procesamiento posterior.	Las reglas de mapeo que se solapan deben expresar una estrategia deliberada para el dato final y no intenciones independientes.
Mapeo seguido de transformación	Una etapa de mapeo establece el valor o destino y después Data Transformation modifica el valor que existe tras el mapeo.	Las reglas de transformación deben diseñarse para el resultado mapeado y no para un valor anterior de origen que ya no sea la entrada relevante.
Filtrado y procesamiento posterior	Data Filter excluye registros de la población participante antes de cualquier mapeo o transformación.	Los Add-ons posteriores deben evaluarse sobre la población filtrada que realmente llegará hasta ellos.

Este modelo de interacción facilita revisar requisitos compuestos. Un comerciante puede separar una petición empresarial en alcance de registros, destino, representación a nivel de base de datos y lógica del valor final, y después comprobar si esas piezas se refuerzan entre sí o crean supuestos contradictorios.

El caso más sensible aparece cuando varias reglas de mapeo afectan al mismo campo o columna de destino. En esa situación, el orden de procesamiento determina el valor disponible para Data Transformation. El diseño más seguro parte del valor final previsto en la tienda de destino y recorre la secuencia hacia atrás, confirmando qué etapa debe establecer cada resultado intermedio.

Esa revisión inversa también es útil cuando los Add-ons afectan a campos diferentes. Puede revelar reglas innecesarias, destinos que no representan adecuadamente el significado del origen, transformaciones que esperan una entrada equivocada o registros que deberían haberse excluido antes de comenzar el procesamiento posterior.

La compatibilidad es más que hacer coincidir nombres de campos

Un campo de origen y uno de destino pueden tener etiquetas parecidas sin ser compatibles. Las decisiones de mapeo deben considerar si la plataforma de destino puede representar correctamente el valor de origen.

Para los Add-ons de mapeo, el campo o columna de destino debe tener suficiente capacidad de tipo de valor para representar el valor de origen. Un valor numérico de origen suele poder representarse en un destino de texto, mientras que un texto arbitrario no puede tratarse con seguridad como número simplemente porque algunos valores de muestra parezcan numéricos. Cuando la compatibilidad no está clara, debe validarse en lugar de asumirse.

Los Add-ons de mapeo también tienen límites funcionales. Los datos de Tax quedan fuera del alcance compatible de Advanced Data Mapping y Advanced Database Mapping. Los requisitos que incluyan tipos de datos, campos, columnas, relaciones, scripts o comportamiento de aplicaciones no compatibles pueden necesitar Tailored Add-on, Custom Add-on o una revisión más amplia de Custom Service.

Standard, Tailored y Custom Add-ons

La función necesaria y el grado de personalización necesario son decisiones distintas.

Nivel de Add-on	Significado	Tratamiento del precio
Standard Add-on	Add-on predefinido utilizado dentro de su alcance fijo compatible.	Precio fijo de catálogo.
Tailored Add-on	Función de un Standard Add-on que necesita ajustes, modificación o ampliación de alcance más allá de la capacidad Standard.	Se revisa y cotiza mediante Custom Service.
Custom Add-on	Funcionalidad de Add-on a medida fuera del alcance funcional del catálogo de Standard Add-ons.	Se revisa y cotiza mediante Custom Service.

Un requisito no se convierte en Custom Service simplemente porque combine varios Standard Add-ons. Si cada operación encaja en su alcance Standard aplicable, el flujo combinado puede seguir estando formado íntegramente por Standard Add-ons.

Del mismo modo, las expresiones custom field o database column no convierten automáticamente el proyecto en personalizado. El requisito debe comprobarse primero frente al alcance compatible de Advanced Data Mapping o Advanced Database Mapping. Custom Service cobra relevancia cuando el resultado necesario supera lo que esos controles compatibles pueden ofrecer.

Add-ons y Custom Service resuelven problemas diferentes

Los Add-ons cubren requisitos acotados de tratamiento de datos. Custom Service se ocupa de trabajo más amplio, adaptado o no estándar cuando el requisito no puede satisfacerse dentro del funcionamiento compatible de la migración y los Standard Add-ons.

Custom Service cobra relevancia cuando la operación requerida deja de encajar en el modelo acotado de Standard Add-ons. Entre las señales habituales están datos no compatibles de aplicaciones o extensiones de terceros, scripts a medida o procesamiento mediante API, relaciones o lógica de migración no estándar y funcionalidad de Add-on que deba adaptarse o desarrollarse más allá del catálogo Standard. El alcance no estándar más amplio se trata en la guía específica de Custom Service; la decisión importante aquí es reconocer cuándo un Add-on por sí solo deja de describir el trabajo necesario.

Una migración también puede utilizar Standard Add-ons dentro de un alcance más amplio de Custom Service. La presencia de Custom Service no cambia lo que hace cada Add-on; cambia el tratamiento adicional necesario para el trabajo específico del proyecto.

Cómo se relacionan los Add-ons con Entity Points y los precios

Entity Points y Add-ons responden a preguntas de planificación diferentes.

Entity Points mide la capacidad contabilizada para Products, Customers, Orders y Blog Posts. Los Add-ons controlan comportamientos de procesamiento compatibles concretos. Un Add-on no crea un nuevo peso de Entity Points, y un tipo de datos no contabilizado no pasa a contabilizarse únicamente porque se utilice un Add-on con él.

Los precios fijos de Standard Add-ons mostrados en el catálogo anterior son independientes de la capacidad de Entity Points. Tailored Add-ons y Custom Add-ons no utilizan esos precios fijos Standard como cotización final del proyecto porque su trabajo adicional se revisa mediante Custom Service.

Cuando un Add-on elegible se añade más adelante a la misma migración adquirida, la mejora aplicable sigue el principio de pagar únicamente la diferencia. El Add-on modifica el paquete de servicio de esa migración; no cambia la ruta fija desde la plataforma de origen hasta la plataforma de destino ni reinicia la duración del servicio.

Cómo evaluar si un Add-on encaja con un requisito real

Una evaluación útil empieza por el resultado deseado en la tienda de destino, no por los nombres de los Add-ons. Después, el requisito empresarial puede dividirse en las decisiones que controlan realmente las cuatro etapas.

Pregunta de evaluación	Qué revela la respuesta
¿Qué registros deben participar en el resultado?	Si se necesita Data Filter.
¿El valor de origen ya es correcto pero debe ir a otro campo compatible de destino?	Si se necesita Advanced Data Mapping.
¿El requisito depende de un campo o columna subyacente de base de datos y ambas plataformas son Open-Source?	Si debe evaluarse Advanced Database Mapping.
Una vez completado el mapeo, ¿debe cambiar el propio valor de destino?	Si se necesita Data Transformation.
¿Qué evidencia demostrará que el valor, destino, relación y significado empresarial resultantes son correctos?	Qué debe validarse antes de considerar que el requisito se ha cumplido.

El lenguaje utilizado en un requisito suele ofrecer pistas útiles. Palabras como incluir, excluir, únicamente o condición suelen describir selección de registros. Mapear, colocar, enviar o destino suelen describir mapeo de campos. Las referencias a columnas de base de datos, campos específicos de plataforma o campos personalizados pueden requerir Advanced Database Mapping cuando la ruta completa y el alcance compatible cumplen los requisitos. Calcular, normalizar, añadir, eliminar, convertir o reestructurar suelen indicar transformación del valor.

Son señales de diagnóstico, no aprobaciones automáticas. Un campo con un nombre adecuado puede seguir teniendo un Value Type incompatible. Un campo personalizado puede encajar en un Standard Add-on de mapeo, mientras que otro puede depender de lógica no compatible y requerir Custom Service. Una migración Open-Source hacia Open-Source puede cumplir el requisito arquitectónico de Advanced Database Mapping y, aun así, la columna concreta puede quedar fuera del alcance compatible.

Por ello, el requisito más sólido describe cinco elementos a la vez: el tipo de datos y los registros afectados, el valor de origen, el destino previsto, cualquier regla final de valor y la evidencia que confirmará el resultado. Cuando estos elementos están explícitos, la combinación de Add-ons puede evaluarse frente a sus límites compatibles en lugar de seleccionarse solo por el nombre de la función.

Este enfoque centrado en el resultado evita dos errores opuestos. Impide escalar un requisito compatible a Custom Service únicamente porque intervienen varios controles, y también impide forzar un Standard Add-on más allá de su función compatible solo porque su nombre parece relacionado con la necesidad.

Conclusión

Los Add-ons de Next-Cart son más útiles cuando se entienden como etapas distintas dentro de un mismo modelo compatible de tratamiento de datos y no como una lista de funciones independientes. Data Filter selecciona registros, Advanced Data Mapping cambia destinos compatibles de campos, Advanced Database Mapping amplía el mapeo elegible a campos y columnas de base de datos cuando tanto la plataforma de origen como la plataforma de destino son Open-Source, y Data Transformation modifica los valores resultantes en destino.

Su orden fijo de procesamiento forma parte de la decisión. Cada etapa aplicable trabaja con el resultado establecido anteriormente, por lo que los requisitos combinados deben diseñarse en torno al resultado final previsto en la tienda de destino y validarse como un flujo coordinado.

Los Standard Add-ons siguen siendo capacidades compatibles y acotadas. Cuando la función necesaria exige modificación, lógica ampliada, desarrollo a medida o tratamiento no compatible, el requisito pasa a Tailored Add-on, Custom Add-on o un alcance más amplio de Custom Service, en lugar de ampliar artificialmente la capacidad Standard más allá de sus límites previstos.

Preguntas frecuentes

¿Cómo puede saber un negocio si necesita un Add-on o varios?

Divida el requisito en selección de registros, destino de campos, representación a nivel de base de datos y cambio del valor final. Si el resultado empresarial contiene más de una de estas operaciones, puede ser adecuado utilizar varios Add-ons. El número importa menos que comprobar que cada etapa resuelve una parte distinta y compatible del mismo resultado.

¿Se pueden utilizar varios Standard Add-ons en una misma migración sin Custom Service?

Sí. Combinar varios Standard Add-ons no convierte por sí solo la migración en un caso de Custom Service. Cada operación debe permanecer dentro del alcance Standard compatible de su Add-on, las etapas deben formar una estrategia de procesamiento coherente y el resultado combinado debe validarse frente al resultado empresarial previsto.

¿Importa el orden de los Add-ons cuando se utilizan varios?

Sí. La secuencia es Data Filter, Advanced Data Mapping, Advanced Database Mapping y después Data Transformation. Cada etapa aplicable trabaja con el resultado establecido por las anteriores, por lo que las reglas que se solapan deben planificarse como una sola secuencia.

¿Advanced Database Mapping está disponible si solo la plataforma de destino es Open-Source?

No. Tanto la plataforma de origen como la plataforma de destino deben ser Open-Source para que Advanced Database Mapping esté disponible. Si cualquiera de las dos es Non-Open-Source, el Add-on no está disponible.

¿Cuál es la diferencia entre Advanced Data Mapping y Data Transformation?

Advanced Data Mapping cambia el destino compatible de un campo de origen compatible sin modificar el valor como parte de la operación de mapeo. Data Transformation modifica el propio valor seleccionado de destino. Cuando se utilizan ambos, el mapeo establece dónde debe quedar el valor antes de que la transformación aplique la regla final compatible que lo modifica.

¿Pueden dos Add-ons de mapeo afectar al mismo destino?

Pueden formar parte de un requisito que converja en el mismo destino, pero las reglas deben diseñarse como una sola secuencia y no como mapeos independientes. Advanced Database Mapping se ejecuta después de Advanced Data Mapping, por lo que el valor establecido por la etapa de mapeo aplicable posterior es el que queda disponible para Data Transformation.

¿Un campo personalizado o una columna de base de datos puede seguir encajando en un Standard Add-on?

Potencialmente sí. Un campo personalizado o una columna de base de datos debe evaluarse primero frente al alcance compatible de Advanced Data Mapping o Advanced Database Mapping. La palabra custom no significa automáticamente Custom Service, aunque el funcionamiento no compatible o a medida sigue necesitando revisión adicional.

¿Advanced Data Mapping y Advanced Database Mapping admiten datos de Tax?

No. Los datos de Tax están fuera del alcance compatible de ambos Add-ons de mapeo.

¿Los Add-ons cambian el cálculo de Entity Points?

No. Entity Points sigue utilizando el modelo contabilizado de Products, Customers, Orders y Blog Posts. Los Add-ons afectan al comportamiento de procesamiento compatible y a los precios de forma independiente de la capacidad de Entity Points.

¿Cuándo debe pasar un requisito de Add-on a Custom Service?

Custom Service es adecuado cuando el requisito supera las capacidades compatibles de la migración Standard y los Add-ons, incluidos trabajos de Tailored Add-on o Custom Add-on y otra lógica de tratamiento de datos a medida o no compatible. El factor decisivo es el límite compatible, no la mera presencia de varios Add-ons, un campo personalizado o una columna de base de datos.