El propietario de una tienda que lleva diez o quince años con PrestaShop 1.6 (o incluso 1.5) suele llegar con el mismo cuadro: la tienda carga lenta, el panel de administración da errores intermitentes, el proveedor de hosting ha avisado de que va a retirar PHP 7.4, los módulos de pasarela de pago empiezan a fallar y la agencia de turno dice que "esto hay que rehacerlo de cero". Cada año que pasa aumenta el riesgo de que la tienda, directamente, no arranque tras la siguiente actualización del servidor.
Salir de 1.6 es posible en 2026 sin perder catálogo, pedidos, clientes ni posicionamiento. Pero no se hace con el instalador integrado, ni con el módulo 1-Click Upgrade del backoffice.
Lo que ya no funciona en 2026
PrestaShop 1.6 llegó a fin de vida oficial el 30/06/2018. Desde entonces no recibe parches de seguridad ni compatibilidad. La rama 1.7 recibió su último parche público en 2024 y arrastra las mismas limitaciones de arquitectura. Lo que ves hoy en una 1.6 funcionando es un parche artesanal sobre PHP 7.4 que el hosting mantiene por cortesía.
En paralelo, el ecosistema se ha movido. PrestaShop 8.x está en PHP 8.1 y 8.2, con Symfony 4 en la parte de backoffice migrada, Twig para las vistas nuevas, el tema Classic como tema por defecto y el módulo PS_Checkout como pasarela recomendada. PrestaShop 9.0, publicada en 2025, consolida el salto a Symfony y retira parte del código antiguo de Smarty en backoffice. Ninguno de estos cambios es cosmético: el tema de 1.6, los módulos override y los hooks personalizados no sobreviven al salto sin reescritura.
Los síntomas típicos que están empujando a actuar ahora: el hosting avisa de que retira PHP 7.4 o PHP 7.2 en una fecha concreta; Redsys, Stripe o PayPal han retirado el módulo antiguo o lo marcan como no soportado; Google Search Console reporta errores de rastreo o Core Web Vitals en rojo; el backoffice tarda diez segundos en abrir una ficha de producto; alguien intentó aplicar 1-Click Upgrade y la tienda se quedó rota.
Por qué el 1-Click Upgrade no es la respuesta
El módulo oficial 1-Click Upgrade existe y funciona, pero su rango útil es estrecho: saltos menores dentro de la misma rama (de 1.7.8.9 a 1.7.8.11, de 8.1.5 a 8.1.7). Intentar saltar de 1.6.1.24 directamente a 8.1 o a 9.0 desde el backoffice deja la base de datos en estado inconsistente: la tienda arranca, pero en el catálogo faltan asociaciones producto-categoría, las traducciones de 1.6 no cuadran con la nueva estructura de ps_lang, los hooks personalizados se duplican o se pierden, y el checkout falla al calcular transportistas.
El motivo técnico es que la estructura de la base de datos cambia entre generaciones. Tablas como ps_customization_field_lang, ps_cart_rule_combination o la gestión de ps_configuration para claves nuevas de Symfony no existen en 1.6. El migrador automático trata de rellenar, pero no sabe qué hacer con las columnas custom añadidas por módulos antiguos.
La vía correcta para pasar de 1.6 a 8.x o 9.x es Rebuild and Data Migration: instalación limpia de la versión destino en un dominio de desarrollo, migración controlada de datos desde la base antigua con scripts SQL por entidad, verificación, y conmutación.
Cuánto cuesta en tiempo real
Para una tienda típica española de 500 a 2 000 SKUs, con pasarela Redsys o PS_Checkout, dos o tres transportistas (SEUR, MRW, Correos Express), módulos de facturación integrada y un tema personalizado heredado de 1.6, el trabajo serio se mueve en el rango de 60 a 120 horas de ingeniería: instalación limpia de la rama destino y configuración base; adaptación o reconstrucción del tema sobre Classic; reinstalación y configuración de módulos actuales (pasarela, transporte, facturación, SEO); scripts SQL de migración por entidad (productos, categorías, atributos, combinaciones, clientes, direcciones, pedidos, carritos abandonados, reglas de carrito, páginas CMS, URLs amigables); mapa de redirecciones 301; SEO técnico 2026 (Schema.org en JSON-LD, hreflang si procede, canonical, sitemap limpio); pruebas de checkout extremo a extremo con pasarela en modo sandbox; y conmutación en ventana de bajo tráfico con dos semanas de soporte post-corte.
La vía automatizada con módulos de terceros tipo Cart2Cart o migradores "en un clic" cuesta formalmente unos pocos cientos de euros, pero el resultado requiere entre dos y seis semanas de corrección manual posterior. En coste total, "automatizar y rezar" sale casi siempre más caro que un Rebuild honesto.
8.x o 9.x: cuál tiene sentido en 2026
Ambas ramas están activas.
PrestaShop 8.2.x es la elección pragmática cuando el stack de módulos es grande y maduro. La mayoría de módulos de pago, transporte y facturación españoles tienen versión estable para 8.x; algunos aún no han publicado versión para 9.0. Funciona en PHP 8.1 y 8.2. Es la versión con más documentación concreta y más desarrolladores con experiencia práctica en 2026.
PrestaShop 9.0 tiene sentido cuando toca rehacer de verdad. Si el plan incluye reescribir el tema desde cero, auditar módulos uno por uno y aceptar que algunos de pago hay que esperarlos o reemplazarlos, 9.0 deja mejor posicionada a la tienda para los próximos cinco años. El backoffice está más migrado a Symfony, Smarty queda relegado al front, y el soporte de PHP 8.2 y posteriores es nativo.
No recomiendo 1.7.8.x como destino en 2026. Es la última rama 1.x, su ciclo de parches de seguridad va a cerrar pronto y obliga a repetir la migración en dos años.
El orden del trabajo
El trabajo arranca con una auditoría técnica. Se revisa la versión exacta de PrestaShop, PHP, MySQL o MariaDB, el listado de módulos activos, qué overrides hay en /override/, qué modificaciones directas al core existen (en 1.6 era habitual), el estado del tema, el estado del SEO, Core Web Vitals y las pasarelas de pago activas. En cinco días hábiles sale un informe por escrito con lo que se ha encontrado, qué es crítico, qué versión destino encaja con el caso concreto y presupuesto estimado. Precio fijo de auditoría: 290 €.
A continuación se hace el escaneo de URLs y la copia dev. Se rastrean todas las URLs vivas de la tienda (categorías, productos, páginas CMS, fabricantes, etiquetas) para la tabla base del mapa 301. En paralelo se levanta una copia de desarrollo de ficheros y base de datos en un dominio aparte. La tienda en producción no se toca.
Después viene la instalación limpia y la migración de datos. En dev se instala 8.2 o 9.0 en estado limpio y se hace la transferencia entidad por entidad: productos y combinaciones, categorías, atributos y características, grupos de clientes, clientes, direcciones, histórico de pedidos, reglas de carrito, páginas CMS, bloques de contenido. Cada entidad va con un script SQL o export intermedio documentado. No hay herramienta oficial fiable para saltos de 1.6 directa a 8.x o 9.x; los servicios cloud tipo Cart2Cart y LitExtension exigen revisión manual pieza a pieza.
Con los datos ya en dev se abordan módulos, tema y SEO técnico. Cada módulo se trata individualmente: se reinstala la versión actual para la rama destino, se migra la configuración y se verifica. El tema se adapta desde Classic a la marca de la tienda (colores, logo, tipografías, estructura de bloques) o se construye el diseño aprobado desde cero sobre Classic con Core Web Vitals en mente. SEO técnico a estándar 2026: canonical, hreflang si hay versiones de idioma, sitemap limpio, robots.txt configurado para rastreadores de IA (OpenAI, Perplexity, Google Extended) y marcado Schema.org en JSON-LD para producto, oferta, organización y breadcrumb.
Para cerrar, mapa 301 y conmutación. La estructura de URLs amigables cambia entre 1.6 y 8.x/9.x en varios puntos (prefijos, inclusión del ID en la URL por configuración, estructura de categorías anidadas). Sin mapa 301 explícito en Nginx o Apache las posiciones caen. La conmutación DNS se hace en ventana de bajo tráfico (típicamente martes de 03:00 a 05:00) con dos semanas de soporte post-corte.
Los puntos donde más tiendas se parten
El tema. En 1.6 los temas usan Smarty 2/3 con una estructura de carpetas que no existe en 8.x ni 9.x. En 8.x el tema Classic se apoya en Bootstrap 4 y Twig para el checkout; en 9.0 esto sigue consolidándose. No hay compatibilidad directa: el product.tpl de 1.6 no se abre. Rehacer el tema partiendo de Classic sale casi siempre más barato que intentar portar el antiguo.
Los overrides. En /override/classes/, /override/controllers/ y /override/modules/ suelen vivir diez años de ajustes. Cada override hay que leerlo, entenderlo, decidir si sigue siendo necesario, y reimplementarlo correctamente en 8.x o 9.x. Muchos overrides de 1.6 están resolviendo problemas que las versiones actuales ya resuelven de serie: no se migran, se descartan.
Los módulos de pasarela. Redsys tiene módulo oficial actualizado para 8.x. PS_Checkout cubre tarjeta y PayPal con una sola instalación y es la vía recomendada por PrestaShop. Stripe tiene módulo propio mantenido. Los módulos antiguos de bancos (La Caixa, BBVA TPV virtual en versiones de 2015) suelen estar sin mantenimiento: hay que reemplazarlos por Redsys unificado o PS_Checkout.
Las URLs amigables. La configuración PS_REWRITING_SETTINGS, el formato de URL de producto (con o sin ID, con o sin categoría padre) y el comportamiento de categorías anidadas cambian de una rama a otra. Sin mapa 301 explícito, Google trata todo como páginas nuevas, las antiguas desaparecen del índice y la recuperación tarda tres a seis meses.
La factura y el cumplimiento normativo. Si la tienda emite facturas desde PrestaShop, cualquier migración en 2026 tiene que contemplar Verifactu. La obligación entra el 01/01/2026 para empresas (sociedades) y el 01/07/2026 para autónomos. El sistema de facturación elegido en el nuevo PrestaShop debe estar preparado para el envío a la AEAT en el formato y plazos que exige el reglamento. Esto se trata en detalle en la guía Verifactu, pero conviene decidir el módulo de facturación antes de la migración, no después.
Preguntas frecuentes
¿Se puede quedar la tienda en 1.6 un año más? Técnicamente la tienda puede seguir funcionando mientras el hosting mantenga PHP 7.x. El riesgo real no es que deje de arrancar: es que una vulnerabilidad conocida sin parche se explote, o que la pasarela de pago retire el módulo. Cada mes añade exposición.
¿Se pierden las posiciones de Google? Con auditoría, mapa 301 y SEO técnico limpio, la caída es temporal (dos a seis semanas) y se recupera. Sin esos tres elementos, las posiciones pueden tardar seis meses en volver, y algunas no vuelven.
¿Se puede migrar en interno? Con un desarrollador senior de PrestaShop en plantilla y tiempo dedicado, sí. Si el plan es "la agencia que montó la tienda hace diez años lo mirará cuando pueda", no. La migración 1.6 a 8.x o 9.x no es un trabajo de ratos sueltos.
¿Qué pasa con el histórico de pedidos? Se migra. Clientes, direcciones, pedidos, estados, facturas emitidas y notas de crédito pasan a la tienda nueva. Es parte del alcance estándar del Rebuild.
¿Y si tiene más sentido cambiar de plataforma? Es una decisión legítima y se trata en el artículo de migración a Shopify. El marco de decisión está ahí; no es la respuesta por defecto.
Qué hacemos nosotros
Oficio eCommerce es un taller de rescate y modernización de tiendas antiguas en PHP, con PrestaShop como foco. Soy Serhii Bulak y llevo desde 2009 con tiendas en PHP; he visto todas las ramas de PrestaShop desde 1.4 hasta 9.0, y conozco los puntos exactos por donde se parten las migraciones.
Trabajo solo, con proyectos pequeños y claros, y empiezo siempre por la auditoría de 290 €: cinco días hábiles, informe por escrito, decisión informada. A partir de ahí presupuesto fijo para el Rebuild.
Para una tienda en 1.6 o en una 1.7 antigua, el momento razonable para actuar es ahora, antes de que el hosting fuerce la mano o Verifactu llegue sin facturación compatible.