Recentemente, um cliente nos procurou com um problema que a maioria das empresas de serviços em crescimento reconhecerá. Seu trabalho estava distribuído entre o ClickUp e Freshservice. Eles queriam permissões mais granulares para seus contratos com clientes, que são altamente regulamentados, e a capacidade de automação necessária para fornecer um atendimento ao cliente consistente e em escala. Eles decidiram qual caminho seguir: HaloPSA, e concluíram que essa ferramenta poderia substituir ambas as outras. No entanto, havia um obstáculo: eles precisavam manter anos de dados históricos dos quais seus clientes dependiam para a continuidade do serviço. Isso significava que o empecilho para a migração para uma nova ferramenta seria a tarefa que ninguém gosta de fazer: a migração de dados.
A solução tecnológica geralmente já está clara quando somos chamados — existe uma plataforma de destino que funcionaria melhor. O obstáculo não é qual ferramentausar, mas sim o receio de que o processo seja lento, caro e imprevisível. Que os chamados sejam perdidos, que os relatórios falhem, que as equipes se rebelem, que os órgãos reguladores ou os clientes se oponham e que os custos ultrapassem o limite.
Mas nada disso é inevitável. Se bem executada, a migração de dados não deve ser um obstáculo para que sua empresa utilize as ferramentas certas. A consolidação pode — e deve — ser uma oportunidade para melhorar a forma como a empresa opera, e não apenas para mover dados de um ponto A para um ponto B. Veja como abordamos o processo.
As duas metades da consolidação
Um projeto de consolidação tem duas metades que são fáceis de confundir, mas muito diferentes em sua natureza.
A primeira etapa é a movimentação de dados — transferir tickets, comentários, anexos, usuários, campos personalizados e registros históricos das plataformas de origem para o destino. Este é um trabalho genuinamente técnico. Para qualquer caso que não seja o mais simples, você precisará trabalhar com APIs, frequentemente em uma ordem estrita, porque os anexos dependem dos tickets, os comentários dependem dos usuários, os campos personalizados dependem dos esquemas e assim por diante. Importações de arquivos simples resolvem parte do problema, mas não o resolvem completamente. É exatamente para esse tipo de trabalho que existem ferramentas especializadas — como Help Desk Migration .
O segundo ponto é a do modelo operacional — decidir como a nova plataforma deve funcionar na prática para a empresa. Quais categorias de trabalho fluem por ela? Como é um bom relatório? Quem é responsável por quais filas? Quais novos recursos estão disponíveis — faturamento e emissão de notas fiscais, autoatendimento ao cliente, gestão integrada de mudanças — que não eram possíveis antes, e quais deles valem a pena ativar agora em vez de depois?
Essas duas partes precisam uma da outra. Fazer apenas a primeira resulta na antiga bagunça em um novo sistema. Fazer apenas a segunda deixa você preso, porque os dados históricos não serão importados.
Onde a maioria dos projetos de consolidação falha é ao tratá-los como um mero exercício de migração de dados. Os maiores ganhos — e os maiores riscos — estão no modelo operacional.
Por que a consolidação é mais difícil do que parece
Parte da complexidade é genuinamente técnica. Parte é organizacional. As armadilhas que vemos com mais frequência são:
1. O mapeamento de dados não é organizado. Diferentes ferramentas estruturam os mesmos conceitos de maneiras diferentes. Nomes de status, níveis de prioridade, tipos de tickets, campos personalizados, categorias, tipos de requisição — quase nada se mapeia diretamente. A parte difícil não é escrever o mapeamento; é decidir qual deve ser o mapeamento, o que força decisões sobre o modelo operacional antes que você esteja preparado para elas.
2. O modelo de agente/usuário/cliente varia entre as ferramentas. Algumas plataformas separam agentes internos de usuários externos e clientes externos como três tipos de entidade distintos. Outras os mesclam. Algumas permitem que agentes sejam parceiros externos; outras não. A forma como Freshservice modela pessoas não é a mesma que a Halo , nem a Jira Service Management . Migrar usuários raramente é um copiar e colar — é uma tradução, e as escolhas que você faz aqui moldam permissões, relatórios e licenciamento por anos.
3. Campos personalizados e tipos de tickets se acumulam. A maioria dos sistemas de origem tem anos de personalização acumulada, algumas úteis, muitas esquecidas. Migrar tudo de uma vez recria o mesmo problema de manutenção em uma nova ferramenta. Migrar apenas o necessário força conversas difíceis com as pessoas que criaram esses campos.
4. As permissões ficam mais complicadas, não menos. Uma plataforma consolidada geralmente tem mais equipes usando-a do que qualquer fonte individual. Isso significa novos modelos de permissão, novas regras de visibilidade e um padrão mais alto para fazer tudo certo — porque os erros são mais visíveis.
5. Os relatórios são onde os erros aparecem primeiro. Os sistemas de origem geralmente têm relatórios que dependem de estruturas de campo, status ou convenções de nomenclatura específicos. Quando esses elementos mudam no destino, os relatórios param de funcionar — e as partes interessadas percebem imediatamente. Os requisitos de relatório devem ser projetados durante a migração, não adicionados posteriormente.
6. Geralmente, você precisará de um ensaio geral completo da migração. Não uma amostra, não uma parcial — uma migração completa de UAT com dados reais, no destino configurado, executada pelas pessoas que realmente usarão o novo sistema. É aqui que surgem as verdadeiras surpresas: formatos de dados inesperados, decisões de mapeamento que se mostram erradas, integrações que precisam de ajustes. Reserve o tempo e o custo para isso. Tentar pular esta etapa é o atalho mais caro na consolidação.
7. Requisitos regulatórios e do cliente frequentemente ditam o que deve ser preservado. Às vezes, um cliente quer "deixar o sistema antigo para trás e começar do zero" — mas seus próprios clientes, ou seus órgãos reguladores, exigem que os tickets, comentários e anexos históricos sejam mantidos para fins de auditoria. Isso muda completamente o escopo da migração, porque o histórico de comentários e anexos é a parte que exige mais trabalho com a API e o sequenciamento mais cuidadoso. Já tivemos projetos em que o requisito de retenção de dados foi o único motivo pelo qual o projeto de migração se tornou complicado. Descubra isso logo no início.
Uma abordagem prática
Todas as consolidações que realizamos seguiram um padrão semelhante. Os rótulos importam menos do que o pedido.
1. Entenda o que está sendo usado na prática. Antes de mapear qualquer coisa, descubra como os sistemas de origem são usados atualmente — não como deveriam ser usados, e nem o que diz a documentação. Obtenha relatórios de uso. Converse com as pessoas que executam o trabalho. Geralmente, você descobrirá que uma parcela significativa da personalização no sistema de origem está inativa ou não é mais relevante. Isso não é um problema; é uma oportunidade para consolidar em um destino mais simples.
2. Defina o modelo operacional de destino. Esta é a pergunta que sempre fazemos: o que você quer que a nova plataforma faça pelo negócio que as antigas não fazem? Relatórios de SLA melhores? Faturamento e emissão de notas fiscais integrados? Portais de autoatendimento para solicitações? Gerenciamento de mudanças vinculado a um CMDB? Cada um desses recursos direciona a configuração para um objetivo específico. Decida o que você está otimizando antes de começar a mapear os dados.
3. Projete o mapeamento de dados com base no novo modelo, não no antigo. O erro que a maioria das equipes comete é mapear a estrutura de dados de origem diretamente para o destino. A abordagem correta é mapear os dados de origem por meio do modelo operacional de destino — quais campos merecem seu lugar, quais são arquivados, quais são desativados e quais são consolidados. É aqui que as decisões do modelo operacional e a migração técnica convergem.
4. Execute migrações de teste direcionadas. Antes do ensaio geral completo, — os tickets de uma única equipe, um fluxo de trabalho personalizado ou um grupo de usuários — para validar se a lógica de mapeamento e o sequenciamento da API realmente funcionam de ponta a ponta. Esses testes curtos detectam problemas enquanto são baratos de corrigir.
5. Execute uma migração completa de UAT (Teste de Aceitação do Usuário). O ensaio geral. Dados completos, configuração completa, usuários reais testando cenários reais. Planeje o tempo. Esta é a etapa que determina se a transição real será tranquila ou caótica.
6. Faça a transição com um plano, não com base na esperança. Comunicações, critérios de reversão, cobertura de suporte, quem decide o quê durante o período de teste. A transição em si geralmente é anticlimática se o UAT foi completo.
7. Ofereça suporte adequado à adoção. Uma nova ferramenta que funciona perfeitamente, mas que ninguém usa, é um projeto fracassado. A adoção requer defensores internos, documentação clara, treinamento que corresponda à forma como as pessoas realmente trabalham e apoio visível da liderança. Essa é a parte que os projetos de migração puramente técnicos subestimam sempre.
Um exemplo recente
A migração teve que lidar com três formatos de dados diferentes:
- Documentos do ClickUp, onde a estrutura era semelhante a uma wiki e vinculada a projetos
- Tarefas do ClickUp, onde o modelo era aninhado e levava em consideração as dependências
- Tickets do Freshservice, onde o modelo era um esquema de ticket clássico com comentários, anexos e relações de solicitante
Cada um desses elementos precisava ser mapeado — não em uma réplica exata de como existiam na origem, mas sim no modelo operacional que havíamos projetado para o destino. Os documentos iam para um lado, as tarefas para outro, os tickets para um terceiro e, em alguns casos, era necessário fazer referências cruzadas, pois o mesmo trabalho de negócios era representado em diferentes sistemas.
Existe uma alternativa "faça você mesmo" para esse tipo de trabalho: escrever scripts de migração diretamente nas APIs de origem e destino. É algo que já fizemos em projetos anteriores, e as ferramentas de IA estão tornando o processo mais rápido. Mas em projetos onde os formatos de dados são variados, a configuração de destino é complexa e o cronograma é crucial, usar as ferramentas especializadas da Help Desk Migrationreduz significativamente os riscos da migração de dados e otimiza o tempo. Isso nos permitiu focar no que o cliente realmente buscava: a configuração, o design da automação e o modelo de permissões.
O resultado que importava para o cliente não era "migramos os dados com sucesso". Era que a nova plataforma lhes proporcionasse os controles e as automações de que seus negócios precisavam — sem perder o histórico de dados do qual seus clientes dependiam. Essa é a diferença entre um projeto de migração de dados e um projeto de consolidação.
Observamos dinâmicas semelhantes quando o destino é uma plataforma PSA — que integra recursos de faturamento, emissão de notas fiscais, análise de rentabilidade de projetos e controle de tempo, além do trabalho operacional. Para um exemplo prático de consolidação no HaloPSA, consulte nosso estudo de caso recente sobre bdq.cloud.
Onde Help Desk Migration se encaixa
Não pretendemos ser uma empresa de ferramentas de migração de dados. O trabalho técnico de criar e executar scripts de migração para múltiplas APIs de plataforma, na sequência correta, lidando com casos extremos como anexos, comentários e mapeamentos de usuários — isso é uma arte especializada, e Help Desk Migration é realmente muito boa nisso.
Igualmente importante, ferramentas especializadas mantêm o custo e o cronograma da migração de dados previsíveis. Os gastos com a migração devem ser uma rubrica conhecida, não um risco indefinido — e, quando são conhecidos, a justificativa comercial para a consolidação mais ampla torna-se muito mais fácil de aprovar.
O ponto ao qual sempre retornamos
A migração de dados não deve ser um obstáculo para a utilização das ferramentas certas em sua empresa. Pode ser cara, demorada e arriscada, mas com os parceiros certos e a abordagem adequada, não é motivo para permanecer em uma plataforma que já não atende às suas necessidades.
As organizações que mais se beneficiam da consolidação são aquelas que a encaram como uma oportunidade para aprimorar o modelo operacional, e não apenas para transferir dados. Os detalhes técnicos de scripts de API e mapeamento de campos não devem ser o foco do valor para o negócio. O valor reside em relatórios melhores, processos mais eficientes, maior automação e equipes que conseguem visualizar e agir de fato no trabalho que realmente importa.
Se você está considerando uma consolidação, a pergunta inicial não é "como migramos os dados?", mas sim "como isso deve ficar depois da conclusão?". A questão dos dados virá em seguida.
Sobre a BDQ
A BDQ Cloud é uma consultoria de TI sediada em Londres, especializada em migração, consolidação e modernização de plataformas de gestão de serviços. Trabalhamos com HaloITSM, Atlassian, Freshworks, Asana e outras ferramentas modernas, e temos parceria com Help Desk Migration para o trabalho técnico de migração de dados que sustenta nossos projetos de consolidação. Se você gostaria de discutir um desafio específico de consolidação, oferecemos uma avaliação de migração de 30 minutos focada no modelo operacional e nos resultados esperados, e não apenas nos dados.
