Actualizar PrestaShop sin perder pedidos: plan seguro

Elige entre actualización y migración antes de tocar la tienda

La primera decisión es el método. La documentación de PrestaShop distingue una actualización de una migración. Una actualización modifica una instalación existente y busca conservar su información y configuración dentro de la ruta admitida. Una migración prepara una tienda nueva y transfiere los datos necesarios; puede ser preferible ante un salto importante de versión o cuando arrastrar personalizaciones y dependencias antiguas añade más riesgo que reconstruirlas.

No existe una respuesta universal basada solo en el número de versión. El tema, los módulos, la versión de PHP, los cambios realizados sobre el núcleo, las integraciones y la calidad de los datos condicionan el camino. La documentación oficial advierte además que una migración no conserva automáticamente todos los elementos. Permisos, cuentas de empleados u otras configuraciones pueden necesitar una recreación y una validación expresa.

Antes de elegir se prepara una copia de la tienda y un inventario. PrestaShop separa el respaldo de archivos —núcleo, tema, módulos e imágenes— del respaldo de la base de datos, donde residen clientes, pedidos, productos y configuración. Ambos forman una unidad. Tener solo uno puede impedir una restauración coherente, y tener los dos no demuestra que la recuperación funcione si nunca se ha ensayado.

Update Assistant puede guiar una actualización y facilitar copia y restauración. Es una herramienta, no el criterio de aceptación. La empresa debe seguir sabiendo qué versión de origen se ha respaldado, dónde están los ficheros, quién puede restaurarlos y qué prueba confirma que el resultado contiene los pedidos y configuraciones esperados. Si la ruta requiere una tienda nueva, la propuesta debe llamarla migración y describir qué se transfiere y qué se reconstruye.

La decisión se documenta con alternativas. Para cada opción se anota compatibilidad conocida, elementos que no se conservan automáticamente, tiempo de indisponibilidad previsto por el proyecto, forma de tratar los pedidos creados durante la preparación, pruebas y reversión. El plazo y la ventana no se inventan: se obtienen después del inventario y de un ensayo representativo.

Inventaría tema, módulos, integraciones y datos que deben sobrevivir

El inventario empieza por los componentes ejecutables. Incluye versión de PrestaShop y PHP, tema y tema hijo, módulos, overrides, tareas programadas, conectores, código propio y cambios sobre el núcleo. Para cada elemento se registra fabricante o responsable, versión, licencia, función, compatibilidad declarada y decisión: conservar, actualizar, sustituir, reescribir o retirar. Un módulo que parece accesorio puede intervenir en precios, transportistas o impuestos y bloquear el pedido al desaparecer.

Después se dibuja el recorrido comercial. Un cliente busca un producto, aplica una promoción, calcula impuestos y transporte, paga, recibe mensajes y puede pedir una devolución. El almacén prepara el envío; el ERP o el software de gestión recibe datos; contabilidad y atención al cliente consultan el pedido. La migración debe identificar qué módulo o integración participa en cada paso y qué resultado permite darlo por válido.

Los datos necesitan su propio catálogo. Productos, combinaciones, categorías, imágenes, clientes, direcciones, consentimientos, carros, pedidos, facturas, abonos, devoluciones, stock, reglas de precio, cupones y contenidos no tienen la misma criticidad ni la misma forma de comprobarse. Se acuerdan recuentos y relaciones: no basta con que existan cien pedidos si faltan sus líneas, estados, impuestos o documentos asociados.

También se identifican datos que cambian mientras se prepara la nueva tienda. Si el ensayo utiliza una copia del lunes y producción sigue vendiendo hasta el corte, aparecerán nuevos clientes, pedidos, movimientos de stock y cambios de catálogo. El plan debe definir el delta que se volverá a transferir, el momento de congelación y quién concilia lo ocurrido entre ambas capturas. Mantener producción abierta sin esa respuesta crea una pérdida silenciosa, aunque la importación inicial sea correcta.

Este inventario evita confundir «migrar todo» con una obligación verificable. Lo que queda fuera se escribe: historiales no transferidos, módulos sin soporte, cuentas que se recrearán, contenidos que se retirarán o integraciones que requieren otro proveedor. La transparencia permite decidir antes del corte y no cuando el equipo descubre el hueco en producción.

Ensaya pedidos, pagos, impuestos y SEO en una copia representativa

El ensayo debe utilizar una copia aislada y suficientemente parecida a producción. Incluye versiones, módulos, tema, configuración, volumen de datos y conexiones simuladas o de prueba. No se reutilizan credenciales reales de pago ni se envían correos a clientes. Los servicios externos se configuran en sandbox cuando exista o se sustituyen por dobles controlados que permitan observar el intercambio sin ejecutar operaciones reales.

Las pruebas recorren casos completos, no pantallas sueltas. Se comprueba un producto simple y uno con combinaciones, cliente nuevo y existente, invitado cuando aplique, promociones, impuestos, zonas, transportistas, stock, diferentes formas de pago, cancelación, devolución y emisión de documentos. También se prueba el error: pago rechazado, transportista sin tarifa, llamada al ERP que expira o reintento de un evento. El objetivo es comprobar que el sistema falla de forma conocida y recuperable.

El cambio de versión puede alterar el comportamiento aunque la interfaz parezca igual. La pregunta es qué debe quedar demostrado antes de abrir la tienda. Se comparan importes, estados, referencias e identificadores entre origen y destino. Las integraciones se validan en ambos sentidos y se revisan colas, registros y alertas. Un pedido visible en el back-office no demuestra que haya llegado al almacén, ni una respuesta correcta del ERP garantiza que no se haya creado dos veces tras un reintento.

El rendimiento se observa con recorridos representativos y bajo las condiciones que soportará producción. No se promete que una versión nueva sea más rápida por definición. Se registran páginas críticas, tiempos de servidor, errores y consumo antes y después en el mismo entorno de prueba. Si el cambio de tema o módulos altera imágenes, JavaScript o caché, la comprobación debe incluir móvil y las plantillas con más uso.

El SEO se trata como parte del corte. Si cambian direcciones, Google recomienda un mapa de cada URL antigua a su destino relevante y redirecciones permanentes del lado del servidor. No se envían todas las páginas a la portada. En la nueva tienda se revisan canonical, reglas noindex, enlaces internos y sitemap. Si las URL no cambian, se conserva igualmente la comprobación de títulos, contenido, paginación, filtros y códigos de estado para detectar regresiones del tema o la configuración.

La aceptación reúne resultados y responsables. Comercio valida catálogo, precios y promociones; operaciones confirma stock y preparación; administración revisa impuestos y documentos; tecnología comprueba integraciones, alertas, copias y seguridad. Una demostración del proveedor ayuda a explicar el cambio, pero no sustituye la aceptación de quienes ejecutan el proceso real.

Programa el corte, el delta de pedidos y una reversión verificable

El plan de corte ordena tareas, propietario, duración observada en el ensayo, dependencia y verificación. Incluye aviso interno, modo mantenimiento cuando corresponda, última copia, exportación o sincronización del delta, cambio de código o infraestructura, actualización de DNS solo si el proyecto lo exige, pruebas rápidas, apertura y vigilancia. La ventana se calcula con el ensayo; no se adopta una duración genérica de otra tienda.

El tratamiento de pedidos merece una decisión visible. Se fija la hora del último pedido aceptado en el origen, se extraen los registros creados o modificados desde la copia inicial y se importan o concilian según el método acordado. Después se comparan identificadores, importes, estados, clientes, facturas y movimientos de stock. Si el origen sigue recibiendo operaciones tras el punto de corte, se detiene la apertura o se repite el delta; la convergencia de ambos sistemas debe comprobarse.

La reversión indica hasta qué momento es posible volver y qué ocurrirá con los datos creados en la nueva tienda. Restaurar la copia puede recuperar la plataforma anterior y perder pedidos posteriores si nadie los conserva. Por eso el punto de no retorno se vincula a una verificación de datos y a un procedimiento para exportar o reproducir las operaciones nuevas. La copia se considera útil cuando una restauración ensayada cumple el tiempo y la integridad que el negocio necesita.

Tras abrir, se ejecutan casos de humo: navegación, búsqueda, producto, carro, cálculo, pago controlado, mensajes, back-office e integración principal. Se supervisan errores, colas, pagos pendientes, pedidos sin sincronizar y respuestas de terceros. La tienda anterior, sus accesos y las reglas temporales no se eliminan hasta cerrar la aceptación y la retención acordada. Después se actualizan inventario, documentación, copias, monitorización y procedimiento de mantenimiento.

Una propuesta seria separa el alcance de la actualización, la adaptación de módulos PrestaShop a medida, el posible desarrollo de la tienda online y el trabajo de proveedores externos. No promete compatibilidad antes de revisar versiones ni confunde una copia con una recuperación demostrada.

Élite Solutions Tech puede ayudar a inventariar la tienda, comparar actualización y migración, preparar pruebas y concretar entregables desde Murcia. Para una primera valoración puedes indicar versión, tema, módulos e integraciones en el formulario de contacto, sin enviar credenciales ni bases de datos.