Migración de PrestaShop 8 a 9: checklist de compatibilidad para 2026

PrestaShop 9 está en versión estable desde principios de 2026 (9.1.3 a finales de mayo, según el feed de releases de GitHub que consulta nuestro vigilante de compatibilidad). Para tiendas que llevan más de 2 años ancladas en PS 8.x, la migración por fin es manejable: la mayoría de los módulos importantes se han puesto al día, y las versiones menores 9.0 → 9.1 han pulido los peores bugs del flujo de migración.

Este es el checklist de 14 puntos que usamos cuando ayudamos a una tienda PS 8 a planificar el salto. No es exhaustivo, pero es el orden que ha funcionado, y señala lo que se le escapa al módulo oficial de actualización con 1 clic.

Antes de tocar nada

1. Inventaría todos los módulos activos

Back office → Módulos → Administrador de módulos → filtra "Instalados". Copia la lista a una hoja de cálculo con tres columnas: nombre del módulo, proveedor, ¿compatible con PS 9?. Rellena la tercera columna buscando cada módulo en PrestaShop Addons (la ficha muestra la versión máxima de PS bajo "Compatibilidad").

Cualquier módulo sin build para PS 9 es o bien a) un bloqueante duro (necesitas un reemplazo antes de migrar), o bien b) algo que puedes descartar porque en realidad no lo usas.

2. Inventaría módulos personalizados y overrides

Mira en /modules, /themes/<tu-tema>/modules, y especialmente /override. Cualquier archivo de override personalizado necesita una revisión manual frente a los cambios del core de PS 9 (la mayoría se rompen).

3. Línea base de motor de base de datos y versión de PHP

Mínimos de PS 9: PHP 8.1, MySQL 5.7 / MariaDB 10.5. Muchas tiendas PS 8 siguen en PHP 7.4: esa es una actualización a nivel de sistema operativo que haces antes de tocar PrestaShop. Hacer ambas a la vez es la causa más común de migraciones fallidas.

Comprobaciones previas (no las saltes)

4. Copia de seguridad completa

Volcado de la base de datos + /img + /modules + /themes + /override. Verifica que la copia se restaura de verdad en un servidor de staging. Las copias sin probar no son copias.

5. Clona a staging

Levanta una instancia de staging en un subdominio. Usa un volcado reciente de la base de datos. Ejecuta la migración ahí primero, nunca en producción.

6. Ejecuta el módulo oficial de actualización con 1 clic en staging

Back office → Módulos → busca "1-click upgrade" (oficialmente llamado "AutoUpgrade"). Configura: destino PS 9.1.x estable, copia de seguridad antes de actualizar = sí. Ejecuta.

Tiempo de ejecución esperado: 10–45 minutos según el tamaño de la base de datos. El módulo listará al final todo lo que necesita intervención manual: léelo con atención.

Los puntos que se le escapan al módulo AutoUpgrade

7. Compatibilidad del tema

AutoUpgrade no toca tu tema. Si usas un tema personalizado o de terceros, probablemente tenga problemas de sintaxis de Smarty 4 (PS 9 incluye Smarty 4.x; PS 8 iba con Smarty 3.x). Audita los archivos .tpl de tu tema en busca de etiquetas obsoletas.

8. Archivos de override, línea por línea

Cada archivo bajo /override necesita una revisión línea por línea frente al core de PS 9. La forma más rápida de descubrir qué está roto es ejecutar la tienda de staging restaurando cada archivo de override de uno en uno y observar el log de errores.

9. Hooks personalizados

Varios hooks se renombraron o eliminaron en PS 9. La chuleta:

• actionProductAdd aún funciona, pero actionObjectProductAddBefore es el recomendado.
• El comportamiento de displayHeader cambió: el contenido a veces se renderiza antes que antes.
• actionDispatcher obsoleto → usa actionDispatcherBefore.

10. Cotejamiento de la base de datos

PS 9 prefiere utf8mb4_unicode_ci en todo. Muchas tiendas PS 8 tienen una mezcla de utf8 y utf8mb4 acumulada con los años. Ejecuta el SQL de corrección de cotejamiento después de la actualización: hay un script de la comunidad de PrestaShop para esto. No lo ejecutes antes.

Verificación posterior a la actualización

11. Smoke test de la tienda

Recorre: página de inicio → categoría → ficha de producto → añadir al carrito → compra como invitado → compra como cliente registrado. Pasa por cada plantilla del tema.

12. Smoke test del back office

Recorre: catálogo, pedidos, clientes, módulos, estadísticas, SEO. Comprueba especialmente el propio "administrador de módulos": es la superficie del BO más modificada en PS 9.

13. Verificación del módulo de búsqueda

Los módulos de búsqueda son la rotura más común en las migraciones de PS 8 → 9. El plugin necesita un build específico para PS 9 que enganche la nueva firma del controlador de búsqueda. Verifica:

• El overlay de búsqueda de la tienda sigue renderizándose
• El autocompletado devuelve resultados
• Las reglas de searchandising siguen aplicándose
• El indexador puede reindexar sin errores

Para NP Search: nuestro build para PS 9 está publicado y nuestro vigilante de compatibilidad prueba cada nueva versión 9.x en las 24h siguientes al tag upstream. Si eres cliente, ya has recibido el build para PS 9 mediante el actualizador dentro del módulo.

14. Reactiva las suscripciones del vigilante de compatibilidad

La mayoría de los módulos incluyen un cron de "buscar actualizaciones". Tras la actualización, confirma que siguen apuntando a las URLs de proveedor correctas (PS 9 a veces reinicia las tareas cron).

Plan de cutover para producción

Cuando staging tenga buen aspecto durante 3–5 días de tráfico sintético + real (pon al personal a usarlo, haz pedidos de prueba reales), planifica el cutover de producción para una ventana de poco tráfico:

1. Modo mantenimiento en producción. Back office → Preferencias → Mantenimiento.
2. Volcado final de la base de datos.
3. Ejecuta el módulo AutoUpgrade en producción (ahora que staging te ha dado los tiempos + la lista de avisos).
4. Reaplica las correcciones de tema + override de la prueba en staging.
5. Modo mantenimiento desactivado. Vigila los logs de errores durante 60 minutos.
6. Ejecuta la reindexación de búsqueda y la regeneración del sitemap.
7. Envía el sitemap actualizado a Search Console.

Tiempo de inactividad total realista: 15–45 minutos para una tienda pequeña o mediana, asumiendo que no haya incendios.

Qué hacer si sale mal

Restaura el volcado de la base de datos. Restaura /modules + el tema. Vuelve a staging, identifica qué difería entre staging y producción, corrígelo y reinténtalo. No intentes depurar un cutover de producción roto: haz primero el rollback.

En resumen

PS 8 → 9 en 2026 es manejable si haces los deberes de inventario + staging. El módulo de actualización en sí es fiable; lo que se rompe es la larga cola de código personalizado que nadie documentó.

Por nuestra parte: cada plugin que vendemos en neuroplugin.com tiene builds tanto para PS 8 como para PS 9, reprobados automáticamente frente a cada nueva versión upstream mediante nuestro vigilante de compatibilidad. La razón de ser de ese vigilante es precisamente que los clientes no tengan que seguir este checklist para los módulos que nos compraron.