La migración de datos hacia Zen Cart implica traducir la información a un modelo de comercio autohospedado en el que la identidad de cada Product, su ubicación en Categories, los nombres y valores de opciones, los atributos asignados, las distintas capas de precios, los módulos de totales de pedido, las ubicaciones de contenido, los plugins y la configuración influyen en el significado de los registros. Un Product o un Order de la tienda de origen puede parecer completo en la base de datos y, aun así, perder las relaciones que permiten venderlo o interpretarlo correctamente.
La distinción fundamental está entre los registros migrados y las estructuras que permiten interpretarlos. Una elección de Product puede requerir un nombre de opción, un valor de opción, la asignación al Product, un ajuste de precio o peso, una marca de selección obligatoria y una representación en la línea del Order. Un Product situado en varias colecciones de origen puede necesitar un único Product de Zen Cart vinculado a varias Categories, en lugar de Products duplicados. Una CMS Page puede corresponder a una EZ-Page, una define page, una descripción de Category, una descripción de Product u otra ubicación de contenido.
El significado de los datos en Zen Cart está estrechamente vinculado a la configuración
Zen Cart ofrece a los propietarios de la tienda control directo sobre el catálogo, los precios, los módulos, las plantillas y las extensiones de base de datos. Ese control genera un modelo de datos con muchas relaciones. Los Products se conectan con Categories, tipos de producto, atributos, imágenes, fabricantes, clases fiscales, Specials, descuentos por cantidad, descargas, metadatos y configuración. Los Orders se conectan con atributos seleccionados, direcciones, totales, Coupons, certificados regalo, historial de estados, etiquetas de pago y envío, comentarios y referencias externas.
| Área de datos de origen | Interpretación en Zen Cart | Decisión sobre la relación en destino |
|---|---|---|
| Product | Registro vendible conectado con ubicación en Category, estado, modelo, precio, cantidad, impuestos, imagen, tipo y atributos | Determinar qué valores permanecen a nivel de Product y cuáles pertenecen a atributos, precios, contenido o plugins. |
| Ubicación en Category | Jerarquía más vínculos entre Product y Category | Conservar una única identidad de Product mientras se representan todas las ubicaciones de navegación intencionadas. |
| Datos de opciones y atributos | Nombres de opciones, valores de opciones, atributos de Product asignados, indicadores de selección, efectos sobre precio/peso y posibles descargas | Reconstruir toda la relación de elección en lugar de copiar únicamente las etiquetas. |
| Customer | Cuenta, direcciones, estado de newsletter, contexto de grupo y relación con Orders | Separar la identidad actual de la cuenta de las instantáneas históricas de transacciones. |
| Order | Líneas de Product, atributos seleccionados, totales, estado, direcciones, comentarios y referencias | Conservar evidencia legible de la transacción sin dar a entender que se reproduce la configuración activa de los módulos. |
| Contenido | EZ-Pages, define pages, descripciones de Product/Category, enlaces, banners y metadatos | Hacer corresponder el contenido de origen con la ubicación y función de navegación de Zen Cart que lo sustituye. |
| Datos de plugins/personalizados | Campos personalizados, tablas, cambios administrativos, plantillas, integraciones y cálculos modificados | Conservar únicamente los registros que tengan un registro principal definido y un consumidor vigente en destino. |
Un modelo de destino sólido hace visibles estas relaciones antes de mover los datos. No trata la configuración, los módulos, las plantillas y los plugins como tipos de registro ordinarios, pero tampoco ignora los datos de los que esos componentes son propietarios.
Los Products y su ubicación vinculada en Categories deben conservar una sola identidad
Un Product de Zen Cart puede asociarse con una o varias Categories. La ubicación mediante Products vinculados permite que una misma identidad de Product aparezca en distintas ubicaciones de Category sin crear registros de Product duplicados. Esta distinción es importante cuando la plataforma de origen utiliza colecciones, departamentos, agrupaciones por marca, rutas de navegación o conjuntos automatizados de merchandising.
| Estructura de origen | Pregunta de interpretación en Zen Cart | Resultado de la relación |
|---|---|---|
| Familia jerárquica permanente | ¿Debe convertirse en un árbol de Categories? | La ubicación del Product sigue siendo comprensible para clientes y administradores. |
| Un Product en varias rutas de navegación | ¿Debe un único Product vincularse a varias Categories? | Precio, stock, atributos e identidad del Product permanecen centralizados. |
| Colección por marca o proveedor | ¿Debe ser una Category, una relación con fabricante, una faceta de búsqueda o una página de contenido? | El destino responde a las necesidades de navegación y administración, no al nombre utilizado en origen. |
| Colección estacional o de campaña | ¿Es una jerarquía duradera o merchandising temporal? | Se evita crear Categories permanentes a partir de campañas de corta duración. |
| Registro principal de origen con variantes hijas | ¿Deben las hijas convertirse en atributos, Products independientes u otra estructura? | La identidad del Product, los precios, el stock y el significado en las líneas de Order permanecen intencionados. |
| Product digital | ¿Qué relaciones de tipo de Product, descarga, atributos y acceso son necesarias? | La entrega del archivo permanece conectada con el Product comprado y el estado del Order. |
Duplicar un Product para conservar varias ubicaciones de origen puede fragmentar inventario, precios, Reviews y administración. Vincular el Product conserva la identidad central, pero solo cuando las agrupaciones de origen representan realmente varias ubicaciones de navegación y no artículos comerciales independientes.
El tipo de Product también importa. Un Product físico, documento, Product musical, donación o artículo descargable puede llevar campos y funcionamiento de tienda diferentes. El destino no debe forzar todos los artículos de origen a una misma representación genérica de Product cuando su modelo de venta es distinto.
Los nombres de opciones, los valores de opciones y los atributos forman un modelo de elección de tres partes
Las elecciones de Product en Zen Cart se construyen a partir de tres estructuras relacionadas: un nombre de opción, uno o varios valores de opción y atributos que asignan pares de nombre/valor de opción a un Product. El atributo asignado puede incluir funcionamiento como tipo de visualización, selección predeterminada u obligatoria, ajuste de precio, ajuste de peso, orden, relación con archivos descargables y otros ajustes específicos del Product.
| Capa de relación | Significado | Riesgo al trasladarla |
|---|---|---|
| Nombre de opción | La dimensión de elección, como Color o Size | Crear dimensiones duplicadas o incoherentes entre Products. |
| Valor de opción | Un valor reutilizable como Red o Large | Fusionar valores distintos o multiplicar valores equivalentes sin una regla de gobierno. |
| Asignación de atributo al Product | El emparejamiento específico de un Product entre nombre y valor de opción | Perder qué elecciones pertenecen a cada Product y qué efectos comerciales se aplican. |
| Indicadores de atributo | Selección obligatoria/predeterminada, visualización y otros comportamientos | Permitir valores predeterminados no válidos o eliminar decisiones obligatorias del cliente. |
| Efecto sobre precio o peso | Ajuste comercial asociado al valor asignado | Conservar etiquetas mientras cambian los totales del carrito o el significado para el envío. |
| Funcionamiento de texto/archivo/descarga | Entrada del cliente o relación con entrega digital | Reducir datos interactivos o sujetos a control de acceso a simple texto descriptivo. |
Una plataforma de origen puede almacenar una variante como Product hijo con SKU e inventario propios. Los atributos de Zen Cart pueden representar la elección del comprador, pero el modelo de destino debe decidir cómo conservar los identificadores de los registros hijos, la propiedad del stock, las imágenes y el significado para la preparación de pedidos. La etiqueta de la elección por sí sola no es suficiente.
El origen también puede utilizar modificadores que dependan unos de otros. No debe suponerse que ese funcionamiento surgirá automáticamente de asignaciones ordinarias de opciones. La representación de destino necesita una relación definida o una extensión capaz de interpretar la dependencia.
Los precios, Specials, descuentos, Coupons y totales de Order son capas distintas
Los precios en Zen Cart pueden combinar el precio base del Product, ajustes de precio por atributo, Products cuyo precio depende de atributos, Specials, promociones, descuentos por cantidad, precios por grupo, Coupons, certificados regalo, envío, impuestos, cargos y módulos de total de Order. Estas capas afectan etapas distintas del cálculo en la tienda y de la interpretación de Orders históricos.
| Regla comercial de origen | Pregunta para el modelo de datos de Zen Cart |
|---|---|
| Precio específico de una variante | ¿El importe pertenece a un Product, a un ajuste de atributo, a una estructura de precio por atributo o a un Product independiente? |
| Precio promocional temporal | ¿Debe convertirse en un Special, una regla promocional o solo en un valor histórico? |
| Descuento por volumen | ¿Es un descuento por cantidad del Product, un tratamiento por grupo, una regla de módulo o una decisión de precios externa? |
| Precio por grupo de Customers | ¿Qué relación entre Customer, grupo y precio lo controla? |
| Coupon o certificado regalo | ¿El registro representa una regla activa, saldo almacenado, historial de canje o contexto histórico de un Order? |
| Línea de cargo, impuesto, envío o crédito | ¿Qué relación de total de Order explica el cálculo desde subtotal hasta total final? |
Un Order histórico puede contener una línea de Coupon o certificado regalo sin que eso implique recrear la regla futura o el saldo restante. Un Product puede conservar un antiguo precio Special sin que esa promoción deba seguir activa en la tienda de destino. El modelo de destino debe conservar la evidencia comercial necesaria para interpretar Orders, mientras que las estructuras futuras de precios y promociones se definen por separado.
Customers, direcciones, grupos e identidades externas necesitan propietarios distintos
Los Customers de Zen Cart pueden incluir identidad de cuenta, entradas de libreta de direcciones, estado de newsletter, historial de Orders, precios por grupo, campos de aprobación o estado y datos pertenecientes a plugins o sistemas externos. Las direcciones de facturación y envío registradas dentro de Orders deben permanecer separadas de la libreta de direcciones actual del Customer.
| Datos del Customer | Pregunta sobre la relación en destino |
|---|---|
| Identidad de cuenta | ¿Qué email, nombre, estado y resultado del tratamiento de contraseña definen la cuenta de destino? |
| Libreta de direcciones | ¿Qué direcciones actuales de facturación y envío siguen siendo válidas y están correctamente localizadas? |
| Dirección histórica de un Order | ¿Qué instantánea de dirección pertenece a la transacción original? |
| Grupo de Customer | ¿El grupo controla precios, aprobación, comunicación u otro funcionamiento configurado? |
| Newsletter y consentimiento | ¿Qué preferencia o evidencia actual es la autoridad? |
| Identificador externo | ¿Qué CRM, ERP, sistema fiscal, marketplace o sistema de soporte sigue siendo el propietario? |
| Campo de plugin | ¿Qué componente de destino leerá el valor después de la migración? |
Los nombres de grupo no deben tratarse como si fueran toda la lógica comercial. Un Customer mayorista o aprobado necesita una relación definida con el precio, acceso o funcionamiento de aprobación que continuará en la tienda de destino. Si ese funcionamiento pertenece a un plugin o sistema externo, el registro del Customer debe conservar la clave necesaria sin dar a entender que la cuenta principal por sí sola lo reproduce.
Los Orders necesitan que los atributos seleccionados y las líneas calculadas sigan siendo legibles
Los Orders de Zen Cart conservan el historial de transacciones mediante encabezados de Order, líneas de Product, atributos seleccionados, instantáneas de direcciones, historial de estados, comentarios, impuestos, envío, descuentos, Coupons, certificados regalo y líneas de totales. Los atributos seleccionados son especialmente importantes porque el nombre del Product principal puede no indicar qué talla, color, personalización o descarga compró el cliente.
| Relación del Order | Significado que debe conservarse |
|---|---|
| Línea de Product | Nombre, modelo, cantidad, precio, impuesto y relación con la identidad del Product de origen. |
| Atributos seleccionados | Las elecciones exactas de nombre/valor de opción y cualquier texto introducido por el cliente o referencia de archivo. |
| Totales del Order | Subtotal, descuentos, Coupons, certificados regalo, cargos, envío, impuestos y total final. |
| Estado y comentarios | Flujo histórico y contexto para atención al cliente. |
| Etiquetas de pago y envío | Evidencia de la transacción original, no módulos activos en el destino. |
| Referencias externas | Claves de marketplace, contabilidad, ERP, pasarela, envío o soporte que sigan teniendo valor. |
El Order debe seguir siendo comprensible incluso cuando la taxonomía de estados o el funcionamiento de los módulos del origen no tengan un equivalente exacto en Zen Cart. Es preferible una correspondencia semántica a copiar etiquetas que el personal pueda interpretar de manera incorrecta.
El texto histórico de Products y opciones también debe permanecer lo bastante estable para explicar la transacción incluso si el Product activo cambia posteriormente. Un Order es evidencia de lo que se compró en ese momento, no únicamente un puntero al registro actual del catálogo.
El contenido puede pertenecer a EZ-Pages, define pages, registros de catálogo o plantillas
El contenido de Zen Cart se distribuye en varias ubicaciones. Las EZ-Pages pueden ofrecer enlaces internos o externos y participar en la navegación de cabecera, pie o sidebox. Las define pages contienen contenido específico de la tienda. Las descripciones de Product y Category contienen contenido de catálogo. Banners, sideboxes, archivos de idioma, plantillas y plugins pueden aportar presentación o navegación adicional.
| Contenido de origen | Posible ubicación en Zen Cart | Relación que debe conservarse |
|---|---|---|
| Página de política o información | EZ-Page, define page u otra estructura de contenido | Identidad de página, ruta, idioma y ubicación en la navegación. |
| Contenido de landing de Category | Descripción de Category o página de contenido independiente | Asociación con la Category e intención de navegación del cliente. |
| Guía de compra de Product | Descripción de Product, EZ-Page o contenido enlazado | Enlaces internos y relación con los Products relevantes. |
| Enlace de cabecera/pie | Ubicación de EZ-Page, navegación de plantilla o configuración de sidebox | La presencia del contenido permanece separada de su ubicación de presentación. |
| Página de destino de campaña | EZ-Page, página personalizada o ruta controlada por plugin | El contenido duradero se separa del marcado específico de la plantilla de origen. |
| Metadatos SEO | Campos de Product, Category, EZ-Page o pertenecientes a plugin | Los metadatos permanecen unidos al objeto y ruta correctos. |
Migrar únicamente el texto de una página no conserva el modelo de navegación. Una página puede existir y, aun así, desaparecer de la cabecera, el pie, un sidebox, el sitemap o la red de enlaces internos. A la inversa, el marcado de presentación copiado desde el origen puede resultar inutilizable si la plantilla de destino no lo interpreta.
Los plugins y los registros personalizados de base de datos necesitan relaciones con su registro principal y su consumidor
Las tiendas Zen Cart con muchos años de uso suelen contener plugins, archivos del núcleo modificados, tablas personalizadas, overrides de plantilla, overrides de idioma, extensiones de informes, generadores de fuentes de datos, módulos SEO, integraciones de pago y envío y cambios en los flujos administrativos. Estas ampliaciones pueden almacenar datos comerciales duraderos, datos derivados, configuración o residuos técnicos.
| Patrón de datos personalizados | Decisión para el modelo de destino |
|---|---|
| Campo personalizado de Product, Customer u Order | Identificar su significado comercial, registro principal, campo de destino y propietario vigente. |
| Entidad perteneciente a un plugin | Conservar la entidad y sus relaciones solo cuando un plugin o proceso de destino vaya a consumirlas. |
| Tabla personalizada | Distinguir registros autoritativos de registros, cachés, índices y datos intermedios obsoletos. |
| Cálculo modificado | Reconstruir la regla o módulo; no tratar el resultado calculado como si fuera toda la lógica comercial. |
| Override de plantilla o idioma | Extraer el contenido duradero y reconstruir la presentación en el sistema de plantillas del destino. |
| Clave de sistema externo | Conservar identificadores estables entre sistemas en la relación correcta de Product, Customer u Order. |
El esquema de la base de datos puede revelar dónde se almacena un valor, pero no si sigue siendo autoritativo. Una tabla de plugin puede contener datos críticos de suscripciones, envíos, marketplace o informes. También puede contener cachés obsoletas que nunca deberían incorporarse al modelo de destino. La propiedad y el uso previsto en destino marcan la diferencia.
La propiedad de los datos debe definirse antes de decidir la correspondencia entre campos
Un modelo coherente para Zen Cart como plataforma de destino asigna cada valor importante del origen a uno de estos resultados:
- relación nativa de Product, Category, opción, atributo, Customer, Order, Coupon, Review, contenido o medios;
- datos personalizados o pertenecientes a plugins, gobernados y con un consumidor de destino definido;
- identidad estable de un sistema externo vinculada al registro principal correcto;
- configuración o presentación de destino que debe reconstruirse en lugar de copiarse como datos;
- residuos obsoletos, almacenados en caché, derivados o de poco valor que deben archivarse o excluirse.
| Área de decisión | Pregunta sólida para el modelo de destino |
|---|---|
| Identidad del Product | ¿El artículo es un solo Product, un Product vinculado en varias Categories, un conjunto de elecciones mediante atributos o varios Products independientes? |
| Elecciones del Product | ¿Qué nombre de opción, valor de opción, asignación al Product, indicadores y efectos sobre precio/peso forman la elección completa? |
| Cálculos comerciales | ¿Qué valor es dato del Product, precio de atributo, lógica promocional, funcionamiento por grupo de Customers o evidencia histórica de un Order? |
| Customers y Orders | ¿Qué identidades actuales, registros de direcciones, instantáneas históricas, atributos seleccionados y totales permanecen diferenciados? |
| Contenido | ¿Qué objeto y ubicación de navegación de Zen Cart dan significado al contenido? |
| Plugins e integraciones | ¿Qué componente de destino o sistema externo sigue siendo propietario del registro? |
Este modelo basado en relaciones evita ambos extremos: copiar todas las tablas del origen a campos personalizados sin explicación, o descartar datos no pertenecientes al núcleo que siguen siendo necesarios para las operaciones. Así, Zen Cart puede interpretar los registros migrados como una tienda coherente y no como un archivo de filas del sistema de origen.
Conclusión
Las diferencias del modelo de datos de Zen Cart se concentran en la ubicación de Products en Categories, las relaciones entre nombre de opción, valor de opción y atributo, las capas de precios, la propiedad de Customers y direcciones, los atributos y totales de Orders, la ubicación de EZ-Pages y otros contenidos, los plugins, las tablas personalizadas y los identificadores externos.
Una migración fiable conserva la relación completa que hay detrás de cada valor importante. Los Products mantienen una sola identidad en todas las ubicaciones de navegación intencionadas, las elecciones del cliente conservan sus efectos comerciales, los Orders siguen siendo legibles como transacciones históricas, el contenido mantiene una ubicación adecuada en Zen Cart y los registros personalizados tienen un propietario vigente.
Preguntas frecuentes
¿Por qué los nombres de opciones, los valores de opciones y los atributos están separados en Zen Cart?
El nombre de opción define la dimensión de elección, el valor de opción define uno de sus posibles valores y la asignación de atributo al Product conecta ese par con un Product concreto y con funcionamiento específico, como precio, peso, orden, selección obligatoria o ajustes de descarga.
¿Un Product que aparece en varias colecciones de origen debe convertirse en varios Products de Zen Cart?
Normalmente no, cuando los registros de origen representan un único Product comercial. Un Product de Zen Cart puede vincularse a varias Categories para mantener centralizados precio, stock, atributos y administración. Los Products separados solo son adecuados cuando los artículos tienen identidades realmente independientes.
¿Todas las variantes del origen pueden convertirse en atributos de Zen Cart?
No automáticamente. Las variantes de origen pueden tener SKU, inventario, imágenes, coste, código de barras o identidad de preparación de pedidos propios que van más allá de la estructura prevista de atributos. El modelo de destino debe conservar esas relaciones o utilizar Products independientes o una estructura compatible mediante una extensión.
¿Cómo deben representarse los totales de Orders históricos?
Conserva subtotal, descuentos, Coupons, certificados regalo, cargos, envío, impuestos y total final como líneas calculadas comprensibles vinculadas al Order. Estas líneas preservan la evidencia de la transacción sin recrear automáticamente futuras promociones o el funcionamiento de módulos.
¿Dónde deben ubicarse las CMS Pages del origen en Zen Cart?
Cada página debe corresponder a su función en destino: EZ-Page, define page, contenido de Product o Category, página personalizada u otra estructura. La ruta, el idioma, los enlaces internos, los metadatos y la ubicación prevista en la navegación deben conservarse por separado del cuerpo de la página.
¿Cómo deben clasificarse los datos de plugins y tablas personalizadas?
Rastrea cada registro hasta su objeto principal, propósito comercial, consumidor de destino y propietario vigente. Conserva entidades autoritativas y claves de integración; reconstruye las reglas activas en el entorno de destino; y excluye registros, cachés, índices y residuos obsoletos que no tengan valor duradero.