Migrar PrestaShop 1.7 a 9: qué revisar antes de actualizar tu tienda

Una tienda PrestaShop 1.7 puede seguir vendiendo, cobrando y gestionando pedidos con aparente normalidad. Eso no significa que actualizarla sea una operación rutinaria. Con los años suelen acumularse módulos, cambios de tema, overrides, scripts, conexiones externas y decisiones que no aparecen en el número de versión.

PrestaShop 9 es una versión mayor y el propio proyecto advierte de que algunos módulos y temas pueden necesitar cambios para funcionar. Pero incluso esa comprobación se queda corta: una tienda puede cargar correctamente y, al mismo tiempo, dejar de enviar pedidos al ERP, calcular mal un transporte o perder visibilidad orgánica.

Por eso, migrar PrestaShop 1.7 a 9 no debe plantearse como copiar la instalación y actualizar el core. El 9 define un posible destino técnico, no una ruta universal ni garantiza que cualquier instalación 1.7 pueda llegar de forma directa. Antes hay que entender qué sostiene hoy la operación y qué deberá continuar funcionando después. Este diagnóstico es también el punto de partida de una migración PrestaShop planificada, aunque todavía no se haya decidido cómo ejecutarla.

1. Empieza por inventariar la tienda actual

El primer entregable útil no es una copia de archivos ni una instalación nueva. Es un inventario que describa el punto de partida con suficiente precisión para detectar dependencias y estimar riesgos.

En un salto desde 1.7, este inventario debe separar dos entornos que pueden necesitar requisitos distintos: el que mantiene viva la tienda antigua y el que ejecutará la versión 9.x elegida. No conviene actualizar PHP primero en producción para «preparar» el cambio. La revisión correcta compara la versión exacta de partida con los requisitos oficiales de la versión de destino y construye un entorno compatible en paralelo.

Conviene registrar, como mínimo:

• Versión exacta de PrestaShop: no solo «1.7», sino la revisión concreta, el historial de actualizaciones y cualquier cambio aplicado sobre el core.
• PHP y entorno de ejecución: versión, extensiones, base de datos, servidor web, sistema de caché, colas si existen y límites relevantes.
• Tema: nombre, versión, tema padre si lo hay, plantillas modificadas y personalizaciones acumuladas.
• Módulos: activos, desactivados pero todavía necesarios, versión, licencia, proveedor, función y estado de mantenimiento.
• Overrides y código propio: qué clases o controladores se alteran, qué problema resuelve cada pieza y quién conoce su funcionamiento.
• Integraciones externas: ERP, CRM, PIM, WMS, logística, marketplaces, pagos, email, analítica y cualquier API o intercambio de archivos.
• Infraestructura: alojamiento, dominios, certificados, DNS, copias, cron, despliegues, acceso al código y disponibilidad de staging.

La versión de destino tampoco debería quedar escrita solo como «PrestaShop 9». Hay que fijar la revisión 9.x que se probará, comprobar sus requisitos y confirmar que los proveedores de los componentes críticos la contemplan. Una declaración de compatibilidad con otra versión mayor o con «PrestaShop 8/9» sin más detalle no sustituye una prueba sobre la combinación real.

No basta con exportar la lista de módulos. Hay que contrastarla con el uso real. Puede existir un módulo activo que ya no aporta nada, otro aparentemente secundario que calcula una tarifa crítica y una tarea programada fuera de PrestaShop que actualiza el catálogo cada noche.

Este mapa determina si tiene sentido una actualización progresiva, una instalación paralela con traspaso de datos o una intervención selectiva sobre determinadas capas. También permite saber si la infraestructura disponible puede sostener versiones actuales de PHP, entornos separados, copias verificables y un cambio controlado.

Update Assistant puede formar parte de una ruta de actualización y aportar comprobaciones de requisitos, copias, logs y restauración. No decide, sin embargo, si un override sigue teniendo sentido, si el conector del ERP conserva su contrato o si una plantilla personalizada mantiene el checkout. Primero se valida la ruta con una copia representativa; después se decide si esa herramienta encaja en el procedimiento de esta tienda.

2. Comprueba los módulos antes de tocar el core

La compatibilidad de módulos PrestaShop debe revisarse uno a uno y contra la versión de destino que realmente se vaya a probar. Que un módulo funcione en la instalación actual no dice si dispone de una edición compatible, si conserva la configuración ni si el proveedor mantiene la misma funcionalidad.

No debe suponerse que todos los módulos se pueden copiar a la nueva instalación. Algunos crean tablas propias, guardan referencias a pedidos o clientes, añaden estados, modifican el checkout o intervienen en los cálculos. Sustituirlos exige saber qué datos históricos deben conservarse y cómo se comportarán los pedidos anteriores.

Los módulos de pago y transporte merecen una revisión específica. Además de cargar sin errores, deben aceptar credenciales, operar en el entorno adecuado, calcular importes, devolver estados y mantener el flujo de pedido esperado. Una pantalla de configuración correcta no valida un cobro ni una expedición.

3. Revisa el tema como una capa independiente

El objetivo comercial puede ser conservar la identidad y la experiencia de la tienda. Eso no obliga a conservar cada plantilla, dependencia o parche del tema actual.

En una instalación con años de recorrido, el tema puede incluir:

• Plantillas sobrescritas para producto, categoría, carrito, checkout o cuenta de cliente.
• Cambios directos sobre un tema comercial que dificultan instalar su siguiente versión.
• JavaScript dependiente de librerías antiguas o de comportamientos de módulos concretos.
• CSS construido sobre un marcado que cambia al actualizar la plataforma o un módulo.
• Lógica funcional introducida en plantillas para resolver necesidades que deberían estar separadas de la presentación.
• Fragmentos sin documentar añadidos por varios proveedores a lo largo del tiempo.

Adaptar el tema tiene sentido cuando su base está mantenida, las personalizaciones son localizables y el coste de llevarlas al entorno nuevo es razonable. Reconstruir la capa de presentación puede ser más seguro cuando conservarla obliga a arrastrar plantillas obsoletas, JavaScript frágil y cambios sin trazabilidad.

Esto no equivale a rediseñar toda la tienda. Es posible mantener el diseño y los recorridos que funcionan mientras se cambia su implementación técnica. La decisión debe comparar el coste y el riesgo de ambas rutas, no asumir que «mantener el aspecto» significa copiar la carpeta del tema.

4. Audita overrides y desarrollo propio

Los overrides y el código heredado suelen concentrar uno de los mayores riesgos porque pueden cambiar el comportamiento del core sin resultar visibles desde el back office. Además, dos overrides compatibles por separado pueden entrar en conflicto entre sí o con una versión nueva de la plataforma. Un override también puede seguir cargándose sin errores tras un cambio mayor de plataforma y, a la vez, haber dejado de encajar con el método o el comportamiento del core que originalmente reemplazaba. En ese caso el síntoma suele ser un fallo sutil —un cálculo, un estado o un dato que deja de ser correcto— antes que un error fatal visible, y por eso cada override heredado debe revisarse contra la versión de destino y no solo comprobarse que existe.

Cada pieza debería responder cuatro preguntas:

1. ¿Qué necesidad del negocio resuelve?
2. ¿Sigue utilizándose y existe una persona capaz de validarla?
3. ¿Está aislada y se puede mantener, o depende de detalles internos de la versión antigua?
4. ¿Debe conservarse, refactorizarse o sustituirse por una capacidad estándar o un módulo mantenido?

Una personalización es mantenible cuando tiene un propósito claro, límites identificables y una forma razonable de probarse. La deuda técnica aparece cuando solo se sabe que «si se quita, algo falla», cuando hay cambios directos sobre el core o cuando una regla está repartida entre tema, override, módulo y scripts externos.

La migración ofrece una oportunidad para devolver esas reglas a componentes con responsabilidad clara. No se trata de reescribir por principio: un desarrollo PrestaShop especializado puede conservar código sano, adaptar lo que sigue aportando valor y refactorizar únicamente las partes que bloquearían la evolución.

5. No olvides las integraciones

Un ecommerce puede parecer migrado desde el navegador y estar roto para el equipo que prepara, factura o expide pedidos. ERP, CRM, stock, logística, marketplaces, pasarelas y APIs externas forman parte de la tienda aunque su interfaz viva en otro sistema.

Para cada conexión hay que identificar:

• Qué datos intercambia: productos, combinaciones, precios, stock, clientes, pedidos, facturas, estados o seguimiento.
• Qué sistema es la fuente de verdad para cada dato.
• En qué dirección viaja la información y con qué frecuencia.
• Qué credenciales, endpoints, formatos y versiones utiliza.
• Si depende de un módulo, una tarea programada, un middleware o un script externo.
• Cómo registra fallos, reintenta operaciones y evita duplicados.
• Qué entorno existe para probarla sin enviar datos reales incorrectos.
• Quién valida el resultado por parte del negocio y del sistema externo.

No basta con comprobar que una API responde. Hay que completar recorridos: crear un pedido, recibirlo donde corresponde, actualizar su estado, devolver el seguimiento y reconciliar un fallo. Lo mismo ocurre con stock y precios: una primera importación correcta no demuestra que los cambios posteriores seguirán llegando.

Cuando la tienda depende de varios sistemas, una revisión de integraciones técnicas ayuda a separar el cambio de plataforma de los contratos de datos y procesos que deben preservarse. En el caso concreto de gestión empresarial, la guía sobre qué revisar al integrar PrestaShop con un ERP profundiza en propiedad del dato, direcciones, frecuencias y tratamiento de errores.

6. Decide qué datos deben mantener continuidad

La distinción más útil es sencilla: los datos de negocio suelen necesitar continuidad; los componentes de software necesitan un análisis de compatibilidad.

Continuidad no significa copiar todas las tablas sin criterio. Hay que decidir qué entidades se trasladan, cómo se relacionan, qué recuentos o muestras permiten verificar la integridad y qué configuración debe reconstruirse en el destino.

El catálogo exige atención especial cuando hay combinaciones, idiomas, precios específicos, grupos de clientes, packs, reglas o referencias externas. Un total de productos idéntico no garantiza que cada combinación conserve su precio, stock, imagen y relación con ERP.

Clientes y pedidos también requieren contexto. Deben revisarse direcciones, estados, pagos, impuestos, facturas, devoluciones y cualquier campo añadido por módulos. El histórico tiene valor comercial y operativo, pero puede depender de componentes que no existirán exactamente igual en la plataforma actualizada.

7. Protege las URLs y el SEO

Una migración técnica puede cambiar rutas aunque el catálogo siga siendo el mismo. Antes de publicar conviene extraer y comparar las URLs indexables actuales: categorías, productos, fabricantes, páginas CMS, idiomas y cualquier landing que reciba tráfico o enlaces.

El control SEO debería cubrir:

• Conservación de URLs cuando sea posible y coherente.
• Mapa de redirecciones cuando una ruta deba cambiar.
• Canonicals consistentes con las URLs finales.
• Títulos y metadescripciones relevantes.
• Sitemap generado con las rutas correctas.
• robots.txt, meta robots y cabeceras que no arrastren bloqueos de staging.
• Enlaces internos, paginaciones, filtros e idiomas.
• Datos estructurados en las plantillas donde sean pertinentes.
• Respuestas HTTP, cadenas de redirección y páginas no encontradas.

El objetivo es preservar señales y evitar pérdidas evitables, no prometer que una migración mantendrá posiciones exactas. Incluso con una ejecución correcta, los buscadores necesitan rastrear y procesar cambios. Por eso hacen falta una referencia previa, comprobaciones al publicar y seguimiento posterior.

8. Migra en staging, no directamente en producción

La nueva base debe prepararse en un entorno separado donde sea posible actualizar, adaptar y equivocarse sin interrumpir ventas reales. Staging permite probar datos, módulos, tema, checkout e integraciones antes de decidir el cambio.

Pero una copia inicial no resuelve toda la migración. Mientras se trabaja, la tienda en producción continúa recibiendo:

• Pedidos y altas de clientes.
• Cambios de stock y precios.
• Altas o modificaciones de catálogo.
• Actualizaciones procedentes del ERP.
• Estados de pedido, devoluciones y otras operaciones.

El plan debe especificar qué datos se copian al principio, cuáles pueden modificarse en ambos lados, cómo se incorporan los cambios recientes y en qué momento se limita la edición o se abre una ventana de corte. También necesita una copia verificada, criterios de salida, responsables y una estrategia de reversión compatible con los pedidos que puedan entrar durante el cambio.

La duración y el impacto dependen del volumen, de las integraciones y de la arquitectura. Algunas tiendas admiten un cambio muy corto; otras necesitan una ventana operativa acordada. No es responsable prometer «cero downtime» de forma universal sin haber analizado antes esas condiciones.

9. Valida la operación real de compra

La validación no consiste en abrir la home y confirmar que no hay errores visibles. Debe utilizar productos, clientes, destinos y reglas representativos, incluidos casos menos frecuentes que afecten al importe o a la gestión del pedido.

Catálogo y condiciones comerciales

• Productos, categorías, atributos y combinaciones están completos.
• Imágenes, idiomas y contenidos se muestran correctamente.
• Precios base, tarifas, descuentos y promociones coinciden con las reglas esperadas.
• Stock, reservas y disponibilidad por combinación son coherentes.
• Impuestos y redondeos producen los totales esperados.

Cliente, checkout y pedido

• Registro, login, recuperación de acceso y direcciones funcionan.
• Las cuentas de cliente existentes conservan el acceso, o el cambio de credenciales se ha gestionado de forma deliberada.
• Las referencias y numeraciones de pedidos, facturas y documentos mantienen continuidad entre el histórico migrado y los nuevos documentos.
• Carrito y checkout conservan productos, cantidades y descuentos.
• Cada método de pago crítico completa y devuelve el estado correcto.
• Transportistas, zonas, costes y restricciones de envío se calculan bien.
• El pedido se crea una sola vez con líneas, totales, impuestos y estado correctos.
• Los emails transaccionales se generan y llegan con contenido válido.

Operación y sistemas externos

• El back office permite gestionar productos, clientes y pedidos habituales.
• El inicio de sesión en el back office funciona para las cuentas de empleado existentes tras la migración.
• ERP, CRM, logística, marketplaces y APIs reciben y devuelven la información necesaria.
• Los procesos cron y tareas programadas se ejecutan, registran resultado y alertan si fallan.
• Los reintentos no duplican pedidos, clientes ni movimientos.
• Los usuarios internos conservan permisos adecuados.

SEO y rendimiento

• URLs, redirecciones, canonicals y enlaces internos están comprobados.
• Sitemap, robots e indexabilidad corresponden al entorno de producción.
• Metadatos y datos estructurados relevantes siguen presentes.
• No hay errores generalizados ni una degradación de rendimiento sin explicar.
• Caché, imágenes, búsqueda y filtros se comportan en condiciones próximas a producción.

La checklist debe adaptarse a la tienda. Una operación B2B con tarifas por cliente, una tienda multidioma y un catálogo sincronizado con varios almacenes necesitan casos diferentes. Lo importante es validar procesos de negocio, no acumular casillas genéricas.

10. ¿Actualizar, adaptar o reconstruir?

El análisis puede conducir a tres escenarios. No son paquetes cerrados ni niveles de calidad: son respuestas distintas al estado de la instalación.

Actualizar

La base técnica permanece sana. Los módulos críticos tienen continuidad, el tema es adaptable, hay pocos overrides controlados y el código propio no depende de modificaciones frágiles. El trabajo se concentra en preparar el salto, actualizar componentes y validar.

Adaptar

La plataforma puede evolucionar, pero algunas piezas requieren intervención. Puede ser necesario sustituir un módulo abandonado, reescribir un override, adaptar una integración o reconstruir determinadas plantillas sin rehacer el resto de la tienda.

Reconstruir partes seleccionadas

La deuda técnica de una capa concreta hace poco razonable conservar su implementación: por ejemplo, un tema lleno de modificaciones directas o una función repartida entre core, overrides y scripts. Se reconstruye esa parte sobre una base mantenible mientras continúan los datos, las reglas válidas y las demás piezas que sí pueden evolucionar.

Reconstruir partes no significa que rehacer todo el ecommerce sea automáticamente mejor. Tampoco actualizar es siempre la opción más conservadora: forzar componentes incompatibles puede trasladar más riesgo al futuro. La decisión correcta es la intervención mínima que deja una operación completa, comprobable y mantenible.

Si el análisis cuestiona no solo la implementación sino el encaje de la propia plataforma, entonces conviene separar esa decisión y comparar PrestaShop con otras opciones a partir de los requisitos del negocio. No debería aprovecharse una migración técnica para cambiar de plataforma sin demostrar que resuelve una limitación estructural.

Conclusión

La pregunta importante no es simplemente «¿se puede actualizar este PrestaShop?», sino «¿qué tiene que seguir funcionando después de la migración?». La respuesta incluye catálogo y pedidos, pero también pagos, transportistas, tarifas, integraciones, procesos programados, URLs y trabajo diario del equipo.

Un inventario riguroso permite decidir qué se actualiza, qué se adapta y qué merece reconstruirse sin arrastrar dependencias por inercia. También convierte la puesta en producción en un cambio planificado, con datos sincronizados y recorridos reales validados.

Si necesitas pasar de esa revisión inicial a una estrategia concreta, en el servicio de migración PrestaShop explicamos cómo analizamos la instalación y definimos el camino según su estado técnico y operativo, no según un salto de versión decidido de antemano.