Por que migrar para um novo CRM ou ERP é mais difícil do que parece — e o que realmente faz funcionar

Seis meses depois da virada de chave, o novo CRM tem oitenta por cento dos registros do sistema antigo e cerca de um quinto dos usuários diários que tinha. Em algum lugar da área comercial, uma planilha-mestra pessoal foi silenciosamente reativada. A assinatura continua ativa. O sistema simplesmente deixou de ser onde o trabalho acontece.

Esse resultado — não uma falha técnica, não um desastre de dados, mas uma deriva gradual de volta aos velhos hábitos — é o desfecho mais comum de migrações que funcionaram tecnicamente e falharam operacionalmente. As decisões que produziram esse cenário não foram tomadas no dia da virada nem durante a importação. Foram tomadas meses antes, ainda na fase de planejamento.

A falha não está no código

É tentador tratar uma migração de CRM ou ERP como responsabilidade exclusiva da TI. Aprovam-se o orçamento e o cronograma, e aguarda-se um relatório meses depois. Esse é o primeiro erro — e costuma ser o decisivo.

Quando o projeto fica restrito à TI, decisões críticas são tomadas sem contexto de negócio. A equipe de vendas não é ouvida sobre os estágios do pipeline no novo CRM. O time de logística não valida os fluxos de recebimento no novo sistema. O resultado é uma plataforma tecnicamente funcional e operacionalmente inutilizável — um sistema que força os usuários a criar planilhas paralelas para contornar suas deficiências, anulando o retorno esperado.

Uma migração de sistema é, em essência, um projeto de mudança organizacional. A tecnologia é o veículo. Sem um patrocinador executivo com autoridade real e representantes de todas as áreas impactadas envolvidos desde o início, a plataforma mais sofisticada do mercado vai gerar os mesmos problemas que a anterior.

Quanto mais tempo esperou, mais tem para mover

As empresas com as migrações mais dolorosas são quase sempre as que esperaram mais tempo para começar. A lógica do adiamento é racional: as gambiarras funcionam bem o suficiente para passar a semana, e a troca é disruptiva. Mas cada mês de convivência com um sistema que a empresa já superou enterra essas gambiarras mais fundo na operação.

As planilhas se multiplicam. O que começou como uma lista única de clientes vira quinze versões, mantidas por pessoas diferentes com convenções diferentes. O processo para lidar com um caso específico — um cliente com dois endereços de faturamento, um produto expedido em duas caixas separadas — deixa de estar no sistema e passa a existir na memória institucional: "Fala com a Cláudia, ela sabe como funciona." Quando a decisão de migrar finalmente é tomada, a empresa não está mais rodando no sistema declarado. Está rodando na infraestrutura de contorno que cresceu ao redor dele.

Essa infraestrutura é o que a migração precisa mover de verdade. Não apenas registros, mas o conhecimento do que eles significam, quem é responsável por quais contas, e quais são as exceções. Em empresas que operam em planilhas, isso raramente está documentado. Precisa ser reconstruído em conversas — o que é mais lento e menos confiável do que exportar um banco de dados bem mantido.

A armadilha dos dados limpos

"Precisamos limpar os dados antes de migrar." A lógica parece sólida. Na prática, essa decisão transforma a migração em um projeto que nunca termina.

A limpeza leva mais tempo do que o previsto. Casos específicos surgem. As pessoas descobrem inconsistências que não sabiam que existiam. Novos registros continuam sendo criados no sistema antigo durante o processo de limpeza, e também precisam ser tratados. Decidir o que é um duplicado, o que fazer com contatos sem atividade há três anos, e como tratar registros que existem em um sistema mas não no outro vira uma discussão organizacional — não uma tarefa técnica. Quando os dados finalmente são declarados prontos, passaram-se meses e o projeto perdeu impulso, muitas vezes junto com o responsável que o liderava.

A abordagem mais eficaz é migrar o que importa, aceitar que alguns registros vão precisar de ajuste depois, e usar o próprio processo de importação para identificar e resolver problemas. Uma importação estruturada que mostra os dados mapeados para o novo modelo, sinaliza duplicatas e violações de formato registro a registro, e permite resolução antes de qualquer commit encontra problemas de qualidade de dados mais rápido do que uma limpeza manual em planilha. A ferramenta entende o modelo de destino e diz exatamente o que o viola.

Os registros que precisam estar limpos antes da migração são os ativos. Contatos sem atividade há dois anos, produtos descontinuados, pedidos fechados há três exercícios fiscais — esses podem ser arquivados ou deixados para trás. Um sistema novo com registros ativos limpos e um arquivo histórico separado não é uma concessão. É a resposta certa.

O escopo que cresce antes de começar

O instinto é levar tudo. Se a empresa está passando pela disrupção de uma migração, faz sentido trazer todos os registros, todo o histórico, todos os documentos anexados, e recriar cada relatório e automação que existia antes. Isso maximiza escopo, custo e prazo sem maximizar o valor entregue na mesma proporção.

A maioria dos dados históricos com mais de dois ou três anos não é consultada na operação cotidiana. Recriar relatórios legados que não servem mais às decisões atuais adiciona tempo sem agregar valor. Automações construídas para fluxos de trabalho antigos costumam refletir como a empresa operava, não como opera hoje — recriá-las fielmente reproduz restrições que poderiam ter sido eliminadas.

A pergunta certa não é "o que existe no sistema antigo?", mas "o que a equipe precisa para trabalhar no primeiro dia?". A resposta costuma ser: clientes e contatos ativos, negociações abertas, informações de produto e preço atualizadas, e histórico suficiente para atender um cliente que liga com uma dúvida. Em geral, uma fração do que existe no sistema antigo. Migrar uma fração é mais rápido, menos arriscado e mais fácil de validar.

Falha técnica e falha humana

A falha técnica é a mais discutida. Registros corrompidos, erros de mapeamento de campos, relacionamentos que quebram porque a estrutura de chave estrangeira difere entre sistemas, integrações que funcionavam na API antiga e não têm equivalente na nova. Essas falhas são reais.

A falha humana é menos visível e muito mais comum. Ela acontece quando a migração técnica é um sucesso — dados no lugar certo, campos mapeados corretamente, validações aprovadas — e as pessoas simplesmente não usam o sistema. Elas fazem login quando um gestor pede. Seus registros reais vivem em outro lugar.

A causa raramente é falta de conhecimento. Treinamento resolve lacunas de conhecimento. Quem para de usar um sistema novo depois da migração geralmente sabe como usá-lo. Para porque usá-lo é mais lento do que a gambiarra para as tarefas do dia a dia, porque o sistema não entrega nada que a pessoa precisava e não tinha, e porque o caminho de menor resistência — o sistema antigo, a planilha — ainda está disponível. Remova a alternativa e a adoção acelera. Deixe disponível e a gambiarra vira permanente.

Por que rodar os dois sistemas ao mesmo tempo quase sempre falha

A recomendação padrão é manter o sistema antigo e o novo rodando em paralelo até que a confiança no novo esteja estabelecida. Em teoria reduz o risco. Na prática, é um dos preditores mais confiáveis de uma migração fracassada.

Quando as pessoas podem atualizar qualquer um dos sistemas, não atualizam nenhum de forma consistente. Os dados divergem em dias. O CRM mostra um total de negociações abertas; a planilha mostra outro. Um registro no sistema novo tem o último contato anotado como há duas semanas; alguém registrou uma ligação no sistema antigo ontem, por hábito. Ninguém sabe qual número confiar. A equipe fica com o pior dos dois mundos: dois sistemas para manter e nenhuma fonte confiável.

Migrações bem-sucedidas costumam usar uma virada de chave definitiva — uma data a partir da qual o sistema antigo vira somente leitura ou fica inacessível. Isso remove a rede de segurança e a substitui por urgência. Os problemas são resolvidos porque não há alternativa. O desconforto é concentrado e resolvido em semanas. A operação paralela distribui esse desconforto ao longo de meses sem nunca responder qual sistema é o real.

A planilha que nunca é aposentada

Para empresas saindo de planilhas — não de outro sistema estruturado — existe um modo de falha específico: as pessoas voltam a elas imediatamente quando o sistema novo parece estranho. Não porque o sistema novo não tenha a funcionalidade. Mas porque a memória muscular já está lá, e o custo de reaprender um fluxo que a pessoa já sabe fazer é real, mesmo quando o resultado é o mesmo.

O problema é difícil de eliminar porque planilhas são legítimas para alguns usos. Modelagem de cenários, análises pontuais, flexibilidade de layout — são vantagens reais. O que você quer evitar é usar uma planilha como registro principal de clientes ativos, negociações abertas ou níveis de estoque. Sem uma política clara, o limite fica difuso e o sistema esvazia gradualmente. Vira uma camada de relatório, não um ambiente operacional — exatamente o que faz a adoção de CRM fracassar, só que chegando por outro caminho.

O que implementações bem-sucedidas têm em comum

Implementações bem-sucedidas compartilham características independentes da plataforma escolhida.

Há um responsável de negócio nomeado para a migração — não um líder de TI gerenciando um projeto técnico, mas alguém do negócio que responde pela adoção. Essa pessoa define o que importa migrar, decide o que vai e em que estado, estabelece e faz cumprir a data de virada, e lida com as áreas que querem manter o sistema antigo funcionando. Sem essa pessoa, a migração é um projeto de tecnologia sem responsabilidade operacional. E projetos de tecnologia sem responsabilidade operacional entregam menos do que o prometido de forma consistente.

O sistema entra no ar em uma data definida em estado funcional, não em fases ao longo de meses. Quando um sistema novo chega incompleto — algumas funcionalidades disponíveis, outras vindo depois — as pessoas preenchem as lacunas com ferramentas antigas. O hábito de trabalhar em torno do sistema novo se estabelece antes que ele esteja completo, e persiste depois que as lacunas são fechadas. Um sistema completo em uma data clara é muito mais fácil de adotar do que um sistema incompleto chegando progressivamente.

A importação é tratada como a fase de qualidade de dados, não como uma porta que precisa ser liberada antes de a migração começar. As melhores ferramentas de onboarding mostram seus dados mapeados para a estrutura do novo sistema antes de qualquer commit, apontam os registros e campos específicos que violam o modelo de destino, e permitem resolução ou substituição naquele momento. A empresa não precisa de dados limpos para entrar nesse processo. Precisa de um processo que produza dados limpos na saída.

A decisão que você só toma uma vez

Uma migração é um ponto de inflexão. A empresa tem, naquele momento, mais atenção voltada para seus próprios dados e mais permissão organizacional para reestruturar como as informações são armazenadas e acessadas do que terá em qualquer outro momento até a próxima migração. Essa janela não permanece aberta.

Uma empresa que migra seus dados de CRM para uma plataforma onde os mesmos registros também são acessíveis ao faturamento, controle de estoque, reservas e atendimento ao cliente faz o trabalho de integração uma única vez. Uma empresa que migra para um CRM standalone e mantém sistemas separados de contabilidade, estoque e atendimento adia esse trabalho — e continua pagando o custo de manter essas conexões indefinidamente, em tempo de engenharia, em esforço de conciliação e em decisões tomadas com dados incompletos.

Para a maioria das empresas no momento da migração, a abordagem integrada é a decisão de longo prazo mais acertada, mesmo que torne a migração em si mais complexa. A complexidade de mover dois ou três sistemas para uma plataforma única é delimitada e temporária. A complexidade de manter dois ou três sistemas conectados por integrações pontuais não tem limite definido e é permanente. Essa escolha se faz no momento da migração. Raramente se refaz de forma limpa.

---