PrestaShop 1.6 en 2026: ¿mantener, actualizar o rehacer?

Tu tienda funciona con PrestaShop 1.6, vende, y todo el mundo te dice que ha llegado el momento de rehacerla. Probablemente has recibido un presupuesto, quizá varios, y ninguna forma de juzgar si la cifra es justa o si te están vendiendo una preocupación. Este artículo no va a decidir por ti: reúne lo verificable (fechas oficiales, alertas de seguridad publicadas, versiones de PHP soportadas) y separa las decisiones que descansan sobre hechos de las que descansan sobre tu situación.

La parte de buscadores se trata aparte en nuestra guía práctica de SEO para PrestaShop. Este texto va de riesgo, mantenimiento y dinero.

«Ya no se mantiene»: qué significa, al día

PrestaShop anunció el fin del mantenimiento de la 1.6 el 30 de junio de 2019. El anuncio es explícito sobre lo que se detuvo: ese trabajo de mantenimiento «consistía principalmente en corregir errores críticos o vulnerabilidades de seguridad». Desde esa fecha, el núcleo de tu tienda no ha recibido ninguna corrección, seguridad incluida. Estamos en 2026: son más de siete años.

Hay una segunda capa, más a menudo olvidada, y es la que te va a alcanzar primero: PHP. La línea 1.6 es contemporánea de PHP 5 y del comienzo mismo de PHP 7. La documentación para desarrolladores de PrestaShop solo empieza en la 1.7, cuyo suelo es PHP 7.1.3. Y todo PHP 7 está fuera de soporte: php.net solo lista hoy la rama 8.2 y posteriores como receptoras de correcciones de seguridad.

El punto que conviene retener no depende del detalle de versiones: ninguna de las ramas de PHP con las que puede funcionar una 1.6 sigue recibiendo correcciones. Una tienda 1.6 apila, por tanto, dos programas sin mantenimiento, y el segundo no depende de ti: el día en que tu alojamiento retire PHP 7, la decisión se toma sin contar contigo.

Una precisión, porque marca el tono de todo lo que sigue: «ya no se mantiene» no significa «está roto». Una 1.6 bien cuidada recibe pedidos todos los días. Funciona. La pregunta es el riesgo que estás asumiendo y el coste que estás aceptando.

El riesgo real no está donde crees: está en tus módulos

La propia PrestaShop lo documenta.

Julio de 2022. PrestaShop publicó una alerta sobre una oleada de ataques en curso: una inyección SQL encadenada con la caché de Smarty almacenada en base de datos, que lleva a la ejecución de código y al robo de datos de pago. Las tiendas afectadas eran las de la 1.6.0.10 en adelante en cuanto quedaran expuestas a una inyección SQL. La frase que conviene retener de esa alerta: los atacantes apuntan a «tiendas que usan software o módulos desactualizados, módulos de terceros vulnerables, o una vulnerabilidad aún por descubrir». La corrección salió como versión 1.7.8.7, es decir, en una rama mantenida. Para la 1.6 no hubo ninguna.

Enero de 2025. Otra alerta oficial, misma familia de ataque: una inyección en el valor de configuración PS_SHOP_NAME sirve JavaScript a los clientes de la tienda para capturar sus datos. Esta vez la alerta es categórica sobre el origen: «esta vulnerabilidad no está en el núcleo de PrestaShop sino en módulos de terceros», fallos «muchos de los cuales se corrigieron hace mucho tiempo pero siguen sin parchear en algunas tiendas».

Junta las dos y obtienes un mapa de riesgo que no es el que la gente imagina:

• la vía de entrada es casi siempre un módulo, no el núcleo;
• lo que te protege es haber aplicado las correcciones de esos módulos;
• en la 1.6, las actualizaciones de módulos son precisamente lo que ya no recibes.

Así que el problema no es «mi núcleo es viejo, luego estoy en peligro». Es: «mis módulos ya no se mantienen, y es por ahí por donde se entra». La distinción importa, porque te dice qué inventario hay que hacer.

Qué se puede actualizar en una 1.6 y qué no

Para el núcleo existen parches comunitarios para vulnerabilidades concretas de la 1.6, incluida la cadena de 2022. Son de verdad útiles, y conviene saber qué asumes al instalar uno: un parche de terceros sobre software sin mantenimiento significa que tú te haces cargo de su corrección, de su seguimiento y de su compatibilidad con todo lo demás. Es una forma defendible de ganar tiempo, no una estrategia a largo plazo.

Recomprar módulos: la única pregunta que importa, proveedor a proveedor

Es la partida que inclina la mayoría de los presupuestos, y la que está rodeada de más suposiciones. La respuesta honesta es que no hay regla general: depende del módulo. Un módulo vendido como compatible tanto con tu rama actual como con la de destino no hay que recomprarlo. Un módulo que solo existe para la 1.6 significa comprar su equivalente en la versión de destino, cuando tal equivalente existe.

De ahí un método en lugar de una estimación. Para cada módulo instalado, cuatro preguntas, en este orden:

1. ¿Lo sigo necesitando? El primer ahorro de una migración es la lista de módulos que no reinstalas. Muchas tiendas arrastran módulos instalados una vez y nunca retirados.
2. ¿Se sigue vendiendo? Un módulo desaparecido del catálogo de su proveedor no es un problema de presupuesto sino funcional: necesitas un sustituto, o renuncias a la función.
3. ¿Existe para la versión de destino, del mismo proveedor? Si es así, pregúntale por escrito si tu licencia cubre esa versión. Esa pregunta es para el proveedor, no para un hilo de foro.
4. ¿Cuánto cuesta, y por qué? Precio de compra, más tiempo de reconfiguración, normalmente la partida oculta.

Nada de esto es glamuroso, y es exactamente lo que te permite juzgar un presupuesto. Sin ello comparas cifras; con ello comparas alcances.

Rehacer: ponle precio, no lo adivines

El orden de magnitud primero: una reforma completa (tema rehecho, módulos recomprados y reconfigurados, datos migrados, redirecciones aseguradas, pruebas de aceptación) se cuenta en miles de euros. Es normal: son varias semanas de trabajo cualificado, y un proveedor que lo cotiza así está haciendo bien su trabajo.

De ahí se siguen dos cosas, y ninguna es «aplaza la decisión». Primera: muchas tiendas no necesitan todo eso, y el inventario es lo que te lo dice, por muchísimo menos de lo que cuesta la reforma que a veces evita. Segunda: una cifra no significa nada sin su alcance. De ahí nuestra postura: miramos tu tienda y te la cotizamos gratis, antes de que tengas que decidir nada.

Lo que un artículo sí puede decir con utilidad es de qué está hecha la factura:

• el tema, que hay que rehacer en lugar de portar;
• los módulos, según el inventario anterior;
• los datos: catálogo, clientes, pedidos, historial incluido;
• la visibilidad en buscadores: plan de redirecciones, URLs y etiquetas, la partida que más cuesta cuando se hace con prisas;
• las pruebas de aceptación y la formación, sistemáticamente infravaloradas.

Dos datos útiles para leer un presupuesto. Primero, pasar de la 1.6 a una versión moderna es una migración, no una actualización, y de ahí viene la cuestión de recomprar módulos. Segundo, el destino fija su propio suelo, y la documentación oficial lo indica versión a versión: PrestaShop 8 exige PHP 7.2.5 como mínimo, PrestaShop 9 abandona la compatibilidad por debajo de PHP 8.1, y la 9.1 añade PHP 8.5, ahora la versión recomendada. Para muchas tiendas 1.6 eso significa cambiar de alojamiento al mismo tiempo: mejor previsto de antemano que descubierto a mitad de camino.

Y un punto que nos importa: un presupuesto alto de reforma no es un presupuesto deshonesto. Al comerciante no le falta un precio más bajo, le falta el inventario que le permita entender qué está comprando.

Tres decisiones defendibles

No hay una única respuesta correcta. Hay tres, y cuál encaja depende de tu situación.

Mantener, si aceptas condiciones explícitas: reducir el número de módulos al mínimo estricto, saber cuáles están expuestos, aplicar las medidas que las propias alertas oficiales recomiendan (un prefijo de base de datos que no sea el de fábrica, un cortafuegos de aplicaciones web, seguir los avisos de seguridad), hacer copias de seguridad de verdad, es decir, haber restaurado una al menos una vez, y aceptar que el plazo de PHP de tu alojamiento se te impondrá.

Migrar, cuando aparezca una señal bloqueante: un módulo crítico que no encuentras, un alojamiento que retira PHP 7.1, un techo de rendimiento que no puedes levantar, o un coste anual de mantenimiento que supera el coste amortizado de rehacer la tienda.

Rehacer, cuando el problema de la tienda no es su versión: el recorrido de compra, el catálogo, la marca, la tasa de conversión. Ahí la versión no es más que una excusa de calendario, lo cual está perfectamente bien, siempre que se diga en voz alta.

Lo que no depende de ninguna versión: tu contenido

El contenido (descripciones diferenciadas, páginas de categoría, un blog) se trabaja igual en una 1.6 que en una 9, y es lo que construye el tráfico. No hace falta esperar a la reforma para ponerse. El malentendido caro es «mi tienda es demasiado vieja para las herramientas modernas»: eso es una decisión de arquitectura del proveedor, no una fatalidad técnica.

Publium funciona en una 1.6 sin tocarla. El módulo está escrito para funcionar de forma idéntica de la 1.6.1 a la 9, una restricción aceptada desde la primera línea, porque el parque de 1.6 existe y merece algo mejor que el abandono. El detalle de versiones está en la página de compatibilidad. Una tienda construida en 2015 puede darse un repaso de visibilidad esta misma semana: un blog que por fin existe, fichas de producto reescritas, etiquetas rellenas, enlazado interno, sin migración, sin modificar el núcleo y sin esperar a un presupuesto de reforma. Y, de paso, puedes publicar sin abrir el back office.

Y si rehaces la tienda más adelante, ese trabajo no empieza de cero: tus artículos y tus descripciones reescritas se conservan dentro de Publium, con su historial de versiones, y no solo en tu base de datos de PrestaShop. El día en que la tienda se rehaga en el mismo dominio, se vuelve a emparejar y recupera su contenido, republicable en la nueva versión porque el módulo también la cubre. Mientras tanto, el texto sigue siendo legible y recuperable desde el editor, tanto en markdown como en HTML.

«Ya nos ocuparemos del contenido después de la reforma» está del revés: el contenido es la parte del trabajo que sobrevive a la reforma, y empezar por ahí es invertir en lo único que la migración no te hará repetir.

Preguntas frecuentes

¿Dejará de funcionar mi 1.6? No. No se apaga nada en una fecha concreta. Lo que se degrada es la seguridad y el ecosistema: cada vez menos módulos compatibles, y ninguna corrección cuando aparece una vulnerabilidad.

¿Son serios los parches comunitarios? Algunos están escritos por desarrolladores muy capaces y hacen un bien real. Pero al instalar uno pasas a ser responsable de su seguimiento. Úsalos para vulnerabilidades conocidas mientras decides, no en lugar de decidir.

¿Cuánto cuesta rehacer una tienda? Una reforma completa se cuenta en miles de euros, y está justificado por el trabajo que implica. Pero la cifra que te concierne depende de tu inventario, y muchas tiendas no necesitan rehacerlo todo. Es exactamente lo que miramos, gratis, antes de aconsejar nada.

¿Puedo trabajar mi visibilidad sin migrar? Sí, y es el mejor orden: el contenido no depende de ninguna versión, y sigue siendo tuyo el día que migres. Publium funciona de la 1.6.1 a la 9.

¿Me penaliza Google por mi versión de PrestaShop? No. El posicionamiento no depende de un número de versión: la guía práctica de SEO cubre lo que de verdad importa.