Si X-Cart se selecciona como la plataforma de destino, la preparación debe comenzar por identificar la generación exacta de la tienda de origen y el conjunto de módulos instalado. Las tiendas X-Cart pueden diferir de forma sustancial entre versiones, ediciones, actualizaciones y generaciones de módulos. Los atributos de Product pueden funcionar como especificaciones, valores seleccionables por el Customer o dimensiones de variación. Las instalaciones antiguas pueden usar Product Variants, mientras que entornos de origen más recientes pueden usar Product Variations y una estructura distinta de módulos o API. Memberships, registros Multi-Vendor, módulos personalizados e integraciones externas pueden cambiar aún más el significado de un registro de Product, Customer u Order.
El objetivo de la preparación es describir la tienda real, no un esquema genérico de X-Cart supuesto de antemano. Cada área de preparación debe identificar una acción, un responsable, una evidencia y una condición de listo. Esto crea una base controlada para configurar la migración.
Establece la versión, edición, acceso y linaje de módulos de X-Cart
Registra la versión exacta de X-Cart, la edición o contexto del paquete, el historial de actualizaciones, los módulos activos, los módulos personalizados, el tema, la configuración de la tienda o marketplace, la generación de API y el entorno de alojamiento. El linaje de versiones es especialmente importante cuando el catálogo ha pasado por cambios entre Product Variants y Product Variations, sustituciones de módulos o migraciones personalizadas de base de datos.
| Acción | Responsable | Evidencia | Condición de listo |
|---|---|---|---|
| Identificar la versión exacta de X-Cart y el historial de actualizaciones | Responsable técnico | Captura del administrador, información del paquete, notas de actualización | La generación de origen y las actualizaciones conocidas están registradas. |
| Inventariar módulos activos e inactivos | Administrador de la tienda o desarrollador | Lista de módulos con autor, versión, estado y finalidad | Cada módulo crítico para el negocio tiene un responsable. |
| Identificar el uso de Product Variants o Product Variations | Responsables de catálogo y técnicos | Estado del módulo, Products representativos y ubicaciones de datos relevantes | El modelo activo de variaciones está explícito. |
| Confirmar la conexión al origen y el acceso a archivos | Responsable de alojamiento o técnico | Estado de acceso, lista de permitidos o notas de autenticación | La instalación de origen prevista es accesible. |
| Registrar el tema y las capas de código personalizado | Desarrollador o agencia | Nombre del tema, rutas de módulos personalizados, sobrescrituras y notas de despliegue | La presentación y la lógica personalizada pueden distinguirse de los registros del núcleo. |
| Registrar API y sincronizaciones | Responsable de integraciones | Versión de API, responsable de credenciales, lista de webhooks o tareas programadas | Se conocen los sistemas externos y sus claves de registros. |
No deduzcas la estructura actual de la tienda a partir de un documento antiguo del proyecto o de una factura de módulos. La lista activa de módulos, la base de datos, el árbol de código y los registros representativos deben ser coherentes entre sí.
Prepara Products, clases de Product, atributos y variaciones
La preparación de Products en X-Cart debe distinguir el Product base, la clase de Product, la definición de atributo, el valor de atributo, el valor seleccionable por el Customer, la especificación y la variación vendible. Un atributo llamado "Color" puede ser un campo descriptivo en un Product y una dimensión de variación con SKU, precio, stock, peso o imagen independientes en otro.
Crea un inventario del catálogo que incluya ID de Product, SKU, nombre, estado, tipo de Product cuando sea relevante, asignaciones de Category, clase de Product, atributos, variaciones o variantes, precios, stock, peso, imágenes, archivos, membresías, clases fiscales, propiedad de vendedor cuando corresponda e identificadores externos.
| Patrón de origen | Acción de preparación | Evidencia | Condición de listo |
|---|---|---|---|
| Atributo a nivel de clase | Registrar clase, grupo de atributos, tipo, valores permitidos y Products asignados | Exportación de clases y atributos de Product | Las definiciones compartidas pueden separarse de los valores específicos de cada Product. |
| Atributo o especificación simple | Registrar si el valor es descriptivo, filtrable o introducido por el Customer | Products representativos y capturas de la tienda | Las especificaciones no se confunden con variaciones vendibles. |
| Dimensión de variación seleccionable | Registrar los atributos usados para construir variaciones y cada combinación activa | Manifiesto de variaciones con SKU, stock, precio, peso e imagen | Cada combinación vendible tiene una identidad estable. |
| Módulo heredado Product Variants | Registrar generación del módulo, estado de actualización y registros de variantes | Evidencia del módulo e ID de Products representativos | Las estructuras heredadas y actuales de variaciones no se mezclan silenciosamente. |
| Product con archivos o entrega digital | Registrar referencias de archivos y reglas de acceso | Lista de Products/archivos y muestras de Orders | Los archivos y las relaciones históricas de compra están disponibles. |
| Product restringido por membresía o vendedor | Registrar relación de acceso o propiedad | Matriz de membresías/vendedores | La visibilidad o propiedad del Product está documentada más allá de la fila del Product. |
Normaliza los nombres de atributos solo después de que el responsable del catálogo confirme que dos valores tienen el mismo significado. Las clases de Product compartidas pueden amplificar un cambio incorrecto en muchos Products.
Prepara Categories, navegación, visibilidad por membresía y alcance del catálogo
Categories, menús, clases de Product, membresías, vendedores y la presentación de la tienda pueden influir en el descubrimiento. Prepara la jerarquía de Categories y las asignaciones de Product, pero no asumas que la pertenencia a una Category reproduce la navegación o las reglas de acceso.
En tiendas que utilizan membresías, documenta qué Products, Categories, precios, contenido o funciones de cuenta dependen de la membresía. En entornos marketplace o Multi-Vendor, registra la propiedad del vendedor, identificadores específicos del vendedor, Products del vendedor, referencias de comisión o liquidación cuando existan y la relación entre los registros de vendedor y Order.
| Área del alcance del catálogo | Responsable | Evidencia | Condición de listo |
|---|---|---|---|
| Jerarquía de Categories | Responsable del catálogo | Lista padre-hijo y asignaciones de Product | Las Categories conservadas tienen una finalidad y un padre claros. |
| Navegación y menús | Responsable de la tienda | Capturas de menús y lista de destinos | La presentación del menú está separada de los datos de Category. |
| Clases de Product | Arquitecto del catálogo | Mapa clase-Product y clase-atributo | La herencia de atributos compartidos es visible. |
| Restricciones por membresía | Responsable B2B o de cuentas | Matriz membresía-Product/Category/precio | Los efectos sobre acceso y precios son explícitos. |
| Alcance de vendedores | Responsable de marketplace | Muestras vendedor-Product y vendedor-Order | La propiedad del vendedor no se aplana como campo de fabricante o marca. |
Prepara Customers, membresías, direcciones y Orders
Los datos de Customer de X-Cart pueden incluir usuarios, direcciones, membresías, roles, campos de perfil, estado de cuenta, preferencias de marketing, perfiles de vendedor e ID externos. Separa la identidad de inicio de sesión de los roles de Customer, personal, administrador, vendedor o membresía.
La preparación de Orders debe conservar descripciones de Product, SKU, atributos, selecciones de variación, precios, descuentos, impuestos, envío, etiquetas de pago, estados, notas, expediciones, reembolsos, devoluciones, contexto del vendedor y referencias externas tal como existían en el momento del Order. Registra qué módulos crean artículos adicionales de Order, recargos, registros de suscripción, transacciones de pago, datos de procesamiento o detalles de liquidación de marketplace.
| Área de registros | Acción de preparación | Evidencia | Condición de listo |
|---|---|---|---|
| Usuarios y Customers | Clasificar Customer, administrador, vendedor y otros roles | Inventario de usuarios y roles | Las cuentas no se fusionan solo porque compartan una tabla. |
| Memberships | Registrar el significado actual e histórico de cada membresía | Lista de membresías y muestras de Customers | La lógica de catálogo o precio dependiente de membresía tiene un responsable. |
| Direcciones | Separar direcciones del perfil de instantáneas de Orders | Muestras de direcciones de Customer y Order | Las direcciones históricas siguen siendo interpretables. |
| Estados de Order | Registrar nombres de estados, significado en el flujo y dependencias de módulos | Mapa de estados y Orders representativos | El estado histórico se entiende sin depender del color o icono del antiguo administrador. |
| Artículos y totales de Order | Incluir valores de variación, descuentos, impuestos, cargos, envío y líneas creadas por módulos | Detalle de Orders representativos | La transacción puede reconstruirse a partir de su evidencia histórica. |
| ID externos | Registrar claves de pago, ERP, marketplace, envío o contabilidad | Libro de identificadores | Los sistemas que continúan pueden localizar el mismo registro. |
Evita "limpiar" Orders históricos sustituyendo nombres o atributos antiguos de Product por valores actuales del catálogo. La instantánea de origen forma parte de la evidencia.
Inventaría módulos, código personalizado, tablas personalizadas y sistemas externos
Los módulos de X-Cart pueden ampliar o sustituir estructuras de datos principales, añadir tablas de base de datos, modificar la lógica del modelo, crear recursos API, añadir campos o controlar la representación en la tienda. Las generaciones actuales y antiguas de X-Cart también utilizan rutas y frameworks de módulos distintos. Prepara un registro de propiedad en lugar de una simple lista de módulos instalados.
| Efecto del módulo | Evidencia que debe prepararse | Condición de listo |
|---|---|---|
| Campo de Product o Customer | Clave de campo, tipo de dato, entidad propietaria e ID representativos | El valor tiene un propietario de destino o una exclusión deliberada. |
| Extensión de variaciones o inventario | Registros de combinaciones, origen del stock y clave SKU externa | La identidad vendible y la autoridad del stock son explícitas. |
| Registro de suscripción, reserva, bundle o servicio | Relaciones con Product padre, Customer, Order y programación | Los registros especializados no se reducen a metadatos de Product. |
| Módulo de marketplace | Relaciones de vendedor, oferta, comisión, pago y Order | Los registros de marketplace están separados de la identidad principal del catálogo. |
| Módulo de pago o procesamiento | Referencias históricas de transacción, envío o estado | El historial puede separarse de la configuración futura. |
| Código o tabla personalizada | Esquema, relaciones entre claves, flujo activo y responsable de datos | Se documenta la entidad empresarial, no solo la tabla. |
| PIM, ERP, WMS, CRM o marketplace externo | Autoridad por campo e ID estables | Se identifica el sistema que continuará siendo autoritativo. |
Clasifica los módulos como activos y necesarios, activos pero sustituibles, solo históricos, inactivos con datos conservados u obsoletos. Un módulo inactivo todavía puede ser propietario de registros necesarios para Orders históricos.
Prepara contenido, recursos multimedia, URL y activos de la tienda
El contenido de X-Cart puede incluir descripciones de Products y Categories, Pages estáticas o CMS, Blog Posts cuando un módulo los proporciona, menús, banners, etiquetas, traducciones, plantillas de correo electrónico, bloques del tema y páginas generadas por módulos. Prepara el contenido por propietario en lugar de tratar todo el texto visible como una única exportación CMS.
Registra rutas importantes de Product, Category, contenido, membresía, vendedor y módulos. Incluye rutas canónicas, alcance por idioma o tienda, importancia de tráfico, módulo que genera la ruta y disposición prevista. Temas y módulos pueden crear rutas que no están representadas por registros ordinarios de contenido.
Prepara los archivos multimedia y activos originales junto con sus relaciones de base de datos. Registra almacenamiento externo, tamaños generados, originales ausentes, rutas sensibles a mayúsculas y minúsculas y archivos protegidos mediante reglas de acceso específicas de módulos.
Construye un paquete de origen X-Cart restaurable
Un paquete de origen de X-Cart autohospedado debe incluir una copia de seguridad de la base de datos, los archivos relevantes de aplicación y públicos, detalles del entorno, manifiestos de módulos, notas de despliegue o actualización, estado de acceso y un registro de cambios estructurales posteriores al corte de evidencias.
| Componente del paquete | Responsable | Evidencia | Condición de listo |
|---|---|---|---|
| Base de datos | Administrador de base de datos | Volcado con marca temporal y nota de preparación para restauración | Las tablas del núcleo y de módulos proceden del mismo estado de la tienda. |
| Aplicación y archivos públicos | Responsable técnico | Archivo de ficheros o árbol de origen accesible | Módulos, temas, recursos multimedia y archivos protegidos están disponibles. |
| Entorno | Responsable técnico | Notas de PHP, base de datos, colas, caché, almacenamiento y servidor web | Puede interpretarse la lógica sensible a versiones. |
| Manifiesto de módulos | Desarrollador o administrador de la tienda | Lista de módulos activos/inactivos con versiones | Las entidades propiedad de módulos pueden rastrearse. |
| Registro de cambios | Responsable del proyecto | Cambios tardíos después de recopilar evidencias | Los nuevos Products, módulos o cambios de esquema son visibles. |
Selecciona muestras representativas para probar la migración
Prepara un manifiesto de muestras que incluya ID de origen, registros relacionados de módulos o sistemas externos, archivos multimedia y las relaciones esperadas en la tienda de origen. El manifiesto está listo cuando la evidencia seleccionada es completa, trazable y tiene un revisor asignado.
Incluye:
- Products simples y Products de varias clases de Product;
- Products con atributos descriptivos, valores introducidos por Customers y variaciones activas;
- un caso de variante heredado o variación migrada si la tienda ha pasado por ese cambio de módulo;
- Products restringidos por membresía o propiedad de vendedores cuando se utilicen;
- Customers con membresías, varias direcciones, ID externos o roles de vendedor;
- Orders de invitados y registrados con variaciones, totales inusuales, reembolsos, envíos y registros creados por módulos;
- ejemplos importantes de Category, contenido, recursos multimedia y rutas;
- un registro activo de módulo personalizado y una relación con un sistema externo.
Aplica el control final de preparación de X-Cart
| Pregunta de preparación | Resultado requerido |
|---|---|
| ¿Se conoce el linaje del origen? | Están registradas la versión, el contexto de edición, el historial de actualizaciones, la generación de módulos y el entorno. |
| ¿Está completo el significado del catálogo? | Están representadas clases de Product, atributos, variaciones, Categories, membresías, vendedores y recursos multimedia. |
| ¿Son interpretables las cuentas y Orders? | Roles, membresías, direcciones, instantáneas de Order, estados y referencias externas tienen responsables. |
| ¿Están clasificados los módulos y datos personalizados? | Los registros activos e históricos propiedad de módulos tienen una disposición definida. |
| ¿Se han inventariado contenido y rutas? | Están documentadas rutas públicas, rutas de módulos, recursos multimedia y activos de presentación. |
| ¿Es restaurable el paquete de origen? | La base de datos y los archivos corresponden al mismo estado de la tienda. |
| ¿Es representativo el manifiesto de muestras? | Incluye casos principales, complejos, heredados, propiedad de módulos y relacionados con sistemas externos. |
Las incógnitas críticas deben mantenerse como decisiones abiertas con un responsable. No finalices la preparación mientras el modelo de variaciones, el propietario de un módulo, la relación con un vendedor o un identificador externo sigan sin clasificar.
Conclusión
La preparación de una migración hacia X-Cart depende del linaje del origen. La versión, la generación de módulos, las clases de Product, los atributos, las variaciones, las membresías, los vendedores, las extensiones de Orders, los módulos personalizados y los sistemas externos determinan qué registros existen y cómo se relacionan.
Un paquete de origen restaurable y un manifiesto de evidencias representativas permiten que la configuración de la migración refleje la tienda real.
Preguntas frecuentes
¿Por qué deben registrarse la versión de X-Cart y la generación de módulos?
Las estructuras y las implementaciones de módulos de X-Cart han cambiado entre generaciones. Un mismo concepto visible en la tienda puede almacenarse mediante módulos, entidades o API diferentes, por lo que la versión activa y el conjunto de módulos determinan qué evidencia es autoritativa.
¿Los atributos y Product variations de X-Cart son lo mismo?
No. Los atributos pueden describir Products, recopilar valores introducidos por Customers o participar en variaciones vendibles. Solo las relaciones que definen un SKU, stock, precio, peso o imagen independientes deben tratarse como identidad de variación.
¿Qué debe prepararse para las membresías de X-Cart?
Registra las definiciones de membresía, las asignaciones de Customers, las restricciones de Product o Category, los efectos sobre precios, las reglas de cuenta y Orders representativos. Una etiqueta de membresía por sí sola no conserva su significado comercial o de acceso.
¿Deben ignorarse los módulos inactivos de X-Cart?
No automáticamente. Un módulo inactivo aún puede ser propietario de registros históricos de Order, campos de Customer o identificadores externos. Registra si sus datos siguen siendo necesarios antes de considerarlo obsoleto.
¿Qué debe incluir el manifiesto de muestras de X-Cart?
Incluye Products simples y basados en clases, atributos y variaciones, membresías o vendedores cuando se utilicen, Orders complejos, rutas importantes, registros propiedad de módulos y relaciones con sistemas externos. Utiliza ID exactos del origen y las evidencias relacionadas.
¿Por qué se necesitan copias de seguridad tanto de la base de datos como de los archivos?
La base de datos contiene registros del núcleo y de módulos, mientras que los archivos pueden contener módulos, temas, recursos multimedia, activos descargables, configuración y código personalizado. Un paquete completo de origen necesita ambos elementos correspondientes al mismo estado de la tienda.