Não entre em pânico: o guia do migrador de dados de CRM

A cena costuma começar assim: a empresa decidiu trocar de CRM. A decisão veio de cima, o contrato novo já está assinado, e a notícia chega para quem gerencia o atendimento junto com um detalhe que ninguém tinha mencionado: o sistema antigo desliga em duas semanas.

Dentro do sistema antigo tem quatro anos de tickets. Cada reclamação, cada troca de e-mail, cada promessa feita para cliente, cada anexo com nota fiscal. Tem o histórico que o time consulta todo dia para responder "isso já aconteceu antes?". E agora tudo isso precisa aparecer do outro lado, inteiro, em duas semanas.

O medo que bate nessa hora tem fundamento. Já vi migração em que todos os tickets entraram no sistema novo com a data de criação do dia da importação. Quatro anos de histórico viraram uma quinta-feira. Relatório de volume? Perdido. "Esse cliente reclama disso desde quando?" Desde quinta, aparentemente.

É por isso que eu roubei o conselho da capa do Guia do Mochileiro das Galáxias: não entre em pânico, em letras grandes e amigáveis. Migração de dados tem método. Antes de trabalhar com CRM eu passei cinco anos na Adobe movendo dados em larga escala com Hadoop e Spark, e trato migração de helpdesk do jeito que aprendi a tratar pipeline de dados lá: como uma sequência de etapas, e não como um copia e cola grande.

Este artigo é o processo que eu sigo, de ponta a ponta, construído em migrações envolvendo Zendesk, Freshdesk, Salesforce, Movidesk e Zenvia. Serve para quem vai contratar uma migração e quer entender o que está comprando, e serve para quem vai executar uma e quer um mapa.

Os três tipos de migração

A primeira conversa que eu tenho com um cliente sobre migração não é sobre ferramenta. É sobre o que ele quer que aconteça com o histórico. Dessa conversa saem três respostas possíveis, e eu chamo de tipo I, II e III.

Tipo I: o arquivo morto. A gente exporta tudo do sistema antigo e guarda num lugar consultável: um banco de dados, um conjunto de planilhas bem organizado, às vezes o próprio sistema antigo mantido em modo leitura por mais alguns meses. Nada disso entra no CRM novo. Escolha esse tipo quando o histórico importa por obrigação, auditoria ou consulta eventual, mas não faz parte da operação do dia a dia. O preço: quando alguém precisar de um ticket de 2023, vai procurar fora do CRM. É de longe a opção mais barata, e para muita empresa é o suficiente. Parte do meu trabalho é dizer isso em voz alta mesmo quando eu ganharia mais vendendo o tipo III.

Tipo II: a migração com campos legados. Os registros principais entram no CRM novo: clientes, tickets, conversas. Mas os campos específicos do sistema antigo não são traduzidos para o modelo do sistema novo. Eles ficam estacionados em campos de legado, um "legacy_status" aqui, um "legacy_categoria" ali. Escolha quando você precisa de continuidade rápida: o time abre o cliente e enxerga o histórico inteiro na mesma tela, mesmo que uma parte dele ainda esteja de mala pronta. O preço: você carrega o formato do sistema antigo para dentro do novo. Relatório em cima de campo legado é sempre meio torto, e um dia alguém vai perguntar por que existe um campo chamado legacy_fila_n2.

Tipo III: a migração completa. Cada campo da origem é mapeado deliberadamente para um campo do destino, ou descartado de forma consciente. Status vira status, prioridade vira prioridade, o campo customizado de lá vira um campo customizado equivalente de cá. O histórico se comporta como se sempre tivesse vivido no sistema novo: dá para filtrar, dá para fazer relatório, dá para automatizar em cima. Escolha quando o CRM novo é a casa definitiva e o histórico é parte da operação. O preço é tempo e dinheiro, porque a maior parte do esforço de uma migração completa está no mapeamento, e mapeamento bom se faz com gente do negócio na sala.

Não trate isso como um ranking em que o tipo III é a resposta certa e os outros são a versão pobre. É um controle entre custo e fidelidade, e o ponto certo depende do valor que o histórico tem para a operação. E os projetos reais quase sempre misturam os tipos: tipo III para os tickets abertos e recentes, que precisam funcionar de verdade no sistema novo, e tipo I para os milhares de tickets fechados de anos atrás, que só precisam existir em algum lugar. Pagar preço de migração completa em cima de dado que ninguém vai abrir é queimar orçamento.

Os três tipos

Tipo I

O arquivo morto

Um export completo, guardado num lugar consultável. Nada entra no CRM novo.

custo baixo histórico fora

Tipo II

Campos legados

Os registros principais entram; os campos antigos vão de carona como legacy_*, sem tradução.

continuidade rápida modelo torto

Tipo III

Mapeamento completo

Cada campo mapeado ou descartado de propósito. O histórico se comporta como nativo.

custo alto histórico nativo

menos esforço mais fidelidade

As pré-condições (ou: saiba onde está a sua toalha)

No Guia do Mochileiro, viajante que se preza sabe sempre onde está a sua toalha. Na migração, a toalha é o export completo dos dados. Antes de discutir mapeamento, cronograma ou qualquer outra coisa, a primeira providência é garantir uma cópia integral de tudo que existe no sistema de origem, guardada num lugar que é seu. Se o sistema antigo desliga em duas semanas, isso não é a primeira tarefa da lista. É a tarefa de hoje. CRM desligado não atende pedido de "só mais um export, por favor".

Depois da toalha, o resto das pré-condições:

Acesso de administrador nos dois sistemas. Não é conta de agente, é admin. Migração roda em cima de API, e as APIs de exportação em geral só entregam tudo para quem tem permissão sobre tudo. Boa parte dos atrasos de início de projeto que eu já vi era exatamente isso: esperando alguém descobrir quem é o dono da conta.

Alguém do negócio com tempo reservado. O mapeamento (daqui a pouco) não se escreve sozinho. Precisa de uma pessoa que saiba responder o que significa aquele campo "Fila 2 - especial" criado em 2021, e por que metade dos tickets está com ele vazio. Sem essa pessoa a migração trava. Ou pior: não trava, e alguém decide sozinho.

A decisão de tipo, por escrito. Tipo I, II ou III, ou a mistura, decidida e combinada antes da primeira linha de código. Mudar de tipo no meio do projeto é refazer o projeto.

O acesso aos dados

Com as pré-condições no lugar começa a parte técnica, e com ela a primeira surpresa: "exportar os dados" significa uma coisa diferente em cada sistema. Zendesk e Freshdesk têm APIs maduras e bem documentadas, que entregam tickets, conversas e contatos sem drama. O Salesforce te dá relatórios e APIs poderosas, mas o dado vive num modelo tão customizável que primeiro você precisa entender o que a empresa fez com ele ao longo dos anos. Movidesk e Zenvia têm APIs mais enxutas, e às vezes o caminho inclui exports em planilha para completar o que a API não entrega.

E tem o detalhe que separa quem já fez de quem está fazendo pela primeira vez: os anexos. O export te dá o ticket e o texto das conversas, mas os arquivos, os prints, o PDF da nota fiscal, a imagem colada no meio de uma resposta, tudo isso em geral vem como URL autenticada apontando para o servidor do sistema antigo. Migre o ticket e ignore os anexos, e no dia em que o sistema antigo desligar cada um desses links vira um 404. Baixar, guardar e re-hospedar anexo é frequentemente a parte mais lenta da extração inteira, e é a que ninguém coloca no orçamento.

O mapeamento

O mapeamento é a planilha mais importante do projeto: de um lado, cada campo do sistema de origem; do outro, para onde ele vai no destino, mais a regra de transformação no caminho. Campo por campo, com uma coluna de decisão: migra, vira legado ou morre. Parece burocrático e é. Também é o que decide se a migração vai prestar.

origem (Movidesk)        destino (Freshdesk)       decisão
Status "Aguardando"      Status "Pending"          de-para direto
Urgência 1 a 4           Priority Low a Urgent     traduz a escala
Fila N2                  legacy_fila (texto)       vira legado
Motivo do contato        (nenhum)                  morre, decisão do negócio

Só que campo é a parte fácil do mapeamento. A parte difícil são os relacionamentos. Um ticket não existe sozinho: ele aponta para o cliente que abriu, para o agente que respondeu, para a empresa do cliente. No sistema de origem esses vínculos são feitos por IDs, e nenhum desses IDs existe no destino. A migração precisa carregar primeiro as empresas, depois os contatos, depois os tickets, guardando a cada passo uma tabela de tradução: o cliente 4471 de lá é o cliente 892 de cá. Errou essa ordem, ou perdeu essa tabela, e o resultado é um CRM cheio de tickets órfãos, sem dono e sem cliente. Tecnicamente migrado. Na prática, inútil.

E tem a armadilha que eu mencionei lá no começo: as datas e as autorias. Todo CRM, ao receber um registro novo, carimba a data de criação como agora e o autor como o usuário da API. É o comportamento padrão. Se a migração não fizer nada a respeito, todos os tickets nascem no dia da carga, criados pelo "usuário integração". Os bons sistemas têm um jeito de preservar os valores originais na importação, mas quase nunca é o caminho padrão da API, e descobrir isso depois da carga é tarde demais. Essa é a pergunta que eu faria para qualquer fornecedor de migração: como vocês preservam a data e o autor originais? Quem já fez responde na hora.

A área de staging

Agora o conceito que eu trouxe da engenharia de dados, o que segura tudo junto: a área de staging. A ideia vem do Ralph Kimball, num livro clássico sobre ETL, e é simples: entre a origem e o destino existe um terreno neutro, um banco de dados intermediário que é seu, onde o dado extraído pousa antes de qualquer transformação.

Todo o trabalho acontece ali: a limpeza, o de-para de campos, a tradução de IDs, a conferência do que chegou. O sistema de origem é lido uma vez e depois deixado em paz. O sistema de destino só recebe dado quando o dado está pronto. E quando alguma coisa dá errado no meio, e alguma coisa sempre dá errado no meio, você corrige na staging e recarrega, sem estressar a API de ninguém e sem depender do sistema antigo continuar vivo.

A alternativa, transformar o dado em voo, lendo da origem e escrevendo direto no destino, funciona em demo e cobra caro em produção. Sem staging, cada erro te obriga a extrair tudo de novo. Com staging, o erro custa uma correção e uma recarga. Numa migração com prazo apertado, essa diferença é o projeto.

O pipeline

CRM de origem

Tickets e conversas

extraídos uma vez, via API

Contatos e empresas

quem aponta para quem

Anexos

URLs autenticadas

Área de staging

Terreno neutro

Limpar Mapear campos Traduzir IDs Preservar datas Validar

seu banco, suas regras

CRM de destino

Tickets

datas e autores originais

Clientes

vínculos refeitos

Anexos

re-hospedados, sem 404

O teste com amostra

Com a staging montada e o mapeamento escrito, a tentação é carregar tudo. Segura. Primeiro vai uma amostra: cem tickets, escolhidos a dedo para incluir os casos estranhos. O ticket com vinte respostas e três anexos. O que foi mesclado com outro. O do cliente que foi deletado do cadastro. O que tem emoji no assunto e acento em tudo quanto é campo, porque a gente escreve em português e encoding quebrado é uma tradição.

A amostra entra no CRM novo e aí vem a parte importante: quem valida não sou eu, é o cliente. A pessoa do negócio abre esses cem tickets no ambiente novo e confere se eles contam a história certa: as datas batem, as conversas estão na ordem, o anexo abre, o campo que importa está onde deveria. É nessa validação que aparecem as surpresas baratas de achar cedo, do tipo "ah, esse campo a gente lia de outro jeito". Corrige o mapeamento, roda outra amostra, e só quando uma amostra sai limpa é que a carga grande entra no calendário.

A carga

A carga completa é a parte mais previsível do projeto e a mais mal compreendida no cronograma. O motivo tem nome: rate limit. A API do CRM de destino aceita um número limitado de requisições por minuto, e a matemática não perdoa. Uma base com 180 mil tickets, cada um com suas conversas e anexos, pode facilmente significar mais de um milhão de chamadas de API. Divide isso pelo limite da plataforma e o resultado se mede em dias, não em horas. Quem promete migrar uma base grande "no fim de semana" ou não fez a conta ou vai estourar o limite, ser bloqueado pela plataforma e ver a migração parar no meio.

Por isso a carga é desenhada para rodar sozinha e sobreviver a tropeços: em lotes, com pausa entre chamadas para respeitar o limite, com retry para quando a API engasgar, e idempotente, uma palavra feia para uma ideia simples: se o processo cair no meio e você rodar de novo, ele continua de onde parou em vez de duplicar os dez mil tickets que já tinham entrado. A staging ajuda de novo aqui, porque é nela que fica a contabilidade: o que já foi, o que ainda falta.

A data de corte

Enquanto a carga roda, a operação continua atendendo, e a cada hora que passa nascem tickets novos no sistema antigo. É aqui que entra a decisão mais operacional do projeto: a data de corte. A partir deste momento, toda conversa nova nasce no sistema novo; o que está no antigo congela e vira passado.

O desenho que costuma funcionar: primeiro migra o histórico, aquela massa de dados que não muda mais, com calma, durante a semana. Chegando a data de corte, o time vira a chave e passa a atender no sistema novo. E aí roda uma segunda migração, pequena, só do delta: os tickets que nasceram ou mudaram no antigo entre o início da carga e o corte. Assim ninguém para de atender enquanto o histórico atravessa, e o trecho desconfortável com um pé em cada canoa dura horas, não semanas. Vale combinar também o plano B: se algo der errado na virada, o sistema antigo continua acessível em modo leitura até tudo estar conferido. Ninguém desliga nada no dia do corte.

A checagem pós-migração

Migrou, acabou? Ainda não. A última etapa é a conferência, e ela tem dois níveis.

O primeiro é o dos números: contagem por entidade, origem contra destino. Tantos mil clientes lá, tantos mil aqui. Tickets, conversas, anexos, a mesma conta. Qualquer diferença precisa de explicação por escrito, e "sumiu uns" não é explicação. Em geral a diferença tem causa boa, tipo tickets de spam deixados para trás de propósito, mas isso precisa estar no papel.

O segundo nível é o humano: uma rodada final de conferência por amostragem, com o time de atendimento abrindo tickets antigos no sistema novo durante os primeiros dias de operação e reportando qualquer coisa estranha. É o mesmo espírito da amostra, agora com a base inteira e com quem usa de verdade.

E duas providências de despedida. O export completo do começo, a toalha, fica arquivado, porque ele é a sua cópia de segurança da verdade original. E a área de staging, que carrega dado pessoal de cliente, é destruída depois que tudo foi validado. Cópia intermediária de dado pessoal não é lembrancinha de viagem. Não se guarda.

Não entre em pânico

Volto ao gerente do começo, com o sistema desligando em duas semanas. O que o processo desta página muda não é o prazo, é o pânico. Duas semanas continuam sendo pouco, mas viram uma sequência de decisões conhecidas: garante o export hoje, decide o tipo, mapeia com alguém do negócio do lado, testa com amostra antes de carregar, vira a chave numa data combinada e confere antes de comemorar.

Migração de dados de CRM é um daqueles trabalhos que, bem feito, ninguém nota. O time abre o sistema novo na segunda-feira, o histórico está lá, as datas batem, o anexo abre, e a vida segue. É exatamente esse anticlímax que a gente persegue.

Se tem uma migração dessas no seu horizonte, com prazo apertado ou não, vem trocar uma ideia com a gente na Red Lotus.

Leandro é fundador da Red Lotus Tecnologia, especializada na implementação, suporte e evolução de Freshdesk para times de atendimento no Brasil.

Citados neste artigo

• Ralph Kimball e Joe Caserta. "The Data Warehouse ETL Toolkit." Wiley, 2004.
• Douglas Adams. "O Guia do Mochileiro das Galáxias." 1979. A parte da toalha é o capítulo 3.