Migrar do GLPI 10 para o GLPI 11 quase nunca falha no comando de atualização do banco - falha no que vem antes e depois dele. Este guia consolida o roteiro que aplicamos na sustentação de clientes: onde as coisas realmente quebram, como blindar cada etapa e como voltar atrás se algo der errado.
Antes de tudo: por que a migração exige método
A migração do 10 para o 11 altera o schema do banco de forma irreversível e substitui a camada de apresentação inteira (agora sobre Symfony e Twig). Não é um "trocar os arquivos e subir". Os dois pontos que mais geram downtime não planejado são plugins incompatíveis ativos durante a atualização e a versão do PHP embarcada no servidor. Trate a migração como um projeto pequeno, com janela e plano de rollback, não como um hotfix. Planeje também comunicar aos usuários que a interface do 11 é visualmente diferente da do 10 - boa parte dos chamados pós-migração é gente perdida no layout novo, não bug de verdade.
Checklist de pré-migração
- Backup completo do banco (mysqldump) e dos diretórios 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.
- Inventário de plugins com o status de compatibilidade de cada um no GLPI 11.
- Ambiente de homologação com uma cópia real do banco 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 core (formulários nativos) | Desativar e remover |
| GenericObject | Incorporado ao core (objetos personalizados) | Desativar e remover |
| FusionInventory | Descontinuado | Migrar para o GLPI Agent |
| Fields, Escalade, DataInjection, PDF, Tag | Possuem 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 você nunca restaurou não é um backup, é uma esperança. Gere e, no mínimo, valide o tamanho do arquivo:
# Banco de dados
mysqldump -u root -p --single-transaction glpi > /backup/glpi_pre_migration.sql
# Arquivos (config, 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á em Configurar > Plugins e desative todos os que não têm versão para o 11. Remova os diretórios dos incompatíveis. Este passo não é opcional: é a causa nº 1 de falha no comando de atualização.
3. Atualizar os arquivos 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 arquivos preservando config, dados e plugins
rsync -av --delete /tmp/glpi/ /var/www/glpi/ --exclude plugins/ --exclude marketplace/
chown -R www-data:www-data /var/www/glpiBaixe sempre a última release estável da linha 11.x, não necessariamente a 11.0.0.
4. Executar a migração do banco
php /var/www/glpi/bin/console db:update --no-interactionEste comando aplica todas as migrações de schema. Acompanhe a saída inteira - qualquer erro precisa 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
- Login funciona e a versão em Configurar > Geral mostra 11.x.
- Chamados, ativos e usuários estão presentes e com os totais esperados.
- Abertura de um chamado novo funciona de ponta a ponta.
- Logs 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 db:update em si. Falha no depois: um plugin incompatível que ficou ativo e derruba a interface com erro 500, o PHP do FPM apontando 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 no comando de atualização com um schema que não bate. Por isso nosso roteiro sempre 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 você precisa 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. Eles não migram: o plugin sai, mas os formulários que ele criava precisam ser recriados manualmente no core novo. Levante o inventário de formulários do FormCreator antes de remover o plugin, senão você descobre a perda em produção, com o usuário reclamando que o formulário sumiu. O segundo erro mais comum é rodar o db:update com plugin incompatível ainda ativo: o console tenta carregar o plugin, encontra uma API que não existe mais e aborta no meio da migração.
Rollback: quando algo dá errado
Como a alteração de schema é irreversível, o rollback não é "desfazer" - é restaurar o estado anterior. Por isso o backup testado da etapa 1 é inegociável:
# Restaurar arquivos
tar -xzf /backup/glpi_files_pre_migration.tar.gz -C /
# Restaurar banco
mysql -u root -p glpi < /backup/glpi_pre_migration.sqlEnsaiar esse restore 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 demais novidades do GLPI 11, e reintroduza os plugins essenciais. Para expandir o core sem acumular plugins que quebram na próxima major, o NexTool concentra dezenas de módulos em um único plugin, com versões para 10 e 11. Precisa de apoio na migração? Fale com a equipe.
Revisado pela equipe NexTool Solutions.
