Las tiendas X-Cart suelen contener varias generaciones de lógica de catálogo y extensiones. Las versiones actuales de la plataforma distinguen Product Variations de los Product Variants heredados, mientras que las clases y los atributos de Product aportan información estructurada del catálogo. Los registros de Customer pueden estar vinculados a tipos de usuario, roles, direcciones, campos de perfil y membresías. Orders utiliza estados de pago y de procesamiento separados. Los módulos pueden añadir precios mayoristas, compatibilidad de vehículos, datos de distribuidores, reseñas, fidelización, suscripciones o lógica de mercado electrónico.
Estas capas significan que una migración de X-Cart no puede reducirse a Products, Categories, Customers y Orders. Una matriz de color y talla en la tienda de origen puede requerir Product Variations actuales, interpretación de variantes heredados u otra estructura de opciones de Product. Un grupo de Customer puede representar precios por membresía, acceso, impuestos o restricciones de pago. Un valor de compatibilidad de vehículos puede pertenecer a un módulo y a una taxonomía externa de vehículos, en lugar de a un atributo general de Product.
Por tanto, la migración depende de traducir correctamente la propiedad y las relaciones: qué entidad de X-Cart es propietaria del valor, qué otros registros le dan significado y si el valor pertenece al núcleo, a una estructura heredada, a un módulo, a la presentación o a un sistema externo.
El significado del catálogo de X-Cart depende de la versión y de los módulos instalados
Las estructuras de datos actuales y heredadas de X-Cart deben separarse antes de definir las correspondencias. Las versiones actuales de X-Cart utilizan Product Variations, mientras que las tiendas antiguas pueden conservar estructuras heredadas de Product Variants. Las instalaciones de X-Cart con muchos años de evolución también pueden contener módulos históricos, código personalizado o estructuras importadas que no coinciden con una instalación actual limpia.
| Evidencia en la tienda de origen | Interpretación en X-Cart | Consecuencia para la migración |
|---|---|---|
| Registros actuales de variaciones | Product Variations y los datos de Product relacionados | Preservar la identidad actual de la variación, los atributos seleccionados y los valores comerciales. |
| Tablas o campos de variantes heredados | Estructura heredada de Product Variants | Interpretar según la versión de origen en lugar de asumir el esquema actual. |
| Registros de clases y atributos de Product | Características estructuradas de Product y definiciones de atributos reutilizables | Mantener la pertenencia a la clase y las relaciones entre atributos y valores. |
| Campos de Product específicos de un módulo | Datos de extensión propiedad del módulo | No tratar todos los campos como parte del núcleo de X-Cart. |
| Tablas personalizadas de base de datos | Entidad o relación personalizada | Definir un destino solo después de identificar el flujo de trabajo que consume esos datos. |
| ID de integraciones externas | Identificador de ERP, PIM, WMS, CRM, mercado electrónico o sistema automotriz | Preservar las claves estables necesarias para volver a conectar la tienda de destino. |
La versión de origen y el inventario de módulos no son simples metadatos técnicos. Determinan qué significa realmente un campo de Product, opción, Customer u Order. Dos tiendas X-Cart pueden utilizar la misma etiqueta y, aun así, almacenar y consumir el valor de forma distinta.
Products, variaciones, clases y atributos cumplen funciones diferentes
Un Product de X-Cart contiene la identidad principal, como nombre, SKU, precio, inventario, descripciones, imágenes, asignaciones de Category, propiedades de envío e impuestos y visibilidad. Product Variations representa versiones seleccionables de un Product. Las clases y los atributos describen características estructuradas y pueden respaldar la organización del catálogo, el filtrado, la comparación o la información de la página de Product.
Una opción de Product de la tienda de origen debe clasificarse según su función. Si el valor seleccionado identifica una combinación gestionada por separado con su propio precio, cantidad, SKU, imagen o peso, se aproxima más a una variación. Si el valor modifica un Product sin inventario independiente, puede ser más adecuada otra estructura de selección. Si el valor describe el Product sin cambiar el artículo comprado, corresponde a atributos o contenido.
| Patrón de origen | Pregunta sobre el destino en X-Cart | Relación que debe preservarse |
|---|---|---|
| SKU hijo por combinación de color y talla | Product Variation actual o Product Variant heredado | Identidad del hijo, stock, precio, contenido multimedia y valores seleccionados. |
| Campo de personalización | Entrada del comprador u opción de Product propiedad de un módulo | El valor introducido permanece asociado a la línea de Order. |
| Especificación técnica | Atributo de Product bajo la clase adecuada | La característica estructurada permanece separada de una elección de compra. |
| Precio mayorista por cantidad | Relación de precios mayoristas del núcleo o propiedad de un módulo | Los umbrales de cantidad y el alcance de la membresía permanecen conectados. |
| Archivo digital | Relación de E-goods o archivo adjunto cuando corresponda | El acceso pertenece al contexto correcto de Product y Order. |
| Compatibilidad de vehículos | Registro del módulo de compatibilidad y taxonomía de vehículos | La relación entre Product y vehículo permanece separada de los atributos generales. |
Las Product Variations actuales de X-Cart y los Product Variants heredados nunca deben mezclarse de forma indiscriminada. Una migración puede necesitar interpretar registros heredados y representarlos en un modelo actual de la tienda de destino, pero la procedencia debe seguir siendo clara para evitar duplicar o perder identidades hijas y combinaciones de opciones.
Categories, clases, atributos y búsqueda definen cómo se descubre el catálogo
Categories organiza la navegación del comprador y la asignación de Products. Las clases de Product agrupan atributos reutilizables. Los atributos contienen características de Product. Los módulos de búsqueda y filtrado pueden indexar Categories, atributos, SKU, marcas, etiquetas, compatibilidad de vehículos u otros valores propiedad de extensiones. Estas estructuras están relacionadas, pero no son intercambiables.
Una marca representada como Category en la tienda de origen puede encajar mejor como atributo o registro de un módulo de marcas en X-Cart. Un árbol de especificaciones puede convertirse en clases y atributos de Product. Una página de destino puede necesitar contenido y navegación en lugar de una Category. Un selector de compatibilidad puede depender de registros de vehículos y de una relación Product-vehículo, no de filtros ordinarios.
| Elemento de descubrimiento | Propietario en X-Cart | Límite de traducción |
|---|---|---|
| Jerarquía orientada al comprador | Category y asignaciones de Product | La existencia de una Category no recrea automáticamente la navegación. |
| Especificación de Product | Clase y valor de atributo | Los valores permanecen estructurados y conectados con el tipo correcto de Product. |
| Marca | Atributo o registro de módulo de marcas | El significado de la marca no debe duplicarse entre Categories y campos. |
| Valor filtrable | Atributo o campo de índice propiedad de un módulo | El funcionamiento de la búsqueda depende de valores normalizados y de la indexación en destino. |
| Compatibilidad de vehículos | Registros de compatibilidad automotriz | La compatibilidad necesita taxonomía de vehículos y claves de relación, no texto libre. |
| Product relacionado | Relación de Product del núcleo o propiedad de un módulo | Los enlaces de merchandising permanecen separados de la pertenencia a Categories. |
Este modelo evita que la lógica de descubrimiento se reduzca a descripciones de Product. Una descripción migrada puede mostrar especificaciones, pero no sustituye a los atributos estructurados, la compatibilidad, la comparación ni las relaciones de filtrado.
Customers, tipos de usuario, roles, campos de perfil y membresías son elementos distintos
La gestión de usuarios de X-Cart puede incluir administradores, Customers y vendedores; roles y permisos; cuentas de Customer y direcciones; campos de perfil personalizados; y niveles de membresía. Las membresías pueden afectar al acceso a Products y Categories, a los precios de Product, a cantidades mínimas, descuentos, cupones, ofertas especiales, impuestos o métodos de pago.
Por tanto, un segmento de Customer de la tienda de origen debe interpretarse por su función. Los estados de mayorista, distribuidor, VIP, empleado, exento de impuestos, comprador autorizado, fidelización o suscripción no tienen por qué pertenecer a una membresía genérica. Algunos valores son datos de identidad, otros son reglas de acceso comercial, otros pertenecen a módulos y otros son clasificaciones de un CRM o ERP externo.
| Significado de la cuenta de origen | Propietario de X-Cart que debe considerarse | Relación que debe conservarse |
|---|---|---|
| Comprador individual | Cuenta de Customer y libreta de direcciones | Identidad, inicio de sesión, direcciones y Orders permanecen conectados. |
| Usuario administrativo | Tipo de usuario administrador y rol | Los permisos permanecen separados de la segmentación de Customers. |
| Usuario vendedor de mercado electrónico | Usuario vendedor y relación organizativa propiedad de un módulo | El usuario pertenece al vendedor o entidad de mercado electrónico correctos. |
| Nivel de precios o acceso | Nivel de membresía y reglas comerciales relacionadas | La membresía afecta a los Products, precios, impuestos o métodos previstos. |
| Información adicional de Customer | Campo de perfil o identificador externo | La finalidad del campo y la privacidad permanecen explícitas. |
| Cuenta de empresa externa | Estructura personalizada/de módulo o clave de sistema externo | Varios compradores siguen asociados a la empresa autoritativa cuando sea necesario. |
El historial de membresía también es distinto de la asignación actual. Un Order histórico debe conservar el precio, descuento, impuesto y evidencia de pago registrados en el momento de la compra; no debe recalcularse a partir de la membresía actual del Customer después de la migración.
Orders utiliza relaciones comerciales y de procesamiento separadas
Orders de X-Cart puede incluir identidad de Customer o invitado, direcciones, referencias de Product y variación, atributos seleccionados, cantidades, precios, descuentos, impuestos, estado de pago, estado de procesamiento, envíos, transacciones, devoluciones, notas, facturas y registros propiedad de módulos. X-Cart separa los estados de pago y de procesamiento, por lo que un único estado genérico del Order de origen puede no contener información suficiente.
| Elemento del Order de origen | Relación en X-Cart | Significado histórico |
|---|---|---|
| Línea de Order | Instantánea de Product o variación, SKU, cantidad, precio y opciones seleccionadas | Explica exactamente qué se compró. |
| Estado de pago | Estado de pago y registros de transacción | Separa el progreso financiero del progreso de procesamiento. |
| Estado de procesamiento | Estado de procesamiento, envío y seguimiento | Explica qué se envió o qué sigue pendiente. |
| Devolución o reembolso | Registro del módulo de devoluciones, importe reembolsado y líneas afectadas cuando estén disponibles | Preserva el historial posventa. |
| Dirección del Customer | Instantánea de facturación y envío en el momento del Order | La dirección histórica no debe cambiar cuando se edita el perfil actual. |
| Estado o referencia propiedad de un módulo | Suscripción, descarga, reserva, mercado electrónico u otra relación | La evidencia histórica permanece conectada con el flujo de trabajo que la creó. |
Cuando la plataforma de origen combina varios estados en una sola etiqueta, la migración debe preservar la evidencia subyacente en lugar de forzar la etiqueta a un único campo. La configuración actual de pagos, envíos, impuestos y notificaciones permanece separada de los registros históricos de Orders.
El contenido, las páginas estáticas, las URL y la presentación de la tienda tienen propietarios distintos
Los datos visibles de una tienda X-Cart pueden incluir descripciones de Products y Categories, Pages estáticas, menús, imágenes, vídeos, pestañas personalizadas de Product, banners, bloques de diseño, temas, metadatos, URL limpias, redirecciones y valores por idioma. Estos recursos deben separarse según su propiedad de contenido, ruta y presentación.
Las descripciones de Product pertenecen a Products. Las Pages estáticas tienen su propia identidad y ruta. Las pestañas personalizadas de Product pueden pertenecer a un módulo. Los menús y bloques de diseño controlan la ubicación. Los temas y plantillas definen la presentación. Los metadatos SEO y las redirecciones protegen las relaciones entre rutas. Una tienda headless o muy personalizada puede mantener contenido adicional fuera del núcleo de X-Cart.
| Recurso de origen | Capa de destino en X-Cart | Significado que debe preservarse |
|---|---|---|
| Descripción de Product o Category | Contenido del catálogo | El texto permanece asociado a la entidad y el idioma correctos. |
| Página informativa estática | Registro de Page | Contenido, ruta, jerarquía y visibilidad permanecen diferenciados. |
| Pestaña personalizada de Product | Relación de contenido de Product propiedad de un módulo | La ubicación de la pestaña y la asignación al Product permanecen conectadas. |
| Banner o bloque de inicio | Configuración de presentación o registro de módulo | La ubicación visual no queda implícita por migrar el contenido. |
| URL heredada | Estructura de URL limpia y redirección | La ruta antigua y el destino en la tienda de destino permanecen explícitos. |
| Personalización del tema | Implementación de presentación en destino | El código de plantilla no es contenido CMS ordinario. |
Este modelo de propiedad evita un error habitual de clasificación: tratar todos los elementos visibles de la tienda como contenido portable. Algunos elementos visibles se generan a partir de Products y Categories, otros son Pages separadas y otros existen solo porque un módulo o tema los representa.
Los módulos de X-Cart pueden ser propietarios de datos de catálogo, Customer y Order
Los módulos de X-Cart pueden introducir campos y entidades para precios mayoristas, fidelización, suscripciones, reseñas, archivos adjuntos de Product, pestañas personalizadas, compatibilidad automotriz, distribuidores, vendedores de mercado electrónico, devoluciones, inicio de sesión social, servicios fiscales, servicios de pago, integraciones de envío y flujos de datos externos. Los registros de módulos pueden depender de configuraciones, procesos programados, credenciales API o taxonomías externas.
La pregunta central de la migración no es si existe un módulo con el mismo nombre en la tienda de destino. La pregunta es si los registros y las relaciones siguen siendo necesarios y si la plataforma de destino ofrece un lugar capaz de interpretarlos.
| Propietario de los datos | Registros de ejemplo | Implicación para el alcance |
|---|---|---|
| Núcleo de X-Cart | Products, Categories, clases, atributos, usuarios, Orders, Pages | Mapear mediante relaciones de datos nativas. |
| Módulo de X-Cart | Precios por membresía, compatibilidad, ubicaciones de distribuidores, reseñas, fidelización, suscripciones | Inspeccionar el esquema del módulo y sus vínculos con registros principales. |
| Código personalizado | Campos, tablas, estados o flujos de trabajo a medida | Definir deliberadamente un destino o una decisión de archivo. |
| Servicio externo | Pagos, impuestos, envíos, búsqueda, mercado electrónico, analítica | Preservar las referencias necesarias para conciliar sistemas históricos y activos. |
| ERP/PIM/WMS/CRM | Identificadores maestros de Product, Customer, stock y Order | Mantener claves estables para reconexión y propiedad. |
Los datos automotrices ilustran bien esta diferencia. Año, marca, modelo, motor, acabado, tipo de compatibilidad y ubicación del distribuidor pueden parecer atributos de Product, pero la compatibilidad operativa depende de taxonomías compartidas de vehículos y relaciones Product-vehículo. Aplanarlos como texto puede conservar las palabras y destruir al mismo tiempo la búsqueda y el mantenimiento de compatibilidades.
Los formatos de transferencia de datos no definen por completo el modelo de X-Cart
Las funciones de importación y exportación de X-Cart pueden gestionar Products, Categories, atributos, usuarios, Orders, inventario, reseñas y determinados registros de módulos. Que un campo exista en un CSV confirma que los datos pueden representarse en un formato de transferencia; no demuestra que se incluyan todas las relaciones, configuraciones de módulos o dependencias externas que lo rodean.
Por ejemplo, importar un valor de atributo no recrea automáticamente su clase de Product ni su funcionamiento de presentación. Importar un Customer no establece precios específicos por membresía si no existen la membresía y sus reglas relacionadas. Importar un Order no recrea los métodos actuales de pago o envío. Importar un ID de compatibilidad carece de significado si falta la taxonomía de vehículos a la que hace referencia.
| Evidencia de transferencia | Relación adicional que debe identificarse |
|---|---|
| Fila de Product | Category, clase, atributos, variación, contenido multimedia, stock y vínculos de módulos. |
| Valor de atributo | Definición del atributo, asignación de clase, tipo de entrada y relación con Product. |
| Fila de Customer | Tipo de usuario, direcciones, campos de perfil, membresía e identidad externa. |
| Fila de Order | Líneas, estados, transacciones, envíos, devoluciones e instantáneas históricas. |
| CSV de módulo | Módulo instalado, tablas de referencia, configuración y taxonomía externa. |
| Campo de ID externo | Sistema autoritativo, regla de unicidad y proceso de reconexión. |
El plan de traducción debe seguir las relaciones entre los datos, no la forma de un único archivo de exportación. Esto es especialmente importante en tiendas X-Cart antiguas cuyos datos pueden haber pasado por actualizaciones, importaciones personalizadas o sustituciones de módulos.
Decisiones de traducción de X-Cart según el significado empresarial
| Patrón de origen | Pregunta de traducción correcta | Consecuencia de una suposición incorrecta |
|---|---|---|
| Combinaciones hijas actuales o heredadas | ¿La tienda de origen utiliza Product Variations actuales, Product Variants heredados o lógica personalizada de opciones? | El SKU hijo, el stock, el precio o los valores seleccionados se duplican o se pierden. |
| Especificaciones técnicas | ¿Pertenecen a clases y atributos de Product? | El filtrado, la comparación y el gobierno del catálogo dejan de ser fiables. |
| Segmento mayorista o de distribuidores | ¿El significado corresponde a una membresía, a datos de empresa propiedad de un módulo o a una clasificación de CRM externa? | Los precios y el acceso se vinculan a una capa de identidad incorrecta. |
| Estado combinado de Order | ¿Cómo debe separarse la evidencia de pago y procesamiento? | El estado financiero o de envío histórico resulta engañoso. |
| Compatibilidad automotriz | ¿Qué módulo y taxonomía de vehículos son propietarios de la relación? | La búsqueda y el mantenimiento de compatibilidades desaparecen aunque los valores textuales migren. |
| Pestaña o campo personalizado | ¿Es contenido del núcleo, datos de un módulo o presentación del tema? | Los datos llegan sin la estructura de la tienda que los utiliza. |
| Clave de ERP o mercado electrónico | ¿Qué sistema es autoritativo y qué registro identifica la clave? | El registro migrado no puede conciliarse ni sincronizarse. |
Una migración de X-Cart conserva el significado cuando el linaje de versiones, los tipos y estructuras principales de datos, los módulos y los sistemas externos se tratan como dominios de propiedad distintos. Este enfoque permite que, en la tienda de destino, las opciones de Product, el tratamiento de Customers, los Orders históricos, el contenido y las integraciones sigan siendo comprensibles, no simplemente estén presentes.
Conclusión
La traducción del modelo de datos de X-Cart depende de la versión de origen, la estructura del catálogo, las relaciones de usuarios, la semántica de Orders, los módulos y los sistemas externos. Las Product Variations actuales deben distinguirse de los Product Variants heredados. Las clases y atributos de Product deben permanecer separados de las elecciones de compra. Las membresías pueden gobernar precios, acceso, impuestos y relaciones de pago. Orders requiere contextos separados de pago, procesamiento, transacción, envío y devolución. Los módulos pueden ser propietarios de registros como precios mayoristas, compatibilidad, distribuidores, fidelización, suscripciones y datos de mercado electrónico.
Un alcance de migración sólido asigna cada valor de origen a la entidad o módulo de X-Cart que posee el mismo significado empresarial y preserva identificadores estables entre sistemas conectados. Esto evita la falsa seguridad de una transferencia campo por campo y produce una tienda de destino cuyo catálogo e historial comercial siguen siendo utilizables.
Preguntas frecuentes
¿Cuál es la diferencia entre las Product Variations actuales de X-Cart y los Product Variants heredados?
Pertenecen a generaciones distintas de la estructura de catálogo de X-Cart. Las versiones actuales utilizan Product Variations, mientras que las tiendas antiguas todavía pueden contener registros heredados de Product Variants. Deben identificarse la versión de origen y las relaciones entre tablas antes de representar esas combinaciones en la tienda de destino.
¿Todas las opciones de la tienda de origen deberían convertirse en una Product Variation de X-Cart?
No. Un valor encaja como variación cuando identifica una combinación gestionada por separado con valores comerciales propios. La personalización, los servicios de regalo o las especificaciones descriptivas pueden corresponder a otra estructura de selección de Product, a un atributo o a un campo propiedad de un módulo.
¿Cómo afectan a la migración las clases y los atributos de Product de X-Cart?
Las clases agrupan definiciones de atributos reutilizables, mientras que los valores de atributo describen Products individuales. Preservar solo los valores sin las relaciones de clase y definición debilita el gobierno del catálogo, el filtrado, la comparación y la estructura de las páginas de Product.
¿Un grupo de Customer de la tienda de origen puede convertirse siempre en una membresía de X-Cart?
No. Una membresía es adecuada cuando gobierna la lógica comercial o de acceso de X-Cart. Los segmentos de marketing, las relaciones de empresa, el estado de fidelización, los indicadores fiscales y las clasificaciones de CRM externas pueden requerir destinos diferentes.
¿Por qué los datos de compatibilidad automotriz deben tratarse por separado de los atributos ordinarios de Product?
La compatibilidad suele depender de registros compartidos de vehículos y de relaciones Product-vehículo. Los valores de año, marca y modelo en texto libre no preservan la taxonomía ni las claves de relación necesarias para una búsqueda y un mantenimiento precisos de la compatibilidad.
¿Qué debe hacerse con los registros propiedad de un módulo o una tabla personalizada de X-Cart?
Identifica el módulo o flujo de trabajo personalizado, los registros principales que amplía y cualquier taxonomía o identificador externo que utilice. Las relaciones activas necesitan un destino explícito en la tienda de destino; los datos obsoletos pueden archivarse o excluirse sin clasificarlos erróneamente como datos nativos de Product, Customer u Order.