Mapeando Campos Entre Sistemas Legados e Novos

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.

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

Sistema de origem	Objeto de origem	Conceito de destino	Notas
Salesforce	Lead	Contato (pré-conversão)	Leads do Salesforce convertem para Contato + Conta + Oportunidade
Salesforce	Contact	Contato	Mapeamento direto
Salesforce	Account	Empresa
Salesforce	Opportunity	Negócio
Salesforce	Activity (Task/Event)	Atividade
HubSpot	Contact	Contato	Mapeamento direto
HubSpot	Company	Empresa	Mapeamento direto
HubSpot	Deal	Negócio	Mapeamento direto
HubSpot	Ticket	Ticket / Caso de Suporte	Depende do destino
Pipedrive	Person	Contato
Pipedrive	Organization	Empresa
Pipedrive	Deal	Negócio	Mapeamento direto
Pipedrive	Activity	Atividade
Zoho CRM	Lead	Contato (pré-conversão)	Semelhante ao modelo Lead do Salesforce
Zoho CRM	Contact	Contato
Zoho CRM	Account	Empresa

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.

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.

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
HubSpot: Configurações > Propriedades. Filtre por "Criado por" = sua equipe para ver propriedades customizadas
Pipedrive: Configurações > Campos de Dados
Zoho CRM: Configuração > Customização > Campos

Para cada campo customizado, aplique o teste de três perguntas:

Você gera relatórios com ele? Se não houver nenhum relatório que use este campo, provavelmente não está fornecendo valor.
Você segmenta por ele? Se nenhum fluxo de trabalho, sequência ou filtro de lista faz referência a este campo, pode estar inativo.
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

Nome do campo	Objeto	Tipo	Relatórios que o usam	Uso de segmentação	Uso de automação	Decisão	Notas
Tipo de Parceiro	Contato	Lista de opções	Sim (1 relatório)	Sim (1 lista)	Não	Migrar	Usado em relatórios de parceiros
Território Legado	Conta	Texto	Não	Não	Não	Arquivar	Substituído por novo modelo de território
Pontuação MQL (manual)	Contato	Número	Não	Não	Não	Pular	Substituído por pontuação automatizada
Detalhe da Fonte de Indicação	Contato	Texto	Sim (2 relatórios)	Não	Não	Migrar

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:

Exporte todos os valores distintos para cada campo de lista de opções da origem
Exporte todos os valores permitidos para o campo correspondente no destino
Construa um mapeamento explícito de valor para valor
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

Valor de origem	Contagem	Valor de destino	Tratamento
Novo	1.450	Lead	Mapeamento direto
Em Trabalho	680	Lead	Mapear para Lead
Em Nutrição	320	Lead	Mapear para Lead
Qualificado pelo Marketing	290	MQL	Mapeamento direto
Aceito por Vendas	175	SQL	Mapeamento direto
Qualificado por Vendas	210	SQL	Combinar com acima
Demo Agendada	88	SQL	Mapear para SQL + adicionar nota de atividade
Proposta Enviada	62	SQL	Mapear para SQL
Cliente	2.400	Cliente	Mapeamento direto
Em Risco	155	Cliente	Mapear para Cliente, adicionar tag "em-risco"
Churn	310	Cliente	Mapear para Cliente (inativo)
Morto	890	Desqualificado	Mapear para Desqualificado
Sem Interesse	430	Desqualificado	Mapear para Desqualificado

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.

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.

Tabela de Referência de Conversão de Tipo

Tipo de origem	Tipo de destino	Seguro?	Transformação necessária
Texto	Texto	Sim	Nenhuma
Texto	Lista de opções	Arriscado	Valores devem corresponder à lista; valores não mapeados falham
Lista de opções	Texto	Sim	Valores importam como estão
Número	Texto	Sim	Nenhuma
Texto	Número	Arriscado	Qualquer caractere não numérico causa erro de importação
Moeda	Número	Arriscado	Remover símbolo de moeda e separadores de milhar
Número	Moeda	Sim	Nenhuma
Data	DataHora	Sim	Acrescentar T00:00:00Z
DataHora	Data	Sim	Remover componente de hora
Texto (formato de data)	Data	Arriscado	Deve converter para ISO 8601 primeiro
Checkbox (Booleano)	Texto	Sim	Verdadeiro/Falso como strings
Texto	Checkbox	Arriscado	Deve padronizar para Verdadeiro/Falso exatamente
Pesquisa (ID)	Associação	Arriscado	Requer lógica de resolução — a maioria das ferramentas de importação não lida com isso automaticamente

O problema da Receita Anual: Ocorre constantemente. 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.

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]

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.

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.

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
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.

Data Migration Guide