Si Zen Cart se selecciona como plataforma de destino, la preparación debe hacer comprensible la tienda de origen real antes de cerrar la configuración de la migración. Una instalación con muchos años de uso puede combinar Products nativos, Categories vinculadas, atributos, descargas, grupos de precios para Customers, totales de Orders, EZ-Pages, define pages, plantillas, plugins, overrides, archivos de idioma y campos personalizados de base de datos. La tienda puede parecer coherente aunque los registros que la sostienen estén distribuidos entre varios responsables técnicos y comerciales.
El objetivo de la preparación es convertir ese entorno en evidencia controlada del origen. Cada área principal debe definir la acción que debe completarse, la persona responsable de la respuesta, la evidencia que debe aportarse y la condición que determina que el área está lista. Esto permite distinguir registros ordinarios, configuración de plataforma, datos pertenecientes a plugins y código personalizado antes de comenzar a configurar la migración.
Establece el acceso al origen y registra el entorno de Zen Cart
Empieza identificando la instalación exacta. Registra la versión de Zen Cart, el entorno de hosting, la base de datos, el directorio raíz, la ruta de administración, los paquetes de idioma activos, monedas, zonas fiscales, plantillas, plugins, overrides y sincronizaciones externas. Una tienda visualmente idéntica puede funcionar de forma distinta si una instalación usa funciones nativas actuales y otra depende de plugins antiguos o modificaciones directas de archivos.
Prepara el acceso al origen requerido para la ruta de migración seleccionada. El acceso a base de datos, hosting, administración o archivos no debe presentarse como opciones intercambiables. El responsable técnico debe proporcionar el acceso que corresponda a la instalación real y mantenerse disponible cuando sea necesario aclarar permisos, allowlists, rutas de archivos o prefijos de base de datos.
| Acción | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Registrar el entorno exacto de Zen Cart y PHP | Responsable de hosting o técnico | Capturas de versión, nota del entorno, versión de base de datos | La instalación de origen y su contexto de compatibilidad son inequívocos. |
| Confirmar el acceso al origen | Responsable de accesos | Estado de conexión, detalles de allowlist, prefijo de base de datos, nota del directorio raíz | La conexión necesaria llega a la tienda correcta. |
| Inventariar plantillas, overrides y plugins | Desarrollador o agencia | Plantilla activa, lista de plugins, directorios de overrides, registro de archivos modificados | Pueden separarse los datos nativos del funcionamiento dependiente de código. |
| Registrar idiomas, monedas, zonas fiscales y unidades | Responsable de comercio | Evidencia de ajustes y lista de idiomas activos | Los valores globales que afectan al significado de Products y Orders están documentados. |
| Identificar importaciones y sincronizaciones externas | Responsable de integración | Calendario de fuentes de datos, lista de sistemas externos, detalles de la última ejecución | Los valores que pueden cambiar durante la preparación tienen una autoridad definida. |
Crea un registro de cambios una vez capturada esta evidencia. La actividad comercial ordinaria puede continuar, pero deben registrarse nuevos plugins, cambios de base de datos, reestructuraciones importantes de atributos o cambios de URL para evitar que el modelo preparado del origen quede desactualizado sin control.
Prepara Products, atributos, descargas y relaciones de precios
Zen Cart utiliza atributos de Product para representar valores seleccionables, texto introducido por el Customer, cargas de archivos, información de solo lectura, ajustes de precio o peso y archivos descargables. Option Names, Option Values y la asignación del atributo a un Product son registros separados. Algunas instalaciones también utilizan funciones de stock por variante o atributos dependientes, ya sea mediante capacidades nativas de la versión actual o mediante plugins.
Prepara un inventario de Products que incluya Product ID, modelo o SKU, estado, precio, clase fiscal, cantidad, funcionamiento de stock, peso, tipo de Product, fabricante, Category principal, Categories vinculadas, imágenes, Specials, estado destacado, descuentos por cantidad, grupos de precios de Customers, atributos y referencias de descarga cuando corresponda. La evidencia debe mostrar qué valores identifican una elección vendible y cuáles son únicamente descriptivos o introducidos por el Customer.
| Patrón de origen | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Talla, color o formato seleccionable | Registrar Option Name, Option Value, asignación de atributo, orden y estado obligatorio/predeterminado | IDs de Products representativos y exportación de atributos | El vocabulario de elección y la relación con el Product están completos. |
| Atributo que cambia precio o peso | Registrar ajuste, prefijo, inclusión en precio base, tratamiento de descuentos y Product propietario | Ejemplo de precios y ajustes de atributos | El efecto comercial es explícito y no se deduce de la etiqueta. |
| Entrada de texto o archivo | Separar entrada específica de la compra de valores de opción reutilizables | Lista de Products y líneas de Orders representativos | Los datos introducidos por el comprador no se confunden con una variante con stock. |
| Product descargable | Registrar archivo, atributo, días de caducidad, número de descargas y ubicación de almacenamiento | Manifiesto de Product/archivo y archivos originales accesibles | La relación Product-descarga y el archivo de origen están disponibles. |
| Stock por variante o regla de dependencia | Identificar propietario nativo o plugin, combinaciones, SKU y cantidad | Tabla de combinaciones o exportación del plugin | El stock independiente y las relaciones de dependencia están documentados. |
| Precios por grupo de Customer o por cantidad | Registrar Product, grupo, umbral, importe y fechas | Inventario de relaciones de precios | Los precios condicionales no se reducen al precio base del Product. |
No normalices etiquetas de atributos ni fusiones valores de opción sin aprobación comercial. Nombres similares pueden tener distinto significado para precio, stock, descarga o líneas de Order.
Documenta Categories, Products vinculados, fabricantes y descubrimiento
Los Products de Zen Cart tienen una Category principal y también pueden vincularse a otras Categories. La jerarquía de Categories, la ubicación mediante Products vinculados, la navegación por fabricante, Specials, Products destacados, listados de Products nuevos y la búsqueda pueden influir en el descubrimiento. El registro de preparación debe separar la clasificación del catálogo de los menús y sideboxes de la plantilla.
Prepara el árbol de Categories con IDs, relaciones entre padre e hijo, estado, contenido por idioma, imágenes, orden, restricciones por tipo de Product y rutas importantes. Para cada Product situado en varias Categories, registra la Category principal y las Categories vinculadas. Una ubicación vinculada no debe confundirse con un registro de Product duplicado.
| Área de descubrimiento | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Jerarquía de Categories | Responsable de catálogo | Exportación padre-hijo y lista de Categories retenidas | Cada Category retenida tiene un padre y propósito conocidos. |
| Categories principales y vinculadas | Responsable de merchandising | Relaciones Product-Category | La ubicación compartida es visible sin crear Products duplicados. |
| Registros de fabricantes | Responsable de marca | Lista de fabricantes, asignaciones de Products, notas sobre rutas públicas | El significado público de marca queda separado de datos internos de proveedores. |
| Specials, destacados y listados de nuevos Products | Responsable de merchandising | Listas de Products activos y reglas de fechas | Se identifican las acciones de merchandising dependientes de tiempo o estado. |
| Menús y sideboxes | Responsable de tienda | Capturas y notas de diseño/módulo | La presentación queda separada de las relaciones de catálogo. |
Prepara Customers, grupos de precios, direcciones e historial de Orders
La preparación de Customers debe distinguir identidad de cuenta, entradas de libreta de direcciones, estado de autorización, preferencia de newsletter, grupo de precios, nivel mayorista cuando exista, saldo de certificado regalo, Reviews e identificadores externos. Un grupo de precios de Customers puede afectar al funcionamiento comercial y debe documentarse como relación, no conservarse solo como etiqueta.
La preparación de Orders debe conservar evidencia histórica. Selecciona Orders que representen proceso de compra como invitado y registrado, atributos, descargas, descuentos, Coupons o certificados regalo, impuestos, etiquetas de envío y pago, comentarios, historial de estados, distintas direcciones de facturación y envío y totales generados por plugins. Mantén las direcciones y descripciones de Product registradas en el momento del Order separadas de los registros actuales de Customer y catálogo.
| Área de registro | Acción de preparación | Evidencia | Condición de preparación |
|---|---|---|---|
| Identidad de Customer | Identificar duplicados, estados de autorización, grupos de precios y claves externas | Lista de excepciones de Customers | Las excepciones de identidad tienen responsable y decisión. |
| Libretas de direcciones | Separar direcciones reutilizables del Customer de instantáneas de Orders | Ejemplos de direcciones de Customer y Order | Los datos actuales de cuenta y el historial de transacciones no se mezclan. |
| Grupos de precios o mayoristas | Registrar membresía y toda relación de Product o precio a la que afecta | Matriz grupo-regla | El significado comercial está documentado más allá del nombre del grupo. |
| Estados y comentarios de Orders | Registrar etiquetas, secuencia, visibilidad para el Customer y Orders representativos | Inventario de estados | Los estados históricos pueden interpretarse sin depender solo de la etiqueta. |
| Totales de Orders | Identificar subtotal, impuestos, envío, descuento, certificado regalo, cargo y líneas de plugins | Conjuntos de totales representativos | Cada ajuste material tiene un propietario de origen conocido. |
| Historial de descargas | Registrar atributos de archivo comprado, acceso restante y relación con el Order | Orders relacionados con descargas | El contexto de compra digital forma parte de la evidencia de origen. |
Los registros históricos no deben editarse únicamente para hacerlos uniformes. Documenta por separado las anomalías cuando ayuden a explicar la transacción original.
Inventaría plugins, overrides, plantillas y datos personalizados
Los plugins de Zen Cart pueden añadir campos, tablas, reglas de precios, lógica de stock, totales de Orders, rutas SEO, propiedades de Customers, informes, fuentes de datos o integraciones. Los overrides y modificaciones directas también pueden cambiar el funcionamiento sin crear un registro evidente de plugin. La preparación debe identificar qué datos comerciales pertenecen a cada componente.
Crea un registro de dependencias con nombre del plugin, versión, propósito, estado activo, entidades afectadas, ampliaciones de base de datos, archivos modificados o sobrescritos, sistemas externos y la persona que puede confirmar si el funcionamiento sigue siendo necesario. Utiliza “plugin de Zen Cart” o el nombre concreto del componente para no confundir extensiones de plataforma con mejoras del servicio de migración.
| Efecto de la dependencia | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Extensión de atributos o stock por variante | Registros de combinaciones, claves de Product, campos de SKU y cantidad | Cada combinación activa tiene un propietario de origen definido. |
| Módulo de totales de Order o proceso de compra | Resumen de configuración y Orders históricos representativos | Los valores históricos pueden separarse de la configuración actual de la tienda. |
| Plugin SEO o de URLs | Ajustes de reescritura, ejemplos de rutas y tablas de redirecciones | Las rutas de origen importantes pueden reconstruirse. |
| Extensión de Customer o fidelización | Campos, saldos, historial de transacciones y claves de Customer | Los datos activos de cuenta tienen una decisión explícita de destino. |
| Integración ERP, marketplace o de preparación de pedidos | IDs externos, dirección de sincronización y autoridad | Los sistemas que continúan pueden identificar el mismo Product, Customer u Order. |
| Contenido dependiente de plantilla | Rutas de plantilla, capturas y fuente del contenido | El contenido comercial se separa del código de presentación. |
Prepara EZ-Pages, define pages, medios y evidencia de URLs
El contenido de Zen Cart puede mostrarse mediante EZ-Pages, define pages, descripciones de Product y Category, banners, sideboxes, archivos de plantilla y archivos de idioma. Prepara un inventario que identifique responsable del contenido, idioma, ruta actual, ubicación en menú o sidebox, enlaces incrustados, imágenes y disposición prevista.
Registra las URLs prioritarias de Products, Categories, fabricantes, EZ-Pages, políticas, contacto e información. Las rutas nativas de Product y Category pueden utilizar IDs y rutas de Category, mientras que los plugins SEO pueden sustituirlas por rutas reescritas. Por ello, el inventario de rutas debe identificar si cada ruta importante es nativa, generada por plugin, estática o redirigida externamente.
Haz copia de seguridad de las imágenes y archivos de descarga originales junto con sus rutas. La base de datos puede contener nombres de archivos sin contener los propios archivos. Marca archivos ausentes, URLs de imágenes externas, diferencias de rutas sensibles a mayúsculas/minúsculas y miniaturas generadas que no sean originales de origen.
Crea un paquete restaurable del origen Zen Cart
Conserva un estado recuperable de la tienda Zen Cart de origen antes de realizar limpieza estructural o ejecutar la migración. El paquete debe incluir base de datos, árbol de archivos relevante, directorio de descargas, referencias de configuración, evidencia de plantillas y plugins y una nota del entorno vinculada al mismo estado de la tienda.
| Componente del paquete | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Copia de seguridad de base de datos | Administrador de base de datos | Dump con fecha/hora y nota de prefijo de base de datos | El dump está completo y pertenece a la tienda prevista. |
| Archivos y descargas | Responsable de hosting o técnico | Archivo de ficheros o árbol de origen accesible | Imágenes, descargas, plantillas, overrides y plugins originales están disponibles. |
| Registro del entorno | Responsable técnico | Nota de PHP, base de datos, servidor y versión de Zen Cart | Puede interpretarse el funcionamiento dependiente de versión. |
| Registro de accesos | Responsable del proyecto | Responsable del acceso y estado de conexión | El acceso necesario está disponible sin exponer credenciales en la documentación. |
| Registro de cambios | Administrador de la tienda | Cambios posteriores al corte de evidencia | Los cambios estructurales tardíos pueden incorporarse deliberadamente. |
Selecciona muestras representativas para probar la migración
Prepara un manifiesto compacto de muestras con IDs de origen, motivo comercial, archivos vinculados y relaciones esperadas en origen. Debe incluir registros ordinarios y las relaciones con mayor riesgo de interpretarse mal. El manifiesto de muestras de Zen Cart está listo cuando cada expectativa de origen, dependencia de plugin o atributo, archivo vinculado e identificador están completos y asignados a un revisor.
Incluye al menos:
- un Product sencillo, un Product inactivo y un Product vinculado a varias Categories;
- un Product con muchos atributos y efectos sobre precio o peso;
- entrada de texto o archivo, stock por variante o atributos dependientes cuando existan;
- un Product descargable con archivo de origen e historial de compra;
- Products con Specials, precios por cantidad o precios por grupo de Customers;
- Customers de grupos de precios o autorización relevantes;
- Orders con atributos, comentarios, distintas direcciones, certificados regalo, totales inusuales y descargas;
- URLs prioritarias nativas y reescritas;
- un registro activo perteneciente a un plugin y un ejemplo de contenido dependiente de plantilla.
Aplica la comprobación final de preparación para Zen Cart
Zen Cart está listo para el siguiente paso de la migración cuando el origen puede explicarse sin suposiciones no documentadas.
| Pregunta de preparación | Resultado necesario |
|---|---|
| ¿Se conoce la instalación exacta? | Se registran versión, hosting, base de datos, idiomas, plantilla, overrides y plugins. |
| ¿Están completas las relaciones de Products? | Se representan atributos, descargas, Categories, precios, medios y extensiones de stock. |
| ¿Pueden interpretarse Customers y Orders? | Grupos, direcciones, estados, totales, comentarios e IDs externos tienen responsables. |
| ¿Están clasificados plugins y datos personalizados? | Cada dependencia activa tiene un propósito comercial y una decisión de destino. |
| ¿Se han inventariado contenido y rutas? | EZ-Pages, define pages, medios y URLs importantes nativas o reescritas están documentadas. |
| ¿Están listas las copias de seguridad y los accesos? | El paquete de origen puede restaurarse y el acceso requerido está disponible. |
| ¿Es representativo el conjunto de muestras? | Los registros ordinarios y complejos están listados con IDs de origen y relaciones esperadas. |
Los elementos no resueltos deben quedar en un registro de decisiones con responsable y fecha límite. La preparación está incompleta cuando una tabla crítica de plugin, un archivo de descarga, un vínculo de Category, una relación de precios o un identificador externo todavía se describe únicamente como desconocido.
Conclusión
La preparación para migrar hacia Zen Cart es más sólida cuando la tienda se trata como un catálogo conectado y un registro histórico, no como una simple exportación de Products. Atributos, descargas, Categories vinculadas, grupos de precios de Customers, totales de Orders, EZ-Pages, plugins, overrides, plantillas y archivos originales necesitan cada uno un responsable claro y un conjunto de evidencias.
Un paquete de origen restaurable, un manifiesto de muestras representativas y una comprobación explícita de preparación constituyen la base para configurar la migración.
Preguntas frecuentes
¿Por qué los atributos de Zen Cart deben prepararse por separado de los campos de Product?
Los atributos conectan Option Names y Option Values con Products y pueden afectar precio, peso, selección obligatoria, entrada del comprador, descargas o stock. Una fila plana de Product no puede conservar estas relaciones de forma fiable.
¿Cuál es la diferencia entre una Category principal y una Category vinculada?
Un Product tiene una Category principal y puede vincularse a otras Categories adicionales. Registra ambas relaciones para que la ubicación adicional no se confunda con un Product duplicado ni se pierda durante la preparación del catálogo.
¿Una copia de seguridad de la base de datos de Zen Cart incluye imágenes y archivos descargables?
No. La base de datos normalmente almacena referencias. Las imágenes originales, descargas, plantillas, overrides y archivos de plugins también deben prepararse desde el sistema de archivos.
¿Cómo deben documentarse los datos de plugins de Zen Cart?
Registra plugin, versión, entidades afectadas, campos o tablas, IDs de origen representativos, dependencias externas y propósito comercial vigente. Los datos activos necesitan un propietario explícito; los registros obsoletos pueden marcarse para archivo o exclusión.
¿Qué Orders deben incluirse en el conjunto de muestras del origen?
Incluye Orders ordinarios y Orders con atributos, descuentos, certificados regalo, distintas direcciones de facturación y envío, comentarios, totales inusuales, descargas y referencias externas. Estos casos muestran relaciones que los Orders básicos no revelan.
¿Deben tratarse las URLs reescritas de Zen Cart como URLs nativas de Product?
No automáticamente. Registra si cada ruta importante es nativa, generada por un plugin SEO, estática o redirigida externamente. Ese propietario determina la evidencia necesaria para reproducir la relación de ruta.