Guía técnica: Cómo migrar de PrestaShop 1.7 a PrestaShop 9 sin romper tu tienda

¿Por qué migrar a PrestaShop 9?

PrestaShop 9 no es una actualización incremental más. Es una reconstrucción profunda de la plataforma que afecta al core tecnológico, la arquitectura del back office, la API, el sistema de temas y la forma en que los módulos interactúan con el sistema. Seguir en PrestaShop 1.7 supone trabajar sobre una base tecnológica que dejará de recibir soporte y actualizaciones de seguridad, lo que expone a tu tienda a vulnerabilidades crecientes.

Las razones principales para dar el salto son claras: Symfony 6.4 LTS como framework base (con soporte hasta 2027), compatibilidad con PHP 8.1 a 8.5 en las ramas 9.1 y posteriores, una nueva Admin API basada en API Platform, un back office completamente reconstruido con Symfony y Twig, y mejoras de rendimiento que en nuestras pruebas alcanzan hasta un 20% de reducción en tiempos de carga.

Actualizado en octubre de 2026. El destino de la migración ya no es la 9.0 con la que nació esta guía: la versión estable es PrestaShop 9.2.0, publicada el 30 de septiembre de 2026, y la 9.1.5 (18 de agosto de 2026) fue la última entrega planificada de la rama 9.1. Si estás planificando el salto ahora, planifícalo directamente contra la 9.2 y no contra una rama que ya no recibe funcionalidad nueva.

La 9.2 añade además cosas que cambian el alcance del proyecto y conviene conocer antes de presupuestar: un módulo nativo de One Page Checkout (se puede alternar entre checkout de una página y el de cuatro pasos desde el back office), Extra Properties para añadir campos tipados a entidades del core como Producto, Combinación, Cliente o Pedido sin tocar código, un asistente conversacional Ask AI en el back office que se conecta al proveedor de IA que elijas a través del servidor MCP de PrestaShop, automatización de email y SMS con Klaviyo en la edición Classic, seis páginas más del back office migradas a Symfony detrás de un feature flag (Países, Devoluciones de mercancía, Enganchar un módulo, Acceso rápido, Traducciones de cuerpos de email y Reglas de impuestos), tres modos de redimensionado de miniaturas (Fit por defecto, Crop y Bound) y la versión 2.1.2 de Hummingbird como tema de front incluido.

Pero la migración no es trivial, y hacerla mal puede significar semanas de tienda offline, pérdida de datos o un sistema inestable. En este artículo compartimos nuestra experiencia real migrando tiendas de clientes desde PrestaShop 1.7 a la versión 9, con todos los riesgos, decisiones técnicas y pasos críticos que debes conocer.

Antes de empezar: auditoría técnica de tu tienda actual

Inventario de módulos y compatibilidad

El primer paso, y probablemente el más importante, es realizar un inventario exhaustivo de todos los módulos instalados en tu tienda PrestaShop 1.7. Para cada módulo necesitas determinar si existe una versión compatible con PrestaShop 9, si el desarrollador ha confirmado que habrá actualización, o si necesitas buscar una alternativa.

En nuestra experiencia, los módulos que más problemas generan en la migración son los de pasarela de pago, los de transporte y logística, y los que implementan overrides del core. Los módulos que usan hooks estándar y siguen las buenas prácticas de desarrollo de PrestaShop suelen adaptarse con menos fricción. Tenemos desglosado el detalle de esa compatibilidad en la guía de mantenimiento de módulos en PrestaShop 9: overrides, hooks y compatibilidad.

Recomendamos crear una hoja de cálculo con tres columnas: módulo, estado de compatibilidad (compatible, pendiente de actualización, sin soporte) y alternativa disponible. Este documento será tu guía durante todo el proceso.

Análisis de overrides y personalizaciones

Los overrides son uno de los puntos más críticos en cualquier migración de PrestaShop. Si tu tienda 1.7 utiliza overrides de clases o controladores del core, es muy probable que estos dejen de funcionar en PrestaShop 9 debido a los cambios en la arquitectura Symfony.

PrestaShop 9 ha migrado gran parte del back office a controladores Symfony, lo que significa que los overrides basados en el legacy controller system simplemente no aplican. Cada override necesita ser evaluado individualmente y, en muchos casos, reescrito como un módulo que utilice hooks o servicios Symfony.

Este es el área donde más tiempo se invierte en una migración real. No subestimes esta fase. Si tu tienda viene de un salto previo, en la guía de PrestaShop 8 y la migración desde 1.7 está explicado cuándo conviene pasar por la 8 y cuándo ir directo a la 9.

Estado del servidor y requisitos técnicos

PrestaShop 9 requiere como mínimo PHP 8.1. El techo depende de la rama: la 9.0 llega hasta PHP 8.4 y la 9.1 y posteriores admiten hasta PHP 8.5, así que la recomendación práctica es usar la versión de PHP más reciente que tu hosting mantenga y que el conjunto de tus módulos soporte, no la más nueva que exista. Sobre base de datos, la postura actual del proyecto es menos rígida que un número concreto: usa una versión de MySQL o MariaDB que tu proveedor mantenga con soporte, y evita quedarte en una rama sin parches de seguridad. Revisa también la configuración de Nginx o Apache, deja el memory_limit en 256 MB o más para una tienda real de producción (y bastante más si el catálogo es grande o haces importaciones masivas), y asegúrate de tener suficientes recursos de servidor para ejecutar el proceso de migración, que puede ser intensivo en CPU y memoria.

El proceso de migración paso a paso

Paso 1: Crear un entorno de staging completo

Nunca, bajo ninguna circunstancia, ejecutes la migración directamente en producción. Crea una réplica exacta de tu tienda en un entorno de staging: misma versión de PHP, misma configuración de servidor, misma base de datos (copia completa) y mismos módulos instalados.

Este entorno será donde pruebes toda la migración antes de tocar producción. En Keliam configuramos entornos de staging automatizados que se actualizan diariamente con datos de producción para que las pruebas sean lo más realistas posible.

Paso 2: Actualizar primero a la última versión de PrestaShop 1.7

Antes de saltar a PrestaShop 9, asegúrate de estar en la última versión estable de 1.7 (1.7.8.x). Esto resuelve posibles inconsistencias en la base de datos y garantiza que partes del estado de partida sea lo más limpio posible.

Paso 3: Usar el Update Assistant (antiguo 1-Click Upgrade)

PrestaShop ha rediseñado completamente su herramienta de actualización, ahora llamada Update Assistant. La nueva versión ofrece una interfaz paso a paso con generación automática de backups, detección de errores antes de iniciar el proceso, soporte para CLI (ideal para tiendas grandes) y registros detallados de cada fase.

El Update Assistant guía el proceso de migración de la base de datos, la actualización de archivos del core y la verificación de integridad post-migración. Sin embargo, no migra automáticamente los overrides ni adapta los módulos incompatibles — eso es trabajo manual.

Paso 4: Verificación post-migración

Una vez completada la migración técnica, la fase de verificación es crítica. Necesitas comprobar:

• Catálogo: Que todos los productos, categorías, atributos, combinaciones e imágenes se han migrado correctamente.
• Clientes: Que las cuentas de cliente, direcciones y grupos funcionan correctamente.
• Pedidos: Que el historial de pedidos es accesible y consistente.
• Proceso de compra: Realizar pedidos de prueba completos con diferentes métodos de pago y envío.
• Back office: Verificar todas las secciones del nuevo panel de administración basado en Symfony.
• Integraciones: Comprobar que las conexiones con ERP, CRM, plataformas de marketing y servicios de logística funcionan correctamente.
• SEO: Verificar que las URLs, meta tags y redirecciones se mantienen para no perder posicionamiento.

Paso 5: Planificar el go-live

El paso a producción debe planificarse en un momento de bajo tráfico (idealmente un domingo por la noche o lunes por la mañana temprano). Prepara un plan de rollback claro por si algo falla, con backups completos de la base de datos y los archivos de la versión anterior.

Los riesgos reales que debes conocer

Incompatibilidad de módulos de pago

Los módulos de pasarela de pago son especialmente sensibles. Si tu módulo de pago no es compatible con PrestaShop 9, tu tienda no puede procesar ventas. Verifica la compatibilidad con tu proveedor de pagos semanas antes de la migración y ten siempre un plan B.

Pérdida de personalizaciones del tema

Si tu tema actual de PrestaShop 1.7 está muy personalizado, necesitarás reconstruir esas personalizaciones sobre el nuevo tema Hummingbird o sobre un tema compatible con PrestaShop 9. El tema Classic de 1.7 no es compatible directamente. Si vas a reconstruir sobre Hummingbird, aprovecha para cumplir de una vez los requisitos de accesibilidad WCAG en PrestaShop 9, que es donde el tema nuevo aporta más.

Tiempo de inactividad

Dependiendo del tamaño del catálogo y la complejidad de la tienda, la migración puede llevar desde unas horas hasta varios días. Planifica un período de mantenimiento adecuado y comunícalo a tus clientes con antelación.

¿Migrar a 9.2 ya o esperar?

Es la pregunta que nos llega más a menudo cuando sale una versión menor nueva, y la respuesta depende de dónde estés, no de la versión.

Si vienes de 1.7, la respuesta es clara: tu destino es la 9.2. No tiene ningún sentido planificar una migración de meses contra la 9.0 o la 9.1 cuando la rama 9.1 ya cerró su ciclo de funcionalidad con la 9.1.5 de agosto de 2026. Vas a tener que validar módulos y reconstruir overrides de todas formas; hazlo una sola vez contra la versión que vas a mantener.

Si ya estás en 9.0 o 9.1 y la tienda funciona, el cálculo es distinto. Subir de menor a menor dentro de la rama 9 es un proyecto pequeño comparado con el salto desde 1.7, pero sigue siendo un cambio que toca el core: hay que probarlo en staging igual. Lo que justifica hacerlo pronto es si alguna de las novedades de la 9.2 te ahorra desarrollo a medida. Dos casos concretos que vemos mucho: tiendas que pagaron un módulo de checkout de una página pueden valorar sustituirlo por el nativo, y tiendas que añadieron campos personalizados a producto o cliente con un módulo propio pueden plantearse migrarlos a Extra Properties y quitarse ese mantenimiento de encima.

Si sigues en PrestaShop 8, no tienes la urgencia de quien está en 1.7 — la 8.2 todavía recibe actualizaciones de seguridad, la última fue la 8.2.8 del 18 de agosto de 2026 — pero sí estás en una rama que es ya claramente la anterior. Es un buen momento para empezar a planificar sin prisa, que es la única forma en la que estos proyectos salen bien.

La decisión previa: actualizar, reconstruir o cambiar de plataforma

Antes de abrir el Update Assistant hay una decisión que casi nadie se plantea y que a veces ahorra la mitad del presupuesto: ¿tiene sentido arrastrar lo que tienes?

Una tienda 1.7 con ocho años de vida suele llevar encima módulos que ya no se usan, overrides escritos por tres agencias distintas, un tema parcheado y campos en base de datos que nadie sabe para qué son. Migrar eso es pagar por mover deuda técnica de sitio. En tiendas así, reconstruir sobre una instalación limpia de 9.2 e importar únicamente los datos que importan — catálogo, clientes, pedidos, URLs — sale a menudo más barato y siempre más limpio que una actualización in situ.

La regla aproximada que usamos: si al hacer el inventario de módulos y overrides descubres que vas a reescribir más de la mitad, deja de llamarlo migración y llámalo proyecto nuevo con importación de datos. El esfuerzo es parecido y el resultado es mucho mejor.

Y hay un tercer escenario que conviene nombrar aunque no sea el nuestro por defecto: si la conclusión del inventario es que PrestaShop ya no encaja con cómo trabajas, el momento de replanteárselo es este y no dentro de dos años. Tenemos documentada la ruta inversa — de WooCommerce a PrestaShop 9 — y una comparativa para elegir plataforma de ecommerce en 2026 que sirve exactamente para hacer esa pregunta con datos y no por intuición.

Cómo se reparte el presupuesto de una migración real

Cuando presupuestamos una migración de 1.7 a 9, el reparto del esfuerzo rara vez es el que el cliente espera. La parte técnica de mover el core y la base de datos — lo que hace el Update Assistant — es la menor.

Lo que concentra el trabajo es, por orden: la reconstrucción de los overrides y las personalizaciones del core, que es la partida más grande y la más difícil de estimar sin ver el código; la adaptación o sustitución de módulos incompatibles, donde el coste depende por completo de la suerte que tengas con los proveedores; la reconstrucción del tema si estaba muy personalizado; y el testing, que siempre se infraestima y es lo primero que se recorta cuando el proyecto se alarga, con las consecuencias previsibles.

Hay una partida que casi nunca aparece en el presupuesto inicial y que deberías exigir que esté: la verificación funcional con pedidos reales de prueba, con cada combinación de método de pago y método de envío que tu tienda ofrece. Es tedioso y no luce, pero es lo único que detecta el problema que de verdad duele, que es el pedido que no se puede completar.

Y una recomendación de gestión: no cierres el proyecto el día del go-live. Deja presupuesto reservado para las dos semanas siguientes, porque los incidentes que no aparecen en staging aparecen en producción con tráfico real.

SEO: qué hay que proteger en el salto

Una migración de versión no debería tocar tus URLs, y eso es precisamente lo que hay que verificar en lugar de dar por supuesto.

Lo que comprobamos siempre, antes y después: que la estructura de URLs amigables se mantiene idéntica (si cambia, hay que mapear redirecciones 301 una a una); que las meta tags y los textos SEO de productos y categorías han viajado completos; que el sitemap se regenera y declara las mismas URLs; que las etiquetas canonical siguen apuntando donde deben y no al dominio de staging, que es un error clásico y silencioso; y que no se ha colado un noindex global del entorno de pruebas.

Ese último punto merece un párrafo propio porque es el fallo más caro y más frecuente de todos: una tienda que pasa a producción con el robots.txt o la meta de robots del staging puede desaparecer de Google en días. Añádelo como paso explícito de la checklist de go-live, no como algo que alguien recordará.

Y aprovecha que vas a tocar el rendimiento: PrestaShop 9 es más rápido de serie, pero eso no arregla una tienda con 400 kB de CSS y sin caché bien configurada. La guía de optimización de rendimiento en PrestaShop cubre lo que conviene cerrar en la misma ventana de trabajo.

Los primeros 30 días después del go-live

La migración no termina cuando la tienda carga. Termina cuando una semana de datos reales confirma que todo se comporta igual o mejor que antes.

En los primeros días, vigila los logs de PHP y de la aplicación en busca de avisos nuevos, que suelen ser la pista temprana de un módulo que falla a medias. Compara el embudo de conversión y la tasa de abandono del carrito con el mismo periodo del mes anterior: una caída de conversión sin errores visibles casi siempre es un paso del checkout que se ha roto en algún navegador o en móvil. Revisa Search Console a los pocos días para detectar errores de rastreo y caídas de impresiones que delaten un problema de indexación.

También es el momento de cerrar la parte de seguridad, que una migración deja inevitablemente expuesta: contraseñas de administración rotadas, acceso al back office restringido, el entorno de staging apagado o protegido con autenticación, y los módulos ya actualizados a sus últimas versiones. Si quieres montar esto como rutina en lugar de como una tarea puntual, el enfoque está en nuestra guía de seguridad informática para pymes desde cero, y el marco formal de control de cambios en los controles técnicos de ISO 27001 para desarrollo seguro.

Preguntas frecuentes

¿Puedo saltar directamente de 1.7 a 9.2 o tengo que pasar por la 8?

El Update Assistant permite el salto directo y es el camino que recomendamos para la mayoría de tiendas: pasar por la 8 significa hacer dos migraciones, con dos rondas de validación de módulos. La excepción es una tienda muy grande o muy personalizada, donde partir el salto en dos reduce el riesgo de cada ventana de parada aunque aumente el esfuerzo total.

¿Cuánto dura una migración de 1.7 a 9?

La ventana de parada técnica va de unas horas a varios días según el catálogo. El proyecto completo, incluyendo inventario, reconstrucción de overrides, adaptación de módulos, tema y testing, se mide en semanas, no en días. Cualquiera que te dé un plazo sin haber visto tus módulos y tus overrides está adivinando.

¿Qué pasa con mis módulos de pago si el proveedor no ha sacado versión para 9?

Es el riesgo que hay que resolver antes de empezar, no durante. Confírmalo por escrito con el proveedor semanas antes de fijar la fecha. Si no hay versión y no hay fecha, las salidas son cambiar de pasarela, usar un módulo alternativo que soporte la misma pasarela, o encargar la adaptación — y las tres tienen plazo e implicaciones de certificación que no se improvisan en un fin de semana.

¿Se pierden los pedidos y los clientes históricos?

No, si se hace bien: el Update Assistant migra la base de datos completa. Pero «no se pierden» no es lo mismo que «se muestran correctamente»: hay que verificar que el historial de pedidos es accesible y consistente desde el back office nuevo, porque un pedido que existe en base de datos y no se renderiza en el panel es, operativamente, un pedido perdido.

¿Hace falta cambiar de hosting?

No necesariamente, pero sí hace falta que el hosting soporte PHP 8.1 como mínimo, una versión de MySQL o MariaDB con soporte, y que puedas tocar la configuración lo suficiente para dar 256 MB o más de memory_limit. Si tu proveedor actual no te deja subir de PHP 7.4, el cambio de hosting es parte del proyecto y conviene hacerlo antes, no a la vez.

Conclusión

Migrar de PrestaShop 1.7 a 9 no es una actualización, es un proyecto de desarrollo con una ventana de parada en medio. La parte que la herramienta hace sola — core y base de datos — es la menos problemática; el trabajo de verdad está en los overrides, los módulos de pago, el tema y el testing, y ninguna de esas cuatro cosas la resuelve el Update Assistant.

Si estás todavía en 1.7, el argumento para moverse no es tener la versión nueva: es dejar de trabajar sobre una base que ya no recibe parches de seguridad. Y el destino hoy es la 9.2, no la versión con la que empezaste a leer sobre esto.

La mejor inversión que puedes hacer antes de empezar es la menos vistosa: el inventario honesto de módulos, overrides y personalizaciones. De ese documento sale el presupuesto, el plazo y, a veces, la conclusión más útil de todas, que es que te conviene reconstruir en lugar de migrar.

Nuestra recomendación: no migrar solo

La migración de PrestaShop 1.7 a 9 es un proyecto técnico que requiere experiencia, planificación y conocimiento profundo tanto de la versión origen como de la destino. Los riesgos de una migración mal ejecutada —pérdida de datos, tienda offline, problemas de rendimiento, pérdida de SEO— pueden tener un impacto directo en la facturación.

En Keliam hemos migrado decenas de tiendas PrestaShop a lo largo de los años y conocemos los problemas más comunes antes de que aparezcan. Si estás planificando la migración de tu tienda, contacta con nuestro equipo para una evaluación técnica de tu caso particular.