Este texto explica cómo se genera esa deuda, cómo detectarla, cuántas horas consume PrestaShop y cómo es un mantenimiento que no la agranda. No vamos a anunciar el fin del mundo en versiones antiguas. Vamos a enseñarle la factura.
El mapa de versiones, sin alarmismo
Bastan tres datos. PrestaShop 8 salió en octubre de 2022 y exige PHP 8.1. PrestaShop 9 salió en junio de 2025: Symfony 6.4, soporte de PHP hasta 8.4, nueva API de administración, nuevo tema. PrestaShop 9.1 salió en abril de 2026. Las versiones 1.6 y 1.7 son históricas.
No daremos una fecha de fin de soporte para 1.7: no la tenemos verificada y no vamos a inventarla. Algo más útil: una tienda en 1.7 está en una rama que ya no se desarrolla, y los módulos de pago dejan de recibir actualizaciones. Eso duele antes. El proveedor de un módulo de pago o transporte publica versión para PrestaShop 8 y 9, y para 1.7 deja la entrega de hace años. Funciona mientras nada cambie en el proveedor; cuando cambia la API, se acaba en un día.
Compruébelo en un cuarto de hora: lea en el back office la versión de PrestaShop y la de PHP, y cuente los módulos sin actualizar desde hace más de dos años. Ese número indica el riesgo mejor que la versión.
Por qué una tienda se queda en una versión antigua
Pocas veces es cosa del núcleo, que se sube de forma previsible. La tienda se queda porque se quedan los módulos y el tema.
Tras unos años, una tienda típica tiene de 30 a 60 módulos: una docena de pago, dos o tres a medida y el resto añadidos en alguna campaña y nunca desactivados. El tema se compró y luego se modificó, a menudo sobrescribiendo plantillas del núcleo. Al plantear la subida, alguien debe responder por cada elemento: ¿existe un equivalente compatible con la versión de destino y, si no, qué hacemos? Para la mayoría la respuesta es fácil. Para tres es "no existe, hay que escribirlo". Y en esos tres se atasca el proyecto.
El mecanismo va en una sola dirección: cuanto más pare, más caro es arrancar. Una tienda en PrestaShop 8 que sube a 9 da un salto. Una en 1.7 cruza dos versiones mayores a la vez, los cambios de ambas ramas se acumulan en un proyecto y todo se prueba junto. A eso se suma PHP: un salto del lenguaje puede tumbar módulos antiguos al margen de PrestaShop. Aplazar no es neutral. Es un crédito con interés creciente.
Qué rompe de verdad las tiendas PrestaShop
Cinco cosas que en nuestra práctica acaban en incidencia, con el orden de magnitud del tiempo hasta restablecer el servicio. Es observación de nuestro trabajo, no compromiso contractual: garantizamos el tiempo de respuesta, no el de reparación.
Conflictos de módulos al sobrescribir los mismos ficheros. Síntoma: al activar un módulo desaparece un botón del carrito o se rompe la vista de precios. Causa: dos módulos sobrescriben la misma plantilla o clase y gana el que se carga después. Orden de magnitud: de 1 a 4 horas, si se sabe qué se subió y cuándo.
Rendimiento con catálogo grande. Síntoma: el listado y el buscador tardan segundos, el back office se atasca al editar un producto. Causa: muchas combinaciones y atributos, índices ausentes o sin reconstruir, caché desactivada o inútil. Orden de magnitud: de 4 a 16 horas de diagnóstico y primeras correcciones: trabajo sobre datos, no sobre un interruptor.
Integraciones con mayorista y ERP. Síntoma: el stock se descuadra, o la importación se para de noche y nadie lo ve hasta la mañana. Causa: cambio de formato en el mayorista, clave caducada, falta de control de errores en el script. Orden de magnitud: de 2 a 8 horas, más la espera a la otra parte, ajena a nosotros.
Pagos y transportistas tras cambios del proveedor. Síntoma: el cliente no termina el pedido, los registros muestran rechazo de la pasarela, las etiquetas dejan de generarse. Causa: el proveedor cambió la API o retiró la versión antigua del módulo, y su tienda no tiene entrega compatible. Orden de magnitud: de 2 a 6 horas si hay módulo de recambio. Si no, ya no es una incidencia, es un proyecto.
Error 500 tras una actualización. Síntoma: página en blanco o error de servidor tras subir un parche. Causa: un módulo incompatible con la nueva versión de PHP o del núcleo, con menos frecuencia permisos y caché. Orden de magnitud: de 30 minutos a 3 horas, siempre que haya copia y se pueda revertir. Sin copia, las cifras son muy otras.
Tratamos estas categorías con más amplitud en el texto sobre las averías más frecuentes en tiendas online.
Cómo es un mantenimiento honesto mes a mes
En la práctica son cinco tareas repetitivas. Ninguna es vistosa.
Primero, inventario de módulos: cada uno con versión, proveedor, caducidad de licencia y si hay entrega compatible con la siguiente versión mayor, mantenido al día. Segundo, un entorno de pruebas copia de producción, donde aterriza cada actualización antes de tocar la tienda. Tercero, actualizaciones tras su aprobación y descontadas de la bolsa, no a escondidas de madrugada. Cuarto, vigilar la compatibilidad de PHP: es el hosting quien cambia la versión del lenguaje, a menudo sin preguntar, la causa más frecuente de un error 500 repentino. Quinto, copias con prueba de restauración trimestral, porque una copia que nadie ha restaurado es una hipótesis, no una protección.
Lo que aquí no hay: la promesa de que nada se romperá. No la hacemos. Prometemos que, cuando algo se rompa, habrá a dónde volver y se sabrá qué cambió por última vez.
Cuántas horas consume PrestaShop
Tres perfiles de nuestra práctica, para orientar la elección de paquete.
Tienda estable: hasta 2.000 productos, una docena de módulos, una integración, cambios en contenidos y banners. Realmente, de 6 a 10 horas al mes. Paquete Basic, 220 EUR, bolsa de 10 h.
Tienda activa: catálogo grande con combinaciones, integración con ERP o mayorista, campañas regulares, módulos de pago con licencias que vigilar. De 15 a 22 horas. Paquete Advanced, 440 EUR, bolsa de 20 h.
Tienda compleja: multiidioma o multitienda, varias integraciones, módulos a medida, cambios frecuentes en la compra. De 30 a 40 horas. Paquete Premium, 880 EUR, bolsa de 40 h.
Un aviso para el presupuesto: una tienda en plena migración consume de dos a tres veces más horas de lo habitual, durante el proyecto y varias semanas después del cambio. Prevea una bolsa mayor para ese periodo. La hora dentro del paquete cuesta 22 EUR y fuera 35 EUR, así que las horas sueltas salen más caras. El coste total lo desarrollamos en un texto aparte sobre mantener una tienda online.
La migración es un proyecto, no una tarea de la bolsa
Las migraciones no van en la cuota ni fingimos que caben en la bolsa de horas. Las presupuestamos aparte: su alcance sale del inventario, no del calendario.
Cinco partes. Auditoría de módulos y tema: qué tiene equivalente, qué lo tiene de pago, qué hay que reescribir y qué se desactiva por llevar tres años sin uso. Decisiones de negocio a partir de esa auditoría, tomadas por usted, no por nosotros. Tema: adaptarlo o construir sobre uno nuevo. Datos: migración y verificación de catálogo, pedidos, clientes y redirecciones. Pruebas en un entorno que copia producción, con proceso de compra y pagos. Al final, el cambio con ventana planificada y vuelta atrás preparada.
Algo práctico: no migre en noviembre, ni en la segunda quincena de octubre. Toda migración genera una oleada de fallos menores en las dos primeras semanas tras el cambio, justo cuando no quiere repartir atención entre temporada y arreglos. Las mejores ventanas: enero, febrero y de mayo a agosto.
Lista de control para su proveedor actual
Siete preguntas. Las respuestas dicen más que una presentación.
- ¿Quién es titular de las licencias de pago: usted o la agencia? Si es la agencia, al separarse pierde el derecho a actualizaciones.
- ¿El código de la tienda está en un repositorio y tiene usted acceso?
- ¿Existe un registro de overrides y modificaciones fuera del estándar, o hay que reconstruirlo?
- ¿Quién tiene acceso al servidor y al panel de hosting, y está usted en esa lista?
- ¿Alguien lee los registros de errores, o esperamos al aviso de un cliente?
- ¿Cuándo se restauró por última vez una copia en pruebas?
- ¿Cuál es la caducidad de la licencia más antigua y quién la vigila?
Si tres preguntas quedan sin respuesta, el mantenimiento es reacción a averías, no conservación. No siempre obliga a cambiar de proveedor: a veces basta con completar lo que falta. Pero conviene saber por qué se paga y si encaja mejor una cuota o la facturación por horas.
Compare alcances y precios en /es/sla-help-desk y elija el que encaje con su perfil de horas. Si prefiere ver primero cómo está su tienda, ejecute Tester eCommerce: indique la dirección y reciba un diagnóstico gratuito, sin llamada comercial previa.