Migrar de CRM sem perder histórico: o que planejar antes da virada

Quase toda empresa que decide trocar de CRM trava no mesmo ponto. Não é o preço da licença nova, nem o tempo de configuração. É uma frase: "e todo o histórico que a gente tem lá dentro?". São anos de contatos, negócios fechados, propostas, conversas e observações que alguém digitou no meio de uma negociação. A sensação é de que trocar de sistema significa começar do zero, e essa sensação segura projetos por meses. Este texto trata exatamente disso: o que dá para migrar, o que não dá, o que precisa ser reconstruído e como conduzir a virada sem parar de vender.

Primeiro: o que você chama de histórico

A palavra "histórico" esconde camadas bem diferentes, e cada uma tem custo, risco e valor distintos. Antes de qualquer orçamento de migração, vale separar o que existe hoje:

• Cadastros: contatos, empresas, endereços, telefones, e-mails, documentos.
• Negócios: oportunidades abertas e fechadas, com valor, etapa, responsável e datas.
• Campos personalizados: aquilo que a sua operação criou porque o padrão não bastava.
• Atividades: ligações registradas, tarefas, notas e comentários dos vendedores.
• Conversas: threads de e-mail e mensagens de WhatsApp ligadas ao cliente.
• Arquivos: propostas, contratos assinados, planilhas de cálculo, fotos, laudos.
• Estrutura: usuários, equipes, permissões, funis, produtos e tabela de preços.
• Configuração: automações, integrações, relatórios e painéis já montados.

Quando um fornecedor diz "migramos tudo" sem perguntar quais dessas camadas existem no seu caso, ele está prometendo antes de saber. Migração honesta começa por um inventário, não por uma promessa.

O que migra bem, o que migra com esforço e o que não migra

Migra bem

Cadastros de contato e empresa, negócios com campos padrão, catálogo de produtos e a estrutura de usuários costumam sair de um sistema e entrar no outro com previsibilidade. São dados tabulares, com correspondência direta. No Bitrix24 esse tipo de carga entra por importação de arquivo ou pela API REST, o que permite repetir a operação quantas vezes for preciso até o resultado ficar correto, em vez de depender de uma única tentativa manual.

Migra com esforço

Campos personalizados, histórico de atividades, anexos e conversas dão trabalho porque exigem tradução e não apenas transporte. Cada campo criado no sistema antigo precisa de um destino no novo, e nem sempre existe equivalência limpa: um campo de texto livre que virou um funil paralelo, uma lista de opções que mudou de nome três vezes, um campo de data que na prática guarda outra coisa. Anexos costumam ser a parte mais lenta, porque são muitos arquivos pequenos passando por limites de API.

Não migra, precisa ser reconstruído

Automações, regras de permissão, relatórios prontos, integrações com ERP e telefonia e gravações presas ao provedor antigo não atravessam a fronteira. Isso não é falha do projeto, é a natureza da coisa: são configurações de uma plataforma, não dados. E aqui vale uma opinião de quem faz isso com frequência. Reconstruir é uma oportunidade, não um prejuízo. Copiar para o sistema novo as mesmas automações confusas que ninguém entendia no antigo é a forma mais cara de trocar de CRM, porque você paga a migração e mantém o problema.

As quatro decisões que definem o tamanho do projeto

1. Até onde o histórico precisa voltar

Migrar dez anos de base é caro, lento e quase sempre desnecessário. A pergunta útil não é "quanto existe", é "quanto disso alguém abre". Na prática, o que a operação consulta no dia a dia é a base ativa e os negócios recentes. Um recorte comum é levar todos os cadastros, os negócios abertos com histórico completo e os fechados de um período definido, deixando o resto em um arquivo consultável. Menos volume também significa menos superfície de erro.

2. O que fazer com a bagunça

Toda base antiga tem duplicidade, contato sem telefone, empresa cadastrada três vezes com grafias diferentes e negócio parado há dois anos na etapa "em negociação". Migrar sem tratar isso transporta o problema e ainda contamina o sistema novo logo no primeiro dia, o que dá ao time o argumento perfeito para desconfiar da ferramenta. A limpeza pode ser feita antes da extração ou durante a carga, com regras de deduplicação, mas precisa ser feita e precisa ter dono. Quem decide se dois cadastros parecidos são a mesma empresa é alguém que conhece o cliente, não o script.

3. Como campos e etapas se traduzem

Esta é a parte que mais atrasa migrações, e ela é conversa de negócio, não tarefa técnica. É preciso desenhar um mapa: cada campo de origem, seu destino, o tipo de dado e o que fazer quando o valor não existe. O mesmo vale para as etapas do funil, que raramente batem uma a uma. É também o melhor momento para simplificar. Se o funil antigo tinha doze etapas e sete delas nunca eram usadas de verdade, migre para o funil que descreve a operação real, não para a cópia fiel do que estava lá.

4. O que vira operação e o que vira arquivo

Nem todo dado precisa estar dentro do CRM novo para estar preservado. Uma base histórica exportada, organizada e guardada em local seguro cumpre a função de consulta e de eventual exigência legal, sem inflar o sistema que o time usa todo dia. Vale lembrar que a LGPD trabalha com finalidade e prazo de guarda: guardar tudo para sempre, sem motivo declarado, não é conservadorismo prudente, é passivo.

O roteiro de uma virada sem susto

Inventário e extração de teste

Antes de mais nada, confirme que você consegue tirar os seus dados do sistema atual e em que formato. Alguns CRMs exportam bem por arquivo, outros exigem API, alguns limitam anexos ou histórico de conversa. Descobrir isso no dia da virada é o pior cenário possível. Faça uma extração de teste cedo e olhe o conteúdo com atenção.

Carga piloto com uma amostra

Carregue uma amostra representativa no ambiente novo, incluindo os casos estranhos: o cliente com cinco empresas ligadas, o negócio com trinta anexos, o registro antigo com campos vazios. É na amostra que os problemas de mapeamento aparecem, quando corrigir ainda é barato.

Validação por quem usa, não só por quem migra

Peça a dois ou três vendedores que procurem os próprios clientes no sistema novo e confiram se a informação está onde faz sentido. Eles enxergam em cinco minutos o que nenhuma checagem técnica pega, porque conhecem a história por trás do registro.

Janela de virada e carga final

Combine um momento de congelamento do sistema antigo, faça a carga final com os dados mais recentes e defina uma hora a partir da qual o registro novo acontece somente no CRM novo. Sem essa linha clara, a equipe passa semanas alimentando os dois e nenhum dos dois fica confiável.

Convivência curta e desligamento com data

Manter o sistema antigo em modo somente leitura por um período dá segurança para consultar o que porventura ficou para trás. O período precisa ter prazo definido, porque duas fontes de verdade convivendo por tempo indeterminado é o caminho conhecido para ninguém confiar em nenhuma.

Os erros que fazem a migração doer

• Migrar tudo por medo de decidir, e entregar ao time uma base nova já poluída.
• Deixar o mapeamento de campos para o final, quando o cronograma já está apertado.
• Fazer a virada em pico de vendas ou fechamento de mês.
• Reproduzir automações e funis antigos sem revisar o que fazia sentido.
• Esquecer os anexos e as conversas, que só fazem falta quando alguém precisa de uma proposta antiga.
• Não testar a volta: se a carga der errado, você consegue recomeçar sem perder nada?
• Tratar migração como projeto de TI, sem alguém da área comercial respondendo pelas decisões.

Quanto tempo isso leva

A resposta honesta é que depende de três coisas: volume, qualidade da exportação do sistema atual e quantidade de campos personalizados. Uma base organizada, com poucos campos próprios e exportação limpa, é uma migração curta. Uma base grande, com histórico de conversa, muitos anexos e dez anos de improviso acumulado, é um projeto. O que mais atrasa, porém, quase nunca é a parte técnica. É decisão: ninguém define até onde volta o histórico, ninguém responde o que fazer com os duplicados, ninguém aprova o mapa de campos. Migração para quando o dono do processo some.

O que perguntar a quem vai conduzir a migração

• Quais camadas de dado estão incluídas no escopo, e quais ficam de fora?
• Como será feito o mapeamento de campos, e quem valida esse mapa?
• Haverá carga piloto antes da carga final?
• Como será tratada a duplicidade, e quem decide os casos ambíguos?
• Anexos e histórico de conversa entram? Se sim, com qual limite?
• Se algo der errado na virada, qual é o plano de retorno?
• O que precisa ser reconstruído no sistema novo, e isso está no orçamento?
• Quem acompanha a operação nas primeiras semanas depois da virada?

Fornecedor que responde a essas oito perguntas com objetividade está falando de um projeto que já executou. Fornecedor que responde "migra tudo, fica tranquilo" está descrevendo uma expectativa, e a conta dessa expectativa chega depois.

Resumo honesto

• Histórico não é uma coisa só: cadastro, negócio, atividade, conversa e anexo têm custos diferentes.
• Dado tabular migra bem, campo personalizado migra com esforço, configuração não migra e precisa ser refeita.
• Recorte de período e limpeza de base reduzem risco mais do que qualquer ferramenta de importação.
• Carga piloto validada por quem vende evita o susto na virada.
• Convivência entre os dois sistemas precisa de data para acabar.
• O que mais atrasa migração é falta de decisão, não limitação técnica.

Se o que está segurando a sua troca de CRM é o receio de perder anos de informação, esse receio merece um plano concreto, com escopo escrito e recorte definido, e não uma promessa genérica. O nosso diagnóstico gratuito em /diagnostico serve para isso: 45 minutos para entender o que existe hoje no seu sistema atual, o que realmente precisa atravessar e como seria a virada no seu caso, sem compromisso de contratar nada.