Lista de comprobación para migrar y actualizar a PrestaShop 9

Qué haríamos

Para una tienda PrestaShop 1.7 u 8 adecuada, con módulos mantenidos y pocos cambios, primero probaríamos a actualizar una copia de pruebas. Para una tienda 1.6, un tema sin soporte o muchos cambios a medida, normalmente empezaríamos evaluando una instalación nueva de PrestaShop 9 con una migración de datos mapeada. Una reconstrucción es una vía que evaluar, no un requisito automático para toda tienda personalizada: una integración que falla a menudo puede adaptarse o sustituirse por separado, como muestra el ejemplo de abajo.

El PrestaShop Upgrade Service empieza con una comprobación gratuita de versión, PHP, alojamiento, tema y módulos, ofrece un presupuesto fijo por escrito antes de empezar y trabaja en pruebas mientras la tienda en producción sigue recibiendo pedidos; pasar desde 1.6 es una migración con un presupuesto superior.

Antes de aprobar cualquiera de las dos vías, pide los resultados de compatibilidad, el alcance de los datos, las comprobaciones de aceptación y el plan de reversión.

Elige un destino con soporte y una vía adecuada para tu tienda

Una migración a una versión principal de PrestaShop puede cambiar PHP, componentes del framework, páginas de administración, temas y puntos de extensión. Inventaría la tienda exacta antes de elegir una actualización o una reconstrucción. Mantén una lista escrita de aceptación y un punto de decisión para revertir.

A fecha de 26 de octubre de 2026, PrestaShop 9.2 está disponible. Elige una versión de destino parcheada que admitan tus proveedores de pagos, envíos, tema e integraciones. Una tienda que sigue cargando puede, aun así, estar fuera del mantenimiento de software.

El mantenimiento oficial de PrestaShop 1.6 terminó el 30 de junio de 2019; el trabajo voluntario posterior fue una iniciativa aparte. Consulta el aviso de mantenimiento y la explicación del mantenimiento voluntario. El mantenimiento ordinario de 1.7 terminó con el lanzamiento de 9.0.

El actualizador de la primera etapa de 1.6 no tiene mantenimiento. Ensáyalo de forma aislada y conserva una instantánea en cada etapa. Una reconstrucción limpia es otra opción, no una prueba de que actualizar por etapas sea técnicamente imposible. Consulta las vías oficiales de Update Assistant.

Sea cual sea la vía que evalúes, lo que decide si es viable es el proceso de compra, la preparación de pedidos y la recuperación en pruebas. Una copia que arranca y muestra el catálogo todavía no ha superado la evaluación.

La preparación reduce el riesgo, pero no puede excluir defectos ni fallos de infraestructura. No prometas una duración fija de la actualización, un tiempo de inactividad ni una recuperación del posicionamiento a partir del número de módulos o del tamaño del catálogo, y no elijas una vía por una promesa de compatibilidad universal.

Ejemplo: conserva la tienda, sustituye el obstáculo

Supón que una tienda PrestaShop 8 tiene un tema mantenido y herramientas de catálogo que funcionan, pero su conexión a medida con un transportista falla en el destino propuesto. Pide al desarrollador que aísle esa conexión, establezca sus requisitos de datos y etiquetas y pruebe una adaptación o sustitución en pruebas. Ese hallazgo por sí solo no justifica reconstruir todo el catálogo. En cambio, una tienda 1.6 con un tema sin soporte, cambios directos en el núcleo y una conexión de stock sin documentar necesita una comparación presupuestada de ambas vías antes de empezar.

Exige la vía elegida por escrito. Para una actualización, es la secuencia por etapas que indica el origen, el actualizador, el destino y el entorno PHP de cada etapa, además del punto de control desde el que puede restaurarse cada etapa (consulta la sección de compatibilidad de PHP más abajo). Para una instalación nueva, es el mapa de datos y el procedimiento de transferencia final (consulta la sección de la tienda limpia más abajo).

Identifica la versión en ejecución y los requisitos del servidor

Lee la versión de la tienda en ejecución en el pie del back office o en Parámetros avanzados > Información. Confirma que estás en producción y no en una copia antigua de pruebas. La versión de un módulo no es la de la tienda.

La antigua 1.6 suele definir _PS_VERSION_ en config/settings.inc.php. PrestaShop 1.7/8 expone la versión de la aplicación en app/AppKernel.php. En PrestaShop 9.1, esa clase delega VERSION en src/Core/Version.php. Trata un archivo copiado como una pista, no como prueba de un despliegue completo.

En código con la tienda ya inicializada, usa _PS_VERSION_ y version_compare() para comprobar la compatibilidad. Registra la versión PHP web además de PHP CLI, extensiones, límites, versión de base de datos, tema activo y versiones de módulos.

php -v
php -m
php -i | rg 'memory_limit|max_execution_time'
# Run through the actual database connection:
# SELECT VERSION();

mysql --version informa del binario cliente, no necesariamente del servidor conectado. SELECT VERSION() identifica el servidor al que llega esa conexión. PHP CLI también puede diferir del pool PHP-FPM que sirve la tienda.

PrestaShop 9 documenta una recomendación de memoria de 512M por script. Proporciona margen adicional medido para actualizaciones grandes y trabajos PDF o de importación. Comprueba CURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO/MySQL, SimpleXML y Zip, además de la configuración de ejecución necesaria. Consulta los requisitos del sistema.

Las versiones empaquetadas de producción contienen las dependencias. Composer y las herramientas de compilación frontend son necesarios para flujos de compilación desde el código fuente, no para cada actualización empaquetada.

Comprueba por separado la compatibilidad de la base de datos y el mantenimiento del proveedor. MySQL 8.0 entró en Sustaining Support en abril de 2026; no lo trates como destino automático para nuevas instalaciones. Elige una versión mantenida compatible con la tienda exacta y la pila de alojamiento, y prueba su comportamiento SQL. Consulta los avisos del ciclo de vida de MySQL.

Planifica la compatibilidad de PHP en cada etapa

Lo siguiente es un mapa de compatibilidad, no una recomendación de exponer versiones antiguas de PHP públicamente:

Usa la matriz antigua, la matriz de PrestaShop 8 y los requisitos de 9.2 para el origen y el destino exactos.

PHP 7.4 llegó al final de su vida útil el 28 de noviembre de 2022; el soporte de seguridad de PHP 8.1 terminó el 31 de diciembre de 2025. Comprueba las ramas PHP con soporte y la lista de versiones sin soporte. La compatibilidad no hace que un entorno antiguo sea adecuado para un nuevo despliegue público.

1. Registra los requisitos de PHP de la tienda de origen, el actualizador, las fases de actualización y el destino, incluido el entorno que ejecuta las importaciones y otras tareas programadas.
2. Elige una vía directa de 1.7 a 9 solo cuando la versión exacta de Assistant y el destino superen las comprobaciones previas y hayas ensayado cada fase con PHP compatible. El origen y el destino no tienen una versión PHP común con soporte general; no eludas los requisitos ni des por hecho un cambio automático de entorno.
3. Si esa vía no puede completar el traspaso con fiabilidad, elige una vía intermedia probada o una migración limpia.
4. Una etapa opcional de 1.7.8 a 8.2 puede ejecutarse con PHP 7.4; 8.2 puede ejecutarse después con PHP 8.1 para una transición probada a 9. Mantén aislados y temporales esos entornos intermedios sin soporte.
5. Tras alcanzar el destino, cambia a la versión PHP mantenida elegida que admita toda la pila y vuelve a probar.

No cambies una instalación 1.7 en producción a cualquier PHP 8 solo porque el alojamiento lo ofrezca, ni para averiguar si la instalación antigua arrancará: compruébalo en pruebas. Mantén alineados el entorno web, CLI y las tareas programadas. Revierte solo PHP únicamente cuando los archivos de la aplicación y la base de datos restaurados también sean compatibles.

Audita módulos, código personalizado e integraciones

Crea un inventario desde el Gestor de módulos y el sistema de archivos desplegado. Registra nombre del módulo, versión, proveedor, finalidad, asociaciones de tiendas, configuración, titularidad de datos, tareas programadas y endpoints externos. Para cada elemento, elige una actualización compatible, sustitución, eliminación o trabajo de migración explícito.

Prioriza pagos, proceso de compra, transportistas, impuestos, facturación, ERP/PIM, stock, feeds y email. Que cargue el catálogo no demuestra que puedas aceptar y preparar pedidos.

• Lee los rangos de PrestaShop y PHP que declara cada módulo y sus restricciones de dependencias. Pide a los proveedores de temas y módulos que confirmen el soporte para el destino y la versión PHP exactos y después prueba esa afirmación con tu configuración.
• Revisa los overrides personalizados, las plantillas copiadas, los controladores a medida, los endpoints de cron, los clientes de API, las URL de callback y las rutas de administración escritas a mano en el código. Incluye los cambios hechos directamente en archivos del núcleo o de módulos.
• Comprueba las API eliminadas y las traducciones frente al destino exacto y reproduce después cualquier fallo.
• Usa enlaces o rutas de back office generados en vez de concatenar nombres de directorio y tokens.
• Prueba las claves Webservice y los clientes y ámbitos de Admin API más recientes como integraciones independientes.
• Nombra al responsable de cada integración que pueda facilitar credenciales de sandbox, casos de prueba y soporte en el lanzamiento.

PrestaShop 8 usa Symfony 4.4; 9 usa Symfony 6.4. Las páginas de administración modernas usan Twig y Symfony, mientras que los controladores antiguos conservan vías de compatibilidad. No puede darse por hecho que el ciclo de renderizado o el override de plantilla de un controlador antiguo controle una página migrada.

Tools::displayPrice() se elimina en 9. Usa formatPrice($amount, $currencyIsoCode) de la configuración regional actual en el contexto adecuado. Revisa individualmente las llamadas antiguas de traducción de administración y los métodos antiguos del ciclo de vida en vez de imponer una receta universal de asignación de constructor o propiedad.

Prefiere hooks admitidos, suscriptores de eventos y decoración de servicios Symfony cuando proceda. Los overrides de clases antiguas siguen existiendo para las clases pertinentes, pero pueden entrar en conflicto y necesitan comprobar las firmas. Audita los parámetros de hooks, su ejecución y el marcado de la tienda con el tema elegido. Consulta la guía de estructura del código.

Actualiza los módulos en pruebas en un orden controlado. Haz copia de los datos antes de desinstalar o restablecer nada. Desactiva mediante el Gestor de módulos o la acción admitida prestashop:module disable con el contexto de tienda previsto. Actualizar solo module.active no gestiona correctamente las asociaciones de tiendas.

Qué preguntar a tu desarrollador o agencia

• ¿Qué módulos esenciales tienen una versión compatible probada y cuáles dependen de un desarrollo sin presupuestar o de una licencia nueva?
• ¿Qué cambios existen solo en los archivos desplegados, en lugar de en el paquete del proveedor o el repositorio de código fuente?
• ¿Quién probará pagos, transferencias de stock, etiquetas y exportaciones contables con sus respectivos proveedores?
• ¿Qué entorno atiende las solicitudes del navegador y cuál ejecuta importaciones y otras tareas programadas?
• ¿Qué pruebas demostrarán que el trabajo está completo y quién decide si una comprobación fallida bloquea el lanzamiento?

Conserva las respuestas junto al inventario. Marca un proveedor desconocido o una integración sin documentar como una dependencia sin resolver, con una persona designada para investigarla.

Si usas nuestros módulos, Module Updates & Remote Assist muestra las versiones instaladas y las actualizaciones disponibles para tu licencia y te permite elegir instalaciones y actualizaciones en el back office. No sustituye la copia completa y coherente de la tienda ni el ensayo de restauración que se describen abajo.

Crea copias coherentes y ensaya en pruebas

Antes de cambiar versiones, esquema, módulos o temas, haz una copia de seguridad de toda la tienda y de su base de datos correspondiente y anota cómo volver a la instalación original. Incluye los archivos ocultos, los medios subidos, los módulos, los datos de los módulos, las personalizaciones del tema y la configuración. Guarda la configuración del servidor web y de PHP-FPM, los ajustes SMTP, las credenciales de pago, las URL de webhooks, las tareas programadas y las reglas de la CDN en un registro operativo protegido.

El siguiente ejemplo presupone una ruta de acceso MySQL protegida llamada shop-backup y un directorio de copias restringido ya existente. Elige el nombre real de la base de datos y las rutas antes de usarlo.

mysqldump --login-path=shop-backup --single-transaction --quick prestashop > /srv/backups/prestashop-before-update.sql
tar -C /var/www -czf /srv/backups/prestashop-before-update-files.tar.gz html

Comprueba el estado de salida de los comandos, el espacio disponible y la integridad de los archivos. Un volcado transaccional depende de tablas transaccionales y de que no haya cambios de esquema en conflicto. Coordina una instantánea de archivos y base de datos y aplica una pausa adecuada de escrituras cuando sea necesario. No pongas contraseñas en argumentos de comandos ni archivos públicos.

En Docker, incluye los montajes o volúmenes persistentes reales y los datos de la base de datos o un volcado lógico. Registra las versiones de imagen y entorno y la propiedad numérica. Copiar solo la imagen del contenedor no conserva los pedidos reales ni los archivos subidos.

1. Mantén una copia fuera del servidor con credenciales independientes.
2. Prepara el destino aislado antes de que arranque la aplicación copiada o cualquier tarea programada: su propia base de datos, su dominio y un acceso restringido. Desactiva los pagos reales, el correo saliente a clientes, los webhooks en producción y las escrituras externas programadas, o apúntalos a conexiones sandbox y a un buzón de pruebas.
3. Restaura allí los archivos y la base de datos. Confirma que la copia usa de verdad la base de datos y los destinos de pruebas, no solo un dominio distinto.
4. Verifica catálogo, recuentos de pedidos, imágenes, accesos de clientes y facturas representativas.
5. Ejecuta la actualización o migración prevista, incluida cada transición de PHP. Conserva los errores y registra las correcciones.
6. Repite desde una instantánea coherente nueva, para que el procedimiento escrito incluya todos los pasos necesarios.
7. Ensaya también la recuperación: vuelve a la instalación original a partir de archivos de la aplicación, base de datos, medios, configuración y PHP compatible que se correspondan.

Si el ensayo cambia la configuración a mano, registra esos cambios en el procedimiento para que la próxima restauración no vuelva a conectarse sin avisar a producción.

Los archivos de copia en disco no demuestran la recuperación, y los recuentos de filas son útiles, pero no constituyen una prueba completa de restauración. Prueba los flujos de trabajo y accesos reales. Mantén protegidos en pruebas los datos sensibles de clientes. La guía de copias de seguridad cubre el proceso de recuperación completo, y la guía del entorno privado de pruebas te ayuda a organizar la copia.

Ejecuta el flujo ensayado de Update Assistant

Usa una versión empaquetada actual de Update Assistant compatible con la tienda de origen y sigue sus comprobaciones previas y el flujo del destino elegido. Los canales y opciones actuales difieren de las capturas antiguas de «1-Click Upgrade». La selección de destino online también depende del entorno PHP.

Revisa los requisitos y las acciones de módulos antes de empezar. Distingue la desactivación temporal de cualquier propuesta de desinstalación o restablecimiento, que puede eliminar ajustes o datos de negocio. Conserva y migra esos datos antes de aceptar una acción destructiva. Consulta el flujo de Assistant y la ayuda de la propia versión.

Cómo transcurre en la práctica una actualización de PrestaShop 8 a 9, y dónde se atasca en una tienda en producción, lo muestra el caso práctico de 4eck Media (en alemán).

Ensaya primero este flujo exacto en pruebas. En producción, repite el procedimiento escrito en lugar de improvisar:

1. Programa el cambio ensayado y asigna un operador, la lista de comprobaciones de aceptación, una hora límite para decidir la reversión y los fallos que la desencadenan.
2. En Parámetros de la tienda > Configuración > Mantenimiento, establece Activar tienda en No. Añade solo las IP de mantenimiento previstas y prueba desde una dirección externa.
3. Controla también otros procesos que escriben: tareas cron, importaciones ERP, colas y callbacks. El modo mantenimiento por sí solo no congela todas las escrituras externas.
4. Haz la copia final coherente y registra el último punto de conciliación de pedidos y pagos, los callbacks pendientes de los proveedores y las importaciones en cola (consulta la sección del cambio definitivo más abajo).
5. Ejecuta la vía de Assistant y las transiciones PHP probadas. Supervisa el progreso y los registros PHP y de aplicación correctos.
6. Si falla, conserva los registros y diagnostica el paso exacto. No actualices la página, repitas la ejecución ni mates un proceso a ciegas.
7. Tras completarse, reconstruye las cachés con el usuario de ejecución previsto y verifica la propiedad de los archivos generados.
8. Vuelve a activar los módulos aprobados en un orden controlado y ejecuta las pruebas de aceptación, incluidos el proceso de compra, el correo, los callbacks, las redirecciones y las restricciones de indexación, antes de reabrir.

Los comandos CLI de caché para un destino compatible incluyen:

php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

Usa el binario PHP y la identidad correctos. Repara el acceso a las rutas de escritura seleccionadas en vez de entregar recursivamente todo el código de producción al usuario web. Mantén la pausa de escrituras de mantenimiento hasta completar las comprobaciones.

Crea una tienda limpia y define la correspondencia de datos

Un destino nuevo es útil para sustituir un tema 1.6, rediseñar la tienda o eliminar personalizaciones acumuladas. Se crea y se prueba en pruebas mientras la tienda antigua sigue vendiendo, de modo que solo la transferencia final necesita una pausa de escrituras. También supone un proyecto de migración de datos: no todas las tablas, contraseñas, documentos o integraciones pueden copiarse sin cambios.

1. Instala el destino con soporte en una ubicación limpia y protegida.
2. Elige un tema compatible e instala los módulos compatibles necesarios.
3. Configura idiomas, monedas, impuestos, transportistas, pagos, correo y páginas legales.
4. Define la correspondencia de categorías, productos, combinaciones, características, atributos, imágenes, stock, precios y metadatos SEO.
5. Define la correspondencia de clientes, direcciones y grupos de clientes, probando la continuidad de las contraseñas o el proceso de restablecimiento necesario.
6. Define la correspondencia de pedidos históricos, facturas, abonos, pagos, numeración de documentos y relaciones cuando la atención al cliente o la contabilidad los necesiten.
7. Incluye los datos de negocio propios de cada módulo, las asociaciones de tiendas y las referencias de integraciones, no solo las tablas del catálogo del núcleo.
8. Verifica totales, identificadores, asociaciones, referencias de imágenes y acceso del cliente.

La importación CSV nativa admite determinadas entidades de catálogo y clientes; no es una migración completa de pedidos, pagos y documentos históricos. Un servicio o script específico de migración necesita un mapa explícito de campos y relaciones y una transformación probada.

Ejemplo de mapa de migración

Pregunta cómo evita una ejecución repetida de la migración duplicar registros y cómo se tratan en la transferencia final los registros de origen modificados o eliminados. El ensayo solo sirve si el mismo procedimiento puede volver a ejecutarse con los datos finales.

No restaures un conjunto de tablas de 1.6 elegido a mano sobre un esquema 9 nuevo. Las definiciones de tablas, filas de tiendas e idiomas e identificadores difieren. Conserva referencias, relaciones y numeración legal de documentos con un proceso que conozca el esquema.

Los hashes de contraseñas son de un solo sentido. Que los accesos sigan funcionando depende de la herramienta de migración, de las claves antiguas y del soporte de hash del destino; copiar solo las filas de clientes no garantiza la continuidad de las contraseñas. Prueba cuentas reales migradas en el destino aislado. Si hacen falta restablecimientos, usa el flujo de restablecimiento de contraseña admitido y acuerda una comunicación clara con los clientes antes del lanzamiento.

La transferencia final de los cambios hechos desde la instantánea del ensayo tiene lugar en el cambio definitivo (consulta más abajo); exige su procedimiento escrito junto con el mapa de datos.

Conserva un tema compatible o crea un tema hijo

Actualizar el núcleo no obliga en todos los casos a migrar a Hummingbird. Classic sigue disponible en las versiones 9 pertinentes. Puedes conservar un tema basado en Classic compatible y probado o planificar una migración de tema aparte. Un tema 1.6 necesita sustitución o una adaptación considerable para PrestaShop moderno.

Conserva un tema compatible cuando supere los recorridos necesarios; actualizar el núcleo no implica por sí solo que haga falta un rediseño. Trata un rediseño como un trabajo con alcance propio y sus propias comprobaciones de aceptación. Cuando el tema actual no puede pasar al destino, el front office se reconstruye en cualquiera de las dos vías, lo que inclina la balanza hacia evaluar una tienda limpia.

Hummingbird pasó a ser el predeterminado en instalaciones nuevas de 9.1. Usa Bootstrap 5.3 y propiedades CSS personalizadas junto con una compilación SCSS. Los cambios de variables en ejecución y los que necesitan un flujo Sass o de compilación son tareas distintas. Prueba hooks, selectores, diseños adaptables y marcado de terceros.

Para un tema comprado, pregunta por la compatibilidad exacta con el destino y PHP, la vía de actualización, la cobertura de la licencia y el soporte para los módulos del proceso de compra. No des por hecho que un tema funciona solo porque sus plantillas muestran una página de inicio. Si sustituyes el tema, prueba el catálogo, las posiciones de los módulos, los controles móviles y el proceso de compra con tus productos reales.

Una base completa de tema hijo

Este ejemplo presupone que Hummingbird está instalado y que los comandos se ejecutan desde la raíz de la tienda. Crea el directorio config, hereda los recursos del padre y registra expresamente una hoja de estilos independiente del hijo.

mkdir -p themes/shop-child/config themes/shop-child/assets/css themes/shop-child/templates
cp themes/hummingbird/preview.png themes/shop-child/preview.png

Crea themes/shop-child/config/theme.yml:

parent: hummingbird
name: shop-child
display_name: Shop Child
version: 1.0.0
author:
  name: Shop Team
assets:
  use_parent_assets: true
  css:
    all:
      - id: shop-child-overrides
        path: assets/css/shop-overrides.css
        media: all
        priority: 1100

Crea themes/shop-child/assets/css/shop-overrides.css:

body { --shop-child-ready: 1; }

Activa el hijo en Diseño > Tema y logotipo. Reconstruye las cachés, abre el panel de red del navegador y confirma que los recursos del padre y shop-overrides.css devuelven 200. Comprueba la propiedad personalizada calculada --shop-child-ready en body. Esto verifica la carga de estilos antes de añadir cambios reales de diseño.

Copia solo las plantillas que necesites cambiar, conservando su ruta bajo templates/. Compáralas después con las actualizaciones del padre. Consulta la estructura de temas hijos y la guía de temas hijos.

Conserva URL, ajustes de indexación y callbacks externos

Crea el inventario de URL antiguas a partir del catálogo, rastreos, sitemaps, registros y datos de Search Console. Los ejemplos de indexación de Search Console no son una exportación completa de todas las URL indexadas. Incluye los patrones de URL que controlan los módulos, para que un cambio de ruta no rompa sin avisar direcciones que ya usan clientes o sistemas externos.

Conserva las URL operativas cuando sea posible. Para equivalentes que cambien, usa redirecciones permanentes probadas como 301 o 308. Comprueba el contenido final, etiquetas canonical, enlaces internos, alternativas de idioma y feeds. No redirijas páginas eliminadas sin relación a la página de inicio ni prometas un plazo fijo de recuperación.

Usa un módulo de sitemap como gsitemap u otro generador implementado; actualizar el núcleo no establece por sí solo un flujo completo de sitemaps XML. Verifica las URL canonical correctas e indexables antes de enviarlas. Retira las restricciones noindex y de autenticación de pruebas solo en el destino de producción previsto.

Por ejemplo, abre una dirección de producto antigua en cada idioma pertinente y sigue su redirección hasta el producto equivalente en producción. Revisa la dirección canonical final, los enlaces de idioma y la entrada del sitemap. Comprueba que el destino en producción ya no tiene las restricciones de acceso ni el ajuste noindex de pruebas, mientras que la copia de pruebas sigue protegida.

Actualiza los webhooks/IPN de pago, los endpoints del ERP, las URL de feeds, el correo, el seguimiento y las tareas programadas si cambian el dominio o la ruta. Prueba las operaciones autenticadas en lugar de tomar un HTTP 200 por sí solo como prueba de que una tarea cron ha completado su tarea de negocio.

La guía de URL y redirecciones contiene el mapa, ejemplos de servidor y comprobaciones de lanzamiento.

SEO Revolution admite flujos de redirecciones y sitemaps; usa su ayuda del módulo para la configuración.

Smart SEO Friendly URL Manager admite rutas personalizadas e historial de URL; usa su ayuda del módulo cuando conserves o cambies esos patrones.

Prueba la tienda antes de reabrir

Ejecuta estas comprobaciones en cada ensayo en pruebas y de nuevo en el destino de lanzamiento antes de reabrir. Para cada área, reúne pruebas, no impresiones.

Verifica la captura del pago en el panel del proveedor, no solo el estado del pedido. Confirma las facturas, los emails y los cambios de stock esperados y evita cargos duplicados no deseados. Usa los sandbox de los proveedores cuando existan; acuerda y concilia cualquier transacción real controlada de importe bajo para que las pruebas no provoquen cargos, envíos ni mensajes a clientes no deseados.

Convierte la lista de comprobación en carritos realistas

• Usa un carrito de invitado y otro de un cliente existente, con el precio de grupo, vale y destino de entrega correspondientes. Compara impuestos y gastos de envío con el origen en las mismas condiciones.
• Prueba carritos a ambos lados de un umbral configurado de envío gratuito o descuento. Incluye tipos impositivos mixtos o casos de clientes profesionales cuando la tienda los use.
• Completa un pago de pruebas, abandona antes de volver a la tienda y confirma que el callback del proveedor siga produciendo el estado de pedido esperado. Repite un callback con las herramientas de pruebas admitidas por el proveedor y comprueba si hay pedidos, mensajes o cambios de stock duplicados.
• Ejecuta un reembolso mediante el flujo acordado y comprueba el registro del proveedor, el documento de abono y el tratamiento del stock. Cambiar solo el estado de un pedido no demuestra que se haya devuelto el dinero.

Para cada caso, registra el carrito inicial, el resultado esperado, el observado y las pruebas. Pide al personal que prepara los pedidos que dé el visto bueno a su propio flujo.

Conserva los registros durante los primeros ciclos operativos completos: importaciones programadas, liquidaciones, devoluciones y picos de tráfico pueden revelar casos no detectados en el lanzamiento. Compara el éxito de compra, la recaudación, las colas de atención y las páginas de entrada clave con la base de referencia.

Haz el cambio en una única ventana planificada

Sigue vendiendo durante la preparación y el ensayo; solo el cambio definitivo necesita una pausa controlada de escrituras. Ejecútalo como un procedimiento ensayado propio, con un operador, la lista de comprobaciones de aceptación y las condiciones de fallo que desencadenan la reversión acordadas de antemano.

1. Detén el proceso de compra de la tienda antigua y congela el resto de procesos que escriben: modo mantenimiento más tareas cron, importaciones, colas y callbacks, como en los pasos 2 y 3 del flujo de Update Assistant descrito arriba. Esto se aplica también a la tienda antigua en la vía de la instalación nueva.
2. Registra el punto de conciliación: el último pedido y evento de pago conciliados, los callbacks pendientes de los proveedores, las importaciones en cola y los cambios de stock. Acuerda con cada proveedor dónde se recibirán o volverán a enviar los eventos retrasados y quién los comprueba, en lugar de bloquear los callbacks a ciegas.
3. Haz la copia final coherente.
4. Vía de actualización: aplica el procedimiento ensayado a ese estado final de producción o usa un método de transferencia ensayado por separado que conserve todos los cambios intermedios. No pases a producción una base de datos de pruebas antigua sin cambios: le faltan todos los pedidos recibidos desde la instantánea del ensayo.
5. Vía de la instalación nueva: transfiere el delta final desde la instantánea del ensayo (pedidos, clientes, stock, pagos y datos de módulos modificados) y concílialo con el origen.
6. Completa las comprobaciones del destino que sea posible hacer antes del cambio. Cambia el destino en producción con el procedimiento ensayado y después verifica el proceso de compra, el correo, los callbacks de los proveedores, las redirecciones y los ajustes de indexación a través de las rutas de producción antes de reabrir el proceso de compra. Mantén protegida la copia de pruebas independiente.
7. Si tras el traslado queda una instalación antigua independiente, mantenla aislada y en solo lectura para consultas autorizadas. Para una actualización in situ, conserva la instantánea coherente previa a la actualización y el procedimiento de restauración probado. Mantén con escritura solo el proceso de compra de producción elegido; reabrir ambos procesos de compra para evitar la conciliación crea dos flujos de pedidos en competencia.
8. Supervisa durante los ciclos pertinentes de importación, preparación de pedidos y pagos.

Diagnostica los problemas habituales tras actualizar

Empieza por la primera comprobación segura: conserva las pruebas y reproduce el problema en un entorno de pruebas protegido con el entorno de ejecución y las extensiones previstos antes de cambiar la tienda en producción.

• Página en blanco o error 500: revisa primero los registros del servidor web, de PHP-FPM y de PrestaShop y conserva la excepción. En el entorno de pruebas protegido, activa temporalmente el modo depuración para identificar la excepción y desactívalo después. Comprueba extensiones, memoria, código incompatible y rutas de escritura.
• Fallos de reescritura: conserva las reglas personalizadas e inspecciona módulos Apache/AllowOverride o ubicaciones Nginx. Prueba los cambios en el contexto previsto; eliminar .htaccess públicamente también puede eliminar protecciones de seguridad.
• Conflicto de módulos: usa las acciones de desactivación de módulos admitidas y aísla los cambios en la copia. No ejecutes una actualización SQL global del campo active con una lista de módulos nativos permitidos hecha a ojo, y no restablezcas ni desinstales módulos en una actualización en producción sin copia de seguridad, una reproducción en pruebas y un plan de reversión.
• Traducciones ausentes: comprueba nombres de dominio, archivos o catálogos de traducción, contexto de idioma y tienda y cachés. Reinstalar no es una solución general para las traducciones y puede eliminar datos del módulo.
• CSS o JavaScript desactualizados: comprueba primero las URL de los recursos, después reconstruye las cachés de la aplicación y del tema y vacía la caché pertinente de la CDN o del navegador.
• Imágenes ausentes: revisa las direcciones, rutas y permisos de los recursos antes de regenerar nada y, si hace falta, regenera después las miniaturas necesarias. Comprueba la CDN por separado.
• Acceso de administración: comprueba la URL, las cookies, HTTPS, el estado del empleado, los registros de autenticación y la entrega del correo de restablecimiento. Usa el proceso integrado de restablecimiento de contraseña de empleados.

El núcleo de PrestaShop usa su servicio Crypto Hashing, incluidos bcrypt y verificación MD5 antigua. No atribuyas toda la gestión de contraseñas de la tienda a MigratingPasswordHasher de Symfony. La autenticación moderna del back office y las cookies de la tienda usan mecanismos distintos.

No existe un comando estándar de recuperación prestashop:user:change-password en este núcleo. Evita SQL directo para contraseñas y scripts públicos de restablecimiento. Si falla el correo de restablecimiento, repara la entrega o usa un procedimiento administrativo de recuperación expresamente admitido.

Para un diagnóstico detallado, usa la guía de resolución de problemas.

Restaura con seguridad y entrega el resultado

Decide antes de empezar qué fallo desencadena la reversión. Conserva registros y el estado fallido para diagnosticar. Una restauración debe emparejar los archivos, base de datos, entorno PHP, configuración y medios persistentes correspondientes.

1. Mantén la tienda en mantenimiento y controla los procesos externos que escriben.
2. Comprueba si el flujo probado de restauración de Assistant puede usar la copia previa a la actualización prevista.
3. Para una restauración manual, usa un destino limpio y una base de datos vacía independiente.
4. Restaura la instantánea coherente completa, incluidos los archivos ocultos. No superpongas un archivo sobre código actualizado ni supongas que rm -rf /var/www/html/* eliminó los archivos ocultos.
5. Apunta el entorno restaurado a su base de datos y al dominio y entorno correctos, repara los permisos necesarios y reconstruye las cachés generadas.
6. Concilia los pedidos, pagos o eventos externos aceptados después de la instantánea antes de reabrir. Restaurar la copia de ayer tras haber recibido pedidos nuevos necesita un plan de conciliación explícito: una restauración no borra la transacción de un proveedor ni una acción del almacén.
7. Prueba acceso, catálogo, compra, email e integraciones con la lista de recuperación.

Revertir solo la base de datos frente a archivos nuevos deja una instalación mezclada. Si PHP cambió, restaura también las versiones compatibles de servicio web y CLI. Mantén aislado el entorno fallido hasta tener los registros y datos necesarios para investigar.

Sin una copia adecuada, pregunta enseguida al alojamiento por instantáneas y retención, revisa el inventario de copias de Assistant y evalúa la recuperación a un punto temporal si existen registros binarios. Una actualización fallida no puede revertirse con seguridad copiando unos pocos archivos antiguos. Puede ser necesaria una recuperación especializada o una reparación hacia adelante.

Tras recuperarte, reproduce el paso fallido en pruebas y corrígelo antes de reintentar en producción.

Decide quién debe realizar la migración

Usa la complejidad real de la tienda, tu capacidad de restaurarla y el coste de la interrupción para elegir trabajo interno o un especialista. Pide al desarrollador un inventario escrito, un mapa de datos y URL, una vía ensayada, pruebas de aceptación, un plan de reversión y un traspaso de la supervisión. Basa presupuestos y estimaciones de interrupción en ese alcance, no en bandas genéricas de precios de mercado.

En la entrega, documenta las nuevas versiones, el entorno de ejecución, los temas, los ajustes modificados, la titularidad de las credenciales, las tareas, las URL y responsables de las integraciones, las limitaciones conocidas, los pasos para restaurar las copias y la responsabilidad del soporte. Confirma que la salida de depuración está desactivada en producción y que se han retirado las herramientas y accesos temporales.