Migrar datos hacia PrestaShop implica traducirlos a un modelo de catálogo que separa la variación comprable, las características descriptivas, la personalización introducida por el cliente, el alcance por tienda y el comportamiento gestionado por módulos. Registros conocidos como Products, Categories, Customers, Orders, Coupons, CMS Pages, imágenes y URL cambian de significado cuando pasan a formar parte de las relaciones de PrestaShop entre combinaciones, características, grupos de clientes, multitienda, idiomas y módulos.
La distinción central es que una plataforma de origen puede utilizar una única capa amplia de "opciones" o campos personalizados para varias funciones diferentes. En PrestaShop, un valor puede tener que convertirse en un atributo utilizado por una combinación, una característica compartida por todo el Product, un campo de personalización que completa el cliente, una asociación de Product, una asignación a Category, una relación con un grupo de clientes, un valor específico de tienda o un registro gestionado por un módulo. Mapear únicamente por el nombre del campo en lugar de por su significado comercial puede dejar un catálogo técnicamente poblado, pero comercialmente incoherente.
El significado del catálogo de PrestaShop comienza por la estructura del producto
Los Products de PrestaShop pueden ser Products estándar, Products con combinaciones, packs o Products virtuales. El registro de Product también mantiene asociaciones con Categories, contexto de marca y proveedor, imágenes, adjuntos, Products relacionados, características, campos de personalización, precios, stock, idiomas y alcance por tienda. Estas relaciones determinan cómo se selecciona, presenta, gobierna y vende el Product.
| Significado en el origen | Pregunta para el destino PrestaShop | Consecuencia sobre la relación |
|---|---|---|
| Un artículo vendible sin versiones seleccionables | ¿Debe seguir siendo un Product estándar? | La identidad, referencia, precio, stock, imagen, impuesto, Category y URL permanecen a nivel de Product. |
| Talla, color, capacidad, acabado u otra versión comprable | ¿Deben los atributos crear combinaciones? | La identidad de combinación puede controlar referencia, impacto de precio, cantidad, imagen y valores seleccionados. |
| Especificación estable como material o país de origen | ¿Debe convertirse en una característica? | El valor describe el Product completo en lugar de crear una versión comprable distinta. |
| Texto introducido por el cliente o personalización mediante archivo | ¿Debe convertirse en un campo de personalización u otra estructura de destino? | La entrada del cliente permanece separada de los atributos y de las características descriptivas. |
| Grupo de Products existentes vendidos juntos | ¿Es un pack, una asociación, una Category u otra relación de merchandising? | El destino debe preservar la identidad de cada Product y la intención de agrupación sin duplicarlos. |
| Elección o registro generado por un módulo | ¿Qué módulo o proceso de destino es su propietario? | Los campos principales de Product no deberían absorber accidentalmente comportamiento activo de una extensión. |
La representación correcta en el destino depende de lo que hace el valor. Un valor denominado "Color" puede crear una combinación, describir una característica del Product, apoyar una experiencia de Category o filtrado, o existir únicamente como salida de un módulo. La etiqueta por sí sola no basta.
Las combinaciones, los atributos, las características y las personalizaciones no son intercambiables
Las combinaciones de PrestaShop representan versiones comprables de un Product. Se crean a partir de valores de atributos y pueden tener su propia referencia, impacto de precio, cantidad, asociación de imagen, impacto de peso, disponibilidad y otros datos a nivel de variación. Las características describen propiedades compartidas por el Product y no cambian qué versión compra el cliente. Los campos de personalización recopilan texto o archivos proporcionados por el cliente.
Esta separación debe seguir siendo visible en el modelo migrado:
| Estructura de PrestaShop | Significado comercial | Error habitual al pasar del origen al destino |
|---|---|---|
| Grupo y valor de atributos | Dimensión seleccionable, como talla o color | Convertir especificaciones descriptivas en opciones que el cliente debe seleccionar. |
| Combinación | Combinación válida y comprable de atributos | Aplanar variantes reales en un único Product y perder SKU hijo, precio, imagen o stock. |
| Característica y valor de característica | Propiedad estable del Product | Convertir especificaciones útiles para filtrado o comparación en texto libre. |
| Campo de personalización | Texto o archivo introducido por el cliente | Tratar la personalización como un valor fijo de atributo o una nota de Order. |
| Pack | Relación que agrupa Products existentes | Duplicar datos de componentes o confundir un paquete con una variación. |
| Product virtual | Product no físico con significado de entrega asociado | Conservar una referencia de archivo sin sus relaciones con el Product y el acceso. |
Una plataforma de origen puede guardar variantes hijas como Products separados. PrestaShop puede representarlas como combinaciones bajo un Product padre cuando realmente son versiones del mismo artículo. Del mismo modo, Products independientes no deberían colapsarse como combinaciones si tienen identidad propia de merchandising, contenido, ciclo de vida o informes.
La generación de combinaciones también depende del vocabulario de atributos. Valores inconsistentes en el origen como "Large", "L" y "large" deben revisarse antes de convertirse en valores de atributo separados en el destino. Sin embargo, la normalización no debe fusionar valores que tengan SKU, precios, stock o significado para el cliente diferentes.
Categories, marcas, proveedores y asociaciones determinan el descubrimiento
Las Categories de PrestaShop forman rutas jerárquicas de catálogo y pueden contener descripciones, imágenes, metadatos, URL amigables, asociaciones de Product y contexto de tienda. Un Product puede estar asociado a varias Categories mientras una Category actúa como su Category principal. Las marcas, proveedores, Products relacionados, accesorios y packs crean relaciones adicionales de descubrimiento u operación.
Las plataformas de origen suelen mezclar estas funciones. Una colección puede ser una familia real de Products, una campaña estacional, un archivo de marca, un resultado de filtro, un acceso directo de navegación o una página de destino SEO. Reproducir cada agrupación del origen como Category de PrestaShop puede conservar desorden y duplicar intenciones.
| Estructura de origen | Posible significado en PrestaShop | Señal para decidir |
|---|---|---|
| Familia jerárquica permanente | Árbol de Categories | Clientes y personal utilizan la jerarquía como una ruta estable del catálogo. |
| Agrupación por marca o fabricante | Relación de marca, Category, característica o página de contenido | El destino debe responder a necesidades de navegación, confianza, informes y gobernanza del Product. |
| Referencia de proveedor | Relación con proveedor o clave externa de aprovisionamiento | El valor sirve para abastecimiento o administración, no para identidad visual de la tienda. |
| Colección estacional o de campaña | Category temporal, regla de merchandising o página de destino de contenido | La estructura puede no justificar una jerarquía permanente del catálogo. |
| Products relacionados o accesorios | Asociación de Product | La relación apoya la venta cruzada sin cambiar la identidad del Product. |
| Paquete de Products existentes | Pack u otra estructura de paquete definida | Los componentes siguen identificables y el paquete no se convierte en una falsa variación. |
La relación entre Category principal y URL amigable merece atención especial porque el contexto de Category puede influir en cómo se generan e interpretan las rutas de Product. Un Product puede seguir asignado al conjunto correcto de Categories y aun así recibir una ruta principal no deseada si no se define correctamente la relación principal.
La identidad del Customer y el tratamiento por grupos deben separarse
Un registro de Customer en PrestaShop contiene identidad, información de contacto, direcciones, estado de la cuenta, contexto de idioma y relaciones con Orders. Los grupos de clientes pueden influir en cómo la Store trata al comprador mediante descuentos, visualización de precios, visibilidad u otro comportamiento configurado. Por tanto, el grupo no es simplemente una etiqueta.
| Patrón de cliente de origen | Pregunta para el modelo de destino | Resultado de la relación |
|---|---|---|
| Cuenta minorista normal | ¿Qué identidad, dirección, idioma y vínculos con Orders siguen siendo autoritativos? | El historial del Customer permanece conectado con la cuenta correcta. |
| Comprador mayorista o profesional | ¿Qué grupo, precio, impuesto, visibilidad o relación de cuenta externa define su tratamiento? | La identidad del comprador permanece separada de las reglas comerciales. |
| Segmento de fidelización o membresía | ¿El valor es un grupo principal, un registro de módulo, un segmento CRM o una etiqueta histórica? | El destino conserva únicamente la relación que seguirá utilizándose. |
| Comprador invitado | ¿Debe el Order conservar identidad sin crear una cuenta normal? | El Order histórico sigue siendo interpretable sin generar una continuidad de cuenta falsa. |
| Customers duplicados | ¿Qué registro controla email, direcciones, Orders e identificadores externos? | Las decisiones de consolidación no rompen las relaciones con Orders. |
Un grupo de clientes del origen puede haber afectado precios, tratamiento fiscal, acceso al catálogo, aprobación o comunicación fuera de la Store principal. Migrar únicamente el nombre del grupo no conserva esos resultados. El modelo de destino debe indicar qué comportamiento pertenece a la configuración de PrestaShop, qué pertenece a un módulo y qué sigue siendo responsabilidad de un CRM o ERP externo.
Multitienda añade propiedad específica de tienda a registros compartidos
La función multitienda de PrestaShop permite gestionar varias tiendas o grupos de tiendas desde un único back office. Para la migración, esto significa que Products, Categories, Customers, contenido, idiomas, monedas, URL y comportamiento de módulos pueden ser compartidos, heredados o específicos de una tienda. Un recuento de registros no demuestra si se ha conservado esa propiedad.
| Área multitienda | Decisión de propiedad |
|---|---|
| Products y combinaciones | ¿Qué tiendas reciben el Product, la variación, la visibilidad, el precio y el contexto de cantidad? |
| Categories | ¿Qué árbol raíz y asociación de tienda determinan la ubicación de navegación? |
| Customers y grupos | ¿Qué identidades y tratamientos comerciales son compartidos o específicos de tienda? |
| Idiomas y campos localizados | ¿Qué nombres, descripciones, slugs y metadatos traducidos pertenecen a cada idioma y tienda? |
| CMS Pages y contenido | ¿Qué tienda, idioma, ruta de navegación o dominio es propietario del contenido? |
| URL y dominios | ¿Qué tienda sustituye cada ruta importante del origen? |
| Módulos | ¿Qué registros o ajustes de módulos se aplican globalmente, por grupo de tiendas o por tienda individual? |
Aplanar las asignaciones a una tienda predeterminada puede hacer que los datos compartidos parezcan completos y, al mismo tiempo, eliminar límites de marca, región, idioma o B2B/B2C. El error opuesto, duplicar cada registro compartido por tienda, genera divergencia innecesaria y dificulta la gobernanza futura del catálogo.
Los Orders conservan evidencia de la transacción, no la configuración futura de la tienda
Los Orders de PrestaShop conectan Customers o identidades de invitados con instantáneas de Products, combinaciones, cantidades, precios, descuentos, impuestos, envío, etiquetas de pago, direcciones, mensajes, historial de estados y referencias de módulos. Los Orders históricos deben seguir siendo comprensibles incluso cuando el proceso de origen no tenga un equivalente exacto en PrestaShop.
| Relación del Order | Significado en el registro de destino |
|---|---|
| Línea de Product y combinación | Nombre comprado, referencia, atributos seleccionados, cantidad y precio en el momento de la venta. |
| Identidad de Customer o invitado | Contexto del comprador y relación con datos históricos de la cuenta. |
| Direcciones | Instantáneas de facturación y entrega utilizadas en la transacción. |
| Descuentos y vouchers | Efecto histórico sobre el Order, no recreación automática de reglas promocionales futuras. |
| Etiquetas de pago y transporte | Evidencia de la transacción original, no prueba de módulos activos en el destino. |
| Estado y mensajes | Contexto histórico de proceso y atención que puede necesitar mapeo semántico. |
| Referencia de módulo o externa | Clave entre sistemas o contexto gestionado por una extensión con una finalidad de destino definida. |
Un módulo de pago, transportista, regla fiscal, plantilla de email o personalización del proceso de compra forma parte de la configuración activa del destino. Las etiquetas históricas pueden conservarse sin fingir que el proceso futuro está desplegado. Esta frontera mantiene la utilidad de los Orders para soporte y finanzas sin confundir el historial transaccional con la configuración operativa.
Los módulos, overrides, temas y datos personalizados necesitan un propietario explícito
El ecosistema de módulos y overrides de PrestaShop puede ampliar Products, combinaciones, Customers, Orders, proceso de compra, promociones, Reviews, fidelización, feeds de marketplace, SEO, envío, pagos, analítica y administración. Por ello, un valor mostrado en el back office o en la tienda puede proceder de una tabla principal, una tabla de módulo, un override, lógica del tema o un sistema externo.
| Tipo de dependencia | Interpretación en el modelo de datos |
|---|---|
| Registro gestionado por un módulo | Identificar su Product, Customer, Order, elemento de contenido o registro externo padre y el módulo de destino que lo consumirá. |
| Campo personalizado en un registro principal | Utilizar un campo nativo o de extensión gobernado solo cuando se conoce el propietario de destino. |
| Override o código personalizado | Determinar si cambia almacenamiento, cálculo, validación o presentación en lugar de asumir que es dato transferible. |
| Campo del tema | Separar contenido duradero de diseño o marcado de plantilla específico del origen. |
| Identificador externo | Conservar claves de ERP, CRM, PIM, contabilidad, marketplace o preparación de pedidos dentro de una relación de integración gobernada. |
| Salida en caché o derivada | Recrearla desde datos autoritativos del destino en lugar de copiar residuos técnicos obsoletos. |
Los residuos de módulos no deben copiarse simplemente porque existan. A la vez, un campo gestionado por un módulo que controla identidad del Product, derecho del Customer, interpretación de Orders o continuidad de una integración no puede descartarse como metadato opcional. El modelo de destino debe identificar quién seguirá consumiendo ese dato.
El contenido, los idiomas y las URL contienen contexto de tienda
Los campos de Product, Category, CMS Page y otros contenidos de PrestaShop pueden localizarse. Nombres, descripciones, slugs, metadatos y textos de imágenes pueden variar según idioma y tienda. Una plataforma de origen puede utilizar, en cambio, Stores independientes, registros duplicados, plugins de traducción o URL específicas por idioma.
El modelo de destino debe distinguir identidad compartida de expresión localizada. Un mismo Product puede conservar una referencia común y una estructura de relaciones compartida mientras su nombre, descripción, slug y metadatos cambian por idioma. Un registro traducido del origen no debe convertirse en un Product duplicado salvo que represente realmente un artículo comercial separado.
Las URL también necesitan un objeto propietario. Una ruta de origen puede identificar un Product, una Category, una página de marca, una CMS Page, una ruta de idioma o un dominio de tienda. La ruta de destino debe resolver al objeto y contexto de tienda de PrestaShop que sustituyen esa intención. Las cadenas de URL amigable sin el registro, idioma y relación de tienda correctos no son suficientes.
La propiedad en el destino debe definirse antes de mapear campos
Un modelo de destino completo para PrestaShop asigna cada valor importante de origen a uno de estos resultados:
- un Product, combinación, atributo, característica, personalización, Category, Customer, Order, contenido o relación de tienda nativos;
- un módulo gobernado o campo personalizado con un propietario de destino que seguirá existiendo;
- una relación con un sistema externo cuyo identificador estable debe seguir siendo trazable;
- configuración o presentación del destino que debe reconstruirse en lugar de migrarse como datos;
- residuo heredado que debe archivarse o excluirse.
| Área de decisión | Pregunta sólida sobre propiedad |
|---|---|
| Variación de producto | ¿Qué Product y combinación de atributos controlan SKU, precio, cantidad, imagen e identidad comprable? |
| Información de producto | ¿Qué valores son características, descripciones, adjuntos o contenido localizado en lugar de combinaciones? |
| Descubrimiento del catálogo | ¿Qué Categories, marcas, proveedores, asociaciones y URL preservan la intención del cliente? |
| Tratamiento de clientes | ¿Qué grupo o relación externa gobierna precios, visibilidad, impuestos o derechos? |
| Multitienda | ¿Qué tienda o grupo de tiendas es propietario de cada asignación y valor localizado? |
| Datos de módulos/personalizados | ¿Qué módulo de destino, equipo o sistema externo seguirá utilizando el registro? |
Esta visión basada en propiedad evita que PrestaShop se convierta en un contenedor de etiquetas copiadas desde el origen. En su lugar, el catálogo migrado puede funcionar como un conjunto coherente de relaciones entre Products, Customers, Orders, contenido, tiendas y módulos.
Conclusión
Las diferencias del modelo de datos de PrestaShop se concentran en la separación entre Products y combinaciones, atributos y características, contenido fijo y personalización del cliente, identidad del Customer y tratamiento por grupo, registros compartidos y propiedad multitienda, Orders históricos y configuración futura, y registros principales frente a extensiones gestionadas por módulos.
Una migración fiable conserva estas distinciones antes de mapear campos. El resultado no es simplemente una base de datos poblada, sino un catálogo y una estructura de cuentas de destino cuyos registros conservan un significado comercial claro entre tiendas, idiomas, módulos y sistemas conectados.
Preguntas frecuentes
¿Por qué las combinaciones de PrestaShop son diferentes de las opciones de producto generales?
Las combinaciones son versiones comprables de un Product creadas a partir de valores de atributos. Pueden controlar referencia, impacto de precio, cantidad, imagen, peso y disponibilidad a nivel de variación. Una característica descriptiva o una personalización introducida por el cliente tiene una función diferente.
¿Las características de PrestaShop son lo mismo que los atributos?
No. Los atributos crean dimensiones seleccionables para las combinaciones, mientras que las características describen propiedades estables del Product. Confundirlos puede convertir especificaciones en elecciones innecesarias o aplanar variaciones reales como texto descriptivo.
¿Cómo deberían trasladarse las variantes de origen guardadas como Products separados?
Determine si realmente son versiones de un único Product o artículos comerciales independientes. La identidad compartida, contenido común, diferencias seleccionables, propiedad del SKU, stock, precios y ciclo de vida ayudan a decidir si las combinaciones son apropiadas.
¿Por qué los grupos de clientes necesitan algo más que mapear la etiqueta?
Un grupo de clientes puede estar relacionado con descuentos, visualización de precios, visibilidad, tratamiento fiscal o comportamiento de módulos. Conserve la relación Customer-grupo solo junto con una definición clara del tratamiento comercial que continuará en la Store de destino.
¿Cómo cambia multitienda el mapeo de datos?
Multitienda añade propiedad por tienda y grupo de tiendas a Products, Categories, Customers, contenido, idiomas, URL y módulos. Los registros compartidos deben seguir compartidos cuando corresponda, mientras que las asignaciones específicas por tienda no deben aplanarse en la tienda predeterminada.
¿Cómo deben tratarse los datos gestionados por módulos?
Rastree cada registro de módulo hasta su objeto padre, significado comercial y consumidor de destino. Conserve registros duraderos y claves de integración, reconstruya el comportamiento activo en el entorno de destino y excluya residuos en caché, derivados u obsoletos que no tengan una finalidad futura.