Migrar de GLPI 10 a GLPI 11 casi nunca falla en el comando de actualización de la base de datos - falla en lo que viene antes y después. Esta guía consolida el plan que aplicamos dando soporte a entornos de clientes: dónde se rompen las cosas de verdad, cómo blindar cada paso y cómo volver atrás si algo sale mal.
Antes de nada: por qué la migración exige método
Migrar del 10 al 11 cambia el esquema de la base de datos de forma irreversible y sustituye toda la capa de presentación (ahora sobre Symfony y Twig). No es un "cambiar los archivos y arrancar". Los dos factores que más causan downtime no planificado son los plugins incompatibles activos durante la actualización y la versión de PHP del servidor. Trate la migración como un pequeño proyecto, con ventana y plan de rollback, no como un hotfix. Planifique también avisar a los usuarios de que la interfaz del 11 se ve distinta a la del 10 - buena parte de los tickets posmigración son personas perdidas en el nuevo diseño, no bugs reales.
Checklist de premigración
- Backup completo de la base de datos (mysqldump) y de los directorios de configuración y datos.
- Estar en la última minor de GLPI 10 (10.0.x más reciente) antes de saltar al 11.
- PHP 8.1+ instalado y activo en la versión correcta de CLI y FPM.
- Inventario de plugins con el estado de compatibilidad de cada uno en GLPI 11.
- Un entorno de homologación con una copia real de la base de datos para ensayar la migración.
Plugins: qué cambia en GLPI 11
| Plugin | Situación en GLPI 11 | Acción antes de migrar |
|---|---|---|
| FormCreator | Incorporado al core (formularios nativos) | Desactivar y eliminar |
| GenericObject | Incorporado al core (objetos personalizados) | Desactivar y eliminar |
| FusionInventory | Descontinuado | Migrar al GLPI Agent |
| Fields, Escalade, DataInjection, PDF, Tag | Tienen versión para el 11 | Actualizar tras la migración |
| NexTool | Compatible con 10 y 11 | Actualizar a la versión del 11 |
| Plugins sin actualización desde 2023 | Probable incompatibilidad | Evaluar sustitución |
1. Backup completo (y probado)
Un backup que nunca ha restaurado no es un backup, es una esperanza. Genérelo y, como mínimo, valide el tamaño del archivo:
# Base de datos
mysqldump -u root -p --single-transaction glpi > /backup/glpi_pre_migration.sql
# Archivos (configuración, datos y plugins)
tar -czf /backup/glpi_files_pre_migration.tar.gz /var/www/glpi /etc/glpi /var/lib/glpi2. Desactivar plugins incompatibles
En GLPI 10, vaya a Configuración > Plugins y desactive todos los que no tengan versión para el 11. Elimine los directorios de los incompatibles. Este paso no es opcional: es la causa número 1 de fallo en el comando de actualización.
3. Actualizar los archivos de GLPI
cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/11.0.0/glpi-11.0.0.tgz
tar -xzf glpi-11.0.0.tgz
# Reemplazar archivos preservando configuración, datos y plugins
rsync -av --delete /tmp/glpi/ /var/www/glpi/ --exclude plugins/ --exclude marketplace/
chown -R www-data:www-data /var/www/glpiDescargue siempre la última versión estable de la línea 11.x, no necesariamente la 11.0.0.
4. Ejecutar la migración de la base de datos
php /var/www/glpi/bin/console db:update --no-interactionEste comando aplica todas las migraciones de esquema. Siga toda la salida - cualquier error debe resolverse antes de continuar, nunca ignorarse.
5. Limpiar caché y sesiones
php /var/www/glpi/bin/console cache:clear
rm -rf /var/lib/glpi/_sessions/*6. Verificación posmigración
- El login funciona y la versión en Configuración > General muestra 11.x.
- Tickets, activos y usuarios están presentes con los totales esperados.
- La apertura de un ticket nuevo funciona de principio a fin.
- Logs sin errores recurrentes tras unos minutos de uso.
- Reactive y actualice los plugins compatibles uno a uno, probando entre cada uno.
Lo que aprendimos en soporte
En la práctica, la migración rara vez falla en el propio db:update. Falla después: un plugin incompatible que quedó activo y tumba la interfaz con un error 500, el PHP de FPM apuntando a una versión que GLPI 11 no acepta (mientras el CLI ya está en 8.1), o el cliente que se saltó una minor del 10 y llega al comando de actualización con un esquema que no cuadra. Por eso nuestro plan siempre actualiza primero a la última 10.0.x, valida, y solo entonces salta al 11 - y reactiva los plugins uno a uno, nunca todos a la vez, porque cuando algo se rompe necesita saber exactamente qué plugin fue el responsable.
La trampa más común
El error clásico es creer que los formularios de FormCreator migran solos a los formularios nativos de GLPI 11. No migran: el plugin desaparece, pero los formularios que creaba hay que rehacerlos manualmente en el core nuevo. Inventaríe los formularios de FormCreator antes de eliminar el plugin, o descubrirá la pérdida en producción, con un usuario quejándose de que el formulario desapareció. El segundo error más común es ejecutar db:update con un plugin incompatible aún activo: el console intenta cargar el plugin, encuentra una API que ya no existe y aborta a mitad de la migración.
Rollback: cuando algo sale mal
Como el cambio de esquema es irreversible, el rollback no es "deshacer" - es restaurar el estado anterior. Por eso el backup probado del paso 1 es innegociable:
# Restaurar archivos
tar -xzf /backup/glpi_files_pre_migration.tar.gz -C /
# Restaurar base de datos
mysql -u root -p glpi < /backup/glpi_pre_migration.sqlEnsayar esa restauración en homologación antes de la ventana real es lo que separa un susto de un incidente.
Siguiente paso
Tras la migración, explore los formularios nativos y las demás novedades de GLPI 11, y reintroduzca los plugins esenciales. Para ampliar el core sin acumular plugins que se rompen en la próxima major, NexTool concentra decenas de módulos en un único plugin, con versiones para 10 y 11. ¿Necesita apoyo con la migración? Hable con el equipo.
Revisado por el equipo de NexTool Solutions.
