Migrar PrestaShop 1.6 a 9: qué se migra y qué se rehace
De PrestaShop 1.6 no se pasa a la 9 con un botón: los datos se migran, pero el tema, los módulos y los overrides se rehacen. Explicamos los riesgos de quedarse en 1.6, los dos caminos posibles, cómo proteger las URLs y el SEO y cómo ensayarlo todo en una copia.
Migrar una tienda de PrestaShop 1.6 a 1.7, 8 o 9 no es una actualización: es trasladar los datos (productos, clientes, pedidos, categorías) a una instalación nueva y rehacer el tema, los módulos y los cambios a medida, porque los de la 1.6 no funcionan en las versiones actuales. Se prepara en una copia, se ensaya y se cambia en un día de poco tráfico.
Muchas tiendas siguen en 1.6 porque funcionan y porque cada vez que alguien pregunta por la migración la respuesta asusta. Este artículo explica qué implica de verdad, qué se puede aprovechar y qué no, y cómo hacerlo sin perder ventas ni posiciones en Google. Si tu tienda ya está en 1.7, el camino es otro y más corto.
Qué riesgo hay en seguir con PrestaShop 1.6
La rama 1.6 dejó de recibir mantenimiento hace años. Eso, en la práctica, significa:
- Sin parches de seguridad. Cada fallo que se descubre en el núcleo o en un módulo antiguo se queda abierto para siempre, y los ataques automatizados buscan precisamente esas tiendas.
- PHP sin soporte. La 1.6 solo funciona con versiones de PHP que ya no reciben actualizaciones. El hosting acaba retirándolas, y entonces la tienda deja de arrancar o te obliga a quedarte en un servidor viejo.
- Módulos abandonados. Pasarelas de pago, transportistas y conectores dejan de publicar versiones para 1.6. El día que tu banco cambia su sistema de cobro, puede que no haya módulo que lo soporte.
- Rendimiento y móvil. Los temas de la época no están pensados para los requisitos actuales de velocidad, y eso se nota en conversión y en buscadores.
Mientras preparas la migración, una tienda 1.6 se puede mantener con unas mínimas precauciones: copias diarias fuera del servidor, empleados revisados y con contraseñas únicas, módulos que no se usan retirados del disco, avisos de cambios en la configuración de pago y una vigilancia de errores. Es un parche para ganar tiempo, no una solución.
Por qué no hay un botón de 1.6 a 9
Entre la 1.6 y la 1.7 PrestaShop cambió casi todo lo que se ve y buena parte de lo que no se ve: el sistema de temas, la estructura de los módulos, el back-office (que empezó a migrar a Symfony) y la forma de enganchar código propio. Las versiones 8 y 9 siguieron esa línea y exigen versiones de PHP mucho más recientes.
Por eso un tema de 1.6 no se puede instalar en 1.7 o superior, y la mayoría de los módulos de 1.6 tampoco. El asistente de actualización oficial sirve para subir de versión dentro de un camino soportado, pero no convierte un tema ni reescribe un módulo. Lo que sí sobrevive es lo que está en la base de datos.
Qué se migra y qué se rehace
| Elemento | Qué pasa |
|---|---|
| Productos, combinaciones, categorías, marcas, proveedores | Se migran. Conviene revisar después precios con impuestos, imágenes y características. |
| Clientes y direcciones | Se migran. Las contraseñas antiguas pueden seguir valiendo si se conserva la clave de cifrado de la tienda original. |
| Pedidos, facturas y abonos | Se migran, con su numeración. Es lo que más cuidado pide, por la parte fiscal. |
| Páginas CMS y textos legales | Se migran, pero el HTML suele necesitar limpieza. |
| Tema | Se rehace: un tema nuevo o un tema hijo sobre uno actual, con tu diseño adaptado. |
| Módulos | Se sustituyen por versiones actuales del mismo fabricante o por alternativas. Sus datos propios a veces se pueden traer y a veces no. |
| Overrides y código a medida | Se revisan uno a uno: muchos sobran porque la versión nueva ya lo hace, y el resto se reescribe, mejor como módulo que como override. |
Dos caminos: actualizar por escalones o migrar los datos
Por escalones (1.6 → 1.7 → 8 → 9)
Se actualiza la instalación paso a paso con el asistente de actualización, cambiando la versión de PHP en cada escalón. Tiene sentido cuando la tienda está limpia, con pocos módulos y sin apenas cambios en el núcleo. En cada salto hay que comprobar que la base de datos ha quedado bien, y el tema y los módulos hay que sustituirlos igualmente.
Instalación nueva y migración de datos
Se instala la versión de destino desde cero, con su tema y sus módulos, y se traen los datos de la 1.6. Es el camino que suele salir mejor en tiendas con años de historia: no arrastra tablas de módulos que ya no existen, configuraciones olvidadas ni ficheros que nadie sabe para qué sirven. Exige preparar bien la correspondencia de datos y repetir la carga el día del cambio con los pedidos y clientes nuevos.
No hay una respuesta universal. Lo que decide es el estado de la tienda: cuántos módulos tiene, cuánto código a medida, cuánto se tocó el núcleo y cuántos datos hay.
URLs y SEO: lo que no se puede perder
- Lista de URLs actuales. Antes de tocar nada, saca todas las URLs que reciben visitas o enlaces: productos, categorías, CMS, marcas e imágenes si posicionan.
- Mismos identificadores y mismas URLs amigables siempre que se pueda. Si los patrones de URL cambian entre versiones, se ajustan para que coincidan o se preparan redirecciones 301.
- Metatítulos y descripciones migrados con los productos y las categorías, no regenerados.
- Idiomas: si la tienda es multiidioma, cada idioma conserva sus URLs y sus etiquetas de idioma alternativo.
- Después del cambio: rastrear la tienda nueva buscando errores 404, enviar el mapa del sitio y vigilar Search Console unas semanas.
Plazos y prueba en copia
Los plazos dependen del tamaño y del tema, pero el orden es siempre el mismo:
- Inventario: versión, módulos con su uso real, overrides, integraciones (ERP, marketplaces, transportistas) y tareas programadas.
- Copia de la tienda en un entorno de pruebas, protegido y sin indexar, con el correo desviado para no escribir a clientes reales.
- Montaje de la versión nueva con su tema y sus módulos, y primera carga de datos.
- Pruebas completas: registro e inicio de sesión de un cliente antiguo, pedidos con cada forma de pago en modo de pruebas, correos, facturas, transportistas, búsqueda y filtros.
- Ensayo del día del cambio, cronometrado, para saber cuánto tiempo estará la tienda en mantenimiento.
- Cambio: carga final de datos, redirecciones, cambio de dominio o de servidor y comprobación inmediata del checkout.
Saltarse el ensayo es lo que convierte una migración de un día en una semana de incidencias.
Cómo resolverlo en PrestaShop
En Rekire hacemos la migración y actualización de PrestaShop sobre una copia de tu tienda, nunca sobre producción: inventario, montaje de la versión nueva, carga de datos, revisión de URLs y ensayo antes del día del cambio. El trabajo se hace con bonos de horas: el bono de 20 horas de soporte PrestaShop sirve para el inventario y para tiendas pequeñas, y el bono de 50 horas para migraciones con más módulos o código a medida. Antes de empezar te decimos cuántas horas estimamos y solo se descuenta lo trabajado. Preguntar antes de que el hosting retire tu versión de PHP sale bastante más barato que migrar con prisa.
Preguntas frecuentes
¿Se puede actualizar PrestaShop 1.6 directamente a la 9?
No en un solo paso. O se sube por escalones pasando por las ramas intermedias, o se instala la 9 desde cero y se migran los datos. En los dos casos el tema y los módulos se sustituyen.
¿Pierdo los pedidos y los clientes al migrar?
No, si se hace bien: pedidos, facturas, clientes y direcciones se trasladan con sus identificadores. Lo que hay que comprobar es que los clientes antiguos pueden iniciar sesión y que la numeración de facturas sigue.
¿Es mejor ir a la 1.7 o directamente a la 8 o la 9?
Si vas a hacer el esfuerzo de rehacer tema y módulos, lo razonable es ir a una versión con soporte. La 1.7 también ha quedado atrás, y llegar a ella supondría volver a migrar en poco tiempo.
¿Cuánto tiempo está la tienda cerrada?
Depende del volumen de datos, pero si se ha ensayado, el corte suele ser de horas y en un momento de poco tráfico. El ensayo sirve justo para saber ese tiempo antes.