Checklist de Importação de Dados para CRM: Como Testar um CRM Auto-hospedado Antes de Migrar Seus Registros

Por que a qualidade da importação é mais importante do que um primeiro upload bem-sucedido

Um botão de importação não é um plano de migração. Um primeiro upload pode parecer bem-sucedido enquanto cria silenciosamente contatos duplicados, atribui registros à equipe errada, vincula uma negociação à organização errada ou descarta linhas que não passam na validação.

Avalie a capacidade de importação como um sistema de controle. Você precisa saber o que o aplicativo cria, atualiza, rejeita e relata; se é possível corrigir falhas; e se uma execução repetida é segura. A pergunta relevante não é “Ele pode importar CSV?”, mas “Podemos produzir registros confiáveis a partir dos nossos dados reais de origem, de forma repetível?”

CRMs diferentes implementam esses controles de maneiras diferentes. Por exemplo, o EspoCRM documenta os modos de importação Criar Somente, Criar e Atualizar e Atualizar Somente. Seus modos com capacidade de atualização exigem que o operador escolha campos que identifiquem um registro existente. Essa escolha é uma decisão de governança de dados, não um padrão técnico. Consulte a [documentação de Importação do EspoCRM](https://docs.espocrm.com/administration/import/).

• Não aprove um CRM com base apenas em um arquivo de demonstração sem erros.
• Teste com os mesmos tipos de dados, inconsistências e relacionamentos presentes na exportação de produção.
• Registre cada decisão de configuração usada em cada execução de teste.
• Defina sucesso como registros precisos e utilizáveis, com exceções explicáveis.

Comece com um inventário dos dados de origem

Crie um inventário antes de mapear uma única coluna. Planilhas e CRMs de origem frequentemente mantêm informações relacionadas em abas, módulos, notas de texto livre e repositórios de arquivos separados. Se o inventário contar apenas contatos, a migração pode parecer completa enquanto perde contexto comercial, propriedade ou histórico operacional.

Para cada tabela ou exportação de origem, identifique sua finalidade de negócio, contagem de registros, identificador primário, proprietário atual, responsável pelos dados, entidade de destino e dependências de relacionamento. Marque quais dados são essenciais no primeiro dia e quais podem ser adiados ou arquivados fora do CRM.

Inclua atividades somente depois de confirmar que o modelo de destino suporta os registros e painéis relevantes. No EspoCRM, por exemplo, os painéis disponíveis de Atividades, Histórico e Tarefas dependem do tipo de entidade configurado. Não presuma que toda entidade personalizada exibirá as mesmas informações relacionadas que um registro de pessoa ou organização. Consulte a [documentação do Gerenciador de Entidades do EspoCRM](https://docs.espocrm.com/administration/entity-manager/).

• Registros principais: pessoas, organizações, leads, negociações ou entidades equivalentes.
• Relacionamentos: contato para organização, negociação para contato, registros pai-filho e quaisquer vínculos muitos-para-muitos.
• Contexto operacional: notas, chamadas, reuniões, tarefas, e-mails e histórico, quando necessário.
• Arquivos: anexos, documentos, caminhos de arquivos e links para repositórios externos.
• Dados de configuração: campos personalizados, valores enumerados, tags, equipes, proprietários e status.
• Identificadores de origem: IDs da planilha ou do sistema anterior para cada entidade.

Defina o modelo de dados de destino antes de mapear campos

O mapeamento de campos deve seguir um modelo de destino que tenha sido deliberadamente acordado, e não o desejo de preservar todas as colunas de origem. Decida quais entidades de destino existirão, quais campos são obrigatórios, quais são personalizados, quais valores são listas controladas e quais informações devem permanecer fora do CRM.

Para cada campo de origem, selecione um resultado: mapear diretamente, transformar, dividir, combinar, colocar em um campo personalizado controlado, reter em um arquivo ou excluir. Documente a justificativa. Uma coluna de “status” em texto livre, por exemplo, não deve ser mapeada para um campo de status restrito até que seus valores distintos de origem tenham sido revisados e normalizados.

Verifique a elegibilidade para importação no nível do campo. A documentação do Studio do SuiteCRM descreve a configuração de campos e relacionamentos, incluindo se os campos são permitidos, não permitidos ou obrigatórios para importações pelo Assistente de Importação. Ela também identifica tipo de campo, auditoria e configurações de mesclagem de duplicidades como propriedades de campo. Os controles exatos variam conforme o CRM; portanto, valide o aplicativo de destino em vez de inferi-los a partir de outro produto. Consulte a [documentação do Studio do SuiteCRM](https://pre-release.docs.suitecrm.com/admin/administration-panel/studio/).

• Entidade de destino e nome do campo.
• Tabela, coluna e tipo de dados de origem.
• Regra de transformação e valores permitidos.
• Status de obrigatório, opcional, sensível ou somente leitura.
• Elegibilidade para importação e comportamento padrão.
• Responsável pela decisão de mapeamento e pelo resultado do teste.

Crie uma importação de teste representativa em vez de usar uma amostra higienizada

Uma amostra refinada prova apenas que dados refinados podem ser importados. Crie um pequeno conjunto de dados de teste representativo a partir de cópias de registros reais, com valores sensíveis protegidos conforme necessário. Preserve os problemas que seus dados de produção realmente contêm para que o teste revele como o importador se comporta.

Inclua registros comuns e casos extremos deliberados. Teste valores obrigatórios em branco, valores incompatíveis em listas controladas, nomes duplicados, endereços de e-mail duplicados, IDs de origem repetidos, formatos de telefone inconsistentes, campos com múltiplos valores, pontuação, caracteres não ASCII e datas escritas em mais de um formato.

Falhas de validação são evidências valiosas. O EspoCRM documenta que uma linha que falha na validação não cria um registro, citando como exemplos valores enum incompatíveis e valores vazios para um enum que não pode ser vazio. Seu teste deve confirmar o comportamento equivalente no CRM que você está avaliando, incluindo o que acontece com campos válidos em uma linha parcialmente inválida. Consulte a [documentação de Importação do EspoCRM](https://docs.espocrm.com/administration/import/).

• Use uma contagem conhecida de registros para cada arquivo de teste.
• Identifique os registros de teste para que possam ser encontrados e inspecionados posteriormente.
• Mantenha uma cópia intacta do extrato de teste original.
• Inclua linhas sabidamente válidas, sabidamente inválidas e intencionalmente ambíguas.
• Não substitua valores de produção por marcadores irrealisticamente uniformes.

Teste as decisões que criam dados ruins no CRM: duplicidades, valores ausentes, formatação e propriedade

O controle de duplicidades começa com uma política explícita de correspondência. Decida quais identificadores de origem são autoritativos, se o e-mail é suficientemente único para seu caso de uso e como o CRM deve tratar uma correspondência em um campo, mas não em outro. Registre os campos exatos de correspondência selecionados em cada execução.

Identificadores de origem estáveis são particularmente importantes para ciclos de correção. O Odoo documenta que IDs Externos consistentes podem oferecer suporte a importações repetidas sem criar duplicidades, enquanto alterar ou remover um ID Externo pode resultar em um novo registro em vez de uma atualização. Independentemente de o CRM escolhido usar IDs Externos ou outro mecanismo de identificação, verifique se seu identificador permanece intacto em uma reimportação exatamente como esperado. Consulte a [documentação de exportação e importação do Odoo](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

Não confie na detecção automática de datas. O Odoo observa que formatos de data podem ser reconhecidos incorretamente, incluindo inversões de dia e mês, e recomenda verificar ou definir o formato ISO 8601. Coloque datas ambíguas, como 03/04/2024, no arquivo de teste e inspecione o valor salvo, não apenas a prévia da importação.

A propriedade exige o mesmo nível de análise. O EspoCRM pode aplicar padrões, incluindo Usuário Atribuído e Equipes, a registros novos e atualizados durante a importação. Teste se o proprietário de origem é preservado, traduzido, substituído por um padrão ou deixado sem definição. Em seguida, decida qual comportamento é aceitável para cada entidade. Consulte a [documentação de Importação do EspoCRM](https://docs.espocrm.com/administration/import/).

• Crie um registro com um ID de origem existente e dados não-chave alterados; teste o caminho de atualização pretendido.
• Crie dois registros com nomes semelhantes, mas IDs diferentes; assegure que não sejam mesclados acidentalmente.
• Teste campos em branco em um arquivo de atualização para descobrir se apagam valores existentes, são ignorados ou falham na validação.
• Teste formatos de data, número, moeda, telefone e seleção múltipla.
• Teste um registro cujo proprietário original não existe mais no destino.
• Inspecione valores de proprietário e equipe após execuções de criação e de atualização.

Verifique relacionamentos e histórico: contatos, organizações, negociações, notas, tarefas e anexos

A precisão dos relacionamentos costuma ser a diferença entre um CRM útil e um diretório de registros desconectados. Crie casos de teste nos quais uma organização tenha vários contatos, uma negociação tenha várias pessoas relacionadas e os registros compartilhem nomes de exibição semelhantes ou idênticos. Verifique cada relacionamento pelos dois lados na interface de destino.

Importe entidades pai antes das entidades filhas quando o relacionamento depender de registros previamente importados. O SuiteCRM instrui os usuários a importar Contas antes dos Contatos relacionados para que o relacionamento possa ser estabelecido. Da mesma forma, o Odoo documenta a importação prévia de objetos relacionados quando as relações são recriadas por meio de IDs Externos. Consulte a [documentação de Gerenciamento de Registros do SuiteCRM](https://docs.suitecrm.com/8.x/user/core-concepts/record-management/) e a [documentação de exportação e importação do Odoo](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

Evite depender de nomes para correspondência de relacionamentos quando houver possibilidade de ambiguidade. O Odoo alerta que, quando vários registros relacionados têm o mesmo nome, os dados podem ser vinculados ao primeiro registro correspondente. Use identificadores estáveis para campos de relacionamento quando o destino os suportar e comprove o resultado com registros de teste deliberadamente ambíguos.

Anexos e histórico de atividades merecem testes de aceitação separados. Confirme se os arquivos são importados, vinculados, ignorados ou se exigem um procedimento separado e específico do produto. Não presuma que o importador de CSV usado para registros principais também importe anexos, notas, tarefas ou histórico. Para qualquer procedimento suportado, confirme que datas, autores, registros pai e permissões estejam adequados.

• Importe organizações ou contas antes dos contatos relacionados.
• Importe negociações ou casos pai antes de suas notas e atividades dependentes, quando exigido pelo modelo.
• Use IDs de origem para conectar registros em vez de nomes de exibição, sempre que possível.
• Inspecione contagens de relacionamentos e vínculos individuais no aplicativo.
• Abra anexos de amostra e verifique sua associação ao registro pretendido.
• Verifique datas de atividades, criadores, responsáveis e visibilidade.

Verifique como o aplicativo relata registros rejeitados ou alterados

Um importador que relata apenas um total final é difícil de operar com segurança. Exija evidências para cada linha rejeitada: sua linha ou identificador de origem, o motivo da falha e os valores fornecidos. Exija também uma forma de distinguir registros recém-criados de atualizações e linhas ignoradas.

O EspoCRM fornece um painel de Erros que inclui o motivo da falha, o índice da linha e os valores da linha, além de permitir a exportação de linhas com falha para CSV para correção e reimportação. A documentação do SuiteCRM também descreve uma aba de Erros para revisão e correção antes de executar novamente uma importação. Trate esses recursos como exemplos úteis das evidências a buscar, e não como uma suposição de que todo CRM disponibiliza relatórios idênticos. Consulte a [documentação de Importação do EspoCRM](https://docs.espocrm.com/administration/import/) e a [documentação de Gerenciamento de Registros do SuiteCRM](https://docs.suitecrm.com/8.x/user/core-concepts/record-management/).

Execute um teste contendo registros válidos, registros inválidos e candidatos a atualização. Reconcilie a contagem de origem com os resultados de criação, atualização, rejeição e ignorados. Qualquer diferença sem explicação é um critério de aceitação não atendido.

• É possível exportar linhas com falha para correção?
• Cada erro identifica uma linha de origem ou um ID de origem estável?
• O relatório explica a falha em termos operacionais?
• É possível distinguir criações, atualizações, rejeições e itens ignorados?
• É possível salvar as configurações de mapeamento e verificação de duplicidades para uma execução repetível?
• É possível inspecionar os registros resultantes diretamente no relatório de importação?

Teste a correção e a reimportação sem multiplicar registros nem sobrescrever dados confiáveis involuntariamente

O teste de importação mais importante geralmente é o segundo. Corrija um conjunto limitado de linhas rejeitadas e, em seguida, reimporte o arquivo corrigido usando o modo de atualização e as regras de correspondência pretendidos. Confirme que os registros corrigidos sejam criados ou atualizados uma única vez, que registros já importados com sucesso não sejam duplicados e que campos não relacionados permaneçam confiáveis.

Separe o comportamento de criação do comportamento de atualização em seus critérios de aceitação. No EspoCRM, Criar Somente cria registros, enquanto Criar e Atualizar e Atualizar Somente usam campos de correspondência selecionados para localizar registros a atualizar. Uma equipe de produção precisa saber qual modo usará para a carga inicial, a correção de erros e atualizações incrementais posteriores. Consulte a [documentação de Importação do EspoCRM](https://docs.espocrm.com/administration/import/).

Teste valores em branco e alterados com cuidado. Uma reimportação pode sobrescrever informações editadas após a primeira importação, dependendo do modo e dos mapeamentos selecionados. Estabeleça uma janela de transição, identifique o sistema de registro para cada campo durante a migração e defina se as edições pós-importação são protegidas, sobrescritas ou reconciliadas manualmente.

• Execute uma importação inicial e registre IDs criados e IDs de origem.
• Corrija apenas as linhas com falha e mantenha seus identificadores originais.
• Reimporte e compare as contagens de registros antes e depois.
• Teste deliberadamente um valor alterado em um registro existente.
• Teste deliberadamente um valor em branco em um registro existente.
• Verifique se campos editados no CRM após a primeira carga são preservados ou sobrescritos conforme o esperado.