Migrar de CRM: o que levar, o que arquivar, o que reconstruir e quando a coexistência é a melhor decisão

Uma migração de CRM tem três camadas independentes, e cada uma exige uma decisão própria: dados, processo e integrações. A camada de dados costuma ser a mais discutida e a menos arriscada. A camada de processo é onde a migração dá certo ou errado, porque migrar um processo ruim para uma plataforma nova entrega o mesmo resultado em uma interface diferente. A camada de integrações é a que determina o prazo real, já que ela depende de terceiros e de sistemas que a área comercial não controla.

O critério que organiza as três: nada migra por padrão. Cada objeto, cada automação e cada integração precisa de uma decisão explícita entre migrar, arquivar ou reconstruir.

A matriz de decisão

A linha que mais gera discussão é a de atividades. O impulso é levar tudo, e o argumento é sempre o mesmo: alguém pode precisar. Na prática, consulta a histórico de atividade com mais de dois anos é rara, e o volume dessa camada costuma responder pela maior parte do tempo e do custo do projeto. Arquivar o excedente em repositório consultável, fora do CRM, atende à necessidade sem contaminar a base nova.

O que quase nunca vale migrar

Automações legadas. Um workflow criado há quatro anos carrega a lógica de um processo que provavelmente mudou, mais as soluções de contorno das limitações da plataforma antiga. Reconstruir a partir do processo atual custa menos que traduzir e depurar.

Campos sem uso. Toda base antiga carrega propriedades criadas para uma campanha específica, preenchidas em 2% dos registros. Levá-las reproduz a desordem que a troca de plataforma deveria resolver. O critério objetivo: propriedade com preenchimento abaixo de um piso definido e sem uso em relatório ou automação não migra.

Registros duplicados. Duplicidade migrada volta a se multiplicar. A deduplicação acontece antes da carga, sobre o sistema de origem ou sobre o arquivo intermediário, com chave definida e regra de sobrevivência documentada.

Usuários desligados como proprietários. Registro com dono inexistente fica sem responsável e some dos filtros de rotina. A reatribuição precisa acontecer antes da carga, com regra por território, segmento ou carteira.

Quando a coexistência é a decisão certa

Corte seco é preferível quando a operação é homogênea e cabe em uma janela curta. Coexistência temporária entre duas plataformas faz sentido em três situações concretas:

Grupos com unidades de negócio independentes. Uma unidade entra primeiro, valida o desenho e serve de referência para as demais. O risco fica contido e o aprendizado é reaplicado.

Operações com contrato vigente até uma data fixa. Quando a licença anterior tem prazo remanescente relevante, a sobreposição planejada custa menos que o encerramento antecipado.

Áreas com dependência crítica não resolvida. Uma integração essencial ainda em construção pode manter um recorte da operação no sistema anterior enquanto o restante migra.

A coexistência tem custo próprio e precisa ser tratada como projeto, não como estado natural. Dois sistemas simultâneos significam duas fontes de número, e a regra de qual deles responde por cada indicador precisa ser definida no primeiro dia. Também precisa haver data de encerramento definida em contrato interno, porque coexistência sem prazo tende a se tornar permanente, e aí a empresa paga duas plataformas para operar mal em ambas.

A sequência que reduz risco

Inventário. Contagem por objeto, lista de propriedades com percentual de preenchimento, lista de automações ativas com data do último disparo, lista de integrações com responsável e contrato.

Mapa de objetos e propriedades. Correspondência campo a campo entre origem e destino, com tratamento definido para formato de data, fuso horário, listas de valores e campos calculados.

Decisão de corte. A matriz acima, preenchida e aprovada pelas áreas envolvidas. É o documento que evita a discussão recorrente durante a execução.

Carga piloto. Uma amostra representativa, com todos os tipos de registro e as associações entre eles, em ambiente de teste. O objetivo é descobrir os problemas de formato e de associação antes do volume.

Reconciliação. Contagem por objeto nos dois lados, amostragem manual de registros com histórico complexo, verificação de associações e de campos obrigatórios. Divergência acima de um percentual definido interrompe o cronograma.

Congelamento e corte. Janela de bloqueio de escrita no sistema de origem, carga final do delta, validação, e liberação de acesso. Automação de saída desligada durante toda a janela.

Os riscos que aparecem depois do corte

Perda de associação. Contato migrado sem vínculo com a empresa, negócio sem contato associado. Não impede a operação no primeiro dia e destrói qualquer relatório a partir do segundo.

Disparo indevido. Importação que aciona workflow de nutrição ou notificação de proprietário. O controle é suspender automação durante a carga e reativar por lote, com validação de critério de inscrição.

Adoção sem processo. A plataforma nova entra e a equipe reproduz o hábito anterior. É o risco mais comum e o menos técnico. Ele se trata com desenho de processo, treinamento por papel e acompanhamento de uso nas primeiras semanas, não com configuração.

Dimensionamento errado do plano. Requisitos de permissão, hierarquia de times e objetos customizados aparecem durante o desenho de migração, e às vezes depois da contratação. Antecipar essa leitura evita duas conversas desconfortáveis no mesmo trimestre.

Integração subestimada. É a variável que mais desloca prazo, porque depende de sistemas de terceiros. O desenho precisa entrar cedo, junto com o inventário, e não depois da carga de dados.

Continue lendo

• Integrar ERP e HubSpot: as decisões de arquitetura que definem o projeto

• HubSpot Professional ou Enterprise: como decidir sem subdimensionar nem pagar demais

• Conheça os Hubs e as ofertas da Reevia

Perguntas frequentes

Quanto tempo leva migrar de CRM?
O prazo é determinado pelas integrações e pela quantidade de decisões pendentes sobre processo, não pelo volume de registros. Uma operação com processo definido e uma integração simples se resolve em semanas. Uma operação com múltiplos pipelines, ERP acoplado e regras de permissão complexas trabalha em meses, e a maior parte desse tempo é desenho, não carga.

Vale migrar todo o histórico de atividades?
Raramente. Uma janela recente atende à operação corrente, e o excedente pode ser arquivado em repositório consultável fora do CRM. Migrar tudo eleva custo e prazo sem alterar o resultado operacional.

É possível operar dois CRMs ao mesmo tempo?
Sim, e em algumas situações é a decisão mais segura, especialmente em grupos com unidades independentes ou com contrato vigente até data fixa. A condição é ter regra explícita de qual sistema responde por cada indicador e uma data de encerramento definida.

O que fazer com automações do CRM anterior?
Reconstruir a partir do processo atual, não traduzir. Automação legada carrega lógica desatualizada e contornos de limitação da plataforma anterior, e a tradução custa mais que a reconstrução.

Como evitar duplicidade na migração?
Deduplicar antes da carga, sobre a origem ou sobre o arquivo intermediário, com chave definida, regra de sobrevivência documentada e conferência por amostragem. Duplicidade que entra na carga se multiplica nas rotinas seguintes.

Fontes

• Documentação da HubSpot sobre importação de dados, objetos e associações, ambientes de teste e gestão de propriedades

Este artigo descreve critérios de decisão e não substitui o levantamento específico de cada operação.