Resposta direta
Antes de migrar ou integrar ERP e CRM, a empresa deve medir duplicidades, documentos inválidos, contatos inconsistentes, endereços livres ou conflitantes e versões diferentes da mesma entidade. O objetivo não é modificar tudo: é separar registros certificados, correções seguras, casos ambíguos e relações de identidade antes que os erros sejam replicados no sistema novo.
- Migração troca o sistema; não garante qualidade cadastral.
- Duplicidades antigas tendem a atravessar a carga se não forem tratadas antes.
- ERP e CRM podem manter versões diferentes do mesmo cliente e ambas parecerem válidas isoladamente.
- O original e a evidência de cada transformação precisam ser preservados para reconciliação.
O erro mais caro é tratar a migração como cópia de tabela
Projetos de ERP e CRM naturalmente concentram energia em mapeamento, integrações, cronograma e regras de carga. A qualidade cadastral costuma aparecer depois, quando o sistema novo começa a receber registros repetidos, campos incompatíveis e versões diferentes do mesmo cliente.
O problema é que uma migração bem executada tecnicamente pode reproduzir com perfeição uma base ruim. O dado chegou ao destino — mas chegou duplicado, incompleto ou sem relação clara com as demais fontes.
1. Duplicidades e identidade
O primeiro grupo a medir é o de registros que podem representar a mesma entidade. Em bases históricas, CPF e CNPJ podem estar ausentes, inválidos, divergentes ou ter perdido a função de unicidade para permitir importações anteriores.
A deduplicação precisa trabalhar com mais de uma evidência. O MatchIQ, por exemplo, usa oito critérios de identidade combinando nome, endereço, telefone, documentos, nascimento e nome da mãe, conforme o tipo de cadastro e os atributos disponíveis.
2. Documentos e chaves de negócio
Documento preenchido não significa documento confiável. Antes da carga, vale classificar valores válidos, inválidos, ausentes, repetidos e conflitantes. O mesmo raciocínio vale para códigos legados e identificadores internos que serão usados para relacionar tabelas depois da migração.
Quando uma chave deixa de ser confiável, a solução não é simplesmente ignorá-la. É tratá-la como uma evidência entre outras e registrar por que dois registros foram relacionados.
3. Endereços e campos livres
Endereços concentram um tipo diferente de problema: muitas bases misturam logradouro, número, complemento e bairro em um único campo. Outras mantêm CEP, cidade e logradouro em colunas separadas, mas incoerentes entre si.
Antes da integração, é útil separar estruturação, recuperação e validação. Veja o guia de qualidade de endereços em lote para entender a diferença entre interpretar o texto livre e decidir se uma correção tem evidência suficiente.
4. Telefones, e-mails e contatos repetidos
Contatos podem ter DDD ausente, máscara inconsistente, números inválidos ou o mesmo telefone ligado a vários registros. O ponto não é apenas padronizar a aparência: é descobrir quais valores ainda são utilizáveis e quais relações precisam ser investigadas.
5. Versões divergentes entre ERP, CRM e legado
Uma das situações mais comuns é cada sistema manter uma versão plausível do mesmo cliente. O ERP tem razão social e endereço fiscal; o CRM tem telefone e contato mais recentes; um legado mantém um identificador histórico necessário para rastrear transações.
Não é obrigatório escolher imediatamente um único registro físico. Em muitos projetos, a primeira necessidade é conectar as versões e preservar a origem. Essa é a base para decidir depois como o dado mestre será governado. Veja a abordagem de qualidade de dados Pré-MDM.
6. Regras de correção e casos que devem permanecer intactos
Higienização responsável precisa ter guardas. Se a evidência é insuficiente, o sistema deve classificar o caso como ambíguo em vez de “melhorar” o dado por suposição. O princípio é simples: melhor não alterar do que alterar errado.
Por isso, a etapa de diagnóstico deve separar aquilo que pode ser certificado, aquilo que tem correção segura, aquilo que exige dado auxiliar e aquilo que precisa de revisão humana.
7. Preservação do original e reconciliação
Migração não deveria apagar a história da informação. Para cada tratamento, é importante manter o valor recebido, o resultado proposto, a regra utilizada e a evidência que justificou a decisão.
Essa trilha permite comparar antes e depois, reprocessar uma regra, explicar uma divergência e conferir se a carga no ERP ou CRM realmente recebeu o que foi aprovado.
Um roteiro prático antes da carga
- Extraia o escopo real das bases envolvidas.
- Meça 100% dos registros fornecidos, sem amostragem.
- Classifique duplicidades, inconsistências e conflitos entre fontes.
- Defina regras e níveis de confiança antes de alterar dados em escala.
- Preserve o original e execute o tratamento em cópia controlada.
- Audite exceções e bloqueie alterações sem evidência suficiente.
- Entregue dados tratados e trilha para staging, carga ou integração.
Comece pelo diagnóstico, não pela correção
Antes de estimar esforço ou contratar um projeto completo, o Raio X da Base quantifica registros certificados, correções possíveis, inconsistências e duplicidades no escopo. Isso transforma “a base parece ruim” em uma decisão baseada em números.
Para SAP e S/4HANA, veja também o artigo específico sobre saneamento de dados antes da migração.
Perguntas frequentes
A migração de ERP elimina duplicidades automaticamente?
Não. A migração transporta e transforma os dados conforme as regras definidas. Se as duplicidades não forem identificadas antes, elas podem atravessar a carga para o sistema novo.
É obrigatório criar um registro mestre único antes da migração?
Não. Primeiro é possível relacionar versões da mesma entidade, preservar as fontes e medir conflitos. A arquitetura de MDM pode ser decidida depois.
Quais dados devem ser higienizados antes de integrar ERP e CRM?
Normalmente identidade, documentos, endereços, telefones, contatos, chaves legadas, duplicidades e atributos que divergem entre as fontes.
O diagnóstico altera a base original?
Não. O objetivo do diagnóstico é medir e classificar 100% dos registros fornecidos no escopo, sem substituir o dado original.