PrestaShop 8: novedades, migración desde 1.7 y lo que cambia para desarrolladores

PrestaShop 8 marca un antes y un después

PrestaShop 8 no es simplemente una actualización incremental: representa la mayor evolución de la plataforma en años. Con Symfony 5.4 como framework base (sustituyendo al legacy controller pattern), un nuevo sistema de hooks tipados, y mejoras sustanciales en el backoffice, PS8 se posiciona como una alternativa seria para ecommerce profesional en el segmento medio. Para los desarrolladores, el cambio más significativo es la migración completa del backoffice a Symfony con Twig, abandonando definitivamente los controllers legacy basados en Smarty.

Dónde encaja PrestaShop 8 en 2026

El mapa de versiones ha cambiado y conviene tenerlo claro antes de decidir nada:

• PrestaShop 1.6 y anteriores. Sin soporte desde hace años. Cualquier tienda todavía aquí está funcionando con deuda técnica y riesgo de seguridad acumulado; el salto ya no es una actualización, es prácticamente una reimplantación.
• PrestaShop 1.7.8. Estuvo en fase de mantenimiento solo de seguridad hasta la llegada de la rama 9. Con PrestaShop 9 ya publicado, la 1.7 dejó de mantenerse: quedarse ahí significa acumular vulnerabilidades sin parche.
• PrestaShop 8.x. La rama estable y ampliamente soportada por el ecosistema de módulos y temas. Su ventana de soporte se extiende hasta la llegada de la rama 10.
• PrestaShop 9.x. La rama actual, construida sobre Symfony 6.4 LTS y con requisitos de PHP más modernos. Es el destino natural, pero el ecosistema de módulos tardó en acompañar y conviene comprobar compatibilidad módulo a módulo.

La consecuencia práctica: si vienes de 1.7, PrestaShop 8 sigue siendo casi siempre la parada intermedia razonable, porque el salto directo de 1.7 a 9 concentra demasiados cambios a la vez (arquitectura, PHP, tema, módulos) y multiplica el riesgo del proyecto. Todo lo que cuenta este artículo sobre el 8 es, por tanto, trabajo que vas a tener que hacer igualmente.

Novedades técnicas principales

La actualización a Symfony 5.4 trae consigo inyección de dependencias nativa, mejor gestión de eventos y un sistema de routing moderno. El nuevo Product Page v2 en el backoffice es el ejemplo más visible: un formulario completamente reescrito con componentes Vue.js que mejora drásticamente la experiencia de gestión de catálogo. El sistema de multitienda ha sido refactorizado para ser más intuitivo, con un selector visual que indica claramente qué tienda se está editando y qué cambios aplican globalmente.

En el frontend, PrestaShop 8 adopta un tema base más limpio y ligero. El sistema de assets ha sido modernizado con mejor soporte para ES6+ modules y una arquitectura CSS más modular. Las APIs internas han sido estandarizadas, facilitando la creación de headless storefronts o integraciones con frameworks como React o Vue.

Qué se elimina y por qué importa

Buena parte del dolor de la migración no viene de lo que se añade, sino de lo que desaparece. Los puntos que más incidencias generan en proyectos reales:

• Retirada de código obsoleto. Clases, métodos y parámetros marcados como deprecated en 1.7 se eliminan. Cualquier módulo u override que dependiera de ellos deja de funcionar, a veces de forma silenciosa.
• Requisitos de PHP más altos. El salto obliga a actualizar la versión de PHP del servidor, lo que a su vez rompe módulos antiguos que usaban sintaxis o extensiones ya retiradas. Es habitual que el cuello de botella real del proyecto sea el hosting, no PrestaShop.
• Cambios en el sistema de plantillas del backoffice. Los desarrollos a medida que pintaban pantallas de administración con Smarty tienen que rehacerse en Twig.
• Endurecimiento del tratamiento de errores. Avisos que antes pasaban desapercibidos ahora pueden convertirse en errores visibles. Es una buena noticia a medio plazo y una fuente de sustos durante el primer despliegue.

Rendimiento: expectativas realistas

Se suele citar una mejora de rendimiento notable al pasar de 1.7 a 8, y es cierta, pero conviene entender de dónde sale. Una parte procede del propio núcleo; otra parte, probablemente mayor, del salto de versión de PHP y de la limpieza de módulos abandonados que acompaña a la migración. Dicho de otro modo: si migras el core pero arrastras los mismos veinte módulos mal programados, la mejora se diluye. La migración es la mejor oportunidad que vas a tener en años para hacer limpieza de catálogo de módulos.

Migración desde PrestaShop 1.7: paso a paso

La migración de PS 1.7.8 a PS 8 no es automática y requiere planificación. El primer paso es auditar los módulos instalados: aproximadamente el 30% de módulos de PS 1.7 no son compatibles directamente con PS8 debido a los cambios en hooks y en la arquitectura del backoffice. Los módulos que usan AdminController legacy necesitan ser migrados a Symfony controllers.

El proceso recomendado es: (1) clonar el entorno de producción, (2) actualizar PHP a 8.1+, (3) ejecutar el módulo de auto-upgrade con la opción de upgrade a PS8, (4) revisar y actualizar módulos incompatibles, (5) testear extensivamente el checkout, pagos y envíos, (6) verificar el tema o migrar al nuevo tema base. La base de datos sufre migraciones automáticas, pero es recomendable hacer un backup completo antes y verificar la integridad de datos post-migración.

La auditoría previa: el paso que decide el presupuesto

Antes de tocar un servidor, el inventario. Sin esto no hay estimación posible y es donde se van la mayoría de proyectos que se desvían:

1. Listado completo de módulos con versión, autor y estado de mantenimiento. Marca los que llevan más de dos años sin actualizarse: son candidatos a sustitución, no a migración.
2. Inventario de overrides. Revisa la carpeta /override completa. Cada override es una modificación del núcleo que hay que revalidar a mano.
3. Tema: ¿hijo o modificado? Si el tema anterior se tocó directamente en lugar de trabajar con un tema hijo, la migración del frontend es un proyecto en sí mismo.
4. Integraciones externas. ERP, pasarelas de pago, transportistas, marketplaces, sincronización de stock. Cada una necesita su propio plan de pruebas y, en algunos casos, su propia ventana de coordinación con el proveedor.
5. Personalizaciones invisibles. Snippets en el theme, tareas cron, webhooks, scripts que atacan directamente la base de datos. Suelen aparecer justo después del despliegue si nadie los inventarió antes.

Checklist de pruebas antes de dar el salto

Con el entorno de pruebas montado, valida como mínimo estos flujos completos de punta a punta:

• Compra completa como invitado y como cliente registrado, con cada método de pago activo.
• Cálculo de portes por zona, peso y transportista; recogida en tienda si aplica.
• Impuestos y reglas fiscales, especialmente si vendes a varios países.
• Cupones, descuentos por volumen y precios específicos por grupo de cliente.
• Emails transaccionales: confirmación de pedido, cambios de estado, recuperación de contraseña.
• Facturas y albaranes en PDF con la plantilla real, no la de demostración.
• Devoluciones, reembolsos parciales y cancelaciones.
• Buscador y filtros de catálogo con el volumen real de productos, no con cuatro artículos de prueba.
• Sincronización con el ERP o el sistema de stock en ambos sentidos.

SEO: la parte que se olvida y más caro sale

Una migración de versión no debería alterar las URLs, pero en la práctica pasa: cambios de tema, de estructura de categorías o de configuración de amigables acaban generando 404 masivos. Antes de migrar, exporta el listado completo de URLs indexadas y compáralo tras el despliegue. Si algo cambia, monta las redirecciones 301 antes de abrir al público, no después de ver la caída en Search Console. Conserva también los metadatos, los datos estructurados de producto y el robots.txt, y regenera el sitemap al terminar.

Estrategia de despliegue

Lo que funciona en tiendas con volumen: congelar cambios de catálogo unas horas, hacer un volcado final de base de datos del entorno vivo sobre el entorno migrado, ejecutar el script de migración de datos, validar con una lista corta de comprobaciones críticas y conmutar. Ten preparado el plan de vuelta atrás antes de empezar: copia completa de ficheros y base de datos, y decidido de antemano quién y con qué criterio decide revertir. Elige una ventana de baja actividad y evita viernes por la tarde y campañas.

Errores frecuentes

• Migrar sobre producción. No hay atajo: entorno espejo o no hay migración.
• Actualizar PHP y PrestaShop a la vez sin fase intermedia. Cuando algo falla, no sabes qué lo rompió.
• Confiar en que el módulo de actualización lo resolverá todo. Resuelve el núcleo y el esquema de datos; no resuelve tus módulos, tu tema ni tus integraciones.
• No probar con datos reales. Un catálogo de 40.000 referencias se comporta distinto que uno de 40.
• Olvidar los trabajos programados. Cron de sincronización, envío de feeds, limpieza de carritos. Suelen quedarse apuntando al entorno viejo.

Si tu escenario no es una actualización sino un cambio de plataforma, el análisis es distinto y lo cubrimos en la guía de migración entre Magento, PrestaShop, WooCommerce y Shopify.

Lo que cambia para desarrolladores de módulos

Los desarrolladores de módulos deben adaptarse a varios cambios: los hooks legacy siguen funcionando pero están deprecados en favor de los nuevos hooks tipados con clases PHP dedicadas. El sistema de overrides sigue existiendo pero Symfony services son la forma recomendada de extender funcionalidad. Los formularios del backoffice deben usar FormTypes de Symfony en lugar del sistema HelperForm legacy. El testing también mejora: PrestaShop 8 incluye un framework de testing integrado basado en PHPUnit y Behat que facilita crear tests para módulos.

Overrides: por qué conviene abandonarlos

El sistema de overrides fue durante años la forma habitual de modificar comportamiento del núcleo, y es también la causa número uno de migraciones dolorosas. Un override se rompe cada vez que cambia el método sobreescrito, dos módulos que sobreescriben la misma clase entran en conflicto, y el resultado es invisible hasta que algo falla en producción. La alternativa moderna —decorar servicios, escuchar eventos, usar los hooks tipados— cuesta algo más de trabajo la primera vez y elimina esa clase entera de problemas. Si estás migrando de todas formas, es el momento de pagar esa deuda: lo desarrollamos en detalle en el artículo sobre mantenimiento de módulos, overrides y hooks en PrestaShop 9.

Estructura recomendada de un módulo moderno

• Composer y autoload PSR-4. Nada de requires manuales ni clases sueltas en la raíz del módulo.
• Servicios declarados en el contenedor, con dependencias inyectadas en el constructor en lugar de llamadas estáticas al núcleo.
• Controladores de backoffice como controladores Symfony, con rutas declaradas y plantillas Twig.
• Formularios con FormTypes y validación mediante constraints, no con validación manual dispersa.
• Migraciones de esquema versionadas en la instalación y la actualización del módulo, para poder subir y bajar de versión sin sorpresas.
• Traducciones con el sistema nuevo, para que el módulo sea traducible desde el backoffice sin tocar ficheros.

Compatibilidad multiversión

Si distribuyes módulos, tendrás que dar soporte a varias ramas a la vez durante bastante tiempo. Dos enfoques válidos: mantener ramas separadas por versión mayor de PrestaShop (más limpio, más trabajo de mantenimiento) o una única base con capas de compatibilidad y comprobaciones de versión (menos duplicación, más riesgo de que el código se vuelva ilegible). Para módulos con lógica sencilla, la segunda opción suele compensar; para módulos grandes, la primera envejece mucho mejor. En ambos casos, declara el rango de versiones soportado explícitamente y falla de forma clara al instalar fuera de rango, en lugar de dejar que el comerciante descubra el problema a mitad de campaña.

Pruebas automatizadas: el retorno real

El framework de testing integrado es probablemente la mejora menos vistosa y más rentable. Con una batería mínima de pruebas funcionales sobre los flujos críticos del módulo, cada actualización de PrestaShop deja de ser una apuesta. No hace falta cobertura completa: cubrir instalación, desinstalación, configuración y el flujo principal ya elimina la mayoría de las regresiones que llegan a producción.

¿Y PrestaShop 9? Cómo encaja en el plan

PrestaShop 9 llegó en 2025 y consolidó la dirección que marcó el 8: back office sobre Symfony 6.4 LTS, requisitos de PHP modernos (grosso modo la familia 8.1 a 8.4, con 8.3 como opción sensata para producción) y una limpieza importante de código heredado. Para el comerciante, los titulares son un backoffice más coherente, mejor base para rendimiento y accesibilidad, y una plataforma que vuelve a estar alineada con las versiones soportadas de sus dependencias.

La pregunta correcta no es «8 o 9»

Es «cuántos saltos puedo permitirme y en qué orden». Tres escenarios habituales:

• Vengo de 1.7 con muchos módulos y personalización. Migra primero a 8, estabiliza, y planifica el salto a 9 como un segundo proyecto. Dos migraciones controladas cuestan menos que una migración doble que se descontrola.
• Vengo de 1.7 con una tienda sencilla y pocos módulos. Evalúa ir directamente a 9 si tus módulos críticos ya lo soportan. Te ahorras una vuelta entera.
• Ya estoy en 8.x y todo funciona. No hay urgencia inmediata: la rama 8 mantiene soporte hasta la llegada de la 10. Aprovecha para preparar el terreno —eliminar overrides, actualizar módulos, subir PHP— de modo que el salto a 9 sea trivial cuando toque.

Si además te estás replanteando la plataforma en sí, hemos comparado las opciones con criterios de negocio en la guía para elegir plataforma de ecommerce en 2026, y en el análisis de novedades y mejoras de PrestaShop 9 entramos en el detalle de la rama actual.

Seguridad y mantenimiento después de migrar

Migrar no es el final del proyecto; es el momento en que empieza a ser barato mantener la tienda. Lo que conviene dejar montado en las primeras semanas:

• Política de actualizaciones. Los parches de seguridad de la rama se aplican; las versiones menores se planifican. Definir quién revisa las notas de versión y con qué frecuencia evita que la tienda vuelva a quedarse atrás en dos años.
• Entorno de staging permanente. Si el entorno de pruebas se destruye al acabar la migración, la siguiente actualización volverá a hacerse a ciegas. Mantenerlo cuesta poco y ahorra mucho.
• Copias de seguridad verificadas. Una copia que nunca se ha restaurado no es una copia de seguridad. Prueba la restauración al menos una vez.
• Monitorización. Disponibilidad, errores de aplicación, tiempo de respuesta del checkout y tasa de pedidos por hora. Una caída de pedidos suele detectarse antes por métrica de negocio que por alerta técnica.
• Revisión de accesos. La migración es buen momento para limpiar cuentas de empleados que ya no están, tokens de API caducados y accesos de proveedores antiguos.

Si tu tienda maneja datos de clientes y pagos, merece la pena someterla a una revisión externa periódica; explicamos qué cubre y cómo se hace en el artículo sobre auditoría de seguridad y pentesting para ecommerce. Y si el objetivo tras la migración es convertir mejor, el punto con más recorrido casi siempre es el mismo: optimizar el checkout.

¿Merece la pena migrar ahora?

Si tu tienda está en PrestaShop 1.7.7 o anterior, la migración es urgente: estas versiones ya no reciben parches de seguridad. Para tiendas en 1.7.8, la decisión depende del ecosistema de módulos: si todos tus módulos críticos ya soportan PS8, migrar cuanto antes te posiciona mejor para el futuro. La inversión en migración se recupera con creces en rendimiento mejorado (hasta un 25% más rápido), mejor seguridad, y acceso al nuevo ecosistema de módulos que los desarrolladores están priorizando para PS8.

Con la foto de 2026 encima de la mesa, ese razonamiento se refuerza: la rama 1.7 ya no recibe mantenimiento, así que la pregunta ha dejado de ser si migrar y ha pasado a ser hacia dónde y en cuántas etapas. Quedarse quieto tiene un coste que no aparece en ninguna factura hasta que aparece de golpe: una vulnerabilidad sin parche, un módulo de pago que deja de estar certificado, un proveedor que retira el soporte de su integración.

Cómo justificarlo internamente

Si tienes que defender el presupuesto ante dirección, estos son los argumentos que suelen funcionar mejor que «la versión está antigua»:

• Riesgo cuantificado. Coste estimado de un día de tienda caída o de un incidente de datos frente al coste del proyecto.
• Coste de oportunidad. Funcionalidades e integraciones que hoy no puedes contratar porque tu versión no está soportada.
• Coste de mantenimiento creciente. Cada parche a medida sobre una versión sin soporte es dinero que no se recupera.
• Rendimiento y conversión. Una mejora medible de velocidad tiene efecto directo en la tasa de conversión y en el coste de la publicidad de pago.

Preguntas frecuentes

¿Puedo saltar directamente de 1.7 a PrestaShop 9?

Técnicamente puede plantearse, y en tiendas sencillas es incluso lo recomendable. En tiendas con muchos módulos, integraciones y personalización, el salto en dos etapas (1.7 → 8 → 9) es más largo pero mucho más controlable, porque permite aislar qué versión rompe qué.

¿Cuánto dura una migración?

Depende casi por completo del número de módulos y del grado de personalización, no del tamaño del catálogo. Una tienda estándar con módulos comerciales al día se resuelve en pocas semanas; una tienda con desarrollo a medida, integración con ERP y tema propio es un proyecto de varios meses con fases de auditoría, adaptación y pruebas.

¿Perderé mis datos o mi posicionamiento?

Los datos se conservan si el proceso se hace sobre copia y con verificación posterior. El posicionamiento se conserva si las URLs no cambian o si los cambios se cubren con redirecciones 301 desde el primer minuto. Los sustos de SEO tras una migración casi nunca vienen de la plataforma: vienen de no haber comparado el mapa de URLs antes y después.

¿Y si mi módulo crítico no tiene versión compatible?

Tres salidas, en orden de preferencia: buscar un sustituto mantenido, encargar la adaptación al autor original, o reimplementar la funcionalidad como desarrollo propio siguiendo la arquitectura moderna. La cuarta opción —quedarse en la versión antigua por ese módulo— es la que más cara sale a medio plazo.

Conclusión

PrestaShop 8 fue el punto de inflexión que sacó a la plataforma del modelo heredado y la puso sobre bases modernas: Symfony en el backoffice, hooks tipados, servicios en lugar de overrides y un framework de pruebas de verdad. Ese trabajo no se ha quedado obsoleto con la llegada de la rama 9; al contrario, es exactamente el mismo trabajo que hay que hacer para llegar hasta ella.

Si tu tienda sigue en 1.7, la conversación ya no es técnica sino de riesgo: estás en una versión sin mantenimiento. Y si ya estás en 8.x, tienes margen para preparar el salto con calma —limpiando overrides, actualizando módulos y subiendo PHP— en lugar de tener que improvisarlo el día que la rama 8 deje de recibir parches.

En cualquiera de los dos casos, el orden importa: auditoría primero, entorno espejo después, y producción solo cuando la lista de comprobaciones esté entera en verde.