Antes de actualizar PrestaShop: cómo preparar los módulos y el tema

Tu tienda necesita actualizarse, pero antes de acordar una fecha hay una pregunta importante: ¿qué necesita seguir funcionando exactamente igual al terminar? El pago, los transportistas, las combinaciones de productos o la conexión con tu proveedor pueden depender de piezas distintas.

Esta guía te ayuda a preparar la conversación con soporte. No recomienda una versión universal ni pulsar el botón de actualización directamente en la tienda que está vendiendo. El objetivo es llegar a una decisión con un inventario y unas responsabilidades claras.

Define el punto de partida y el destino

Pide que la propuesta identifique la versión actual de PrestaShop, la versión de destino, el tema y las dependencias del alojamiento. «Actualizar a la última» no describe por sí solo el trabajo ni acredita que los componentes de tu tienda estén preparados.

La documentación de Update Assistant distingue versiones recomendadas y últimas disponibles según el contexto de la instalación y PHP. También diferencia errores bloqueantes de advertencias. Conviene que soporte explique qué significa cada aviso para tu tienda antes de continuar.

Como criterio de gestión, solicita dos listas separadas: lo necesario para ejecutar el cambio y lo necesario para aceptar la tienda una vez actualizado el sistema. Cumplir requisitos técnicos no sustituye comprobar que el negocio puede trabajar.

Haz un inventario por función, no por número de módulos

Una lista de nombres técnicos resulta poco útil si nadie sabe qué perdería la empresa al desactivar cada elemento. Organiza el inventario por funciones y empieza por las que intervienen en pedidos, cobros y operaciones diarias.

Añade a cada fila: versión instalada, documentación disponible, titular de la licencia, función utilizada y persona que puede confirmar el resultado. Es una plantilla de preparación, no una declaración de que todas las tiendas necesiten esos componentes.

No desinstales un módulo porque su nombre resulte desconocido o porque no aparezca en la portada. Primero pregunta si guarda configuración o datos y qué proceso depende de él.

Distingue tres estados de compatibilidad

Proponemos utilizar estos estados para que una incertidumbre no se convierta en una aprobación:

• Declarada: el proveedor indica compatibilidad para las versiones concretas que se van a utilizar.
• Probada: además, se ha comprobado la función necesaria en una copia controlada de tu tienda.
• Pendiente: falta confirmación, una versión compatible o la revisión de una personalización.

Son etiquetas de trabajo propuestas, no categorías oficiales de PrestaShop. Para una integración crítica, una ficha genérica de producto no sustituye una prueba del recorrido que usa tu empresa.

Si un proveedor confirma compatibilidad, guarda la referencia y la fecha junto al inventario. Si no hay respuesta, pide una alternativa con su coste y consecuencias: adaptación, sustitución o aplazamiento de esa parte del proyecto. No conviertas «no sabemos» en «seguro que funciona».

El tema y las personalizaciones requieren su propia revisión

PrestaShop advierte en su guía de actualización y migración de posibles incompatibilidades al cambiar de versión principal. También señala que un tema de la rama 1.6 no es compatible directamente con 1.7 y posteriores. Por eso una tienda antigua puede necesitar una decisión sobre diseño y migración, no solo una actualización rutinaria.

Pide que identifiquen modificaciones hechas sobre el tema, módulos desarrollados a medida y cambios de comportamiento. No basta con saber que se compró una plantilla: interesa saber qué se ha modificado desde entonces y dónde está documentado.

Ejemplo hipotético: una tienda tiene un selector especial de medidas en la ficha de producto. Aunque el tema tenga una versión compatible, hay que decidir cómo conservar ese selector y quién comprobará que el dato llega al pedido. Ese detalle cambia el alcance del trabajo.

Revisa las opciones que pueden alterar funciones visibles

Update Assistant contempla opciones sobre módulos no nativos, overrides y regeneración de plantillas de correo; su documentación advierte que esta última puede perder personalizaciones. Pide una explicación de las opciones elegidas y de lo que habrá que revisar después. No cambies todas las opciones por defecto para intentar que desaparezcan los avisos.

Como comprobación de negocio, prepara ejemplos de los correos y pantallas que utilizáis. Deben servir de referencia al equipo técnico, sin incluir datos privados de clientes en documentos compartidos innecesariamente.

Acuerda copia, pruebas y criterio para aplazar

Antes de intervenir, define con soporte la copia disponible, cómo se recuperaría y qué pasaría con los pedidos posteriores. La documentación de Update Assistant recomienda respaldo y contempla archivos y base de datos; no basta con que alguien recuerde haber descargado una copia meses atrás.

Para la copia de pruebas, acordad cómo evitar pagos reales no autorizados, envíos de correo a clientes o sincronizaciones hacia herramientas de producción. El responsable técnico debe controlar ese aislamiento. Aquí estamos preparando el trabajo, no ejecutando compras ni cambios en la tienda.

Un criterio razonable para aplazar es que una función imprescindible siga en estado pendiente y no exista alternativa aceptada. Eso no significa dejar de actualizar indefinidamente: significa asignar responsable y siguiente paso al bloqueo.

Qué pedir en el presupuesto

Solicita partidas distinguibles: revisión inicial, actualización, adaptación o sustitución de componentes, licencias necesarias y comprobaciones de entrega. Pregunta también quién atenderá las incidencias posteriores y qué queda fuera del alcance.

En nuestro mantenimiento PrestaShop valoramos el soporte recurrente según las funciones de la tienda. Un salto de versión, una migración o un desarrollo que exceda el mantenimiento requiere una valoración específica; no se presupone incluido sin revisar el caso.

Para iniciar esa conversación, envíanos la URL, la versión si la conoces y las funciones que no puedes interrumpir. No mandes contraseñas ni exportaciones de pedidos en el primer mensaje. Con ese contexto podemos concretar qué información técnica falta antes de fijar una intervención.