Migração de Dados para Salesforce: Guia Completo para Planejamento, Limpeza e Cutover

A Resposta Concisa

A migração de dados para o Salesforce frequentemente falha, não devido à ferramenta, mas sim a um fluxo de trabalho deficiente: iniciar o carregamento antes de compreender a qualidade da fonte, mapear campos em uma única planilha sem verificar valores discrepantes e carregar sem respeitar as dependências entre objetos. Um processo adequado é construído como um ciclo iterativo: perfil (profiling), mapeamento, limpeza, carregamento controlado, teste e reconciliação — e somente então o Cutover.

O objetivo deste artigo é detalhar este ciclo de vida em etapas claras, com uma tabela de ordem de carregamento e um checklist de reconciliação que podem ser utilizados na prática. Na maioria dos projetos, a diferença entre uma migração tranquila e uma migração que requer retrabalho é determinada já na primeira semana, na fase de perfil da fonte.

O trabalho de limpeza antecipada evita danos posteriores, e vale a pena ler mais sobre isso em Limpeza de Dados Duplicados no Salesforce.

Perfil da Fonte: Conhecendo os Dados Antes de Intervir

Antes de mapear qualquer campo, é essencial realizar um perfil da fonte de dados: quantas entradas existem em cada tabela, quais campos estão realmente vazios (não apenas no esquema, mas nos próprios dados), qual a faixa de valores em campos numéricos e de data, e onde há valores de texto livre que deveriam ser uma lista de seleção fechada. Em um projeto que acompanhamos, o campo "status do cliente" continha 47 formulações diferentes na origem — "ativo", "Active", "ativo " com espaço, "A" — todos deveriam ser mapeados para um único valor no Salesforce.

Ferramentas como OpenRefine, consultas SQL simples ou até mesmo uma Tabela Dinâmica no Excel sobre uma amostra dos dados são suficientes para a maioria dos projetos. O objetivo é criar um documento de perfil que mostre: número total de registros, porcentagem de campos obrigatórios vazios, número de valores únicos para cada campo categórico e uma identificação inicial de possíveis duplicatas por nome, telefone ou e-mail.

Nesta etapa, também se identifica se há várias fontes para informações sobrepostas — por exemplo, o mesmo cliente existe tanto no CRM antigo quanto no sistema de contabilidade — e se decide qual fonte é a "Source of Truth" para cada campo. Tal decisão deve ser documentada, não implícita, pois afeta todas as etapas subsequentes.

Mapeamento de Campos: Além da Planilha do Excel

Um bom mapeamento de campos não é apenas "coluna A da origem = campo B do destino". Ele também inclui a direção da transformação: formato de data, conversão de unidades, divisão de um campo de endereço em rua/cidade/CEP e a resolução para valores que não existem na lista de seleção fechada de destino. O melhor documento de mapeamento que vimos incluía cinco colunas: campo de origem, campo de destino, tipo de transformação, regra para tratamento de valor ausente e exemplo de entrada/saída.

Campos de Lookup e Master-Detail devem ser tratados separadamente: eles não contêm um valor direto, mas uma referência a outro registro. Portanto, seu mapeamento depende de o registro vinculado já ter sido carregado e possuir um identificador ao qual se possa apontar. Esta é a razão pela qual a ordem de carregamento (discutida posteriormente) e o mapeamento de campos são dois lados da mesma decisão.

Uma visão mais aprofundada sobre a gestão da qualidade dos campos ao longo do tempo, não apenas em uma fase única, pode ser encontrada em Qualidade de Dados Salesforce.

Limpeza e Duplicatas: Antes do Carregamento, Não Depois

Uma limpeza de dados realizada após a informação já estar no ambiente de produção é muito mais cara: ela envolve a atualização de registros ativos, o risco de quebrar automações e processos de aprovação, e às vezes, até mesmo danos a relatórios que já foram distribuídos à gerência. Portanto, a fase de limpeza deve ocorrer na camada intermediária (Staging), antes que os dados entrem no Salesforce.

Principais regras de limpeza a serem definidas antecipadamente:

• Normalização de telefone e e-mail (remoção de espaços, formato internacional consistente)
• Identificação de duplicatas por combinação de campos (nome + telefone, ou apenas CPF/CNPJ para empresas)
• Regra de seleção do registro "Master" ao mesclar duplicatas — por exemplo, o registro mais atualizado ou o mais completo
• Tratamento de valores nulos versus strings vazias, para evitar "duplicatas fantasmas"

Em um projeto típico com cerca de 80.000 registros de clientes, uma limpeza razoável identificará entre 3% e 8% de duplicatas reais. Um número significativamente maior sugere que a própria fonte não foi mantida, justificando uma discussão com os proprietários do processo de negócio antes de prosseguir.

External IDs e Ordem de Carregamento

Um External ID é um campo único do sistema de origem que também é armazenado no Salesforce, permitindo o carregamento repetitivo (Upsert) sem criar duplicatas a cada vez que um arquivo é executado novamente. Sem um External ID, cada execução repetida do Data Loader pode criar uma cópia adicional do mesmo registro, pois o sistema não consegue "identificar" um registro existente.

A ordem de carregamento é determinada pelas dependências entre os objetos: não é possível carregar um Contato antes que a Conta à qual está associado exista, e não é possível carregar um Item de Linha de Oportunidade antes da Oportunidade em si.

Desviar-se desta ordem é um dos erros mais comuns em projetos de migração: uma equipe que tenta "economizar tempo" carregando todos os arquivos em paralelo descobre milhares de erros de Lookup que são difíceis de depurar posteriormente, pois não está claro se o erro resulta de dados ausentes ou de uma ordem de carregamento incorreta.

Ambientes e Testes

A migração não é carregada diretamente para produção. Uma estrutura de ambientes recomendada inclui um Sandbox dedicado à migração (separado do Sandbox de desenvolvimento contínuo), onde o mesmo volume de dados e a mesma configuração de Validation Rules e Triggers são carregados, para expor problemas antes que afetem usuários reais.

Os testes nesta fase incluem teste de volume (se o carregamento é concluído em um tempo razoável), teste de erros (qual porcentagem de registros é rejeitada e por quê) e teste do comportamento das automações — um Flow ou Trigger que é executado na criação de um registro pode enviar um e-mail real para um cliente se não for desativado temporariamente no ambiente de teste. A negligência deste detalhe causou, em um projeto, o envio de milhares de e-mails de "boas-vindas" duplicados para clientes existentes.

Dry Run: Execução Completa Repetida

Um Dry Run é uma execução completa do processo de carregamento em condições o mais próximas possível da produção — o mesmo volume, os mesmos arquivos, a mesma ordem — mas em um ambiente Sandbox. O objetivo é medir duas coisas: o tempo de execução real (para planejar a janela de Cutover de forma realista) e a porcentagem de erros em cada etapa.

É recomendável realizar pelo menos dois Dry Runs completos: o primeiro expõe a maioria dos problemas, o segundo verifica se as correções os resolveram e não criaram novos. Se um segundo Dry Run ainda apresentar mais de 1%-2% de erros em objetos críticos, geralmente é preferível adiar a data do Cutover a comprometer a qualidade.

Cutover e Reconciliação de Dados

O Cutover é a janela real em que o sistema antigo é congelado (Freeze), as informações mais atualizadas são carregadas no Salesforce, e os usuários começam a trabalhar no novo sistema. O sucesso nesta etapa é medido não apenas se "o carregamento foi concluído", mas pela Reconciliação — uma comparação sistemática entre a origem e o destino.

Checklist de Reconciliação a ser executado no final de cada Cutover:

• ☐ Contagem de registros idêntica (ou explicada por uma diferença conhecida) em cada objeto principal
• ☐ Soma de campos financeiros (por exemplo, o valor total de oportunidades abertas) corresponde entre as fontes
• ☐ Amostra aleatória de 30-50 registros verificada manualmente campo a campo
• ☐ Verificação de relacionamentos — cada Contato tem uma Conta válida, cada Item de Linha de Oportunidade tem uma Oportunidade
• ☐ Verificação de registros "órfãos" — carregados sem uma referência válida
• ☐ Comparação da contagem de duplicatas antes e depois em relação ao objetivo estabelecido na fase de limpeza
• ☐ Aprovação do proprietário do processo de negócio de que sua amostra de dados parece correta

Discrepâncias comuns de Reconciliação incluem: contagem de registros correspondente, mas totais incorretos porque um campo numérico foi carregado em formato errado; ou relacionamentos ausentes porque um Lookup foi carregado por valor de texto e não por External ID. A documentação completa do processo de reconciliação, incluindo um exemplo de Baseline, também pode ser encontrada em Gestão de Dados Mestre Salesforce.

Correções Pós Go Live

Mesmo um Cutover bem-sucedido deixa um "vestígio" de correções: registros individuais que foram rejeitados no carregamento, usuários que relatam dados ausentes e lacunas que só são descobertas quando usuários reais trabalham com o sistema e não apenas o testam. Uma janela de duas a quatro semanas deve ser alocada antecipadamente para correções pontuais, com um relatório diário de exceções na primeira semana e semanalmente depois.

É importante distinguir entre uma correção pontual (um único registro atualizado manualmente) e uma correção sistêmica (um erro de mapeamento que se repete em milhares de registros e requer correção na própria ferramenta de carregamento e uma nova execução). A confusão entre os dois leva as equipes a corrigir manualmente um problema que é, na verdade, sistemático, e a perder muito tempo.

Cenário Organizacional de Exemplo

Uma empresa de distribuição com cerca de 120.000 clientes em um CRM antigo e uma lista separada de clientes em seu sistema de contabilidade solicitou a migração de ambas as fontes para um único Salesforce. Um perfil inicial revelou que 11% dos clientes apareciam em ambas as fontes com informações de contato diferentes, e o campo "ramo de atividade" continha 340 valores livres que deveriam ser cerca de 25 categorias.

A equipe construiu um mapeamento de campos detalhado, estabeleceu uma regra de mesclagem combinando CPF/CNPJ e telefone, e definiu o sistema de contabilidade como a "Source of Truth" para informações de faturamento e o CRM antigo como a "Source of Truth" para informações de contato. Um primeiro Dry Run revelou que 4% dos registros foram rejeitados devido a um formato de data inválido — uma correção que foi considerada no segundo Dry Run. O Cutover foi realizado no final de semana, com Reconciliação completa na manhã de segunda-feira antes da abertura do sistema para os usuários.

O resultado: menos de 0,3% dos registros exigiram correção manual após o Go Live, em comparação com uma estimativa inicial da equipe que esperava cerca de 5% de exceções. A diferença resultou quase inteiramente dos dois Dry Runs realizados antes da data oficial.

Riscos Comuns e Ações Preventivas

No nível de gestão da migração de dados para o Salesforce, esta tabela de riscos é apenas um ponto de partida. Uma extensão sobre a gestão contínua da qualidade, incluindo a diferença entre limpeza pontual e governança de dados contínua, pode ser encontrada em Data 360 Zero Copy.

Como Medir o Sucesso

Para a maioria dos projetos, de três a cinco métricas são suficientes para a primeira versão. Uma boa métrica pode ser calculada antes e depois da mudança, está relacionada a um proprietário de processo de negócio e não pode ser artificialmente melhorada pela inserção parcial de dados. Quando não há uma linha de base documentada do sistema antigo, é aconselhável investir um ou dois dias na medição do estado atual antes de relatar melhorias.

Checklist Antes do Go Live

• ☐ Perfil da fonte realizado, incluindo porcentagens de campos vazios e duplicatas
• ☐ Documento de mapeamento de campos completo, incluindo transformações e tratamento de valores ausentes
• ☐ External ID definido para cada objeto que requer carregamento repetitivo
• ☐ Ordem de carregamento documentada e acordada pela equipe técnica
• ☐ Dois Dry Runs realizados e os erros reduzidos abaixo do limite estabelecido
• ☐ Cenário de Rollback documentado para o caso de falha no Cutover
• ☐ Checklist de Reconciliação pronto e quem irá executá-lo é conhecido antecipadamente
• ☐ Janela de correções após o Go Live alocada no cronograma
• ☐ Automações que possam enviar comunicações a clientes verificadas e desativadas durante o carregamento
• ☐ Proprietário do processo de negócio aprovou uma amostra final de dados

Notas aprofundadas para Implementação e Manutenção

Nota do Arquiteto: Migração Não é um Evento Único

Mesmo após um Go Live bem-sucedido, mudanças no sistema de origem (se ele continuar operando temporariamente em paralelo) ou correções manuais criam desvio entre os dados. Portanto, é aconselhável manter um relatório de Reconciliação regular — semanal no primeiro mês, mensal depois — que compare uma amostra de dados entre os relatórios antigos e novos e identifique desvios precocemente. Um projeto que trata a migração como uma linha de chegada ignora que a qualidade dos dados é um processo contínuo.

Do ponto de vista gerencial, o verdadeiro teste de uma migração de dados para o Salesforce não é apenas se os registros foram carregados, mas se os gerentes de Dados, CRM e Projetos podem confiar nos relatórios do dia seguinte sem verificar manualmente cada número. Organizações que buscam apoio profissional para tal processo podem utilizar o serviço de integrações e dados, que acompanha tanto a fase de planejamento quanto a própria janela de Cutover.

Fontes Profissionais

• Salesforce Data 360 — https://www.salesforce.com/data/
• Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
• HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data