Cuando se evalúa VTEX como plataforma de destino, el riesgo no consiste únicamente en transferir registros desde la Store de origen. VTEX distribuye el funcionamiento del comercio entre Catalog, Pricing, Promotions, Trade Policies, Marketplace, Checkout, Logistics, Orders, Master Data, implementación de Storefront e integraciones externas. Esta arquitectura permite operaciones complejas, pero también crea un riesgo específico durante la migración: un registro puede existir correctamente en un módulo mientras siguen incompletas las relaciones que otro módulo necesita para que el negocio funcione.
Un Product puede parecer activo en administración y, aun así, carecer de un SKU vendible, una specification heredada, un precio válido, una offer del seller, una ruta de inventario o una representación correcta en Storefront. Un Order puede conservarse y ser legible mientras el Checkout, Payments y Logistics actuales siguen sin relación con ese historial. Por ello, el control de riesgos debe seguir cada supuesto desde la restricción de plataforma hasta la consecuencia para la migración, el impacto operativo, la mitigación, el responsable y la señal que permite validar el resultado.
La estructura Product-SKU puede fallar sin dejar registros vacíos
VTEX Catalog se organiza alrededor de Categories, Brands, Products, SKUs y specifications. Un Product debe estar asociado con una Category y una Brand y contar con al menos un SKU, mientras que el SKU representa la variación física o unidad vendible. En la Store de origen, la misma realidad puede estar modelada mediante Products padres, Products hijos, matrices libres de opciones, conjuntos o inventario basado en atributos.
| Elemento de la cadena de riesgo | Interpretación específica en VTEX |
|---|---|
| Supuesto | Un Product del origen y sus opciones pueden copiarse en un único registro de Product de VTEX. |
| Restricción de plataforma | VTEX separa la identidad del Product de la identidad del SKU, imágenes, activación, stock, precio, offer del seller y SKU specifications. |
| Consecuencia para la migración | La información del Product padre se conserva, pero los SKUs vendibles, imágenes, identificadores o relaciones de variación quedan incompletos. |
| Impacto operativo | Los Products aparecen en administración, pero no pueden comprarse, encontrarse, mostrarse con el precio correcto o prepararse correctamente. |
| Orientación de mitigación | Defina el modelo Product-to-SKU antes de realizar la correspondencia de campos, incluidos Ref IDs, imágenes, lógica de variaciones y responsabilidad de cada unidad vendible. |
| Responsables afectados | Gobierno de Catalog, merchandising, inventario, precios, preparación de pedidos e integraciones. |
| Señal de control | Cada Product representativo contiene los SKUs activos previstos, sus imágenes, identificadores, specifications, precio, seller y contexto de disponibilidad. |
Los conjuntos, kits, services y marketplace offers del origen requieren interpretación independiente, porque su responsable operativo puede encontrarse fuera del Product padre.
La herencia de specifications puede desactivar SKUs o distorsionar Search
Las specifications de VTEX se crean dentro de grupos asociados con Categories. Product specifications y SKU specifications pueden heredarse a través de la jerarquía de Categories, y determinadas SKU specifications obligatorias pueden afectar a que los SKUs permanezcan activos. Las specifications también pueden sostener filtros y selectores de SKU.
| Elemento de la cadena de riesgo | Interpretación específica en VTEX |
|---|---|
| Supuesto | Los atributos del origen pueden añadirse de forma independiente a cada Product o SKU. |
| Restricción de plataforma | Los grupos y campos de specifications dependen de la Category, se heredan y pueden ser obligatorios para todos los SKUs afectados. |
| Consecuencia para la migración | Los campos se crean en un nivel incorrecto de Category, SKUs no relacionados los heredan o los SKUs afectados se desactivan porque faltan valores obligatorios. |
| Impacto operativo | Los filtros de Search se fragmentan, los selectores de SKU fallan y ramas completas del Catalog dejan de estar disponibles. |
| Orientación de mitigación | Diseñe los grupos de specifications, tipos de campo, nivel de herencia, obligatoriedad y valores antes de asociar registros. |
| Responsables afectados | Gobierno de Catalog, Search, merchandising, desarrollo de Storefront e integración de datos. |
| Señal de control | Cada rama de Category muestra solo los campos previstos, todos los valores obligatorios de SKU están presentes y filtros y selectores devuelven el surtido esperado. |
Product specifications y SKU specifications no deben fusionarse únicamente porque sus etiquetas coincidan en el origen. Una puede describir el Product mientras la otra diferencia unidades vendibles.
Las Trade Policies pueden ocultar el contexto comercial fuera del Product
Las Trade Policies de VTEX pueden definir el contexto de canal de ventas para surtido, precios y Logistics. Una Store de origen puede representar distinciones similares mediante websites, Customer groups, regiones, currencies, catálogos B2B o canales de marketplace. Un solo Product migrado no contiene por sí mismo todas estas reglas comerciales.
| Elemento de la cadena de riesgo | Interpretación específica en VTEX |
|---|---|
| Supuesto | Un Catalog de destino y un precio base pueden servir para todos los canales del origen. |
| Restricción de plataforma | La asociación de SKUs, el contexto de precio, Logistics y la disponibilidad por canal pueden depender de Trade Policy y de otras configuraciones comerciales relacionadas. |
| Consecuencia para la migración | Los Products se muestran en el canal equivocado, reciben un precio incorrecto o carecen de una ruta de entrega viable. |
| Impacto operativo | Compradores B2B y B2C ven surtidos incorrectos, las operaciones regionales entran en conflicto y se interrumpe el revenue del canal. |
| Orientación de mitigación | Cree una matriz de canales que relacione Trade Policy, surtido de SKUs, precios, seller, Logistics, moneda y elegibilidad de Customers. |
| Responsables afectados | Operaciones comerciales, ventas B2B, precios, equipos regionales, Logistics y administración de plataforma. |
| Señal de control | Los SKUs representativos se resuelven con el surtido, precio, seller y opciones de entrega previstos en cada canal activo. |
Consolidar canales del origen es posible, pero requiere una regla explícita que determine qué diferencias comerciales se retiran y cuáles seguirán activas.
La correspondencia de sellers y marketplace puede separar la offer del Catalog
En operaciones de marketplace de VTEX, los sellers envían SKU offers que deben asociarse con Brands, Categories y specifications del marketplace y pueden requerir aprobación. El seller posee o prepara el artículo, mientras que el marketplace posee Storefront y el contexto de venta. La plataforma de origen puede no separar estas responsabilidades con la misma claridad.
| Elemento de la cadena de riesgo | Interpretación específica en VTEX |
|---|---|
| Supuesto | Un seller Product puede importarse como un Product ordinario del marketplace sin correspondencia adicional. |
| Restricción de plataforma | Las offer del sellers requieren identidad de seller, correspondencia de Catalog, aprobación, precio, inventario, Logistics y relaciones de canal. |
| Consecuencia para la migración | Las offers se duplican, son rechazadas, se asocian al elemento de Catalog equivocado o se publican sin una ruta operativa válida del seller. |
| Impacto operativo | El surtido de marketplace se vuelve inconsistente, la responsabilidad sobre comisiones y preparación queda ambigua y los Orders se enrutan incorrectamente. |
| Orientación de mitigación | Conserve los IDs de seller y offer y defina responsabilidad sobre Brand, Category, specification, aprobación, comisión, precio, inventario y Logistics. |
| Responsables afectados | Operaciones de marketplace, gestión de sellers, gobierno de Catalog, finanzas y preparación de pedidos. |
| Señal de control | Cada offer del seller de muestra se asocia con un único SKU previsto del Catalog y conserva el seller, contexto comercial y responsabilidad de preparación correctos. |
Los Orders históricos de marketplace deben conservar evidencia del seller incluso cuando la configuración actual del seller cambie posteriormente.
Price, Promotion y disponibilidad pueden ser correctos por separado y fallar en conjunto
VTEX Catalog, Pricing, Promotions, offer del sellers, inventario y Logistics aportan partes distintas del resultado final de compra. Migrar un precio de Product a un módulo no demuestra que el comprador final vaya a recibir ese precio ni que pueda completar la compra del SKU.
| Elemento de la cadena de riesgo | Interpretación específica en VTEX |
|---|---|
| Supuesto | Conservar el precio y la cantidad de stock del origen conserva la disponibilidad comercial. |
| Restricción de plataforma | La posibilidad real de compra depende del contexto de precio, Trade Policy, seller, condiciones de Promotion, inventario, loading dock, carrier y ruta de entrega. |
| Consecuencia para la migración | Un SKU tiene precio pero carece de seller válido o ruta de Logistics, o recibe una Promotion no prevista en un canal. |
| Impacto operativo | Los compradores encuentran artículos no disponibles, totales incorrectos, opciones de entrega ausentes o pérdidas de margen. |
| Orientación de mitigación | Trate la offer comprable como una relación entre SKU, seller, precio, canal, elegibilidad de Promotion, inventario y Logistics. |
| Responsables afectados | Pricing, Promotions, marketplace, inventario, Logistics, finanzas y operaciones de ecommerce. |
| Señal de control | Contextos representativos de comprador producen conjuntamente el surtido, precio, descuento, seller, stock y opciones de entrega previstos. |
Un valor correcto de forma aislada no constituye una señal de control suficiente. La combinación comercial es la unidad real de riesgo.
La evidencia de Orders y OMS puede confundirse con preparación de Checkout y Logistics
Los Orders de VTEX conservan historial transaccional y contexto de OMS, mientras Checkout, pago, prevención de fraude, reserva de inventario, Logistics y configuración de preparación de pedidos controlan las nuevas transacciones. Por ello, un Order histórico legible no demuestra que las operaciones activas estén listas.
| Elemento de la cadena de riesgo | Interpretación específica en VTEX |
|---|---|
| Supuesto | Los Orders migrados demuestran que el comportamiento de pago, shipping y preparación de pedidos se conserva. |
| Restricción de plataforma | La evidencia histórica de Orders es independiente de la configuración actual de Checkout, proveedores de pago, fraude, Logistics, inventario y OMS. |
| Consecuencia para la migración | Etiquetas o referencias históricas se interpretan como configuración activa mientras las nuevas rutas transaccionales siguen incompletas. |
| Impacto operativo | El personal puede consultar Orders antiguos, pero los nuevos Orders fallan en pago, delivery, seller routing o preparación. |
| Orientación de mitigación | Conserve la evidencia histórica según su finalidad y asigne todo comportamiento transaccional actual al responsable operativo correspondiente en VTEX o en el sistema externo que lo gestione. |
| Responsables afectados | Atención al Customer, finanzas, Payments, fraude, Logistics, preparación de pedidos, marketplace y operaciones de ecommerce. |
| Señal de control | Los Orders históricos siguen siendo comprensibles y las nuevas transacciones representativas resuelven por separado responsabilidad de pago, inventario, seller y delivery. |
Orders refunded, cancelled, partially fulfilled y de marketplace revelan más riesgo que los Orders ordinarios completados porque contienen relaciones operativas más ricas.
Master Data puede ocultar registros críticos fuera de las entidades comerciales estándar
VTEX Master Data puede almacenar ampliaciones de Customer, registros B2B, envíos de formularios, perfiles operativos, campos de cumplimiento, estados de flujo de trabajo y objetos específicos de aplicaciones. Las tablas y campos personalizados del origen pueden tener poco volumen y, aun así, sostener decisiones esenciales para la operación.
| Elemento de la cadena de riesgo | Interpretación específica en VTEX |
|---|---|
| Supuesto | Los campos personalizados pueden añadirse a Products, Customers u Orders sin cambiar el alcance. |
| Restricción de plataforma | Schemas de Master Data, permisos, nombres de entidades, relaciones, índices y aplicaciones consumidoras determinan cómo se comportan los registros personalizados. |
| Consecuencia para la migración | Los valores se copian sin schema o referencias, o se fuerzan dentro de entidades estándar que no pueden sostener el flujo de trabajo. |
| Impacto operativo | Aprobación B2B, correspondencia con CRM, cumplimiento, formularios y procesos de aplicaciones pierden continuidad. |
| Orientación de mitigación | Inventaríe cada entidad, campo, relación, permiso, índice, consumidor e identificador externo antes de asignarle un responsable de destino. |
| Responsables afectados | Gobierno de datos, CRM, operaciones B2B, cumplimiento, equipos de aplicaciones e integraciones. |
| Señal de control | Cada registro personalizado prioritario puede consultarse desde el proceso que lo consume y resuelve al Product, Customer, Order o entidad externa previstos. |
Un volumen bajo de registros no convierte Master Data en un área de bajo riesgo. La densidad de relaciones y la importancia operativa pesan más que la cantidad.
La arquitectura de Storefront e integraciones puede hacer engañosa la aprobación del Catalog
Los Storefronts de VTEX pueden usar distintos patrones de CMS e implementación, incluidos enfoques headless. Search, filtros, páginas de Product, contenido, rutas, redirects, navegación, reseñas y personalización pueden depender de código de implementación y aplicaciones, no solo de registros de Catalog. APIs y sistemas externos pueden poseer por separado PIM, ERP, WMS, CRM, precios o sincronización de marketplace.
| Elemento de la cadena de riesgo | Interpretación específica en VTEX |
|---|---|
| Supuesto | Una vez presentes los registros de Catalog, la Store orientada al Customer y las integraciones los consumirán correctamente. |
| Restricción de plataforma | Componentes de Storefront, indexación de Search, rutas, aplicaciones, credenciales de API, eventos, identificadores y responsabilidad externa funcionan como contratos separados. |
| Consecuencia para la migración | Los Products existen, pero no se renderizan, no aparecen en Search, no se enlazan o no se sincronizan a través de la implementación prevista. |
| Impacto operativo | Se deteriora el descubrimiento de Products, fallan URLs prioritarias y sistemas externos sobrescriben o duplican datos ya aprobados. |
| Orientación de mitigación | Defina contratos de Storefront e integración para cada entidad: responsable, identificador, ruta, event, dirección, regla de conflictos y consumidor. |
| Responsables afectados | Ingeniería de Storefront, SEO, Search, contenido, ingeniería de integraciones, seguridad y gobierno de datos. |
| Señal de control | Products y contenido prioritarios se resuelven mediante las rutas y Search previstos, mientras eventos repetidos de integración actualizan una única entidad estable de VTEX. |
La preparación de Catalog, la preparación de Storefront y la preparación de integraciones son estados independientes, aunque dependan de los mismos registros de Product y SKU.
Conclusión
Las restricciones de una migración hacia VTEX nacen de la separación entre identidad de Product y SKU, herencia de specifications, Trade Policies, sellers, Pricing, Promotions, inventario, Logistics, Orders, Master Data, implementación de Storefront y sistemas externos. Un registro puede ser válido dentro de un módulo y, al mismo tiempo, seguir incompleta la relación comercial que necesita otro.
Una migración controlada hacia VTEX evalúa la cadena operativa completa. Conserva identidad de SKUs y sellers, diseña el alcance de specifications, asigna responsables por canal, distingue Orders históricos de configuración transaccional actual y protege relaciones con datos personalizados y sistemas externos. El riesgo queda contenido cuando los contextos previstos del comprador y del equipo operativo funcionan de forma conjunta, no simplemente cuando cada módulo contiene datos.
Preguntas frecuentes
¿Por qué puede existir un Product en VTEX y seguir sin estar disponible?
La disponibilidad depende de algo más que del registro de Product. El Product necesita SKUs viables, specifications obligatorias, imágenes, activación, precio, contexto de seller, inventario, asociación con Trade Policy y una ruta válida de Logistics.
¿Por qué las SKU specifications de VTEX representan un riesgo de alto impacto durante la migración?
Porque están asociadas con Categories, se heredan y los campos obligatorios pueden afectar a todos los SKUs de una rama de Category. Un campo colocado en el nivel equivocado o un valor ausente puede desactivar muchos SKUs y distorsionar filtros o selectores.
¿Las Trade Policies equivalen a los Customer groups del origen?
No necesariamente. Las Trade Policies pueden influir en surtido, precios y Logistics para un canal de ventas, mientras que los Customer groups del origen pueden combinar acceso, precios, impuestos o significado de cuenta. La relación debe diseñarse, no asumirse por similitud de nombre.
¿Por qué las offer del sellers deben mantenerse separadas de los Products del Catalog de VTEX?
El Catalog de marketplace posee la estructura visible para el comprador, mientras la offer del seller conserva contexto de seller, precio, inventario, Logistics y aprobación. Aplanar ambas estructuras elimina la responsabilidad propia del marketplace.
¿Los Orders migrados a VTEX demuestran que la operación está lista?
No. Los Orders históricos conservan evidencia. El comportamiento actual de Checkout, pago, prevención de fraude, inventario, seller routing, Logistics y preparación de pedidos requiere responsables y configuración activa por separado.
¿Qué suele hacer que VTEX Master Data sea un área de riesgo?
El riesgo proviene de schemas y consumidores que pueden quedar ocultos. Un registro personalizado puede sostener aprobación B2B, identidad de CRM, cumplimiento, formularios o flujos de trabajo aunque su volumen sea pequeño.