Si VTEX se selecciona como plataforma de destino, la preparación debe convertir el modelo comercial de la Store de origen en un conjunto de evidencia organizado por dominios antes de ejecutar cualquier migración. Catalog, Pricing, Promotions, Trade Policies, Inventory, Logistics, Checkout, Payments, OMS, Master Data, sellers, relaciones de marketplace y contenido de Storefront están conectados, pero siguen teniendo responsables y reglas distintas.
Para cada área importante, registre la acción necesaria, quién la controla, qué evidencia la demuestra y qué condición permite considerarla preparada. Esto evita confundir una exportación de Products con un Catalog completo de VTEX o interpretar los Orders históricos como si configuraran Logistics y Checkout actuales.
Defina el modelo operativo y la responsabilidad de cada dominio de VTEX
Prepare un mapa conciso que muestre qué dominios de VTEX y qué sistemas externos serán responsables de cada relación comercial después de la migración.
| Área de preparación | Decisión que debe registrarse | Responsable | Evidencia de preparación |
|---|---|---|---|
| Catalog | Categories, Brands, Products, SKUs, specifications, attachments, kits y assembly opciones | Responsable de Catalog | Mapa de relaciones de Catalog |
| Contexto comercial | Prices, Promotions, Trade Policies, sellers, offers y surtido por canal | Responsable comercial | Matriz de responsabilidad SKU/canal/precio |
| Customers y B2B | Perfiles de Customer, direcciones, organizaciones, roles, centros de coste y entidades de Master Data | Responsable de Customers/B2B | Diagrama de identidades y entidades |
| Orders y operaciones | Checkout, Payments, OMS, Logistics, inventario, warehouses, docks, carriers y sellers | Responsable de operaciones | Mapa de dominios de Order y Logistics |
| Storefront | CMS, Search, navegación, rutas, contenido y responsabilidad sobre frontend headless | Responsable de experiencia digital | Mapa de responsabilidad de Storefront |
| Sistemas externos | ERP, PIM, WMS, CRM, marketplace, impuestos, contabilidad y middleware | Responsable técnico | Registro de dependencias y sistemas de origen autorizados |
El mapa debe indicar dónde se mantiene el valor maestro y qué identificador lo conecta con los demás dominios.
Prepare accesos, exportaciones, backups y evidencia del origen
Reúna:
- acceso administrativo al origen y los accesos administrativos necesarios en VTEX;
- exportaciones fechadas de Products, SKUs, Categories, Brands, precios, Promotions, Customers, Orders y contenido;
- archivos de database, media o aplicaciones cuando estén disponibles;
- grupos de specifications, Product specifications, SKU specifications y valores controlados;
- informes de Trade Policies, sellers, canales, warehouses, docks, carriers e inventario;
- ejemplos de Customers, B2B y entidades de Master Data;
- identificadores de Catalog de marketplace y sellers;
- inventarios de CMS, Search, navegación, URLs, metadata y redirects;
- inventarios de aplicaciones, APIs, middleware, integraciones y sistemas externos;
- capturas o informes que expliquen comportamientos importantes del origen.
| Elemento de evidencia | Por qué se necesita | Condición de preparación |
|---|---|---|
| Diccionario de Catalog | Explica el significado de Product/SKU/specification | Cada campo prioritario tiene un responsable y un valor representativo |
| Matriz de canales y sellers | Protege el alcance de Trade Policies y marketplace | Cada relación de seller y canal está documentada |
| Inventario de Master Data | Identifica entidades personalizadas fuera de registros ordinarios de Customer | Cada entidad importante tiene schema, clave y responsable |
| Registro de integraciones | Protege la continuidad de sistemas externos | Cada identificador duradero está vinculado con la entidad correcta de VTEX o externa |
| Inventario de rutas y contenido | Separa implementación de Storefront de datos de Catalog | Cada ruta y contenido prioritario tiene un responsable en destino |
Una exportación de API ausente o una transformación de middleware no documentada debe seguir visible como elemento pendiente, no asumirse resuelta.
Prepare Categories, Products, SKUs y specifications
Seleccione registros representativos que expongan la jerarquía completa de VTEX: Category, Brand, Product, SKU, grupo de specifications, Product specification y SKU specification.
Incluya:
- Products simples con un solo SKU;
- Products con varios SKUs;
- Products cuyos valores de SKU definen talla, color, modelo, voltaje, región o paquete;
- grupos de specifications específicos por Category y campos heredados;
- Products con Brands, media, contenido relacionado o identificadores de PIM externos;
- attachments, services, kits, conjuntos o comportamiento de assembly opciones;
- Products suministrados por varios sellers o canales.
| Comportamiento del origen | Decisión de preparación para VTEX | Evidencia necesaria |
|---|---|---|
| El valor diferencia la unidad vendible | Definir SKU specification y relación de SKU | IDs de Product/SKU, valores, imágenes, stock y claves externas |
| El valor describe el Product genérico | Definir Product specification | Category, grupo de specifications, tipo de campo y valores |
| El Customer aporta información | Definir attachment u otro responsable de aplicación | Definición del input y ejemplo de Order histórico |
| El Product incluye componentes o elementos opcionales | Definir kit, assembly opción, service o responsable externo | Lista de componentes, cantidad, precio, inventario y comportamiento de Order |
| Catalog suministrado por PIM | Conservar identificadores de PIM y VTEX | Sistema maestro y clave de sincronización |
Normalice nombres duplicados de specifications, valores inconsistentes, SKUs huérfanos, Products sin Category y Products obsoletos antes dla correspondencia final. El Catalog está preparado cuando cada familia principal de Products tiene un plan para Category, Brand, Product, SKU, specifications e identificadores externos.
Prepare Trade Policies, Pricing, sellers y contexto comercial
Las Trade Policies pueden conectar Catalog, Pricing, Promotions, inventario, Logistics, configuración de Payments y canales de ventas. Los sellers y marketplace offers añaden una capa adicional de responsabilidad.
| Registro comercial | Acción de preparación | Evidencia de preparación |
|---|---|---|
| Trade Policy | Definir canal de ventas, disponibilidad de Catalog, reglas comerciales y operaciones relacionadas | Matriz de Trade Policies |
| Price | Identificar SKU, moneda, tabla de precios, contexto de Customer o canal y sistema maestro | Ejemplos representativos de precio por SKU |
| Promotion | Registrar condiciones, alcance, fechas y Products o Customers afectados | Inventario de Promotions prioritarias |
| Seller | Definir identidad del seller, Products, offers, responsabilidad de preparación e IDs externos | Matriz de responsabilidad de sellers |
| Marketplace offer | Separar identidad canónica de Catalog del precio, stock y preparación propios del seller | Ejemplo de correspondencia Product/SKU/seller |
| Surtido B2B | Definir organización, Trade Policy, Catalog, precio y relaciones de acceso | Escenario representativo de comprador B2B |
No trate precios de canal ni registros de seller del origen como simples campos de Product. La condición de preparación es que cada SKU prioritario tenga declarado quién controla su precio, el alcance de Trade Policy, la relación con sellers y la autoridad sobre inventario.
Prepare Customers, registros B2B y Master Data
Los datos relacionados con Customers pueden incluir perfiles ordinarios, direcciones, organizaciones, roles de comprador, centros de coste, contexto de aprobación, formularios personalizados, consentimiento, loyalty, IDs de CRM y documentos de Master Data.
Prepare:
- Customers registrados, guests, múltiples direcciones, identidades duplicadas e IDs externos;
- organizaciones B2B, usuarios, roles, centros de coste y contexto comercial;
- entidades personalizadas de Customer y flujo de trabajo almacenadas fuera de perfiles estándar;
- schemas, campos, claves, referencias y consumidores de entidades de Master Data;
- decisiones de consentimiento, privacidad y retención;
- identificadores de CRM, ERP, loyalty, marketplace y soporte.
| Registro del origen | Responsable | Evidencia necesaria | Condición de preparación |
|---|---|---|---|
| Identidad de Customer | Operaciones de Customer | Ejemplos de duplicados y guests | Las reglas de identidad y combinación están documentadas |
| Organización B2B | Responsable B2B | Matriz organización/usuario/rol/centro de coste | Las relaciones de empresa tienen un responsable definido en destino |
| Documento de Master Data | Responsable del proceso de negocio | Schema de entidad y ejemplo de referencia | Se conocen la clave, relación padre y consumidor que seguirá utilizándolo |
| Consentimiento o campo sensible | Responsable legal/de datos | Lista de campos aprobados | La finalidad y base de retención necesarias están documentadas |
| Clave externa | Responsable de integración | Ejemplo de consulta en CRM/ERP/marketplace | La clave está asociada con el nivel de entidad correcto |
Master Data no debe convertirse en un contenedor genérico para campos indefinidos del origen. Cada documento personalizado necesita una entidad de negocio nombrada, una clave, una relación y un responsable futuro.
Prepare Orders históricos y referencias operativas
Seleccione Orders que muestren identidad de Customer, seller, Trade Policy, líneas de SKU, precios, Promotions, taxes, referencias de pago, datos de shipping, preparación de pedidos, status e IDs externos.
Incluya:
- Orders ordinarios, cancelados, refunded y partially fulfilled;
- Orders de cada seller, Trade Policy, moneda y canal de ventas importante;
- Orders de marketplace;
- Orders con varios envíos o carriers;
- Orders que contengan kits, attachments, services o datos personalizados;
- Orders conectados con ERP, contabilidad, WMS, marketplace o sistemas de soporte.
| Área histórica | Evidencia | Condición de preparación |
|---|---|---|
| Líneas Product/SKU | Paquete representativo de Orders | Se explican SKU comprado, seller, cantidad, precio y datos personalizados |
| Contexto de pago | Ejemplos de método, transacción y status | Las referencias históricas y límites de datos sensibles están documentados |
| Contexto de Logistics | Ejemplos de shipping method, SLA, carrier, warehouse, dock, tracking y preparación de pedidos | La relación histórica puede entenderse sin configurar Logistics activa |
| Ajustes | Promotions, taxes, reembolsos, cancelaciones y cambios manuales | Los totales históricos pueden explicarse |
| Linaje externo | IDs de ERP, marketplace o contabilidad | Las claves de reconciliación se conservan en el nivel correcto de Order |
Los Orders históricos son evidencia del comercio pasado. La configuración actual de Checkout, Payments, OMS, Logistics, carriers y warehouses permanece separada de los registros migrados de Order.
Prepare inventario, Logistics, contenido de Storefront y URLs
La preparación de inventario debe identificar qué sistema controla cantidad y disponibilidad, qué warehouses o sellers suministran cada SKU y cómo se representan la Trade Policy y el contexto de Logistics correspondientes.
Para Storefront, recopile:
- contenido de Products y Categories;
- CMS Pages, páginas de destino, Blog Posts, guías y contenido de campañas;
- ejemplos de Search, facetas, navegación y filtros;
- URLs prioritarias de Products, Categories, Brands, campañas y contenido;
- metadata, relaciones canónicas y redirects;
- responsabilidad sobre frontend headless o CMS;
- inventarios de media y enlaces internos.
| Área | Pregunta de preparación | Evidencia de preparación |
|---|---|---|
| Inventory | ¿Qué sistema, warehouse, seller o feed controla la cantidad de cada SKU? | Matriz SKU/sistema maestro |
| Logistics | ¿Qué warehouse, dock, carrier, SLA, pickup o relación de preparación importa? | Mapa representativo de Logistics |
| Search y facetas | ¿Qué specifications y Categories sostienen el descubrimiento? | Ejemplos controlados de campos y filtros |
| Content | ¿Qué CMS de VTEX, CMS externo o repositorio frontend posee el registro? | Inventario de responsabilidad de contenido |
| URLs | ¿Qué ruta y redirect conservan cada ruta prioritaria del origen? | Registro Source/Destination URL |
El área está preparada cuando los registros de Catalog, inventario, Logistics, contenido y rutas tienen responsables diferenciados y no se tratan como una única exportación de Storefront.
Inventaríe aplicaciones, APIs y sistemas externos
Cree un registro de dependencias para cada aplicación, API, flujo de middleware, integración personalizada, webhook y plataforma externa que cree o modifique registros de Catalog, Customer, Order, precio, seller, inventario, Logistics o contenido.
Para cada dependencia, registre:
- finalidad comercial;
- dominio de VTEX y registros afectados;
- sistema externo maestro;
- IDs y claves de referencia;
- disponibilidad de API o exportación;
- responsables comerciales y técnicos;
- decisión sobre continuidad, sustitución o retirada en destino;
- datos necesarios antes de configurar el flujo de trabajo de destino.
Entre las dependencias prioritarias se incluyen ERP, PIM, WMS, OMS, CRM, contabilidad, impuestos, fraude, Search, marketplace, fidelización, suscripciones, personalización, analítica y sistemas de contenido.
El registro está preparado cuando cada valor importante tiene un único responsable autorizado y una clave duradera. Un campo de middleware sin sus entidades de origen y destino sigue siendo evidencia incompleta.
Seleccione muestras representativas para la migración de prueba
| Muestra | Finalidad de preparación |
|---|---|
| Product con varios SKUs | Exponer relaciones Product/SKU/specification/media |
| Category con specifications heredadas | Exponer jerarquía de Catalog y responsabilidad de campos |
| SKU usado en varias Trade Policies | Exponer contexto de precios, canal, inventario y Logistics |
| Product de marketplace y offer del seller | Exponer identidad canónica de Catalog frente a responsabilidad del seller |
| Customer u organización B2B | Exponer identidad, rol, centro de coste y contexto comercial |
| Documento de Master Data | Exponer entidad personalizada, clave, referencia y responsable |
| Order histórico complejo | Exponer seller, SKU, Promotion, pago, preparación de pedidos e IDs externos |
| Content o ruta headless | Exponer responsabilidad de frontend, CMS, SEO y redirects |
Para cada muestra, registre ID de origen, URL de origen cuando corresponda, motivo comercial, dominio previsto de VTEX, identificadores externos, exclusiones conocidas y revisor responsable.
Complete la puerta de preparación de VTEX
| Pregunta de preparación | Evidencia necesaria | Condición de preparación |
|---|---|---|
| ¿Los accesos y archivos del origen pueden recuperarse? | Registro de accesos y exportaciones/backups fechados | Los registros necesarios pueden revisarse sin depender de la Store de origen activa |
| ¿Está documentada la responsabilidad de dominios? | Mapa de dominios VTEX y sistemas externos | Cada familia principal de registros tiene un responsable |
| ¿Están preparadas las estructuras de Catalog y SKU? | Matriz Product/SKU/specification | Cada patrón principal de Product tiene una representación definida en VTEX |
| ¿Están asignadas Trade Policies, sellers y precios? | Matriz de responsabilidad comercial | Los casos representativos de canal y seller están completos |
| ¿Están definidas las entidades de Customer y Master Data? | Diagramas de identidad y entidades | Claves, relaciones y consumidores están documentados |
| ¿Se explican Orders y referencias operativas? | Paquete de Orders históricos | Las transacciones pasadas siguen siendo comprensibles |
| ¿Se han inventariado aplicaciones y sistemas externos? | Registro de dependencias | Cada dependencia crítica tiene un responsable futuro |
| ¿Se han seleccionado muestras representativas? | Registro de muestras | Quedan cubiertas complejidades de Catalog, comercio, Customers, Orders y Storefront |
| ¿Los elementos pendientes están controlados? | Registro de decisiones | Cada elemento abierto tiene responsable y fecha objetivo |
La preparación está completa cuando ninguna decisión crítica sobre Catalog, SKU, Trade Policy, seller, Customer, Master Data, Order, inventario, ruta o integración depende de supuestos no documentados.
Conclusión
Preparar una migración hacia VTEX debe producir un conjunto de evidencia empresarial organizado por dominios y responsables. Categories, Products, SKUs, specifications, Trade Policies, sellers, precios, Customers, Master Data, Orders, Logistics, contenido e integraciones necesitan cada uno un responsable declarado y registros representativos.
Cuando estas decisiones se resuelven antes de la migración de prueba representativa, las muestras pueden reflejar la arquitectura prevista de VTEX en lugar de tratar una colección de registros importados como si constituyera una operación comercial completa.
Preguntas frecuentes
¿Qué registro de preparación para VTEX debería crearse primero?
Empiece por el mapa de responsabilidad de dominios para Catalog, contexto comercial, Customers, Orders, operaciones, Storefront y sistemas externos. Ese mapa determina qué evidencia y responsables hacen falta.
¿Por qué deben prepararse Products y SKUs por separado?
El Product representa la definición comercial genérica, mientras cada SKU representa una variación vendible. Specifications, imágenes, inventario, precios, offer del sellers y líneas de Order pueden depender de esa relación de SKU.
¿Qué debe prepararse para las Trade Policies?
Documente canal de ventas, disponibilidad de SKUs, contexto de precio, Promotions, inventario, Logistics, relaciones de Payments, sellers y sistemas externos asociados con cada Trade Policy prioritaria.
¿Cómo debe prepararse Master Data?
Defina cada entidad, schema, clave duradera, relaciones padre, consumidores, requisitos de privacidad y responsable de destino. No utilice Master Data como ubicación genérica para campos indefinidos.
¿Cómo deben prepararse los Orders históricos para VTEX?
Proporcione Orders representativos con líneas de SKU, sellers, precios, Promotions, taxes, referencias de pago, contexto de shipping, preparación de pedidos, status e IDs externos. Mantenga esa evidencia separada de la configuración operativa actual.
¿Cuándo puede considerarse completa la preparación para VTEX?
Cuando la responsabilidad de dominios, estructuras de Catalog, relaciones comerciales, entidades de Customer y Master Data, Orders, contenido, rutas, integraciones, muestras y decisiones pendientes están documentadas con responsables claros.