Migração de CRM para Salesforce: Planejando a Transição sem Perda de Processos ou Dados

A Resposta Curta

Substituir um sistema de CRM pelo Salesforce não é um projeto técnico de "migração de dados" — é uma decisão organizacional sobre o que vale a pena reter, o que deve ser deixado para trás e como continuar operando o negócio enquanto a transição ocorre. A falha mais comum não reside no design do próprio Salesforce, mas na suposição tácita de que tudo o que existe no sistema antigo deve ser transferido exatamente como está.

A abordagem correta começa com o mapeamento de processos, e não com a exportação de tabelas. Em seguida, um novo modelo de dados é construído, alinhado à forma como a organização opera hoje, e não à estrutura definida há dez anos em outro sistema. Um período de paralelismo controlado e, por fim, a desativação organizada do sistema antigo com documentação para conformidade regulatória, completam o processo.

Organizações que lidam com essas questões encontram um contexto complementar em Implementação do Salesforce em uma Organização, onde o processo abrangente de tomada de decisões em um projeto Salesforce é detalhado.

Mapeamento de Processos Existentes: Não Exportação, Mas Compreensão

O primeiro passo em qualquer transição de sistemas CRM não é usar a função "Exportar", mas sim sentar-se com os proprietários dos processos e entender o que realmente acontece entre a abertura de um lead e o fechamento de um negócio, ou entre o registro de uma solicitação e o encerramento de um caso de serviço. Um documento de processo antigo, se é que existe, está quase sempre desatualizado em relação ao que ocorre na prática.

Nas reuniões de mapeamento, é recomendável documentar não apenas os passos formais, mas também os "processos ocultos" — planilhas Excel paralelas, campos que ninguém preenche, aprovações que ocorrem via WhatsApp em vez de no sistema. São exatamente esses pontos que, se não forem considerados, podem levar ao fracasso da adoção de um novo sistema, mesmo que ele tenha sido construído corretamente.

O resultado do mapeamento deve incluir uma tabela dos processos essenciais, o proprietário do processo, a frequência de uso e o grau de dependência do sistema antigo. Um processo acionado uma vez por trimestre que gera um relatório crítico para o regulador exige uma abordagem diferente de um processo diário de alto volume. Essa categorização também determina a ordem da migração e o nível de testes necessário para cada processo.

O Que Não Migrar: Uma Decisão Que Economiza Metade do Trabalho

Uma das decisões mais significativas em um projeto de migração de CRM não é o que migrar, mas o que não migrar. Na maioria dos sistemas antigos que se acumularam ao longo dos anos, há camadas de campos duplicados, status obsoletos e processos definidos para um projeto pontual que já foi concluído.

Uma regra prática: qualquer objeto ou campo que não tenha sido acessado nos últimos dois anos é, por padrão, movido para a lista de "não migrar", a menos que um proprietário de processo específico solicite uma exceção justificada. Essa lista é construída com base nos logs de uso reais do sistema antigo, e não na memória dos usuários, pois, em geral, a memória humana descreve o sistema como ele deveria funcionar, e não como realmente funciona.

É importante distinguir entre três categorias de informações:

• Dados Vivos – Devem ser movidos para o novo sistema como registros ativos com todas as suas associações.
• Dados Históricos Relevantes – Migram como arquivo para consulta, geralmente sem necessidade de edição ou automação.
• Dados Mortos – Não são migrados de forma alguma, sendo mantidos apenas em backup externo para fins de auditoria, se necessário.

Mais detalhes sobre a gestão dos limites entre as fases de planejamento e construção podem ser encontrados em Scope Creep no Salesforce, pois a tendência de adicionar "apenas mais alguns dados antigos" é uma das fontes mais comuns de desvio de escopo nesse tipo de projeto.

Modelo de Dados Novo versus Antigo: Não Tradução, Mas Design

Um erro comum é abordar o modelo de dados como uma tradução 1:1 — cada tabela do sistema antigo se torna um objeto no Salesforce, cada coluna um campo. Essa abordagem preserva todas as fraquezas do sistema antigo dentro de uma nova plataforma e perde o principal benefício do Salesforce: a capacidade de construir relacionamentos flexíveis entre objetos, automação integrada e uma rica camada de permissões.

Uma comparação entre as duas principais abordagens de transição ajuda a tomar uma decisão consciente:

Na prática, a maioria das organizações opta por uma abordagem intermediária: Redesign para o modelo de dados central (contas, contatos, oportunidades ou casos de serviço) e Lift-and-Shift controlado para entidades secundárias que não têm impacto processual significativo. Essa decisão deve ser tomada explicitamente na fase de planejamento, e não surgir aleatoriamente durante a construção.

Período de Paralelismo: Como Manter a Continuidade dos Negócios

O período de paralelismo é a janela de tempo em que os dois sistemas operam lado a lado — geralmente entre quatro e oito semanas. Seu objetivo é expor lacunas em tempo real, antes que se tornem um problema irreversível. Uma venda fechada, uma solicitação de serviço aberta ou um relatório de comissões gerado — tudo isso deve ser verificado simultaneamente em ambos os sistemas e apresentar um resultado idêntico ou explicável.

Uma pergunta que surge em quase todos os projetos: qual sistema é considerado a "fonte da verdade" durante esse período? A resposta deve ser única e predefinida, geralmente o Salesforce desde o primeiro dia, com o sistema antigo servindo apenas para validação e não para trabalho diário. O trabalho duplicado dos usuários em ambos os sistemas é uma receita para o cansaço e o abandono efetivo do novo sistema.

Ferramentas práticas para gerenciar o período:

• Relatório comparativo diário ou semanal entre os dados-chave dos dois sistemas (número de leads, valor de negócios, chamados abertos).
• Lista de exceções viva, atualizada assim que uma lacuna é detectada, com um proprietário responsável por resolvê-la dentro de um período definido.
• Grupo de "usuários âncora" de cada departamento que relatam diariamente falhas de uso, e não apenas falhas técnicas.

Grande parte dos insights coletados durante esse período é relevante também para o processo de testes formal, detalhado no Guia de UAT para Salesforce, e para o período pós-lançamento, descrito no Plano de Hypercare para Salesforce.

Desativação do Sistema Antigo: Não um Evento Único, Mas uma Sequência de Decisões

A desativação do sistema antigo é realizada em etapas, não com um único clique no dia do cutover. A regra geral é: o sistema é desconectado do trabalho diário imediatamente após o Go Live, mas permanece acessível apenas para leitura por um curto período de graça, geralmente 30-60 dias, caso um dado ausente ou uma pergunta da equipe financeira seja detectada.

Lista de Verificação para Decisão de Cutover

Antes de emitir um aviso oficial de que o sistema antigo será desconectado, é aconselhável verificar:

• ☐ Todos os relatórios gerados regularmente do sistema antigo foram replicados com sucesso no Salesforce ou no arquivo
• ☐ Um ciclo de negócios completo (por exemplo, um mês de fechamento completo) foi concluído inteiramente no novo sistema
• ☐ As lacunas de dados entre os sistemas caíram abaixo de um limite predefinido (por exemplo, menos de 1% dos registros)
• ☐ Há uma confirmação por escrito da área jurídica ou financeira de que o arquivo atende aos requisitos de retenção
• ☐ Foi definido quem é responsável pelo acesso de leitura durante o período de graça e quando ele será encerrado permanentemente
• ☐ Foi feito um backup completo e verificado de todos os dados do sistema antigo antes do cancelamento da licença
• ☐ Foi enviado um aviso a todos os proprietários de processos sobre a data final de desconexão e a forma de acesso ao arquivo

Pular um desses itens é a razão mais comum pela qual, meses após o projeto, descobre-se que não há acesso a informações subitamente necessárias para uma auditoria fiscal ou processo judicial.

Arquivo e Regulamentação: O Que É Preciso Guardar e Por Quanto Tempo

Os requisitos de retenção de dados variam entre os setores, mas quase sempre há a obrigação de reter dados financeiros, contratuais ou relacionados a reclamações de clientes por um período de sete anos ou mais. O erro comum é tentar "empurrar" todo esse histórico para o Salesforce como registros ativos, o que sobrecarrega o desempenho e confunde os usuários que veem transações de uma década atrás em suas listas diárias.

A solução comum é a separação entre duas camadas:

É crucial documentar a política de arquivamento por escrito e obter aprovação da área jurídica antes de desativar o acesso ao sistema antigo, pois, uma vez que a licença é cancelada, não há como voltar atrás se um dado ausente for detectado.

Cenário Organizacional de Exemplo

Uma empresa de serviços financeiros fez a transição de um sistema CRM local de 12 anos para o Salesforce. Durante a fase de mapeamento, a equipe identificou que aproximadamente 40% dos campos existentes não haviam sido tocados por dois anos ou mais e decidiu excluí-los da migração. Isso economizou cerca de um mês de trabalho em construção e testes.

Durante o período de paralelismo, que durou seis semanas, foi descoberta uma discrepância no cálculo de comissões devido a uma diferença no arredondamento de números entre os sistemas — um problema que não teria sido detectado sem um relatório comparativo diário. A equipe corrigiu a fórmula antes que ela afetasse um contracheque real. O sistema antigo foi desconectado do trabalho diário no dia do Go Live, mas o acesso de leitura foi mantido por mais 45 dias para fins de validação de um relatório trimestral que já estava em andamento.

O resultado: três meses após a desconexão final, nenhum acesso adicional ao sistema antigo foi necessário, e a economia nos custos de licenciamento cobriu uma parte significativa do custo do próprio projeto de migração.

Riscos Comuns e Ações Preventivas

Como Medir o Sucesso da Transição

Para a substituição de um sistema CRM pelo Salesforce, é aconselhável escolher apenas três a cinco métricas com antecedência e medi-las tanto antes quanto depois do projeto – caso contrário, é difícil provar que a transição realmente melhorou o processo e não apenas o transferiu para outra plataforma. A execução prática desse processo pode ser realizada com o apoio de serviços de implementação do Salesforce, que acompanham as organizações desde a fase de mapeamento até a desconexão do sistema antigo.

Fontes Profissionais

• Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html
• HPI Pro – Implementação do Salesforce — https://hpi.pro/salesforce-implementation
• HPI Pro – Metodologia de Trabalho — https://hpi.pro/methodology