Como atualizar o GLPI para versão 11 com segurança e o que mudou?

O lançamento do GLPI 11 colocou a palavra “atualização” na boca de toda equipe que roda a ferramenta. Afinal, depois de meses de testes da comunidade, a nova versão chegou estável e com mudanças grandes na forma de criar ativos, formulários e integrações.

Só que atualizar o GLPI não é trocar arquivos no servidor e torcer para dar certo. Um upgrade mal planejado quebra plugins, corrompe o banco e tira o service desk do ar bem na hora do pico de chamados.

Neste guia você vai aprender a atualizar o GLPI como um processo de mudança controlado: backup, checklist, atualização do banco, compatibilidade de plugins e plano de rollback. No fim, você também vê o que muda no GLPI 11 e quando vale a pena subir de versão. Se ainda está começando, vale revisar antes o que é o GLPI como plataforma de ITSM open source.

Por que e quando atualizar o GLPI

Atualizar parece tarefa chata, porém é o que mantém a operação segura. Cada versão nova corrige falhas, fecha brechas de segurança e entrega recursos que reduzem trabalho manual no dia a dia.

O motivo mais urgente é segurança. As versões atuais trazem correções de vulnerabilidades e o próprio projeto recomenda atualizar assim que possível, segundo o anúncio oficial da nova versão.

Além disso, versões antigas saem de suporte. Quando isso acontece, você para de receber correções e fica exposto a problemas que ninguém mais vai consertar. Por isso, rodar uma versão sem manutenção é um risco silencioso que cresce a cada mês.

Há ainda o ganho funcional. A cada ciclo, o GLPI incorpora recursos que antes dependiam de plugins externos, o que simplifica o ambiente. Dessa forma, atualizar também significa menos peças soltas para manter.

Sobre o “quando”: evite o impulso de subir de versão no mesmo dia do lançamento em produção. O caminho seguro é testar em homologação primeiro, escolher uma janela de baixo movimento e tratar o upgrade como uma mudança planejada, não como uma emergência.

Antes de atualizar: o checklist que evita dor de cabeça

A maior parte dos upgrades que dão errado falha por pular o preparo. Antes de tocar no servidor, você precisa de backup, leitura do changelog e um ambiente de teste. Pense nesta etapa como o cinto de segurança do processo.

O backup é inegociável. Faça o dump do banco de dados e copie os diretórios de dados do usuário, ou seja, as pastas de configuração, de arquivos e de plugins. Sem essas cópias, um erro no meio do caminho vira perda de dados de verdade.

Em seguida, leia o changelog da versão de destino. Ele aponta mudanças de comportamento, requisitos novos de PHP ou banco e recursos descontinuados. Assim, você descobre surpresas antes delas aparecerem em produção.

Por fim, valide tudo em homologação. Restaure uma cópia do ambiente, rode o upgrade ali e confira se o sistema sobe limpo. A tabela abaixo resume o checklist mínimo antes de qualquer atualização.

Como atualizar o GLPI passo a passo

Com o backup feito e a homologação validada, o upgrade em si é direto. O procedimento oficial segue sempre a mesma lógica: substituir os arquivos da aplicação e depois atualizar a estrutura do banco de dados.

Antes de tudo, identifique a sua instalação. Anote onde fica o GLPI, qual banco ele usa e onde estão os diretórios de configuração, arquivos e plugins. Esse mapa evita que você restaure a coisa errada no lugar errado.

Um ponto crítico merece destaque. Nunca copie a nova versão por cima da instalação atual, porque isso mistura arquivos e gera erros de aplicação. O correto é mover ou apagar o diretório antigo e extrair a versão nova num diretório limpo.

Depois de extrair, restaure os diretórios que você guardou no backup, junto com o arquivo inc/downstream.php quando ele existir. Em seguida, rode a atualização do banco pelo assistente web ou pela linha de comando, que é o caminho recomendado.

# 1. backup do banco e dos diretorios de dados
mysqldump -u glpi -p glpi > backup-glpi.sql
cp -r config files plugins ../glpi-backup/

# 2. conferir o schema do banco antes de comecar
php bin/console db:check

# 3. baixar e extrair a nova versao num diretorio limpo
tar -xzf glpi-11.0.7.tgz

# 4. aplicar a atualizacao do banco (caminho recomendado)
php bin/console db:update

 
Depois que o comando termina, acesse o GLPI pelo navegador e siga as telas finais: idioma, aceite de licença e confirmação.

Uma boa notícia para quem está em versões bem antigas: o GLPI 11 carrega as migrações desde a versão 0.85, então dá para pular versões maiores inteiras em um único salto.

Você confere cada detalhe na documentação oficial do projeto, que descreve o procedimento completo.

Compatibilidade de plugins: o ponto que mais quebra

Se existe uma armadilha clássica no upgrade do GLPI, é o plugin. Quando o sistema detecta arquivos de uma versão nova, ele suspende a execução dos plugins por segurança. Sem essa atenção, você sobe a versão e descobre que metade das telas customizadas sumiu.

A regra de ouro é simples. Cada plugin precisa de uma versão compatível com a nova major, mas nem todo desenvolvedor acompanha o ritmo do projeto. Por isso, antes de atualizar, liste seus plugins e confirme se cada um já tem release para a versão de destino.

No GLPI 11, essa questão ganha um capítulo especial: o FormCreator. O plugin que praticamente todo mundo usava para criar formulários deu lugar ao construtor de formulários nativo da plataforma. Ou seja, em vez de instalar a extensão, você migra os formulários antigos para o recurso de fábrica.

A própria equipe do GLPI oferece comandos de migração para levar plugins ao núcleo. O FormCreator e o Generic Objects, por exemplo, têm rotinas dedicadas que transferem os dados para os recursos nativos. No caso do FormCreator, as versões 3.0.x do plugin são releases apenas de migração, exclusivas do GLPI 11; confira a prontidão em Tools > Formcreator EOL Info antes de rodar a migração.

# migrar o FormCreator para o construtor nativo do GLPI 11
php bin/console migration:formcreator_plugin_to_core

# reativar os plugins compativeis apos a atualizacao
php bin/console plugin:resume_execution

 
Vale o mesmo cuidado para o inventário. Quem coleta ativos de forma automática deve verificar a versão do agente ao subir o servidor, um ponto que detalhamos no guia de inventário automático com o GLPI Agent.

Para a parte de extensões, customizações e API, o material sobre plugins e customização do GLPI aprofunda cada caminho.

O passo a passo de migração de cada plugin está no tutorial oficial de migração.

O que muda no GLPI 11

A versão 11 não é uma atualização cosmética. Lançada em setembro de 2025, ela reescreve partes importantes da plataforma e traz para o núcleo recursos que antes viviam em plugins. Conhecer essas mudanças ajuda a justificar o upgrade para a diretoria.

O destaque vai para os ativos personalizados nativos. Agora você cria qualquer tipo de ativo, ajusta campos e comportamentos e ainda monta menus próprios, sem depender de extensões. Da mesma forma, os formulários ganharam um editor interativo embutido.

Outro avanço é o portal de autoatendimento renovado, que ajuda o usuário final a encontrar os serviços disponíveis. Soma-se a isso a autenticação de dois fatores reforçada e os webhooks, que disparam chamadas HTTP para sistemas externos quando algo acontece no GLPI.

A tabela compara, ponto a ponto, o cenário antes e depois da major. Ela cobre uma lacuna que quase nenhum conteúdo traz: um retrato direto do que sai do plugin e entra de fábrica.

 
A comparação reflete os destaques oficiais anunciados para a versão. Para a lista completa, sempre consulte o changelog do projeto, já que cada release menor ainda ajusta detalhes. Essa visibilidade do que muda também alimenta o processo de patch management, porque saber a versão exata em produção é o primeiro passo para corrigir o que precisa.

Rollback e validação pós-upgrade: trate como uma mudança

Aqui mora a diferença entre uma equipe madura e um susto. Um upgrade profissional sempre prevê como voltar atrás e como confirmar que deu certo. Em outras palavras, você trata a atualização como uma mudança formal, não como um ajuste improvisado.

Plano de rollback

O rollback é o seu paraquedas. Antes de iniciar, garanta que o backup do banco e dos arquivos está íntegro e que você sabe restaurá-lo. Se a atualização falhar, o caminho é claro: volte os arquivos da versão anterior e restaure o dump do banco em uma base limpa.

Esse plano se encaixa direto na gestão de mudanças do ITIL. Toda mudança de risco precisa de janela aprovada, responsável definido e critério de reversão escrito antes de começar. Dessa forma, ninguém decide no calor do momento se desfaz ou não o upgrade.

Validação e smoke tests

Subiu a versão? Então valide antes de comemorar. Faça uma rodada de smoke tests: abra um chamado, gere um formulário, rode um relatório e confira se os plugins críticos responderam. Esses testes rápidos pegam a maioria dos problemas logo de cara.

Vale registrar o resultado do upgrade como parte do release management. Quando você documenta o que mudou, quem aprovou e como validou, a próxima atualização fica mais fácil. Assim, o ciclo de versões deixa de ser trauma e vira rotina previsível.

Conclusão

Atualizar o GLPI com segurança é menos sobre comandos e mais sobre método. Quando você combina backup íntegro, leitura do changelog, teste em homologação e plano de rollback, o upgrade deixa de ser uma aposta e vira um procedimento controlado, com começo, meio e reversão prevista.

O GLPI 11 ainda adiciona um bom motivo para agir agora. Com ativos e formulários nativos, portal renovado e webhooks, a plataforma entrega de fábrica o que antes exigia plugins frágeis. Mesmo assim, o cuidado com a compatibilidade continua sendo o ponto que mais derruba upgrades apressados.

Se a sua equipe prefere não correr esse risco sozinha, a OpServices cuida do processo de ponta a ponta. Conheça a sustentação e implementação de GLPI da OpServices ou fale com os nossos especialistas para planejar um upgrade sem sustos, do backup à validação final.