Migrar do GLPI 10 para o GLPI 11 quase nunca falha no comando de atualização da base de dados - falha no que vem antes e depois. Este guia consolida o roteiro que aplicamos na sustentação de ambientes de clientes: onde as coisas realmente quebram, como blindar cada etapa e como voltar atrás se algo correr mal.
Antes de tudo: porque a migração exige método
Migrar do 10 para o 11 altera o esquema da base de dados de forma irreversível e substitui toda a camada de apresentação (agora sobre Symfony e Twig). Não é um "trocar os ficheiros e arrancar". Os dois fatores que mais causam indisponibilidade não planeada são plugins incompatíveis ativos durante a atualização e a versão do PHP no servidor. Trate a migração como um pequeno projeto, com janela e plano de rollback, não como um hotfix. Planeie também comunicar aos utilizadores que a interface do 11 é visualmente diferente da do 10 - boa parte dos pedidos pós-migração é gente perdida no novo layout, não bug de verdade.
Checklist de pré-migração
- Backup completo da base de dados (mysqldump) e das diretorias de configuração e dados.
- Estar na última minor do GLPI 10 (10.0.x mais recente) antes de saltar para o 11.
- PHP 8.1+ instalado e ativo na versão correta do CLI e do FPM.
- Um inventário de plugins com o estado de compatibilidade de cada um no GLPI 11.
- Um ambiente de homologação com uma cópia real da base para ensaiar a migração.
Plugins: o que muda no GLPI 11
| Plugin | Situação no GLPI 11 | Ação antes de migrar |
|---|---|---|
| FormCreator | Incorporado ao núcleo (formulários nativos) | Desativar e remover |
| GenericObject | Incorporado ao núcleo (objetos personalizados) | Desativar e remover |
| FusionInventory | Descontinuado | Migrar para o GLPI Agent |
| Fields, Escalade, DataInjection, PDF, Tag | Têm versão para o 11 | Atualizar após a migração |
| NexTool | Compatível com 10 e 11 | Atualizar para a versão do 11 |
| Plugins sem atualização desde 2023 | Provável incompatibilidade | Avaliar substituição |
1. Backup completo (e testado)
Um backup que nunca restaurou não é um backup, é uma esperança. Gere-o e, no mínimo, valide o tamanho do ficheiro:
# Base de dados
mysqldump -u root -p --single-transaction glpi > /backup/glpi_pre_migration.sql
# Ficheiros (configuração, dados e plugins)
tar -czf /backup/glpi_files_pre_migration.tar.gz /var/www/glpi /etc/glpi /var/lib/glpi2. Desativar plugins incompatíveis
No GLPI 10, vá a Configuração > Plugins e desative todos os que não têm versão para o 11. Remova as diretorias dos incompatíveis. Este passo não é opcional: é a causa nº 1 de falha no comando de atualização.
3. Atualizar os ficheiros do 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
# Substituir ficheiros preservando configuração, dados e plugins
rsync -av --delete /tmp/glpi/ /var/www/glpi/ --exclude plugins/ --exclude marketplace/
chown -R www-data:www-data /var/www/glpiDescarregue sempre a última versão estável da linha 11.x, não necessariamente a 11.0.0.
4. Executar a migração da base de dados
php /var/www/glpi/bin/console db:update --no-interactionEste comando aplica todas as migrações de esquema. Acompanhe toda a saída - qualquer erro precisa de ser resolvido antes de seguir, nunca ignorado.
5. Limpar cache e sessões
php /var/www/glpi/bin/console cache:clear
rm -rf /var/lib/glpi/_sessions/*6. Verificação pós-migração
- O início de sessão funciona e a versão em Configuração > Geral mostra 11.x.
- Pedidos, ativos e utilizadores estão presentes com os totais esperados.
- A abertura de um pedido novo funciona de ponta a ponta.
- Registos sem erros recorrentes após alguns minutos de uso.
- Reative e atualize os plugins compatíveis um a um, testando entre cada um.
O que aprendemos na sustentação
Na prática, a migração raramente falha no próprio db:update. Falha no depois: um plugin incompatível que ficou ativo e deita abaixo a interface com um erro 500, o PHP do FPM a apontar para uma versão que o GLPI 11 não aceita (enquanto o CLI já está no 8.1), ou o cliente que saltou uma minor do 10 e chega ao comando de atualização com um esquema que não bate. Por isso o nosso roteiro atualiza primeiro para a última 10.0.x, valida, e só então salta para o 11 - e reativa os plugins um a um, nunca todos de uma vez, porque quando algo quebra é preciso saber exatamente qual plugin foi o responsável.
A armadilha mais comum
O erro clássico é achar que os formulários do FormCreator migram sozinhos para os formulários nativos do GLPI 11. Não migram: o plugin sai, mas os formulários que criava têm de ser recriados manualmente no núcleo novo. Levante o inventário de formulários do FormCreator antes de remover o plugin, senão descobre a perda em produção, com o utilizador a queixar-se de que o formulário desapareceu. O segundo erro mais comum é correr o db:update com plugin incompatível ainda ativo: o console tenta carregar o plugin, encontra uma API que já não existe e aborta a meio da migração.
Rollback: quando algo corre mal
Como a alteração de esquema é irreversível, o rollback não é "desfazer" - é restaurar o estado anterior. Por isso o backup testado do passo 1 é inegociável:
# Restaurar ficheiros
tar -xzf /backup/glpi_files_pre_migration.tar.gz -C /
# Restaurar base de dados
mysql -u root -p glpi < /backup/glpi_pre_migration.sqlEnsaiar esse restauro em homologação antes da janela real é o que separa um susto de um incidente.
Próximo passo
Depois da migração, explore os formulários nativos e as restantes novidades do GLPI 11, e reintroduza os plugins essenciais. Para expandir o núcleo sem acumular plugins que quebram na próxima major, o NexTool concentra dezenas de módulos num único plugin, com versões para 10 e 11. Precisa de apoio na migração? Fale com a equipa.
Revisto pela equipa NexTool Solutions.
