Mapeando Campos Entre Sistemas Legados e Novos

Por Victor Hoang · Atualizado em 8 de abril de 2026

Mapear campos é uma etapa central de qualquer processo de ETL (Extract, Transform, Load). O mapeamento de campos é a parte de uma migração de CRM que parece simples até não ser mais. "Nome mapeia para Nome", certo. Mas o que acontece quando seu sistema de origem tem um único campo Nome Completo e o destino exige Nome e Sobrenome separados? Ou quando Lead Status no Salesforce tem 8 valores e o destino suporta 5? Ou quando Receita Anual importa como campo de texto em vez de campo de moeda, quebrando todos os relatórios de receita no primeiro dia?

Esse último cenário não é hipotético. Acontece o tempo todo. E é evitável, se você construir o documento de mapeamento de campos antes da primeira execução de importação, não durante ela.

Este guia percorre o processo completo de mapeamento de campos: mapeamento em nível de objeto primeiro, depois campos padrão, depois os casos difíceis (campos customizados, valores de lista de opções, campos de relacionamento, incompatibilidades de tipo). Execute estas etapas em ordem antes de tocar no CRM de destino. Se você ainda não executou as etapas anteriores, comece por preparar seus dados antes da migração e limpeza e deduplicação de dados.

Etapa 1: Mapeamento em Nível de Objeto Primeiro

Antes de mapear um único campo, mapeie os objetos. Todo CRM usa terminologia ligeiramente diferente para os mesmos conceitos, e o mapeamento de objetos desalinhado corrompe dados de relacionamento em escala.

Mapeamento de Objetos Padrão

O problema de conversão de Lead do Salesforce: O Salesforce tem tanto Leads quanto Contatos. Leads são pré-conversão; Contatos são pós-conversão. A maioria dos outros CRMs tem apenas Contatos (com estágios de ciclo de vida). Antes de mapear qualquer coisa, decida: você está migrando Leads do Salesforce como Contatos com um estágio de ciclo de vida "Lead", ou está migrando apenas Contatos convertidos? Esta decisão afeta milhares de registros. Mudando do Salesforce para o Rework explica como essa conversão de Lead para Contato acontece especificamente no modelo de dados do Rework. E se a deduplicação desses leads ainda não aconteceu, a limpeza e deduplicação de dados deve ser executada antes de você finalizar o mapa de objetos.

Quando o modelo de objeto não corresponde: Se seu sistema de origem tem um objeto customizado sem equivalente no destino, documente-o explicitamente. Não force dados de objeto customizado em um objeto padrão, isso cria confusão. Ou migre-o como objeto customizado no destino, ou decida que não vale a pena migrá-lo.

Etapa 2: Mapeamento de Campos Padrão

Campos padrão parecem simples. Muitas vezes não são.

Nome / Sobrenome vs. Nome Completo: O Salesforce armazena nome e sobrenome separadamente. Alguns sistemas armazenam um único campo "Nome Completo". Se estiver migrando para um sistema que requer nome e sobrenome separados a partir de uma origem que tem apenas Nome Completo, você precisará de uma transformação de divisão, e é imperfeita.

Multiplicidade do campo de telefone: Contatos do Salesforce têm Phone, MobilePhone, OtherPhone, HomePhone, AssistantPhone, cinco campos de telefone separados. A maioria dos CRMs tem um telefone principal e um secundário. Decida antes da importação quais campos de origem mapeiam para quais campos de destino.

Multiplicidade de e-mail: Mesmo problema. O Salesforce tem Email e um e-mail secundário. O HubSpot suporta múltiplos e-mails por contato. Se o destino suporta apenas um e-mail principal, você precisa de uma regra sobre qual vence.

Campo de website: Formatos de URL inconsistentes causam erros de validação. Alguns registros têm "exemplo.com", alguns têm "https://www.exemplo.com", alguns têm "www.exemplo.com/produtos/pagina". Decida um formato alvo e adicione-o como regra de transformação.

Etapa 3: Inventário de Campos Customizados

É aqui que a maioria das migrações empaca. Todo CRM maduro tem dezenas de campos customizados acumulados ao longo de anos de processos em mudança. A maioria não vale a pena migrar.

Exporte todos os campos customizados do seu sistema de origem:

• Salesforce: Configuração > Gerenciador de Objetos > Selecionar objeto > Campos e Relacionamentos. Exporte como uma lista. A documentação do Salesforce Data Loader explica como o Data Loader exporta o schema dos campos junto com os dados dos registros, útil para montar o inventário junto com sua exportação.
• HubSpot: Configurações > Propriedades. Filtre por "Criado por" = sua equipe para ver propriedades customizadas. A documentação de importação do HubSpot lista quais propriedades são obrigatórias na importação: use-a como referência ao decidir quais campos de destino criar primeiro.
• Pipedrive: Configurações > Campos de Dados
• Zoho CRM: Configuração > Customização > Campos

Para cada campo customizado, aplique o teste de três perguntas. O guia de campos customizados aprofunda convenções de nomenclatura, escolhas de tipo de campo e o processo de governança para criação de campos customizados no destino, e vale a leitura antes de começar a criar campos em produção:

1. Você gera relatórios com ele? Se não houver nenhum relatório que use este campo, provavelmente não está fornecendo valor.
2. Você segmenta por ele? Se nenhum fluxo de trabalho, sequência ou filtro de lista faz referência a este campo, pode estar inativo.
3. Você automatiza a partir dele? Se nenhum gatilho de automação usa este campo, considere se ele precisa ser migrado.

Se a resposta às três for não, arquive no sistema de origem. Não crie o campo no destino.

Documente a decisão de manter/pular para cada campo customizado. Quando um rep perguntar na terceira semana por que seu campo "Tipo de Parceiro" sumiu, você quer um registro escrito de por que essa decisão foi tomada, não um encolher de ombros.

Modelo de Inventário de Campos Customizados

Etapa 4: Transformação de Valores de Lista de Opções

Campos de lista de opções são o tipo de campo de maior risco em qualquer migração. Eles parecem simples, mas escondem complexidade, valores de origem muitas vezes não correspondem a valores de destino, e valores não correspondidos importam em branco ou geram um erro.

O processo:

1. Exporte todos os valores distintos para cada campo de lista de opções da origem
2. Exporte todos os valores permitidos para o campo correspondente no destino
3. Construa um mapeamento explícito de valor para valor
4. Decida o que fazer com valores de origem sem equivalente no destino

Modelo de Mapeamento de Lista de Opções

Exemplo: Lead Status / Estágio de Ciclo de Vida

O que fazer com valores sem equivalente no destino: Não os deixe em branco. Mapeie-os para o valor de destino mais próximo (com uma nota no documento de transformação) ou crie um campo customizado no destino para preservar a distinção.

Etapa 5: Mapeamento de Campos de Relacionamento

Relacionamentos são a parte do mapeamento de campos que quebra com mais frequência e é mais difícil de corrigir depois.

Associações Conta → Contato (Salesforce): Todo Contato no Salesforce está vinculado a uma Conta via pesquisa AccountId. Na maioria dos CRMs de destino, isso se torna uma associação Contato → Empresa. A ferramenta de importação precisa resolver esse relacionamento, tipicamente correspondendo o nome da Empresa do registro do Contato a um registro de Empresa existente.

A ordem das operações importa: Importe Empresas primeiro, depois Contatos. Se você importar Contatos antes que as Empresas existam no destino, o relacionamento não pode ser estabelecido.

Associações Negócio → Contato: Um Negócio no Salesforce (Oportunidade) tem um Contato Principal e pode ter contatos adicionais via Função de Contato da Oportunidade. Verifique se o CRM de destino suporta múltiplas associações de contato por negócio.

Registros com múltiplos relacionamentos: Alguns contatos estão associados a várias empresas (consultores, membros de conselho). A maioria dos CRMs lida com isso de forma diferente do Salesforce. Documente como esses registros serão importados e teste especificamente um punhado deles na sua importação shadow.

Hierarquias de conta pai-filho: Contas do Salesforce podem ter Contas pai (para relacionamentos de subsidiárias). Nem todos os CRMs de destino suportam isso nativamente. Saiba antes de mapear se as hierarquias pai-filho sobreviverão à migração.

Etapa 6: Incompatibilidades de Tipo de Campo

Incompatibilidades de tipo de campo são o problema de mapeamento mais perigoso porque frequentemente importam sem erro, o tipo errado apenas corrompe silenciosamente os dados. A pesquisa da Gartner sobre master data management identifica a inconsistência de tipo de campo como uma das principais causas de falhas de integridade de dados em migrações de sistemas.

Tabela de Referência de Conversão de Tipo

O problema da Receita Anual: Ocorre constantemente. De acordo com a visão geral da Wikipedia sobre migração de dados, incompatibilidades de tipo de campo monetário e numérico estão entre as causas mais citadas de perda de dados em migrações. O Salesforce armazena Receita Anual como um campo de moeda. Alguns CRMs de destino armazenam como um Número simples. Se você importar uma string de moeda formatada como "R$1.250.000,00" em um campo Número, a importação falhará. Remova o símbolo de moeda e os separadores antes da importação: transforme R$1.250.000,00 em 1250000. Para uma visão mais ampla de como os modelos de dados de CRM diferem entre plataformas, incluindo o tratamento de tipos de campo, Rework vs. HubSpot CRM é uma referência útil antes de você finalizar as regras de conversão de tipo.

Campos de checkbox: Sistemas diferentes representam valores booleanos de formas diferentes. O Salesforce exporta True/False. Alguns CRMs importam 1/0. Outros exigem "Sim"/"Não". Saiba o que sua ferramenta de importação espera e transforme de acordo.

Etapa 7: O Documento de Regras de Transformação

Para cada campo que não é um mapeamento direto, escreva a regra de transformação explicitamente. Este documento se torna seu guia de importação, a pessoa executando a importação o segue sem precisar tomar decisões na hora.

Notação de Transformação

Use um formato consistente para todas as regras de transformação:

SE [campo_origem] = "[valor_origem]"
ENTÃO [campo_destino] = "[valor_destino]"
SENÃO [comportamento_padrão]

Exemplos:

SE lead_status = "Morto" OU "Sem Interesse"
ENTÃO lifecycle_stage = "Desqualificado"

SE annual_revenue = formato texto "R$N.NNN.NNN,NN"
ENTÃO annual_revenue = SUBSTITUIR("R$","") + SUBSTITUIR(".","") [apenas numérico]

SE phone = qualquer formato
ENTÃO phone = formato E.164 (+CC + número do assinante, sem separadores)

SE close_date = NULO
ENTÃO close_date = [deixar em branco, não definir nenhuma data padrão]

SE contact.account_id NÃO FOR NULO
ENTÃO [resolver AccountId → Empresa via correspondência de company_name no destino]
SENÃO [criar contato avulso sem associação de empresa]

Escreva uma regra para cada mapeamento não trivial. Se você não consegue escrever a regra, ainda não tomou a decisão, e esse é exatamente o problema que você está tentando evitar.

Etapa 8: Valide o Mapa de Campos com 100 Registros de Teste

Antes de executar a importação completa, valide cada decisão de mapeamento em relação à sua amostra de 100 registros de teste.

Execute a importação de teste usando exatamente as mesmas ferramentas. Não teste com um método de importação diferente do que você usará no dia do cutover. O objetivo é encontrar erros no seu documento de mapeamento, não na sua ferramenta de importação.

Verifique cada campo mapeado na saída:

• Os campos de texto têm os valores corretos?
• Os campos de lista de opções mostram valores de destino (não valores de origem)?
• Os campos de data exibem no formato correto?
• Os campos de moeda/número importam como números, não como texto?
• Os campos de relacionamento resolvem para as empresas/negócios corretos?

Procure por erros silenciosos: Uma execução de importação que termina sem erros não é o mesmo que uma execução de importação correta. Abra 10 registros manualmente e compare-os campo a campo com a origem.

Se você encontrar erros na importação de teste, corrija o documento de mapeamento primeiro. Não corrija registros manualmente no destino, isso corrige o sintoma e deixa a causa raiz no seu arquivo de mapeamento, onde causará o mesmo erro para os próximos 10.000 registros.

Armadilhas Comuns

Mapear campos customizados sem decidir se ainda são necessários. A etapa de inventário de campos customizados existe por um motivo. Migrar um campo que ninguém usa adiciona ruído ao CRM de destino e confunde os reps.

Ignorar incompatibilidades de tipo de campo. "Provavelmente vai ficar bem" é como a Receita Anual se torna um campo de texto que quebra seus dashboards de receita no primeiro dia.

Não documentar regras de transformação e depois esquecê-las. Você vai passar 90 minutos elaborando o mapeamento de valor de estágio de ciclo de vida. Três semanas depois, quando alguém perguntar por que Leads estão mostrando como "Desconhecido" em um relatório, você vai querer esse documento. Para as definições de estágio de ciclo de vida que ancoram esse trabalho de mapeamento, estágios de ciclo de vida de leads cobre a progressão padrão e onde a maioria das equipes diverge dela.

Tratar campos de pesquisa/associação como campos regulares. Campos de relacionamento requerem que o registro associado já exista no destino. Se você importar Contatos antes de Empresas, todas as associações de Empresa falham silenciosamente. A ordem de importação faz parte da decisão de mapeamento de campos. O guia de testes de importação shadow mostra como verificar a resolução de relacionamentos antes do cutover.

Testar apenas com registros limpos. Sua amostra de teste deve incluir casos extremos: registros com valores nulos, registros com comprimento máximo de campo, registros com caracteres incomuns. Um mapeamento que funciona com dados limpos vai falhar com dados reais se você pular os casos bagunçados. O guia de testes de importação shadow especifica exatamente como montar um conjunto de testes representativo com a mistura certa de casos extremos.

Próximos Passos

Exporte os schemas de objeto de origem esta semana. A maioria dos CRMs tem uma forma de baixar uma lista de campos com informações de tipo:

• Salesforce: Schema Builder (visual) ou chamadas describe() via Salesforce Workbench: o Workbench entrega uma lista completa de campos com nomes de API e tipos em uma única exportação
• HubSpot: Configurações > Propriedades > Exportar
• Pipedrive: Configurações > Campos de Dados
• Zoho: Configuração > Customização > Campos

Crie uma planilha com cada campo de origem e comece a preencher a coluna de campo de destino. Nesta fase, mesmo um primeiro passe aproximado é valioso, você descobrirá os casos difíceis (as incompatibilidades de lista de opções, os conflitos de tipo, os campos sem equivalente de destino) e poderá começar a tomar decisões antes que se tornem crises no dia do cutover. Quando o mapeamento de campos estiver concluído e testado, adoção e rollout do CRM cobre como preparar a equipe para o primeiro dia, porque uma importação limpa não garante uma adoção tranquila.

Saiba Mais

• Preparando seus dados antes de migrar qualquer coisa
• Limpeza de dados: deduplicação, normalização e enriquecimento
• Testando a migração com uma importação shadow
• Guia de campos customizados para o CRM de destino
• Adoção e rollout do CRM após o go-live