Seguir con PrestaShop 1.6 o 1.7: qué riesgos tiene y cómo valorarlos

«Si funciona, no lo toques» es un buen consejo para casi todo, menos para el software que está expuesto a Internet y cobra con tarjeta. Una tienda en PrestaShop 1.6 o 1.7 puede vender cada día sin un solo error visible y, a la vez, acumular riesgos que no se notan hasta que estallan.

No se trata de meter miedo. Se trata de entender qué significa estar fuera de soporte, para que la decisión de seguir o migrar sea tuya y con datos.

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

El núcleo ya no recibe parches

La rama 1.6 terminó con la 1.6.1.24 y la rama 1.7 con la 1.7.8.11. Cuando se descubre una vulnerabilidad nueva en el núcleo, la corrección se publica para las ramas mantenidas. Para la tuya, en el mejor de los casos, alguien escribe un parche no oficial; en el peor, no hay nada.

Y aunque estés en 1.7, ¿en qué 1.7 estás? Muchas tiendas siguen en una 1.7.6 o una 1.7.7 sin las correcciones posteriores de la propia rama, que incluyeron arreglos de seguridad.

Los módulos se van quedando atrás

Los desarrolladores de módulos concentran su trabajo en las versiones actuales. Con el tiempo pasa esto:

• Las versiones nuevas de los módulos dejan de ser compatibles con tu tienda.
• Cuando se publica un fallo de seguridad en un módulo, la versión corregida exige un PrestaShop más reciente.
• Algunos autores abandonan sus módulos y nadie los vuelve a revisar.
• Las pasarelas de pago cambian sus API y sus requisitos, y los módulos antiguos dejan de funcionar o pierden funciones.

Este es, en la práctica, el riesgo más grande. Las campañas masivas contra PrestaShop suelen explotar vulnerabilidades en módulos, y una tienda que no puede instalar la versión corregida se queda expuesta indefinidamente.

PHP sin soporte

PrestaShop 1.7.8 llega como máximo a PHP 7.4, y las versiones anteriores a menos. PHP 7.4 dejó de recibir parches de seguridad hace años. Eso significa que el propio lenguaje sobre el que corre tu tienda tiene fallos conocidos que no se van a corregir.

Además, los hostings retiran las versiones antiguas de PHP de sus servidores. Llega un día en que el proveedor avisa de que va a subir la versión, o directamente la sube, y la tienda deja de funcionar. Migrar con prisa por eso es la peor forma de migrar.

Cómo valorar tu riesgo

No todas las tiendas antiguas tienen el mismo riesgo. Estas preguntas ayudan a situarte:

Una tienda con mucha facturación, muchos módulos de terceros y sin vigilancia es la que más tiene que perder y la que más probabilidades tiene de ser atacada con éxito.

Lo que se puede hacer mientras tanto

Si la migración no puede ser inmediata, hay medidas que reducen el riesgo:

• Sube a la última versión de tu rama: la 1.7.8.11 si estás en 1.7. Es mucho menos trabajo que una migración y cierra fallos conocidos.
• Sube PHP a la versión más alta que admite tu PrestaShop, probando antes en una copia.
• Inventaria los módulos y retira los que no usas, incluidas las carpetas de los desinstalados.
• Actualiza los módulos que tengan versión compatible, sobre todo los que tienen controladores públicos.
• Bloquea la ejecución directa de PHP en modules/ y en las carpetas de datos.
• Activa la vigilancia de ficheros, empleados y configuración de pagos, para enterarte pronto si pasa algo.
• Copias de seguridad diarias, fuera del servidor y probadas.

Todo esto compra tiempo. No convierte una tienda sin soporte en una con soporte. Y cuanto más se alarga, más se encarece la salida: cada año que pasa hay más distancia entre tu versión y la actual, más módulos sin equivalente directo y más datos que llevar. Las migraciones más sencillas que hacemos son las de tiendas que dieron el salto cuando todavía podían elegir el momento, no las que esperaron a que algo dejara de funcionar.

Cómo planificar la salida

1. Decide el destino. Hoy lo razonable es saltar directamente a PrestaShop 9, sin parada intermedia en la 8, salvo que algún módulo imprescindible no exista todavía para la 9.
2. Inventaria funciones, no módulos. Lista lo que hace la tienda (facturación, envíos, ERP, pagos, SEO) y, para cada cosa, qué módulo lo resuelve hoy y cuál lo hará en la 9. Muchas veces sobra una buena parte.
3. Calcula el trabajo del tema. Un tema de 1.6 no sirve en la 9, y uno de 1.7 rara vez sirve tal cual. Es la partida más grande de muchas migraciones.
4. Elige el momento. Evita las campañas fuertes de tu sector. Una migración bien planificada necesita semanas de pruebas, no días.
5. Haz un ensayo completo en una copia antes del día del cambio.

La ventaja de planificarlo con tiempo es que eliges tú el calendario. Si esperas a que el hosting retire PHP 7.4 o a que llegue un incidente, lo elegirá otro.

Cómo resolverlo en PrestaShop

En Rekire trabajamos a diario con tiendas en 1.6, 1.7, 8 y 9, y con los bonos de horas de soporte hacemos exactamente este trabajo: una auditoría de la versión, el PHP y los módulos de tu tienda con una valoración del riesgo, la actualización a la última versión de tu rama si quieres ganar tiempo, y el plan de migración a PrestaShop 9 con su inventario de funciones, módulos sustitutos y trabajo de tema. Las horas se consumen según el trabajo real, y puedes empezar por la auditoría y decidir después.