Migrar para o GLPI: plano, etapas e o que avaliar

Migrar para o GLPI deixou de ser uma decisão técnica isolada. Hoje, é uma escolha estratégica de quem cansou de pagar por agente, por ticket ou por módulo em um help desk proprietário. A plataforma entrega gestão de chamados, inventário e ativos em uma base open source, sem que essa conta cresça junto com a equipe.

No entanto, trocar de ferramenta envolve mais do que instalar um servidor novo. O histórico de chamados, os anexos, a base de conhecimento e o inventário precisam chegar do outro lado íntegros. Por isso, este guia trata a migração como um projeto: diagnóstico, mapeamento, importação, validação, go-live e plano de rollback.

Antes de seguir, vale entender o que é o GLPI e onde ele se encaixa na sua operação. A partir daí, fica mais simples decidir de qual ferramenta você sai, o que leva junto e quanto esforço o projeto realmente exige.

Por que migrar para o GLPI

O principal motivo costuma ser financeiro. Ferramentas proprietárias cobram por agente. Esse custo escala rápido quando a operação cresce e novos atendentes entram no time. O GLPI usa a licença GPL, ou seja, você não paga pela ferramenta em si.

Além do custo, pesa o lock-in. Em uma suíte fechada, você depende do roadmap do fornecedor e de conectores limitados. Com a plataforma aberta, a comunidade e a API liberam a customização de fluxos e a integração com o restante do seu gerenciamento de serviços de TI.

Há ainda a soberania dos dados. Manter chamados e ativos em servidor próprio facilita a adequação à Lei Geral de Proteção de Dados. Dessa forma, o time de segurança sabe exatamente onde a informação reside e quem acessa cada registro.

Vale também olhar a customização. A plataforma permite criar campos, formulários e regras de negócio sem depender de um pacote pago. Assim, o fluxo de atendimento se molda ao seu processo, não o contrário. Para muitas equipes, essa flexibilidade pesa tanto quanto a economia de licença.

Por outro lado, migrar nem sempre é a melhor escolha imediata. Se a sua suíte atual está no meio de um contrato caro ou se o time não tem fôlego para um projeto agora, o momento pode não ser ideal. Avalie o ganho real antes de abrir a frente de trabalho.

De quais ferramentas se migra para o GLPI

Cada origem tem um caminho diferente. Não existe um importador único universal, portanto a estratégia muda conforme a ferramenta atual exporta os dados. Em geral, o trabalho combina exportação em CSV, chamadas de API e scripts de transformação.

Quem já opera com o OTRS, por exemplo, costuma carregar filas e histórico extensos, que precisam de mapeamento cuidadoso. Já operações em SaaS, como o Zendesk, dependem da API para extrair tickets e usuários. A tabela abaixo resume o caminho típico de cada origem.

 
Independentemente da origem, o segredo está na fase de mapeamento. Categorias, prioridades, status e grupos de atendimento precisam de um equivalente no destino antes da carga. Quando esse de-para fica claro, a importação vira trabalho mecânico e previsível.

Esse cuidado inicial também encurta a fase de validação, porque menos itens caem em exceção depois da carga. Em síntese, quanto mais tempo você investe no mapeamento, menos retrabalho aparece perto do go-live.

O que dá para migrar (e o que exige atenção)

Em tese, quase tudo migra. Na prática, cada objeto carrega um nível de risco diferente. O histórico de chamados é o mais sensível, porque sustenta auditoria e indicadores de SLA. Os anexos, por sua vez, exigem cuidado com o vínculo entre o arquivo e o ticket de origem.

Os SLAs são um caso especial. Em vez de importar prazos, você recria as regras de atendimento no destino, com calendários e escalonamentos. Trate isso como configuração, não como migração de dados. Reserve tempo específico para validar cada meta de prazo antes do go-live.

No lado de ativos, vale aproveitar o inventário nativo da plataforma para redescobrir a rede, em vez de só importar planilhas antigas. Quando você precisa importar a base de ativos, combine o reinventário automático com a carga dos contratos e licenças que a varredura não enxerga.

Essa etapa conecta diretamente com a sua gestão de ativos de TI, já que o destino passa a ser a fonte única de hardware, software e contratos. Vale validar os modelos de dados com a documentação oficial do projeto antes da carga definitiva.

Base de conhecimento e usuários

A base de conhecimento merece atenção à parte. Artigos costumam ter imagens, links internos e formatação que nem sempre sobrevivem a um export simples. Por isso, revise uma amostra dos artigos importados antes de considerar essa frente concluída.

Já usuários e entidades dão menos trabalho quando existe um diretório corporativo. Com LDAP ou Active Directory integrado, o login e a estrutura organizacional se reconstroem quase sozinhos. Os perfis e as permissões, no entanto, pedem revisão manual após a carga.

Plano de migração passo a passo

Um projeto saudável segue seis fases bem definidas. Cada uma reduz o risco da seguinte, por isso pular etapas costuma sair caro. A seguir, veja o que acontece em cada fase, do levantamento inicial até o plano de retorno.

Diagnóstico e mapeamento

Primeiro, o diagnóstico levanta o volume de chamados, as customizações e as integrações ativas. Esse retrato evita surpresas no meio do caminho. Em seguida, o mapeamento traduz categorias, status e SLAs da origem para o modelo de entidades do destino.

O de-para é o coração do projeto. Quanto mais detalhado, menor o risco de um chamado antigo cair em uma categoria errada. Vale documentar cada decisão em uma planilha que o time inteiro consiga consultar durante a carga.

Importação e validação

Depois, você prepara o ambiente, executa a importação em uma instância de teste e valida amostras antes do corte. A importação programática via API ajuda a carregar chamados em lote, sem digitação manual e com menos erro humano.

# Importa um chamado migrado via API REST (carga programatica)
curl -X POST "$GLPI_URL/apirest.php/Ticket" \
  -H "Session-Token: $TOKEN" \
  -d '{"input":{"name":"Chamado migrado","content":"texto"}}'

 
Com a carga de teste pronta, compare os números: total de chamados, de ativos e de usuários na origem e no destino. Se as contagens batem e as amostras abrem corretamente, o ambiente fica pronto para o corte real.

Go-live e rollback

Com os dados validados, chega o go-live. Esse é o momento de configurar os chamados após a migração, revisar permissões e treinar o time. Antes de desligar o sistema antigo, reconcilie os ativos em uma CMDB confiável.

Por fim, nenhum corte acontece sem plano de rollback. Mantenha o sistema de origem em modo leitura por algumas semanas. Assim, se algo crítico falhar, a operação retorna ao estado anterior sem perder os chamados que ficaram abertos durante a transição.

Riscos comuns e como mitigar

O risco mais citado é a perda de histórico. Ele aparece quando o mapeamento de categorias fica incompleto ou quando os IDs não batem entre origem e destino. Por isso, valide amostras grandes, não apenas três ou quatro chamados de exemplo escolhidos a dedo.

Outro ponto sensível é a paridade de SLA. Regras de prazo da ferramenta antiga raramente têm equivalente exato no destino. Vale destacar que recriar SLAs com calendários e escalonamentos pede tempo de configuração, não só importação de dados.

Por fim, cuidado com a janela de corte. Migrar tudo na sexta à noite parece seguro, mas concentra risco em um único momento. Em contrapartida, um corte gradual por equipe ou por entidade reduz o impacto e facilita o suporte nos primeiros dias.

Não subestime a adoção pelo time. Uma migração tecnicamente perfeita falha se os atendentes resistem à ferramenta nova. Por isso, inclua treinamento no cronograma e indique uma referência interna que tire dúvidas nas primeiras semanas de uso.

Migração assistida ou interna

Times com folga de pessoal e baixa complexidade conseguem tocar a migração internamente. No entanto, quando há muitas customizações, integrações críticas ou volume alto de histórico, a migração assistida reduz o tempo de projeto e o risco de retrabalho.

A OpServices oferece serviço de migração e implementação de GLPI, do diagnóstico ao go-live. Dessa forma, o seu time foca na operação enquanto especialistas cuidam do mapeamento, da carga e da validação dos dados em cada etapa.

Uma boa forma de decidir é medir o custo de oportunidade. Quantas horas o seu time gastaria aprendendo a importar dados em vez de atender chamados? Quando essa conta fica alta, o apoio especializado costuma se pagar já nos primeiros meses de operação.

Conclusão

Migrar para o GLPI é menos sobre instalar um software e mais sobre transportar a sua operação com segurança. Quando você trata o projeto por fases, do diagnóstico ao rollback, o histórico chega íntegro, os ativos batem com a realidade e o time adota a ferramenta sem trauma.

A recompensa é direta: fim do custo por agente, liberdade para customizar fluxos e dados sob o seu controle. Em resumo, a migração bem planejada paga o esforço inicial com economia recorrente e mais autonomia para a TI.

O caminho mais seguro começa por um diagnóstico honesto do seu ambiente atual, das customizações e das integrações que não podem parar. Se você quer um plano de migração sob medida, fale com um especialista da OpServices e estruture cada etapa com quem já fez essa travessia.