VTEX IO es la plataforma de desarrollo de VTEX: la tienda se construye como una aplicación de componentes React versionados y desplegados desde la terminal, en lugar de armarse a mano desde un administrador visual. La diferencia práctica es que en IO cada cambio tiene versión, ambiente de prueba y forma de revertirse. En CMS Legacy, no.
Las tres arquitecturas que conviven hoy
| Arquitectura | Cómo se construye | Para quién tiene sentido |
|---|---|---|
| CMS Legacy | Plantillas y controles editados desde el administrador | Tiendas antiguas que aún no han migrado |
| VTEX IO (Store Framework) | Componentes React versionados, desplegados por CLI | La mayoría de tiendas nuevas y migraciones |
| FastStore (headless) | Next.js propio consumiendo las APIs de VTEX | Equipos con capacidad frontend propia y exigencia alta de performance |
Qué cambia en la práctica al pasar de Legacy a IO
- Los cambios tienen historia. Cada versión queda registrada y se puede volver atrás. En Legacy, si alguien rompe una plantilla un viernes, no hay a dónde regresar.
- Existe un ambiente de prueba real. Los workspaces permiten ver la tienda con el cambio aplicado antes de publicarlo, sin afectar producción.
- El frontend deja de ser artesanal. Componentes reutilizables en lugar de plantillas copiadas y modificadas página por página.
- La velocidad de carga mejora por defecto. IO entrega una base más razonable en Core Web Vitals que una tienda Legacy con años de acumulación.
- Las nuevas funcionalidades de VTEX llegan a IO. Legacy recibe mantenimiento, no evolución. Con el tiempo, la brecha se ensancha sola.
El costo de quedarse en CMS Legacy no aparece de golpe. Aparece como funcionalidades que ya no están disponibles, integraciones que exigen rodeos y una tienda que cada año es un poco más lenta de cambiar.
Cómo saber en cuál estás
Entra al administrador de tu cuenta VTEX. Si editas la tienda desde Site Editor, con bloques y temas, estás en IO. Si editas plantillas HTML y controles desde CMS > Layout, estás en Legacy. Hay tiendas híbridas, con secciones en cada una: es un estado de transición común y conviene resolverlo antes de que se vuelva permanente.
¿Y FastStore? ¿Cuándo vale la pena headless?
FastStore permite construir el frontend en Next.js propio y consumir VTEX por API. Da el máximo control sobre performance y experiencia, y a cambio exige un equipo frontend con capacidad de mantenerlo. No es un paso "más avanzado" que IO: es una decisión distinta.
Para la mayoría de operaciones, VTEX IO es suficiente y sale más barato de mantener. FastStore tiene sentido cuando la experiencia de compra es un diferencial competitivo real y hay equipo interno para sostenerla.
Cuándo migrar y cuándo esperar
- Migra si ya estás postergando funcionalidades por limitaciones de la plataforma, si el rendimiento es un problema medido, o si cada cambio de frontend toma semanas.
- Espera si la tienda Legacy funciona, el catálogo es estable y hay una inversión mayor en curso. Migrar por migrar, sin un problema de negocio que lo justifique, es un proyecto caro sin retorno claro.
Workspaces: el concepto que más cambia el día a día
Si hay que quedarse con una sola idea de VTEX IO, es esta. Un workspace es una copia completa y aislada de la tienda: mismo catálogo, mismos pedidos, mismos datos, pero con el código en la versión que se está probando.
En la práctica significa que se puede abrir un workspace, cambiar la página de producto, ver la tienda funcionando con ese cambio en una URL propia, mostrárselo al área comercial, y solo entonces promoverlo a producción. Si algo sale mal, se descarta el workspace y no pasó nada.
En CMS Legacy no existe ese intermedio: se edita la plantilla que está sirviendo a los clientes. Por eso en tiendas Legacy los cambios grandes se hacen de madrugada y con miedo — no es una costumbre del equipo, es una consecuencia de la arquitectura.
La pregunta que revela en qué arquitectura estás: "¿puedo ver este cambio funcionando antes de que lo vean mis clientes?". En IO la respuesta es sí, siempre. En Legacy, no.
Cómo está compuesta una tienda en IO
Una tienda en VTEX IO no es un sitio: es un conjunto de aplicaciones que se declaran como dependencias, cada una con su versión. Tres piezas explican casi todo:
- El theme. El repositorio propio de la tienda. Define qué bloques componen cada página y con qué propiedades. Es lo que se personaliza en el día a día.
- Las apps nativas de VTEX. Buscador, carrito, minicart, PDP, checkout. Vienen versionadas y se actualizan de forma controlada, sin rehacer la tienda.
- Las apps custom. Componentes propios cuando la funcionalidad no existe. Se desarrollan una vez, se versionan y se reutilizan entre páginas.
Las páginas se arman componiendo bloques en archivos de configuración, no escribiendo HTML por página. La consecuencia práctica: cambiar cómo se ve la ficha de producto se hace una vez y aplica a los 20.000 productos. En Legacy, ese mismo cambio suele significar tocar plantillas que se habían copiado y modificado por separado.
Qué implica una migración de Legacy a IO
Conviene decirlo claro: no es una actualización, es una reconstrucción del frontend. Lo que se conserva y lo que se rehace:
| Elemento | ¿Se conserva? | Comentario |
|---|---|---|
| Catálogo, productos y SKUs | Sí | Viven en la capa de datos, no en el frontend |
| Clientes e histórico de pedidos | Sí | No se ven afectados por la migración |
| Integraciones con ERP y logística | Generalmente sí | Operan por API, independientes del frontend |
| Plantillas y layouts | No | Se reconstruyen como bloques del theme |
| Personalizaciones en JS inyectado | No | Se rehacen como componentes o apps custom |
| URLs indexadas | Deben conservarse | Requiere mapa de redirecciones 301 explícito |
El punto que más se subestima es el último. Una tienda Legacy con años de operación tiene autoridad acumulada en Google sobre miles de URLs. Si la migración cambia la estructura de rutas sin redirecciones, el tráfico orgánico cae de forma inmediata y la recuperación toma meses. Es la parte menos vistosa del proyecto y la que más define su resultado comercial.
Rendimiento: por qué IO parte de mejor lugar
IO no hace mágicamente rápida a una tienda: una tienda en IO mal construida también carga lento. Lo que cambia es el punto de partida y las herramientas disponibles.
- Componentes que cargan bajo demanda en lugar de una plantilla que trae todo desde el inicio.
- Imágenes servidas en formatos modernos y tamaños adecuados por la propia plataforma.
- Menos scripts inyectados a mano. En tiendas Legacy con años encima suele haber capas de JavaScript agregado por distintos proveedores que nadie se atreve a quitar.
Ese último punto es el que más pesa en la práctica. La lentitud de muchas tiendas Legacy no viene de la plataforma, sino de la acumulación de parches que la arquitectura permitió agregar sin control.
Qué hacemos nosotros al respecto
En ePartner desarrollamos directamente sobre VTEX IO y acompañamos migraciones desde CMS Legacy preservando las URLs indexadas para no perder posicionamiento. Si quieres saber en qué arquitectura está tu tienda y si migrar tiene sentido en tu caso, puedes usar el diagnóstico para ecommerce o escribirnos.