Migrar de 1.7.8 a 8 copiando la base de datos: los tropiezos

Un compañero estaba pasando una tienda de PrestaShop 1.7.8 a la 8 a mano: tienda nueva con un tema hecho a medida y los datos copiados tabla a tabla, con ayuda de la IA para arreglar los INSERT. Por el camino se encontró con los tropiezos típicos de este método. Los contamos con lo que le respondieron en el grupo, sobre todo Gustavo.

1. Exportar desde el listado no sirve

Lo primero que probó fue exportar los productos desde el listado del back-office e importarlos en la nueva. Errores por todas partes y campos que faltaban. Gustavo: esa exportación no sirve para migrar; hace falta un módulo o consultas SQL.

2. La columna que ya no existe

Al pasar la tabla de pedidos, la 1.7.8 tenía una columna shipping_number que en la 8 no está (el script de actualización a la 8.0.0 la elimina), y el INSERT fallaba con miles de registros. Hubo dos salidas:

• La de Gustavo, práctica: añadir esa columna a la tabla de la 8. No se usa, no rompe nada y la importación entra tal cual.
• La de otra compañera: exportar con un SELECT que nombre solo las columnas que existen en el destino. El número de seguimiento vive en order_carrier.tracking_number.

Si importas la tabla antigua a una tabla auxiliar, la segunda opción queda así:

INSERT INTO ps_orders (id_order, reference, id_shop_group, id_shop, id_carrier, id_lang, ...)
SELECT id_order, reference, id_shop_group, id_shop, id_carrier, id_lang, ...
FROM old_orders;

Los puntos suspensivos son el resto de columnas comunes: compáralas con SHOW COLUMNS en las dos bases de datos.

3. Imágenes de categoría que no salen

Algunas categorías se quedaban sin imagen en la tienda nueva. En img/c estaban las miniaturas (356-small_default.jpg) pero no la original (356.jpg), y sin la original PrestaShop no puede regenerar nada. Otra compañera había visto lo mismo: el dueño de una tienda borraba ficheros grandes para no tener que ampliar el hosting. Solución: volver a subir esas imágenes o, si no hay original, copiar la miniatura más grande con el nombre de la original, sabiendo que se pierde calidad.

4. Los datos que entran mientras migras

Es el problema de fondo de este método. Pasan semanas entre la copia y la puesta en producción, y en la tienda vieja siguen entrando pedidos, clientes y carritos. ¿Cómo se traen?

• Gustavo: exportar las tablas de producción con INSERT IGNORE (y CREATE TABLE IF NOT EXISTS). Al importar en la nueva entran las filas que no están y se ignoran las que ya existen. Después se pone la nueva en producción, ficheros y base de datos, y se ajustan shop_url y todos los enlaces del subdominio.
• El matiz importante: INSERT IGNORE decide por la clave primaria (el id). Tampoco actualiza las filas que ya tenías: si un pedido copiado cambió de estado después en producción, en la nueva se queda como estaba. Si en la tienda nueva hiciste pedidos o clientes de prueba, sus id chocan con los reales que han entrado después en producción, y se descartan los reales. Vacía los datos de prueba antes.
• La alternativa de Rekire: vaciar la tienda nueva y pasar los datos con un módulo de migración que permita sincronizar, para repetir el proceso justo antes del cambio.

¿Actualizar o migrar?

En septiembre volvió el debate: instalación limpia más migración de datos, o el asistente de actualización oficial. La regla de Gustavo: desde 1.7.6, actualizar; antes de esa versión, migrar. Él ha actualizado tiendas de 1.7.6 a 8 sin problemas. Al compañero que preguntaba lo que más guerra le daba eran los overrides: ni activándolos ni desactivándolos se arreglaba. Toca revisarlos uno a uno.

Si prefieres que lo hagamos nosotros, en Rekire las actualizaciones y migraciones suelen ir dentro del bono de 50 horas.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación