Datos de producto estructurados significa que cada dato del producto vive en un atributo tipado, con…
De PrestaShop 8 a 9 sin replatforming: desacopla primero el frontend
Puedes quitar la mayor parte del riesgo de la actualización de PrestaShop 8 a 9 si separas la storefront del tema de PrestaShop antes de tocar el core. Cuando el frontend se comunica con PrestaShop a través de una API en lugar de plantillas y hooks de visualización, reconstruir el tema y reparar módulos del front office dejan de formar parte de la actualización. Lo que queda es una actualización del backend que puedes probar, planificar y revertir por separado.
Qué cambia realmente entre PrestaShop 8 y 9
PrestaShop 9.0 se publicó el 10 de junio de 2025 y es una versión mayor de verdad. El core pasó de Symfony 4.4 a Symfony 6.4, la línea de soporte a largo plazo con actualizaciones de seguridad hasta noviembre de 2027. También cambian los requisitos de PHP: PrestaShop 8.0 a 8.2 funciona con PHP 7.2 a 8.1, mientras que PrestaShop 9 exige como mínimo PHP 8.1 y es compatible con PHP 8.4. PrestaShop 9.1 amplía la compatibilidad hasta PHP 8.5.
Las notas para desarrolladores son largas: los controladores del back office deben definirse como servicios, y bibliotecas incluidas como Guzzle y Swift Mailer se sustituyeron por componentes de Symfony. La propia PrestaShop advierte que algunos módulos y temas pueden necesitar actualizaciones para funcionar correctamente.
La storefront también cambia. Con PrestaShop 9.1, publicado el 23 de marzo de 2026, Hummingbird 2.0 pasó a ser el tema por defecto del front office. Está basado en Bootstrap 5, y la documentación para desarrolladores marca Classic como obsoleto para nuevos desarrollos. Las tiendas existentes pueden seguir usando Classic por ahora.
Mientras tanto, PrestaShop 8.2 está en soporte extendido desde julio de 2025. Solo recibe correcciones críticas y de seguridad, y el mantenimiento termina con el lanzamiento de PrestaShop 10.0.0. La actualización no es una emergencia, pero debe estar en tu roadmap.
Por qué la storefront concentra la mayor parte del riesgo
En una instalación clásica de PrestaShop, años de personalización viven en el front office: un tema comprado o muy modificado, más módulos que inyectan markup mediante hooks de visualización, como sliders, reseñas, insignias y bloques de venta cruzada.
En la actualización, eso crea una cadena de dependencias:
- El tema tiene que revisarse, parchearse o reconstruirse para PrestaShop 9, y avanzar hacia Hummingbird implica una migración de Bootstrap 4 a 5.
- Cada módulo que se muestra en el front office necesita una versión compatible con PrestaShop 9, y sus plantillas tienen que encajar con el tema.
- Los overrides y los cambios del tema hijo deben volver a aplicarse y probarse.
- El marcado SEO, el tracking y las Core Web Vitals deben validarse de nuevo tras el cambio.
Nada de esto vende un solo producto más. Y como tema y backend están acoplados, el nuevo core y la storefront adaptada tienen que salir en producción a la vez.
Tres opciones que valoran los comercios con PrestaShop
La mayoría de los equipos que afrontan la actualización acaban comparando tres caminos:
- Actualizar lo existente. Core, tema y módulos se actualizan juntos, con el mayor esfuerzo de coordinación concentrado en una sola ventana de lanzamiento.
- Hacer replatforming. Pasar a otro sistema de comercio. Tiene sentido si PrestaShop ya no encaja con tu modelo de negocio, pero sustituye catálogo, flujos de pedido e integraciones de una sola vez.
- Desacoplar primero. PrestaShop sigue siendo el backend de comercio, la storefront pasa a un frontend desacoplado y después se actualiza el core por detrás.
Si lo que de verdad te frena es la storefront y no el backend, la opción tres es un proyecto mucho más pequeño. Explicamos la mecánica en renovar el frontend de PrestaShop sin tocar el backend.
Cómo cambia la actualización con un frontend desacoplado
Con un frontend headless componible, la storefront ya no renderiza plantillas de PrestaShop. Lee productos, precios, carrito y datos de clientes mediante API y los muestra en su propia capa de componentes. PrestaShop sigue siendo el sistema de referencia para catálogo y pedidos.
Para la actualización de 8 a 9, eso cambia el alcance:
- El riesgo del tema sale del recorrido del cliente. Ya no hay un tema Classic o Hummingbird que reconstruir delante de tus clientes, y las versiones de Bootstrap del tema del front office dejan de afectar a lo que ven.
- El riesgo de los módulos de visualización se reduce. Bloques de contenido, sliders e insignias que antes venían de módulos del front office pasan a ser componentes del frontend. Los mantienes una sola vez, con independencia de la versión del core.
- La actualización se puede probar. Tu frontend depende de un contrato de API. Actualizas PrestaShop en staging, lanzas las mismas llamadas de API contra la versión 8 y la versión 9 y comparas los resultados antes de cambiar.
- Marketing sigue publicando. Las campañas se crean en la capa de frontend, por ejemplo en el editor visual de Laioutr Studio, así que congelar el backend no congela la storefront.
Hay límites. Los módulos con lógica de negocio, como pagos, envíos, impuestos o conectores ERP, siguen ejecutándose dentro de PrestaShop y siguen necesitando versiones compatibles con PrestaShop 9. PrestaShop 9 también introduce una nueva Admin API basada en API Platform, que el proyecto describe como un trabajo en curso y que en el futuro debería sustituir a los Web Services actuales. Comprueba qué API usa tu frontend e inclúyela en las pruebas de la actualización.
Laioutr está construido para esta capa. Como Frontend Management Platform, Laioutr se sitúa sobre los sistemas de comercio existentes, trabaja con más de 50 backends y trata el rendimiento como una propiedad de la plataforma: las storefronts de Laioutr en producción alcanzan un LCP mediano de 1,2 s, con objetivos de INP por debajo de 80 ms y CLS por debajo de 0,02. Cómo se aplica a PrestaShop lo verás en la página frontend headless para PrestaShop. Si a tu tienda le encaja un conector ya preparado o una configuración específica del proyecto mediante Orchestr, lo aclaramos en la demo.
Un plan de secuencia para la actualización
El desacoplamiento funciona mejor como secuencia que como un único gran cambio. En un negocio estacional, el orden decide además cuánto riesgo llevas a la temporada alta, algo que tratamos en big bang o migración de frontend progresiva.
- Audita tus módulos. Separa los módulos de visualización del front office, que pasan al frontend, de los módulos con lógica de negocio, que se quedan en PrestaShop y necesitan una revisión para la versión 9.
- Planifica el frontend desacoplado sobre PrestaShop 8.2. Construye y prueba la nueva storefront con tu backend actual, que sigue recibiendo correcciones de seguridad. Usa las Core Web Vitals del tema antiguo como referencia.
- Congela el contrato de API. Documenta los endpoints y datos de los que depende tu frontend y conviértelos en comprobaciones automáticas.
- Prepara la plataforma. PHP 8.1 es compatible tanto con PrestaShop 8.2 como con PrestaShop 9, así que puedes pasar el servidor a PHP 8.1 antes de actualizar el core y aislar ese cambio.
- Actualiza el backend en staging y sal en producción fuera de temporada. Pasa a PrestaShop 9 con el Update Assistant, actualiza los módulos de negocio restantes y ejecuta las comprobaciones de API. Tus clientes ven la misma storefront y, si algo falla, reviertes el backend sin tocar el frontend.
Un lanzamiento arriesgado se convierte en varios más pequeños, cada uno con su punto de retorno.
FAQ
¿Tengo que actualizar a PrestaShop 9 ya?
No. PrestaShop 8.2 recibe correcciones críticas y de seguridad hasta que se publique PrestaShop 10.0.0. Aprovecha ese margen para desacoplar primero el frontend.
¿Un frontend desacoplado elimina todo el riesgo de los módulos?
No. Elimina el riesgo ligado al tema del front office y a los módulos que se muestran en él. Los módulos de pagos, envíos, impuestos y ERP siguen ejecutándose en PrestaShop y necesitan versiones compatibles con PrestaShop 9.
¿Qué pasa con el SEO cuando cambia la storefront?
URL, redirecciones, datos estructurados y metadatos necesitan un plan de migración, como en cualquier cambio de tema. La diferencia: lo haces una vez, en el frontend, y no de nuevo con cada actualización del tema.
¿Solo tiene sentido para tiendas grandes?
No. Aporta más a las tiendas con un tema personalizado y muchos módulos en el front office, sea cual sea su tamaño.
Próximos pasos
Si PrestaShop 9 está en tu roadmap, empieza por la storefront: mapea tus módulos, define el contrato de API y planifica el lanzamiento del frontend antes de actualizar el core. Reserva una demo con nuestro equipo y repasaremos juntos la secuencia para tu configuración.