> Fonte canônica: https://www.itzconsultoria.com.br/recursos/migracao-hubspot-para-pipedrive-o-que-preservar/ > Versão Markdown para leitura por sistemas de IA e ferramentas de pesquisa. > Autor: Bruno França. Publicado no Site em 2026-10-15. Atualizado em 2026-10-15. > Tema: Migração para Pipedrive. # HubSpot para Pipedrive: o que preservar na migração Quando a decisão de sair do HubSpot e ir para o Pipedrive já está tomada, eu não começo a migração contando campos. Primeiro quero entender o que precisa continuar funcionando no dia seguinte à troca. Parte disso está nos dados. Outra parte está na forma como a empresa conduz oportunidades, distribui responsabilidade, registra a próxima ação, entrega informação para outras áreas e lê a carteira. E sempre existe algum legado que fez sentido em outro momento, mas não merece ser reconstruído só porque ainda está na conta. Uma migração bem executada preserva o que ainda tem função e deixa para trás o que virou acúmulo. ## O CRM de origem é uma fonte de evidências sobre a operação Depois de alguns anos de uso, o HubSpot carrega muito mais do que empresas, contatos e negócios. Um campo pode representar uma regra comercial. Uma etapa pode ser referência para marketing, financeiro ou onboarding. Uma automação pode ter assumido uma passagem entre áreas. Um relatório pode depender de uma classificação que ninguém lembra por que foi criada. Também há estruturas que ficaram depois que sua função desapareceu. É por isso que eu olho para a conta de origem como evidência da operação atual, não como um modelo que precisa ser reproduzido no Pipedrive. Antes de decidir o que migrar, quero saber qual capacidade aquele elemento sustenta hoje. ## Preservar histórico e preservar operação são trabalhos diferentes É natural começar pela base: quantos anos de dados serão levados, quais contatos entram, quais negócios precisam ser mantidos e que propriedades serão exportadas. Só que a continuidade da operação depende de outra camada. O vendedor precisa continuar entendendo onde o negócio está, por que chegou ali e o que acontece em seguida. A gestão precisa continuar lendo carteira, evolução e risco. As passagens entre áreas precisam continuar funcionando sem depender de memória. Se os registros chegam ao Pipedrive e essa lógica se perde, a base foi migrada, mas a operação ainda precisa ser reconstruída. Histórico também merece critério próprio. Há informação que precisa continuar disponível por relacionamento, análise ou rastreabilidade. Outra pode ser mantida apenas como arquivo ou consulta durante uma transição. O fato de um dado existir não obriga a colocá-lo novamente no centro da operação. ## O primeiro de-para que me interessa é o de significado Em algum momento teremos uma planilha de mapeamento com origem e destino. Isso faz parte do trabalho. Antes dela, eu quero entender o significado operacional do que está sendo transportado. Se existe uma etapa "Proposta enviada", por exemplo, o que faz um negócio chegar ali hoje? O vendedor muda a etapa quando termina o documento, quando envia ao cliente ou quando recebe algum retorno? A resposta define se a etapa continua igual, muda de nome ou precisa de outro critério. O mesmo vale para campos, motivos de perda, status, propriedades usadas em segmentação e automações. Migrar o nome é fácil. Preservar o significado exige conhecer a regra que estava por trás dele. ## Jornada, responsabilidade e próxima ação vêm antes da carga Na leitura da migração, eu reconstruo primeiro a jornada comercial. Onde a oportunidade nasce? Quais movimentos realmente mudam seu estado? Que evidência sustenta um avanço? Quando ela pode ser considerada perdida? O que acontece depois da venda? Depois olho para responsabilidade. Quem recebe o negócio? Quem pode avançar? Quando outra área entra? Em que momento uma informação muda de dono? Como o comercial sabe que houve retorno? E olho para a próxima ação. Se o time mantém follow-up em agenda pessoal, WhatsApp ou memória, a migração precisa considerar como essa carteira será conduzida no novo ambiente. O objetivo não é transportar todo hábito existente. É evitar que o CRM novo nasça sem memória operacional. ## Campos entram quando carregam função Empresas, pessoas e negócios normalmente fazem parte do núcleo da migração. Campos exigem um pouco mais de julgamento. Um campo pode apoiar a condução da venda, uma passagem, uma integração, uma segmentação útil, uma decisão de gestão ou um histórico importante. Quando a função está clara, fica mais fácil decidir como preservar. Quando ninguém consegue explicar para que serve, eu não o recrio automaticamente. Primeiro verifico se existe alguma dependência escondida. Esse cuidado costuma reduzir bastante a quantidade de estrutura que atravessa de uma plataforma para outra sem necessidade. ## Relatórios também precisam provar utilidade É comum a conta de origem ter uma quantidade considerável de relatórios e dashboards. Alguns existem porque a liderança realmente decide com eles. Outros são herança de projetos antigos. Há casos em que o dashboard oficial existe, mas o forecast continua sendo validado em uma planilha paralela. Antes de reconstruir uma visão no Pipedrive, eu pergunto qual decisão ela precisa sustentar. A migração não precisa carregar todas as telas. Precisa preservar as leituras que ainda fazem parte da gestão. ## Integração precisa ser lida como contrato operacional HubSpot costuma estar conectado a marketing, ERP, atendimento, formulários, WhatsApp e outras peças da operação. Nessa parte, a pergunta "qual integração existe?" é pequena demais. Quero saber que informação entra, quem responde por ela, qual sistema é a referência, o que sai do CRM, o que precisa voltar e o que acontece quando a integração falha. Esse desenho revela dependências que não aparecem numa exportação de dados. Também ajuda a evitar uma situação comum depois da migração: o Pipedrive entra no ar, mas uma parte da operação continua presa à lógica do sistema anterior porque ninguém reconstruiu a passagem completa. Integrações podem deixar uma migração bem mais trabalhosa. Continuam sendo parte da migração quando estão subordinadas ao objetivo de colocar o núcleo Pipedrive em funcionamento. A complexidade muda o delivery, não a natureza do trabalho. ## Cutover precisa de uma fronteira clara Migração raramente é só apertar um botão num sábado e começar na segunda-feira. Em algum momento precisamos definir qual sistema ainda pode receber atualização e qual já passou a ser a referência. A base da carga precisa ser conhecida, os acessos precisam estar prontos, os testes precisam ter ocorrido e o time precisa saber onde trabalhar. Também precisa ficar claro o que ficou para depois sem impedir o go-live. Sem essa fronteira, a empresa pode passar semanas com dois CRMs parcialmente ativos, dados divergentes e ninguém sabendo qual deles representa a situação real da carteira. ## O que eu deixaria para trás Trocar de CRM é uma boa oportunidade para revisar estruturas que ganharam permanência apenas pelo tempo de uso. Campos que ninguém atualiza, etapas interpretadas de formas diferentes, automações criadas para contornar problemas antigos, segmentações abandonadas, relatórios que só repetem informação disponível em outro lugar. Eu não levaria isso automaticamente para o Pipedrive. Também não excluiria por estética ou vontade de "começar limpo". O critério continua sendo função. Se algo ainda sustenta uma capacidade importante, precisamos tratar essa dependência antes de retirar. O AC² entra exatamente nessa camada. Ele ajuda a separar evidência, decisão e arquitetura sem transformar a migração numa cópia técnica da conta anterior. ## Um teste antes de preparar o de-para Escolha algumas oportunidades representativas no HubSpot e reconstrua a história de cada uma. Onde entrou na jornada? Por que está na etapa atual? Qual informação foi necessária para chegar ali? Qual é a próxima ação? Quem responde pelo negócio? Que automação ou integração depende dele? Que leitura a gestão faz depois? Agora imagine o HubSpot desligado. Se você consegue apontar o que precisa existir no Pipedrive para essas histórias continuarem legíveis, o de-para técnico começa com uma base boa. Se cada oportunidade depende de uma explicação diferente, a migração já mostrou onde precisamos esclarecer regra, responsabilidade ou significado antes da carga. Isso não reabre automaticamente a decisão de migrar. Detalhes de execução fazem parte de uma migração. O ponto muda quando uma evidência nova atinge uma premissa material da própria decisão. Se ela coloca em questão o que deve ser preservado, qual arquitetura faz sentido ou se continuar a migração ainda protege o investimento já existente, seguir apenas porque o projeto começou pode sair mais caro do que revisar a direção. Quando essa escolha merece investigação própria, o Diagnóstico ITZ trata a decisão como objeto do trabalho: confronta evidências, compara alternativas e estabelece uma direção sustentada antes de comprometer mais tecnologia, operação e esforço de transição. Essa direção pode confirmar a migração, redirecionar o movimento ou concluir que não há base suficiente para avançar naquele momento. Nesse último caso, o ganho está justamente em evitar que preferência de ferramenta, cronograma ou investimento já realizado substituam a evidência. ## Migração complexa continua sendo migração Uma troca de HubSpot para Pipedrive pode envolver uma jornada simples ou múltiplos funis, histórico extenso, permissões, automações, integrações, governança, treinamento e um cutover sensível. Nos dois casos, se o objeto é colocar a operação comercial em funcionamento no Pipedrive, estamos falando de FastStart. O que aumenta é a profundidade necessária para ler legado, preparar dados, validar decisões, testar dependências e estabilizar a nova operação. Pode existir outro trabalho no mesmo programa. Se, além da migração, a empresa quer criar uma nova capacidade operacional com resultado e aceite próprios, esse objeto precisa continuar distinguível. Um processo de onboarding entre áreas ou uma camada de orquestração entre sistemas, por exemplo, pode ter vida própria além da implantação do CRM. Misturar os dois objetos só porque acontecem ao mesmo tempo dificulta escopo, aceite e gestão. ## O que precisa sobreviver à troca Depois da migração, o vendedor precisa continuar entendendo sua carteira e a próxima ação. A gestão precisa conseguir ler a operação sem reconstruí-la fora do sistema. As áreas envolvidas precisam saber quando recebem responsabilidade e qual informação precisam devolver. Os dados importantes precisam manter significado. E o legado sem função precisa parar de consumir energia só porque tecnicamente poderia ser importado. Quando o destino Pipedrive já está definido, essa é a conversa que me interessa: como mudar a plataforma sem perder a capacidade operacional que ainda vale preservar. ## Próximos recursos - [Saindo da planilha para o Pipedrive: o que precisa estar claro antes de configurar](/recursos/planilha-para-pipedrive-o-que-definir/) - [Consultoria Pipedrive ou configuração: como saber o que você precisa](/recursos/consultoria-pipedrive-ou-configuracao/) - [Conheça a atuação da ITZ com Pipedrive](/pipedrive/)