Migração de CRM: o que quebra quando o dado muda mas o processo não

Uma migração de CRM é orçada como uma exportação de dado e uma importação, e é aí que acontece a maior parte do estrago. Os registros se movem. O que não se move sozinho é o significado por trás deles: por que um negócio ficou seis semanas numa etapa, quem é o dono de verdade de um território quando dois vendedores mexeram na mesma conta, e quais dos quarenta campos personalizados alguém ainda lê.

Nada disso aparece numa contagem de linhas. Aparece três meses depois, num forecast que não bate com o que o time de vendas já sabia.

O que uma cópia direta realmente perde

Contatos e empresas migram limpo quase sempre. Tudo o que depende deles é onde uma cópia direta deixa de ser segura.

Dado	Migra limpo?	Precisa de decisão antes
Contatos e empresas	Sim	Regras de deduplicação, porque os dois sistemas raramente concordam sobre "mesma conta"
Negócios e oportunidades	Quase sempre	Um mapa de etapas entre o pipeline antigo e o novo, por escrito
Histórico de atividade	Raramente completo	Comprimir numa linha do tempo, ou aceitar a perda e dizer isso
Campos personalizados	Não	Quais um vendedor ainda lê antes de uma ligação
Relatórios e painéis	Não	Reconstruídos contra o novo esquema, nunca copiados

O mapa de etapas é o item dessa lista que as pessoas pulam por parecer óbvio. Não é. "Negociação" num pipeline de cinco etapas e "Negociação" num de oito não são a mesma etapa, e mapeá-las 1 para 1 muda em silêncio o que cada relatório histórico de conversão significa.

O corte que não custa um trimestre de pipeline

Duas abordagens, e a errada depende de quanto pipeline está em andamento, não de preferência.

Um corte de uma vez só funciona quando o pipeline é pequeno o bastante para um vendedor reentrar o que faltou num dia. Passadas algumas centenas de oportunidades abertas, não funciona: a janela de congelamento necessária para reconciliar dados cresce além do que vendas tolera, e os vendedores começam uma planilha paralela assim que o congelamento começa, o que arruína a migração antes de ela terminar.

Uma execução em paralelo, onde os dois sistemas continuam ativos e o novo vira o sistema de registro só depois de um período de verificação definido, custa mais tempo de calendário mas não obriga a congelar nada. É o mesmo raciocínio por trás de uma migração em fatias para um sistema legado: substituir carga aos poucos, manter o caminho antigo funcionando até o novo estar provado, e nunca apostar o negócio num único fim de semana de corte.

Disputas de dono são um problema de migração, não do CRM

Uma disputa de território ou de dono de conta que já existia no sistema antigo não se resolve sozinha ao trocar de sistema; ela só é recodificada, quase sempre errado, porque quem roda a migração precisa escolher um dono para cada registro ambíguo e raramente tem o contexto para escolher certo. Resolva as regras de dono antes da migração, não durante, a mesma disciplina que vale ao integrar em volta de um ERP legado sem tocar no modelo de dados dele.

Rodamos migrações de CRM como parte da nossa prática de CRM e Operações de Receita, com a mesma disciplina de qualquer projeto de modernização: um inventário antes de mover um único registro, e um mapa de etapas por escrito que vendas aprova. Como protegemos o dado em trânsito, inclusive sob um BAA assinado quando há dado de saúde envolvido, está nas nossas práticas de segurança.