Editoriais
Como trocar de sistema de chamados sem perder o histórico
Neste artigo· 7 seções
TL;DR: Trocar de sistema de chamados trava menos por preço e mais por medo de perder o histórico. Neste artigo: o que realmente se perde numa migração mal feita, os quatro níveis de dado que um service desk guarda, as três formas de migrar (CSV, API e integração nativa) com o que cada uma consegue trazer, as sete perguntas para fazer ao fornecedor antes de assinar e um roteiro de corte seguro.
A conversa sobre trocar de sistema de chamados quase nunca morre no preço. Ela morre numa frase: “e tudo o que a gente já registrou, vai para onde?”
É uma preocupação legítima. Uma operação de suporte com três anos de uso acumula dezenas de milhares de tickets, e esse acervo não é lixo. É a memória de como cada problema foi resolvido, quem resolveu, quanto tempo levou e qual cliente já reclamou da mesma coisa cinco vezes. Perder isso significa recomeçar do zero a inteligência da operação, mesmo mantendo a equipe.
O resultado é previsível: empresas insatisfeitas com o sistema de chamados atual seguem nele por anos, pagando por uma ferramenta que já não atende, porque a troca parece mais cara do que o incômodo.
Este artigo trata de como avaliar esse risco com critério, antes de assinar qualquer coisa.
O que um service desk guarda, em quatro camadas
O erro mais comum é tratar “histórico” como uma coisa só. Não é. Existem quatro camadas de dado, e elas migram com dificuldades bem diferentes.
1. O ticket em si. Número, título, descrição, data de abertura e fechamento, status, prioridade, solicitante e responsável. É a camada mais fácil: praticamente toda ferramenta exporta e importa isso.
2. A conversa. Todas as interações do chamado, na ordem certa, com autor e data. Aqui já começa a complicar, porque cada sistema estrutura a thread de um jeito, e é comum a migração trazer o ticket e deixar a conversa para trás, ou juntar tudo num campo único de texto.
3. Os anexos. Print de tela, log, documento, áudio. São arquivos, não registros, e muitas migrações simplesmente ignoram. O ticket chega, a frase “segue o print em anexo” chega, e o print não.
4. A camada de configuração e relacionamento. Categorias, filas, SLAs, base de conhecimento, cadastro de clientes, contratos e o vínculo entre chamado e ativo de TI. Essa é a mais trabalhosa e a mais esquecida na hora de negociar.
A pergunta certa para o fornecedor não é “vocês migram o histórico?”. É “quais dessas quatro camadas vocês migram, e o que acontece com o que não vier?”.
As três formas de migrar, e o que cada uma entrega
| Método | O que costuma trazer | Esforço | Risco principal |
|---|---|---|---|
| Export CSV manual | Ticket e campos básicos | Alto, trabalho manual de mapeamento | Conversa e anexos ficam para trás |
| Script via API | Ticket, conversa e, com trabalho, anexos | Alto, exige desenvolvimento | Depende de quem mantém o script; limite de requisição da API de origem |
| Integração nativa com o sistema de origem | Ticket, conversa e anexos, conforme o que o fornecedor implementou | Baixo para o cliente | Só existe para os sistemas que o fornecedor escolheu suportar |
Export CSV é o caminho padrão e o mais arriscado. Funciona para inventário de tickets, serve para auditoria, e é ruim para operação: ninguém abre uma planilha de 40 mil linhas para entender o que aconteceu no chamado de um cliente.
Script via API resolve bem, e custa. Alguém precisa escrever, testar e rodar, lidando com limite de requisição, paginação e formato de anexo. Em geral é projeto de semanas, e o custo some da negociação porque entra como hora de time interno, não como linha na proposta.
Integração nativa é o cenário confortável, e o mais restrito: só existe quando o fornecedor de destino investiu em construir o conector para aquele sistema específico de origem. Por isso vale perguntar pelo nome do seu sistema atual, não pela existência genérica de “ferramenta de migração”.
O caso do GLPI, que é o mais comum no Brasil
Entre as empresas brasileiras que já operam um service desk estruturado, o GLPI é o ponto de partida mais frequente. É open source, roda há anos em muita operação de TI, e por isso mesmo costuma ser onde está o acervo mais antigo.
É também o caso em que a diferença entre os três métodos aparece com mais clareza. Como a base é acessível, dá para extrair quase tudo via banco ou API. O problema é que “dá para extrair” não é o mesmo que “alguém vai extrair”: na prática, a migração do GLPI acaba virando CSV de tickets fechados, e a conversa fica no servidor antigo, que ninguém desliga por medo.
Entre as plataformas do mercado brasileiro, o Milvus TI construiu integração nativa para esse cenário, importando o histórico de chamados direto da instalação de origem, sem export manual. A mesma importação cobre quem vem de outras plataformas usadas no Brasil, como Movidesk e Tiflux, o que vale verificar caso o seu sistema atual não seja o GLPI. Plataformas internacionais como Zendesk Suite, Freshdesk e Zoho Desk trabalham com API e ferramentas genéricas de importação, o que funciona, mas joga o trabalho de mapeamento para o lado de quem está migrando.
A diferença entre os dois modelos não é de qualidade do produto. É de onde o esforço cai.
Sete perguntas para fazer antes de assinar
- Quais dos quatro níveis vocês migram? Ticket, conversa, anexo e configuração. Peça a resposta por escrito.
- Existe integração nativa com o meu sistema atual, pelo nome? Resposta genérica sobre “suporte a migração” não conta.
- Qual o limite de volume? Algumas importações travam acima de certo número de registros, e isso só aparece no dia.
- A numeração dos chamados é preservada? Parece detalhe, e não é: cliente e contrato referenciam número de chamado.
- O que acontece com os chamados abertos no dia do corte? Migram em andamento ou precisam ser fechados antes?
- Quem executa a migração, e está no preço? Serviço do fornecedor, parceiro de implantação ou seu time.
- Dá para testar antes? Uma migração piloto com uma amostra vale mais que qualquer promessa comercial.
Roteiro de um corte seguro
Antes. Levante o volume real, por tipo de registro. Defina o que é essencial e o que pode ficar em arquivo morto, porque migrar tudo nem sempre vale o custo. Combine uma janela de congelamento curta, em que nada novo entra no sistema antigo.
Durante. Rode a migração piloto com uma amostra representativa, incluindo um chamado antigo, um com muitos anexos e um com conversa longa. Confira os três manualmente, um por um. Só então libere o restante.
Depois. Mantenha o sistema antigo em modo leitura por um período, normalmente de 60 a 90 dias. É a sua rede de segurança, e custa pouco perto do risco de descobrir uma lacuna tarde demais. Só desligue depois de uma auditoria por amostragem.
Se a certificação de segurança do fornecedor for parte da avaliação, vale ler também o que muda na homologação com ISO 27001, já que a migração envolve justamente o transporte de dado sensível entre dois ambientes.
Perguntas frequentes
É possível migrar o histórico de chamados entre sistemas diferentes?
Sim, mas o resultado varia. Ticket e campos básicos migram em praticamente qualquer cenário. Conversa completa, anexos e configuração dependem do método e do que o fornecedor de destino implementou.
Quanto tempo leva uma migração de service desk?
De poucos dias, quando existe integração nativa e o volume é moderado, a várias semanas, quando é preciso desenvolver script via API e mapear campos manualmente. O que mais pesa não é o volume, é o número de camadas de dado envolvidas.
Dá para migrar os anexos dos chamados?
Depende do método. Export CSV normalmente não leva anexo. Via API e via integração nativa é possível, desde que esteja previsto no escopo. É o item que mais some sem ninguém perceber, então precisa estar escrito.
Preciso fechar todos os chamados antes de migrar?
Nem sempre. Alguns sistemas importam chamados em andamento com status preservado, outros exigem base fechada. Essa é uma das perguntas que define o cronograma do corte.
Vale a pena manter o sistema antigo no ar depois da troca?
Sim, em modo leitura, por 60 a 90 dias. É barato e evita o cenário pior, que é descobrir uma lacuna de dado quando o ambiente de origem já foi desligado.
A numeração dos chamados muda depois da migração?
Pode mudar, e isso precisa ser verificado antes. Quando a numeração não é preservada, convém manter o número antigo registrado em um campo próprio, para não quebrar referências em contratos e históricos de cliente.
O que levar dessa leitura
Perder o histórico não é consequência inevitável de trocar de sistema. É consequência de migrar sem definir o que precisa vir.
Quem trata a migração como linha de negociação, com as quatro camadas nomeadas e um piloto antes do corte, costuma fazer a troca sem drama. Quem trata como detalhe técnico para resolver depois é quem perde dado, e normalmente descobre meses depois, quando precisa consultar um chamado que não existe mais.
Próximo passo: compare plataformas de service desk lado a lado usando capacidade de migração como critério, veja as alternativas ao GLPI por cenário de uso ou consulte avaliações reais de usuários no perfil do Milvus TI.
