VTEX es una plataforma de comercio en la nube diseñada para operaciones empresariales, extensibilidad, múltiples modelos de negocio y servicios comerciales conectados. Su arquitectura abarca Catalog, Pricing, Promotions, Checkout, Orders, Logistics, Payments, Search, Master Data, capacidades de marketplace, funciones B2B, desarrollo de tiendas e infraestructura de aplicaciones. Una implementación de VTEX puede operar como Store directa al consumidor, entorno multimarca, marketplace, seller conectado con marketplaces externos, canal B2B o una combinación de estos modelos.
Esta amplitud hace que VTEX sea materialmente diferente de plataformas donde el comercio se concentra en una única base de datos de catálogo y una única tienda. La disponibilidad de un Product puede depender de la activación del SKU, inventario, precio, trade policy, relación con seller, logística y configuración de la tienda. Un Product puede existir en Catalog y seguir sin estar disponible porque una de esas capas conectadas está incompleta. Una oferta de marketplace puede aparecer bajo un Product aunque pertenezca a otro seller. Una tienda headless puede presentar datos comerciales de VTEX sin compartir la misma capa de implementación que el entorno administrativo.
Migrar hacia VTEX, por tanto, no consiste solo en transferir Products, Customers y Orders. Es una reconstrucción de relaciones comerciales entre servicios modulares. La cuenta de destino debe expresar qué artículos existen, qué SKUs son vendibles, quién los suministra, dónde se mantiene el inventario, qué precios se aplican, qué canales pueden venderlos, cómo resuelve el proceso de compra la preparación de pedidos y qué tienda o aplicación consume los datos resultantes.
VTEX como arquitectura de comercio en la nube
VTEX ofrece una plataforma gestionada en la nube en lugar de un paquete de aplicación autohospedado. Los servicios principales, la infraestructura de plataforma y las APIs de comercio operan dentro del entorno VTEX, mientras comerciantes y socios de implementación configuran reglas de negocio, integran sistemas externos, construyen tiendas y amplían capacidades mediante modelos de aplicaciones y APIs compatibles.
La plataforma es deliberadamente modular. Los registros de Catalog no determinan por sí solos la experiencia del Customer. Pricing, Promotions, Inventory, Logistics, sellers, trade policies, Checkout, Search y la presentación de la tienda aportan partes independientes del resultado final. Esta modularidad permite escala empresarial y varios modelos operativos, pero también aumenta la dependencia de relaciones precisas entre servicios.
| Capa de VTEX | Finalidad principal | Importancia para la migración |
|---|---|---|
| Catalog | Categories, brands, Products, SKUs, specifications, imágenes, attachments, services, kits y collections | Los conceptos del catálogo de origen deben traducirse a la jerarquía Product-SKU de VTEX y a su modelo de specifications vinculado con Categories. |
| Pricing y Promotions | Valores comerciales y reglas promocionales | Un registro de Product no determina todos los precios de venta ni resultados promocionales. |
| Logistics | Inventario, docks, warehouses, políticas de envío y preparación de pedidos | La disponibilidad de SKU depende de configuración operativa fuera del registro de Product. |
| Sellers y Marketplace | Propiedad de ofertas y relaciones de marketplace | El comerciante puede poseer Catalog mientras otro seller posee precio, inventario y preparación de pedidos. |
| Checkout y Orders | Orquestación transaccional y gestión del historial de Orders | El comportamiento activo de compra depende de configuración e integraciones actuales, no solo del historial de Orders migrado. |
| Storefront y aplicaciones | Experiencia orientada al Customer y extensiones | Los datos comerciales pueden presentarse mediante distintas arquitecturas de tienda y aplicaciones personalizadas. |
La documentación de panorama general de VTEX destaca infraestructura cloud, seguridad, privacidad de datos, composabilidad, extensibilidad, arquitectura de tiendas y experiencia de desarrollo. No son preocupaciones periféricas: definen cómo se gobierna el entorno de destino y qué equipos son responsables de cada capa de un proyecto de migración.
Arquitectura de Catalog: Categories, Products y SKUs
VTEX Catalog comienza con Categories y brands, y después define Products y SKUs. Un Product es la definición comercial general de un artículo, mientras un SKU es la variación específica comprable que mantiene stock y selecciona el comprador. Cada Product pertenece a una Category y una brand, y todo Product debe tener al menos un SKU.
Las specifications también son estructuralmente importantes. VTEX asocia grupos de specifications con Categories y esos grupos pueden heredarse en niveles inferiores de Category. Las Product specifications describen características a nivel de Product, mientras las SKU specifications distinguen variaciones comprables. Por ello, los atributos del origen no pueden relacionarse de forma segura sin determinar si clasifican el Product, definen un SKU, permiten filtrado o sirven únicamente como contenido descriptivo.
| Concepto de origen | Posible destino en VTEX | Pregunta clave de interpretación |
|---|---|---|
| Product padre | Product | ¿El padre del origen representa un artículo general o solo un contenedor de agrupación? |
| Variante | SKU | ¿Cada variante del origen corresponde a una unidad vendible con stock independiente? |
| Atributo | Product specification o SKU specification | ¿El valor describe el Product general o distingue un SKU comprable? |
| Opción o personalización | Attachment, assembly opción, service o estructura de SKU | ¿La selección cambia identidad de inventario, precio, cantidad o información aportada por el comprador? |
| Conjunto | Kit o estructura relacionada con assembly | ¿Los componentes son fijos, opcionales, gestionan inventario o tienen precio independiente? |
| Collection | Collection o estructura de merchandising de la tienda | ¿La agrupación es taxonómica, promocional, estacional o solo de presentación? |
VTEX requiere más que crear registros de Products y SKUs. Categories, brands, grupos de specifications, specifications, imágenes, activación de SKU, precio, inventario y disponibilidad por canal de venta deben funcionar conjuntamente antes de que un artículo sea vendible. Esto explica por qué una simple comparación de recuentos puede exagerar la completitud de la migración. La unidad significativa es una relación comercial activa, no una fila aislada de Product.
Attachments, assembly opciones, services y kits amplían el modelo de Product. Los attachments pueden recopilar información opcional asociada con un SKU. Las assembly opciones permiten combinaciones más complejas, cantidades, artículos adicionales, costes y relaciones de inventario. Los services pueden representar añadidos de pago como envoltorio para regalo o garantías. Los kits agrupan SKUs para venderlos juntos. Cada estructura tiene un significado operativo distinto y no debe aplanarse dentro de un único campo genérico de opciones.
Trade policies, cuentas y contexto de canal
VTEX utiliza trade policies para definir contexto comercial entre canales. Una trade policy puede influir en la disponibilidad de Products y otras condiciones de venta para un canal u operación concretos. Las cuentas empresariales también pueden contener varias Stores, brands, países, unidades de negocio o tiendas cuyos catálogos se solapan, pero no se comportan de forma idéntica.
Este modelo sensible al canal es importante durante la migración porque las Stores de origen suelen codificar diferencias de mercado o canal de formas menos explícitas. Una plataforma de origen puede utilizar sitios separados, listas de precios, grupos de Customers, warehouses, subdominios o campos personalizados para representar lo que VTEX expresa mediante trade policies y configuración de cuenta. El diseño de destino debe decidir si esas diferencias del origen deben mantenerse separadas, consolidarse o convertirse en configuración específica por canal.
Un Product activo en una trade policy puede no estar pensado para otra. Prices, Logistics, sellers, Promotions y comportamiento del Checkout también pueden variar según el contexto comercial. Migrar un único registro global de Product sin conservar estas diferencias puede provocar sobreexposición, falta de surtido o comportamiento comercial incorrecto.
Sellers, marketplaces y propiedad de las ofertas
VTEX admite modelos tanto de marketplace como de seller. Una cuenta VTEX puede actuar como marketplace que recibe ofertas de sellers externos o como seller cuyo catálogo y ofertas se distribuyen a marketplaces externos. Por ello, la integración de Catalog puede implicar algo más que la propiedad de Products.
En un contexto de marketplace, el marketplace puede poseer la presentación compartida del Product mientras los sellers poseen las ofertas, incluyendo precio, inventario, condiciones de preparación de pedidos e identificadores específicos del seller. Las relaciones entre Products y Categories pueden conectar taxonomías de catálogo distintas dentro de relaciones de marketplace. Un mismo Product puede tener varias ofertas de seller, cada una con su propia disponibilidad comercial.
| Elemento de marketplace | Significado operativo | Importancia para la migración |
|---|---|---|
| Product | Identidad compartida de catálogo e información de merchandising | Los listados duplicados del origen pueden necesitar consolidarse alrededor de una única identidad de Product en destino. |
| SKU | Variación comprable de Product | Las ofertas de sellers deben apuntar al SKU correcto en lugar de crear artículos sin relación. |
| Seller | Organización responsable de una oferta | La identidad, permisos y responsabilidad operativa del seller no son datos ordinarios de Customer. |
| Offer | Contexto de precio, inventario y preparación de pedidos específico del seller | Los registros de Offer no pueden reducirse únicamente a precios de Products. |
| Correspondencia | Relación entre Categories o Products externos y VTEX | La traducción de taxonomía e identificadores debe mantenerse gobernada. |
| Flujo de Orders | Orquestación de transacciones entre marketplace y seller | Los Orders históricos y el enrutamiento activo del marketplace pertenecen a capas diferentes. |
Este modelo operativo distingue claramente VTEX de una plataforma para un solo comerciante. Una migración que ignore relaciones entre sellers y ofertas puede conservar Products visibles y perder la estructura de propiedad que hace funcionar el marketplace.
Pricing, Inventory, Logistics y capacidad de venta
VTEX separa la identidad central de Catalog de los servicios que hacen que un SKU esté comercialmente disponible. Prices se gestionan mediante estructuras de Pricing. Inventory se asocia con Logistics y ubicaciones de preparación. Políticas de envío, docks, warehouses, carriers y condiciones de entrega influyen en si Checkout puede resolver una opción viable de preparación de pedidos. Promotions pueden modificar resultados comerciales de forma independiente al precio base.
El resultado es una definición por capas de la capacidad de venta. Un SKU puede existir y contener imágenes y specifications, pero seguir no disponible porque carece de precio válido, inventario, trade policy aplicable, oferta de seller o ruta de preparación de pedidos. A la inversa, el mismo SKU puede venderse con precios o condiciones logísticas diferentes según el canal.
Las plataformas de origen suelen comprimir estas capas en menos campos. Una tabla de Product puede incluir tanto stock como precio. Una extensión de warehouse puede mantener detalle por ubicación. Un módulo de envío puede calcular entregas independientemente. VTEX exige colocar esos conceptos en los servicios que los poseen. La migración debe conservar, por tanto, la relación entre identidad del artículo y ejecución comercial.
Customers, Master Data, Checkout y Orders
La identidad de Customer en VTEX puede implicar registros de cuenta, direcciones, perfiles, información organizativa, consentimiento, campos personalizados y datos almacenados mediante Master Data o sistemas de Customers conectados. Las implementaciones B2B pueden añadir organizaciones, centros de coste, roles, permisos, contextos de precios y funcionamiento relacionado con aprobaciones. Estas estructuras no equivalen a una lista plana de usuarios registrados.
Checkout orquesta el proceso activo de compra entre artículos, sellers, precios, inventario, Logistics, Payments, Promotions y contexto del Customer. Orders registra el resultado de las transacciones completadas y permite su procesamiento operativo. Los Orders históricos pueden conservar contexto valioso para atención al Customer y elaboración de informes, pero no establecen el comportamiento activo del Checkout en la cuenta de destino.
La diferencia importa porque una migración puede transferir correctamente nombres de Customers, direcciones y totales de Orders y dejar incompletos permisos organizativos, datos de perfil personalizados, configuración de pagos, Logistics, enrutamiento de marketplace o integraciones de Checkout. La modularidad de VTEX hace explícitos estos límites.
Modelos de Storefront, VTEX IO y composabilidad
VTEX admite distintos enfoques de Storefront y aplicaciones. VTEX IO ofrece un entorno cloud para desarrollo y aplicaciones, mientras Store Framework y otras opciones de Storefront pueden consumir los servicios comerciales de VTEX. Las implementaciones headless pueden usar frontends personalizados que interactúan con APIs y servicios de plataforma.
Una Storefront, por tanto, no es simplemente un tema unido a Products migrados. Es una capa de implementación que determina navegación, presentación de Products, Search, contenido, experiencia de cuenta, Analytics e integración de Checkout. Los temas, plantillas, widgets y scripts del origen no se convierten automáticamente en componentes de Storefront de VTEX.
La composabilidad y extensibilidad permiten añadir aplicaciones e integraciones sin modificar un núcleo autohospedado. Esta capacidad aumenta la flexibilidad arquitectónica, pero también distribuye responsabilidad entre configuración de plataforma, aplicaciones, sistemas externos y código frontend. Un panorama de migración debe reconocer que la preparación de Storefront y la preparación de datos están relacionadas, pero son distintas.
Integraciones y responsabilidad de sistemas empresariales
VTEX funciona habitualmente junto a ERP, PIM, OMS, WMS, CRM, marketplace, impuestos, pagos, búsqueda y analítica. La guía oficial de Catalog describe explícitamente flujos de integración con sistemas administrativos para crear y actualizar datos de Catalog. En muchas implementaciones, VTEX no es el único sistema de referencia para Products, precios, inventario, Customers u Orders.
Esto crea una de las preguntas definitorias de una migración: ¿qué sistema será responsable de cada registro después del lanzamiento? Un valor migrado puede ser sobrescrito por un feed de ERP. Inventory importado durante la migración puede dejar de ser relevante cuando comienza la sincronización con WMS. Las descripciones de Products pueden gestionarse desde un PIM, mientras las ofertas de marketplace llegan desde conectores de sellers. Los datos de Customers pueden enriquecerse o gobernarse desde un CRM.
| Área de datos | Posible sistema de referencia | Relación requerida en VTEX |
|---|---|---|
| Contenido de Product | PIM, ERP o VTEX Catalog | Identificadores estables de Product, SKU, Category, brand y specification |
| Price | ERP, plataforma de Pricing o VTEX Pricing | Registros de precio correctos por contexto comercial |
| Inventory | WMS, ERP, seller o VTEX Logistics | Cantidades válidas por SKU-ubicación y responsabilidad de sincronización |
| Customer | CRM, Master Data o servicios de cuenta | Identidad y relaciones de direcciones coherentes |
| Order | VTEX Orders, OMS, ERP o flujo de marketplace | Identificadores, estados y procesamiento posterior fiables |
| Oferta de seller | Sistema del seller o conector de marketplace | Correspondencia correcta Product-SKU, precio, stock y contexto de preparación de pedidos |
La naturaleza API-first y extensible de la plataforma facilita estas integraciones, pero no elimina las decisiones de gobierno de datos. La migración debe establecer identificadores estables y responsables claros antes de que los flujos automatizados empiecen a actualizar el entorno de destino.
VTEX dentro del panorama de plataformas
VTEX se sitúa más cerca de las plataformas de comercio composables y empresariales que de los creadores de tiendas alojadas de entrada. Ofrece una base cloud gestionada y, a la vez, expone servicios especializados, APIs, relaciones de marketplace, opciones de desarrollo de Storefront y controles operativos empresariales.
Frente a plataformas SaaS más sencillas, VTEX separa más partes del ciclo comercial en servicios gobernados de forma independiente. Frente a plataformas open-source autohospedadas, reduce la responsabilidad directa sobre infraestructura y código central y pone el énfasis en configuración, APIs, aplicaciones y sistemas conectados. Frente a una arquitectura composable totalmente personalizada, ofrece una plataforma de comercio integrada en lugar de exigir seleccionar y ensamblar cada servicio de forma independiente.
Su importancia para una migración se deriva de esa posición. VTEX puede representar catálogos complejos, canales, sellers, marketplaces, estructuras B2B e integraciones, pero la arquitectura de destino debe ser intencional. Products y Orders son solo una parte del modelo operativo; el contexto comercial, las relaciones entre servicios y la responsabilidad de sistemas determinan si la plataforma resulta utilizable.
Conclusión
VTEX es una plataforma modular de comercio cloud cuya identidad principal se extiende por Catalog, SKUs, specifications, Pricing, Promotions, Inventory, Logistics, trade policies, sellers, marketplaces, Checkout, Orders, Master Data, Storefronts, aplicaciones e integraciones. La plataforma admite modelos operativos empresariales complejos precisamente porque estas áreas se representan como capas conectadas pero distintas.
La orientación central de una migración es reconstruir deliberadamente esas relaciones. Products deben traducirse a la jerarquía Product-SKU de VTEX. Las specifications deben conservar el significado correcto a nivel de Product o SKU. La capacidad de venta debe conectar precio, inventario, seller, Logistics y contexto de canal. Los registros de Customers y Orders deben mantenerse separados del funcionamiento activo de Checkout y B2B. Storefronts e integraciones empresariales deben utilizar identificadores estables y una responsabilidad clara de sistemas. Esta arquitectura define la base para cada artículo posterior del hub de VTEX.
Preguntas frecuentes
¿Cuál es la diferencia entre Product y SKU en VTEX?
Un Product es la definición general de un artículo, mientras un SKU es la variación específica comprable que mantiene stock y selecciona el comprador. Cada Product de VTEX debe tener al menos un SKU.
¿Por qué son importantes las specifications en VTEX?
Las specifications describen características de Product o SKU y se organizan mediante grupos vinculados a Categories. Pueden sostener variación, filtrado, clasificación y presentación en Storefront, por lo que los atributos de origen deben relacionarse según su finalidad real.
¿Qué representa una trade policy?
Una trade policy establece contexto comercial para un canal u operación. Puede influir en la disponibilidad de Products y otras condiciones de venta, permitiendo que una misma cuenta atienda diferentes mercados o canales.
¿Cómo gestiona VTEX a los sellers de marketplace?
VTEX puede conectar ofertas de sellers con Products y SKUs compartidos. Los sellers pueden ser responsables de precio, inventario y contexto de preparación de pedidos, mientras el marketplace gobierna la presentación de Catalog y la orquestación transaccional.
¿Migrar Products los hace inmediatamente vendibles en VTEX?
No necesariamente. Un SKU también puede necesitar specifications válidas, imágenes, activación, precio, inventario, contexto de seller, disponibilidad por trade policy y Logistics antes de poder comprarse.
¿Una Storefront de VTEX forma parte de los datos migrados?
La Storefront es una capa de implementación independiente. Los registros de Products y contenido pueden sostener la experiencia, pero los temas y el código frontend del origen deben implementarse mediante la arquitectura de Storefront elegida en VTEX.