Migración de PrestaShop 8 a 9: módulos, tema, checkout y rollback

La respuesta corta

Una migración de PrestaShop 8 → 9 solo está lista cuando la versión destino exacta, el hosting, los módulos, el tema, el checkout, los impuestos, los transportistas, el correo y el rollback han pasado en un clon parecido a producción. Una etiqueta de compatibilidad o una actualización correcta del core no validan toda la tienda.

Usa esta página como hoja de decisión. Registra una fuente y un resultado de staging para cada dependencia, detente ante compatibilidad desconocida y ensaya el rollback antes de fijar una ventana de producción.

Límite de fuentes actuales — revisado el 30 de julio de 2026

• PrestaShop 9 se publicó de forma general el 10 de junio de 2025. La nota oficial de lanzamiento lo define como una versión mayor y avisa de que módulos y temas pueden necesitar cambios.
• La lista oficial de versiones en GitHub marcaba 9.1.3 como la más reciente cuando revisamos esta guía. Compruébala otra vez el día que congeles el destino.
• Los requisitos actuales de PrestaShop 9 indican MySQL 5.7 o MariaDB 10.2 como mínimos. PrestaShop 9.0 admite PHP 8.1–8.4 y PrestaShop 9.1 admite PHP 8.1–8.5. La versión PHP recomendada cambia según la versión menor.
• El actualizador oficial se llama ahora Update Assistant. Comprueba requisitos y módulos y permite crear copias, actualizar y restaurar. Reduce riesgo, pero no certifica código de terceros ni un storefront personalizado.

Este checklist no demuestra que PrestaShop 9.1.x, un tema o un módulo concreto sean compatibles con tu tienda. La versión destino y cada dependencia necesitan evidencia propia.

Empieza con una sola hoja de evidencia

Copia esta tabla al ticket de migración. “El proveedor dice que es compatible” aporta contexto, no un resultado de staging. Una fila sin responsable o rollback no está lista para producción.

Las 14 puertas de la migración

1. Congela un destino exacto

Escribe la versión completa y no la cambies silenciosamente durante staging. Lee las notas 9.0 o 9.1 y sus requisitos. Un resultado en 9.0.3 no demuestra 9.1.3.

2. Inventaría todas las dependencias instaladas y personalizadas

Exporta los módulos activos y añade los desactivados que aún tengan datos, código propio, módulos de tema, overrides, cron, webhooks y servicios externos. Registra versión exacta y fuente de cada afirmación de compatibilidad. “Desconocido” impide avanzar hasta probarlo o elegir sustituto.

3. Comprueba el hosting por separado

Ejecuta el control de requisitos de Update Assistant contra el destino. Registra PHP, motor de base de datos, memoria, extensiones, servidor web y disco. Siempre que sea posible, cambia una capa cada vez para no confundir un fallo del core con una migración simultánea de sistema o base de datos.

4. Demuestra que la copia restaura

Copia base de datos, aplicación, imágenes, módulos, tema, overrides y configuración por la vía aprobada. Restaura todo en un clon aislado y registra duración y controles. Un archivo descargable que nunca se ha restaurado todavía no es un rollback.

5. Construye un staging parecido a producción

Iguala PHP, base de datos, servidor, caché, idioma, moneda e integraciones relevantes. Desactiva el correo real y los cobros live; usa modos de prueba admitidos por cada proveedor. Enmascara datos de clientes según tu política. Busca comportamiento representativo sin contactar clientes ni crear cargos reales.

6. Ejecuta los controles de Update Assistant antes de actualizar

Usa la interfaz web o la CLI documentada de Update Assistant para comprobar versión, requisitos y módulos. Guarda los logs. Un módulo incierto sigue siendo una decisión manual: no conviertas “desconocido” en “compatible”.

7. Actualiza el clon y reconcilia cada módulo

Tras actualizar el core, compara los módulos instalados con el inventario. Confirma cuáles cambiaron, quedaron desactivados, se eliminaron o siguen inciertos. Para cada módulo comercial o propio, prueba su instalación/upgrade y el proceso de negocio que controla, no solo su pantalla de configuración.

8. Prueba el tema exacto, no un “tema para PrestaShop 9” genérico

PrestaShop 9.1+ usa Hummingbird como tema predeterminado, con Bootstrap 5.3 y código sin jQuery. Una tienda puede conservar Classic, un fork o un tema de terceros. Prueba el paquete, tema hijo, plantillas, JavaScript, hooks y posiciones de módulos exactos en escritorio y móvil.

9. Revisa los cambios oficiales que realmente usa tu código

No dependas de una chuleta genérica de hooks. Compara módulos propios y overrides con los cambios oficiales de 9.0 y, cuando corresponda, los cambios de 9.1. PrestaShop 9 mueve más back office a Symfony/Twig, refuerza tipos y elimina o cambia hooks, servicios y comportamientos concretos. Registra solo lo que tu código use.

10. Prueba el checkout como una matriz

Prueba invitado y cliente registrado, cada pago, transportista, promoción, cupón, dirección y escenario fiscal relevante. Incluye fallo y retorno. Compara totales, impuestos, estados y correo de confirmación con producción. La política legal y fiscal sigue siendo responsabilidad del comercio.

11. Verifica catálogo y búsqueda

Reconstruye índices y prueba nombres, referencias, combinaciones, errores, facetas, resultados vacíos y añadir al carrito desde búsqueda. Comprueba URLs de categorías, productos e imágenes antes y después. La búsqueda es una línea de trabajo, no una afirmación universal sobre lo que más falla.

12. Verifica correo, cron, webhooks y entrega

Ejecuta eventos controlados para correo de pedido, reembolso, stock, trabajos programados, licencias o descargas y webhooks. Comprueba reintentos e idempotencia cuando existan. Mantén destinatarios reales y credenciales live fuera de la prueba.

13. Compara logs y rendimiento antes de aprobar

Registra errores del navegador, avisos de aplicación, trabajos fallidos y tiempos representativos antes y después. Una home visualmente correcta no elimina fallos de fondo. Define tolerancia y responsable para cada aviso aceptado.

14. Ensaya el rollback y firma la decisión final

Activa el rollback en el clon, restaura el estado conocido y repite un smoke test. Registra quién puede detener el cutover, qué señales obligan a volver atrás y el punto máximo de recuperación. No programes producción con una fila crítica desconocida.

Matriz mínima de aceptación

Cutover de producción sin inventar tiempos

1. Congela core, tema y módulos exactos que pasaron staging.
2. Elige la ventana con la duración medida de actualización y restauración.
3. Pausa las escrituras según el procedimiento documentado de la tienda.
4. Crea la copia final y confirma que el responsable puede acceder a ella.
5. Repite la misma vía de Update Assistant y secuencia de paquetes de staging.
6. Ejecuta la matriz mínima antes de reabrir el tráfico normal.
7. Haz rollback al aparecer una condición de parada predefinida.
8. Tras reabrir, vigila logs, trabajos, checkout y entrega el periodo acordado.

No publiques una promesa genérica de inactividad. La ventana creíble sale del clon, el tamaño de base de datos, los ficheros, la vía del operador y la restauración probada.

NP Search: evidencia exacta, no una promesa para PrestaShop 9.1

Si la búsqueda aparece en tu inventario, el registro actual de NP Search 2.14.2 y la página de compatibilidad documentan conjuntamente actualización, esquema, reconstrucción y storefront de escritorio/móvil en PrestaShop 8.2.5 / PHP 8.1 y PrestaShop 9.0.3 / PHP 8.2. El registro de compatibilidad separa esa versión exacta de la evidencia anterior conservada.

Esos resultados no certifican PrestaShop 9.1.3, todos los temas, todos los checkout ni tu catálogo. Usa el ZIP exacto en un clon y guarda el resultado en la hoja. Ningún vigilante automático, etiqueta o ficha sustituye la prueba específica del comercio.

Decisión

Da luz verde solo cuando cada fila crítica tenga responsable, fuente, resultado de staging y rollback probado. Si no, mantén la versión actual compatible, cierra la evidencia que falta y repite el clon. Retrasar una migración cuesta menos que renombrar “compatible” a lo que sigue siendo desconocido.