PrestaShop 8 en soporte extendido: ¿toca migrar a la 9?

Qué significa «soporte extendido» en la práctica

Desde julio de 2025, PrestaShop 8 está en soporte extendido. No es el fin del soporte, pero tampoco es ya un mantenimiento completo: la rama 8.x solo recibe correcciones de errores críticos, parches de seguridad y los cambios de hooks imprescindibles. Las novedades van exclusivamente a la versión 9. El fin real del soporte llegará con la salida de PrestaShop 10.

Dicho de otro modo: la pregunta «PrestaShop 8 llega al fin de soporte, ¿hay que migrar?» no se plantea en términos de avería inminente. Se plantea en términos de deuda técnica que se acumula.

Los tres hechos técnicos que de verdad pesan

PHP. PrestaShop 8 se queda en PHP 8.1, cuyo soporte de seguridad oficial ya ha terminado. PrestaShop 9 admite de PHP 8.1 a 8.4. Tarde o temprano su proveedor de alojamiento retirará PHP 8.1 de su parque y usted dejará de tener elección.

Symfony. PrestaShop 8 se apoya en Symfony 4.4, en fin de vida y sin backports de seguridad. PrestaShop 9 ha pasado a Symfony 6.4 LTS, con correcciones hasta finales de 2026 y parches de seguridad hasta finales de 2027. El equipo de PrestaShop ha dicho de forma explícita que no habrá ningún backport para la rama 8.x.

Node.js. La compilación de los temas en la versión 9 exige Node 20 o superior. Este detalle pilla desprevenidas a las agencias que siguen trabajando con un entorno de build antiguo.

Qué se rompe de verdad al pasar a la 9

Migrar de la 8 a la 9 no es una simple subida de versión. Estas son las rupturas que generan carga de trabajo:

• Bibliotecas retiradas del núcleo: Swift Mailer sustituido por Symfony Mailer, Guzzle por Symfony HTTP Client, League Tactician por Symfony Messenger. Cualquier módulo que declare use GuzzleHttp\... produce un error fatal.
• Controladores de administración: FrameworkBundleAdminController queda obsoleto en favor de PrestaShopAdminController. Los controladores deben declararse como servicios con inyección de dependencias.
• Bundles eliminados: sensio/framework-extra-bundle desaparece, así que las anotaciones de ruta y de plantilla dejan de funcionar.
• Autenticación del back-office trasladada por completo a Symfony: los módulos SSO o de doble autenticación caseros que se apoyaban en la cookie histórica dejan de funcionar.
• Tema: Hummingbird pasa a ser el tema por defecto. Abandona Bootstrap y rompe las sobrecargas escritas para Classic. Classic se sigue entregando, lo que permite ganar tiempo.

La tabla de decisión

Quédese en la 8 por ahora si su tienda es estable, su proveedor mantiene PHP 8.1, depende de módulos de terceros cuyo editor no ha publicado una versión compatible con la 9 y está en plena temporada alta. En ese caso, aplique con rigor cada parche de seguridad 8.2.x.

Planifique la migración a 6 o 12 meses vista si su tienda es un activo principal, desarrolla funcionalidades con regularidad o su tema está muy sobrecargado. Cuanto más espere, mayor será la distancia entre su código y el núcleo.

Plantéese rehacer la tienda en lugar de migrarla si su tema es anterior a 2020, acumula más de diez overrides o más de la mitad de sus módulos de terceros ya no tienen mantenimiento. En ese escenario, migrar suele salir más caro que reconstruir con limpieza, y con peor resultado.

Cómo presupuestar con honestidad

La auditoría previa es la etapa más rentable de todo el proyecto. Consiste en responder a cuatro preguntas:

1. ¿Cuántos módulos de terceros hay y cuántos tienen ya una versión compatible con la 9?
2. ¿Cuántos overrides hay en override/ y siguen siendo útiles?
3. ¿Cuántas plantillas sobrescritas tiene el tema y qué distancia hay respecto al tema padre?
4. ¿Qué volumen de código a medida se ha desarrollado?

Una auditoría seria lleva uno o dos días y convierte un presupuesto aproximado en un plan de carga fiable. También sirve para descubrir que algunos overrides responden a una necesidad abandonada hace tiempo y que la migración será más ligera de lo previsto.

No migre nunca sin plan de vuelta atrás

Tres precauciones innegociables:

• un entorno de preproducción idéntico al de producción, en el que se ejecuta la migración completa antes de tocar nada en real;
• un plan de pruebas escrito que cubra el proceso de compra, los pagos, los transportistas, los correos transaccionales y las exportaciones contables;
• una ventana de cambio con copia de seguridad restaurable y un criterio de fracaso decidido de antemano.

Si su actualización ya está lanzada y bloqueada, nuestro artículo sobre el Update Assistant repasa los errores más frecuentes. Y si parte de una versión anterior, el camino es otro: consulte la migración desde PrestaShop 1.6.

Audite su tienda

Realizamos la auditoría de compatibilidad, presupuestamos la migración y la ejecutamos con un plan de vuelta atrás. Conozca nuestro enfoque en la página de migración de PrestaShop.