Si PrestaShop se selecciona como plataforma de destino, la preparación debe documentar tanto los registros comerciales como el contexto de tienda en el que funcionan. Los Products pueden depender de combinaciones, atributos, características, campos de personalización, proveedores, fabricantes, Categories, imágenes, stock, grupos de clientes, idiomas, monedas y asignaciones multitienda. Customers y Orders también pueden variar por tienda, grupo, transportista, módulo, moneda, impuestos y estado histórico.
Cada tarea de preparación debe identificar un responsable, un artefacto de evidencia y una condición de preparación. El paquete debe separar los registros del origen de la configuración del destino: Orders históricos, combinaciones de Product, grupos de Customers, asignaciones por tienda, URL y datos gestionados por módulos forman parte de la preparación de la migración, mientras que el comportamiento activo de transportistas, pagos, impuestos, temas, email y proceso de compra corresponde a la implementación del destino.
Asegure el back office, hosting, base de datos, archivos y copias de seguridad
Confirme el acceso al back office de PrestaShop, hosting, base de datos, sistema de archivos, directorios de imágenes, archivos descargables, tareas cron, ajustes de Webservice, gestión de módulos y servicios conectados. Registre la versión de PrestaShop, el entorno PHP y de base de datos, el prefijo de la base de datos, el tema activo, idiomas, monedas, tiendas, módulos, overrides y código personalizado.
| Acción de preparación | Responsable | Evidencia | Condición de preparación |
|---|---|---|---|
| Confirmar acceso administrativo | Administrador de PrestaShop | Cuenta funcional y resumen de permisos | Se pueden inspeccionar Products, combinaciones, Customers, Orders, tiendas, módulos y configuración. |
| Crear copias de seguridad recuperables | Responsable de infraestructura | Volcado de base de datos, archivo del sistema de archivos/imágenes, archivo de descargables y responsable de restauración | La Store de origen puede recuperarse sin depender del entorno activo. |
| Registrar el entorno técnico | Responsable técnico | Inventario de PrestaShop, PHP, base de datos, tema, módulos, overrides y despliegue | Los datos y personalizaciones dependientes de versión quedan documentados. |
| Registrar acceso de Webservice e integraciones | Responsables de integraciones | Claves de Webservice, recursos permitidos, endpoints externos y mapas de identificadores | Se conocen los sistemas que continuarán y las interfaces de origen disponibles. |
| Conservar identificadores de origen | Responsable de datos | IDs de tiendas, Products, combinaciones, Customers, Orders, direcciones, Categories, módulos y sistemas externos | Pueden conciliarse las relaciones entre tablas y sistemas. |
No elimine módulos inactivos, overrides o campos antiguos hasta revisar la propiedad de sus datos. Un componente inactivo todavía puede ser propietario de registros históricos de Product, Customer u Order.
Defina el alcance de multitienda, grupos de tiendas, idiomas y monedas
La función multitienda de PrestaShop puede aplicar datos y ajustes a todas las tiendas, a un grupo de tiendas o a una tienda individual. Las tiendas pueden compartir Customers u Orders según la configuración del grupo, mientras Products, Categories, precios, idiomas, transportistas, módulos y URL pueden variar por contexto.
| Área de alcance | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Árbol de tiendas | IDs de grupos y tiendas, nombres, estado, tienda predeterminada, dominios y URI física | Cada contexto de tienda frontal está registrado una sola vez. |
| Ajustes de datos compartidos | Compartición de Customers, Orders y cantidades, además de reglas a nivel de grupo | Las identidades compartidas se distinguen de los registros duplicados. |
| Asignaciones de Products/tiendas | Disponibilidad de Products y Categories, estado específico por tienda, precio, texto e imágenes | La presencia del Product no se infiere únicamente desde la tienda predeterminada. |
| Idiomas y monedas | Asignaciones por tienda, traducciones, idioma predeterminado, moneda, contexto de cambio y fallbacks | Los registros localizados permanecen ligados a la tienda prevista. |
| Contexto de URL | Dominio, subdominio o ruta, dominio SSL, URI física, URI virtual y URL principal | Cada tienda pública tiene una identidad de ruta completa. |
Registre qué tiendas deben mantenerse separadas, cuáles se consolidarán y qué identificadores históricos de tienda deben conservarse en Customers u Orders. Esta decisión debe existir antes de normalizar Products o Customers duplicados.
Prepare Products, combinaciones, atributos y características
PrestaShop distingue Products de combinaciones. Los atributos y sus valores generan combinaciones, mientras que las características describen propiedades que no crean una variación. Los registros a nivel de combinación pueden contener referencias, referencias de proveedor, códigos de barras, impacto de precio, impacto de peso, cantidad, cantidad mínima, fechas de disponibilidad, imágenes y estado de combinación predeterminada.
| Patrón de catálogo | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Product simple | ID de Product, referencia, tipo, precio, grupo fiscal, stock, Category, fabricante, proveedor, imágenes y asignaciones por tienda | El Product puede interpretarse sin datos ocultos de combinaciones. |
| Product con combinaciones | ID de Product, IDs de combinaciones, valores de atributos, referencias, precios, pesos, stock, imágenes y combinación predeterminada | Cada combinación vendible puede rastrearse de forma independiente. |
| Característica de Product | Característica, valor, idioma, asignación a Product, uso de filtro o comparación | La información descriptiva está separada de las opciones comprables. |
| Pack o Product virtual | Relaciones de componentes/archivos, cantidades, reglas de acceso y ejemplos de Orders | El comportamiento no simple del Product tiene evidencia completa en el origen. |
| Relación con proveedor/fabricante | IDs, referencias, enlaces a Product, contexto de compra y claves externas | La propiedad de marca y aprovisionamiento permanece diferenciada. |
| Product multitienda | Asignaciones por tienda, valores específicos, Categories, precios y estado | El contexto de tienda se conserva en lugar de aplanarse. |
Incluya casos inactivos, solo online, no disponibles, descatalogados, sin stock, preventa, cantidad mínima y disponibilidad limitada por fecha. Estos estados necesitan una decisión explícita en el destino y no una normalización automática.
Prepare personalizaciones, precios específicos, stock y grupos de Customers
Los campos de personalización pueden recoger texto o archivos y permanecer asociados a un Product y posteriormente a una línea de Order. Los precios específicos pueden depender de Product, combinación, tienda, moneda, país, grupo de Customers, Customer, cantidad y rango de fechas. El stock puede pertenecer a un Product o combinación y compartirse entre tiendas.
| Estructura comercial | Evidencia | Condición de preparación |
|---|---|---|
| Campo de personalización | ID del campo, Product, tipo, estado obligatorio, etiqueta, ubicación del archivo subido y ejemplo de línea de Order | Los datos introducidos por el comprador siguen separados de atributos reutilizables del Product. |
| Precio específico | Product/combinación, tienda, moneda, país, grupo, Customer, cantidad, fecha, tipo de reducción y prioridad | Cada precio condicional conserva todo su contexto. |
| Grupo de Customers | ID del grupo, miembros, uso como grupo predeterminado, visualización de precios, reducción, acceso a Categories y asignación por tienda | El significado del grupo está documentado más allá de su nombre. |
| Stock | ID de Product/combinación, contexto de cantidad por tienda o compartida, estado reservado cuando esté disponible y autoridad externa | Se conoce la unidad vendible y el contexto de tienda de cada cantidad. |
| Regla de carrito | Código, condiciones, acciones, restricciones, fechas, uso y referencias a Orders históricos | La evidencia histórica del descuento queda separada de la configuración promocional futura. |
Los precios y descuentos de Orders históricos deben conservarse como instantáneas. No deberían reconstruirse a partir de precios específicos, grupos o reglas de carrito actuales.
Prepare Categories, CMS Pages, URL amigables y rutas de descubrimiento
Las Categories de PrestaShop pueden contener jerarquía padre-hijo, asignación por tienda, nombres y descripciones localizados, imágenes, metadatos, URL amigables, acceso por grupos y pertenencia de Products. CMS Pages y Categories pueden aportar contenido legal, de servicio y editorial. Los módulos de navegación y estructuras del tema pueden crear rutas de descubrimiento adicionales.
| Área de la tienda | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Jerarquía de Categories | IDs de Categories, padres, asignaciones por tienda, grupos de acceso, pertenencia de Products y traducciones | La taxonomía y el alcance de acceso están completos. |
| URL de Products y Categories | URL amigable, tienda, idioma, intención canónica, metadatos y prioridad | Las rutas de alto valor tienen decisiones explícitas de destino. |
| Contenido CMS | IDs de CMS Page/Category, idioma, asignación por tienda, estado, ruta y relación con menús | El contenido CMS permanece separado de la presentación del tema. |
| Navegación | Módulo de menú, enlaces, jerarquía, contexto de tienda/idioma y objeto de destino | Las rutas de Customer no se deducen únicamente de Categories. |
| Enlaces internos y redirecciones | Página de origen, objeto enlazado, ruta antigua e intención de destino | Los enlaces pueden reescribirse y las rutas prioritarias conservarse. |
Recopile URL prioritarias a partir de analítica, datos de búsqueda, backlinks, campañas, emails de Customers y navegación interna. Un sitemap por sí solo no revela todas las rutas con valor comercial.
Prepare Customers, direcciones, Orders y documentos históricos
La preparación de Customers debe incluir identidad de cuenta, grupos predeterminados y adicionales, contexto de tienda, idioma, direcciones, consentimiento, información empresarial o fiscal, IDs externos y dependencias de autenticación. La preparación de Orders debe conservar el contexto de Customer o invitado, carrito, moneda, tienda, transportista, módulo de pago, direcciones, líneas de Product y combinación, personalizaciones, totales, estados, facturas, albaranes, mensajes, reembolsos y referencias externas.
| Área de registros | Evidencia | Condición de preparación |
|---|---|---|
| Cuenta de Customer | ID de Customer, email, tienda, grupos predeterminado/adicionales, idioma, estado, direcciones, consentimiento e ID externo | Las cuentas duplicadas y compartidas se resuelven deliberadamente. |
| Autenticación | Esquema de contraseña, SSO/login social, proceso de restablecimiento y responsable de comunicación de cuenta | El acceso a cuenta está planificado sin asumir portabilidad de credenciales. |
| Líneas de Order | Referencias de Product/combinación, etiquetas históricas, personalizaciones, cantidad, precio, impuestos y descuento | Los artículos comprados siguen siendo comprensibles independientemente de los datos actuales del catálogo. |
| Totales y estado de Order | Moneda, subtotal, envío, descuentos, impuestos, total final, estado actual e historial | El significado comercial histórico puede conciliarse. |
| Documentos y registros posventa | Factura, albarán, abono, devolución, mensaje, pago, transportista y referencias de seguimiento | La evidencia para soporte y finanzas es recuperable. |
| IDs externos | Claves de ERP, marketplace, contabilidad, pago y preparación de pedidos | El linaje entre sistemas sigue siendo trazable. |
Seleccione como casos representativos Orders de invitados y registrados, múltiples grupos, multitienda, combinaciones, personalizados, con descuento, reembolsados, devueltos y parcialmente enviados.
Inventaríe módulos, overrides, temas y tablas personalizadas
Cree un registro de propiedad para módulos, overrides, temas, controladores personalizados, tablas personalizadas, cambios directos de base de datos, integraciones Webservice, feeds, marketplaces, búsqueda, fidelización, pagos, envíos, suscripciones y conexiones ERP/PIM/WMS/CRM.
| Dependencia | Evidencia que debe prepararse | Condición de preparación |
|---|---|---|
| Módulo | Nombre, versión, estado, finalidad, responsable de configuración, tablas/campos, hooks y registros afectados | Los datos gestionados por el módulo tienen destino o responsable que los conservará. |
| Override o código personalizado | Override de clase/controlador, comportamiento modificado, impacto en base de datos y desarrollador responsable | La lógica comercial está documentada independientemente de la implementación antigua. |
| Tema | Versión del tema, plantillas, posiciones de módulos, contenido incrustado, scripts personalizados y dependencias de rutas | La presentación está separada del contenido y registros portables. |
| Tabla o columna personalizada | Esquema, claves, registros principales referenciados y proceso consumidor | Los registros personalizados pueden interpretarse en lugar de copiarse sin contexto. |
| Sistema externo | Endpoint, registros autoritativos, dirección de sincronización, IDs y responsable del cambio | Se evitan sistemas de registro contradictorios. |
| Datos generados | Caché, índices, logs, sesiones, exportaciones temporales y tablas abandonadas | Los datos no autoritativos se excluyen deliberadamente. |
Si la misma función existe en varias tiendas, registre si los datos del módulo subyacente se comparten, duplican o son específicos del contexto.
Seleccione muestras representativas para probar la migración
Elija registros de origen que expongan la complejidad real de la Store. Registre IDs, contexto de tienda, idioma, URL, referencias de combinación, grupos de Customers, dependencias de módulos y el motivo por el que se seleccionó cada muestra.
| Muestra | Evidencia que debe prepararse | Finalidad de preparación |
|---|---|---|
| Product simple | Precio, impuesto, stock, Category, fabricante/proveedor, imágenes, tienda y Order | Establece la referencia de un Product ordinario. |
| Product con muchas combinaciones | Atributos, combinaciones, referencias, stock, imágenes, impactos de precio/peso y combinación predeterminada | Representa la estructura de variación vendible. |
| Product con características/personalización | Características, campos/archivos de entrada del Customer y líneas de Order correspondientes | Separa datos descriptivos de valores introducidos por el comprador. |
| Caso multitienda | Product, Category, Customer o precio con contexto de todas las tiendas/grupo/tienda | Representa propiedad compartida y específica de tienda. |
| Caso de grupo de Customers | Customer, grupos, precio específico, acceso a Category y Order relevante | Representa comercio segmentado. |
| Order complejo | Combinación, personalización, descuento, impuesto, transportista, pago, factura, devolución e IDs externos | Representa evidencia histórica de transacción. |
| Registro gestionado por módulo | Registro principal, tablas/campos de módulo, hooks y clave externa | Expone alcance no principal antes de ejecutar. |
El paquete de muestras de PrestaShop está preparado cuando cada registro seleccionado tiene una ficha de expectativa del origen, alcance de tienda e idioma, archivos relacionados y un revisor identificado.
Complete la verificación final de preparación para PrestaShop
| Área de preparación | Condición de preparación |
|---|---|
| Acceso y recuperación | Back office, hosting, base de datos, archivos, imágenes, descargas, credenciales, copias de seguridad y responsabilidad de restauración están confirmados. |
| Multitienda | Tiendas, grupos, dominios, ajustes de datos compartidos, idiomas, monedas y valores específicos de tienda están documentados. |
| Catálogo | Products, combinaciones, atributos, características, personalizaciones, Categories, proveedores, fabricantes, stock, precios e identificadores son trazables. |
| Customers y Orders | Cuentas, grupos, direcciones, carritos, Orders, líneas, totales, estados, documentos, mensajes, devoluciones e IDs externos tienen evidencia. |
| Contenido y URL | Contenido CMS, navegación, URL amigables, metadatos, enlaces internos y decisiones de redirección están documentados. |
| Dependencias | Módulos, overrides, temas, tablas personalizadas, integraciones Webservice y sistemas externos tienen responsables identificados. |
| Muestras | Los registros representativos cubren cada patrón material de Product, tienda, Customer, Order, contenido y módulo. |
El alcance de PrestaShop está preparado cuando cada registro material puede rastrearse hasta su contexto de tienda, propietario en el origen, registros relacionados, artefacto de evidencia y destino previsto o sistema que se conservará.
Conclusión
Preparar PrestaShop requiere evidencia coordinada sobre Products, combinaciones, atributos, características, personalizaciones, alcance multitienda, grupos de Customers, Customers, Orders, contenido CMS, URL amigables, módulos, overrides y sistemas externos. La lista de comprobación debe hacer explícitas estas relaciones antes de ejecutar, en lugar de depender de exportaciones de la tienda predeterminada.
Un paquete de preparación completo conserva evidencia recuperable del origen, resuelve registros compartidos frente a específicos de tienda, separa el historial comercial de la configuración activa y asigna un responsable a cada dependencia de módulo o personalizada.
Preguntas frecuentes
¿Qué debería prepararse primero para una migración hacia PrestaShop?
Confirme el acceso al back office, hosting, base de datos, sistema de archivos, imágenes y módulos; cree copias de seguridad recuperables; y documente la versión de PrestaShop y el árbol multitienda. La preparación del catálogo no debería comenzar hasta que el origen pueda inspeccionarse y restaurarse de forma fiable.
¿Por qué deben prepararse Products y combinaciones por separado?
Un Product contiene información compartida del catálogo, mientras que las combinaciones pueden controlar referencias, códigos de barras, impactos de precio y peso, stock, imágenes, cantidades mínimas y valores de opciones. Cada combinación realmente vendible necesita trazabilidad independiente.
¿En qué se diferencian las características de PrestaShop de los atributos?
Los atributos crean combinaciones de Product que los clientes pueden seleccionar. Las características describen propiedades que permanecen estables entre combinaciones. Mezclarlos puede crear variantes falsas o eliminar información necesaria para filtrar y comparar.
¿Por qué es esencial el contexto multitienda?
Products, Categories, Customers, precios, idiomas, módulos y URL pueden compartirse o personalizarse para todas las tiendas, un grupo o una tienda concreta. Por ello, un mismo ID de origen puede tener un significado comercial distinto según el contexto.
¿Qué Orders de PrestaShop deberían elegirse como muestras representativas?
Incluya Customers invitados y registrados, combinaciones, textos o archivos de personalización, precios por grupos de Customers, descuentos, varios impuestos, facturas, devoluciones, abonos, referencias de pago y transportista e IDs de sistemas externos.
¿Qué debe incluir el registro de módulos y overrides de PrestaShop?
Registre cada módulo, override, tabla personalizada, dependencia del tema, integración Webservice y conector externo que cree o consuma datos comerciales. Cada elemento necesita un responsable, registros afectados, evidencia y una decisión sobre su destino o sistema que continuará utilizándolo.