Se eu trocar o sistema de gestão/prontuário da clínica, perco o histórico e as automações de CRM que já configurei?

"Se eu trocar o sistema de gestão/prontuário da clínica, perco o histórico e as automações de CRM que já configurei?"

Essa pergunta esconde duas perguntas com respostas diferentes.

O histórico é dado. Ele mora num banco, tem dono, e o seu contrato decide se ele sai de lá inteiro ou picado.

A automação não é dado. É configuração. Ela mora numa camada que nenhum export leva junto, porque não é informação de paciente: é regra escrita dentro do sistema que você está abandonando.

Por isso a clínica que migra com o time de TI do fornecedor novo costuma acertar o banco e quebrar a operação. Os pacientes aparecem lá dentro, e o lembrete de consulta simplesmente para de sair.

Neste guia você vai ver:

• O que migra de fato e o que fica para trás na troca de sistema
• Onde cada automação da sua clínica mora (e quais a troca derruba)
• Por que a régua quebra tecnicamente, mesmo com a base inteira migrada
• O que a LGPD garante (e a quem) na hora de sacar os seus dados
• As cláusulas de saída que você precisa exigir antes de assinar o novo contrato
• O prazo legal de guarda do prontuário que impede desligar o sistema antigo
• O plano de virada em paralelo, a ordem de religamento e o checklist de aceite

Dado migra, configuração não: a separação que define a sua troca

Comece separando duas camadas que a conversa comercial junta de propósito.

Camada 1, o banco. Cadastro de pacientes, prontuário, anexos e imagens, plano de tratamento, financeiro, parcelas, agenda histórica. É conteúdo. Migra, desde que o export exista e seja completo.

Camada 2, a automação. Gatilhos por status, réguas de confirmação e retomada, tags, segmentações, templates de mensagem, campos customizados, webhooks, usuários e permissões. É regra. Não migra.

Essa segunda camada é a que você construiu ao longo de anos, testando o que funciona na sua operação. Ela não está num arquivo: está espalhada em telas de configuração.

Nenhum export de banco carrega uma regra como (exemplo) "quando o status virar Orçamento Aprovado, dispare a mensagem no dia seguinte". Isso é reescrito no destino, à mão.

Lembre: o fornecedor novo te promete migrar "todos os dados". Ele está falando a verdade, e ainda assim a sua clínica pode acordar sem régua nenhuma. Dado e automação são conversas diferentes, com responsáveis diferentes.

Onde cada automação da sua clínica realmente mora

Antes de estimar o estrago, descubra o endereço de cada régua. A troca do sistema de gestão derruba algumas e não toca em outras.

Onde a régua mora	Exemplo típico na clínica	O que a troca de sistema faz com ela
Dentro do próprio sistema de gestão	Lembrete de consulta disparado pela agenda	Morre junto. Cancela o sistema, acaba a régua
CRM externo integrado por API	Esteira de orçamento aberto, funil do CRC	Sobrevive, mas quebra: os IDs de paciente mudam
Conta do WhatsApp Business API (BSP)	Templates aprovados, opt-in, histórico de conversa	Fica de pé, se a conta estiver no CNPJ da clínica
Orquestrador no-code	Rotina que liga agenda, planilha e disparo	Sobrevive, mas cada gatilho aponta para o endereço antigo
Planilha mais pessoa	Lista de retorno que a recepção puxa toda segunda	Sobrevive, e é a única que ninguém documentou

Repare no padrão: quanto mais a automação depende do sistema de gestão como fonte da verdade, mais ela cai na troca.

O que está fora dele não cai, mas fica apontando para um lugar que deixou de existir. É pior, porque falha em silêncio.

Por que a automação quebra tecnicamente, mesmo com a base inteira migrada

Aqui está o detalhe que a reunião de migração não cobre. A base pode estar perfeita e a régua continuar morta. Três motivos, em ordem de frequência:

1. Os IDs de paciente são reemitidos. O sistema novo cria a própria chave interna para cada cadastro. Toda automação externa que guardava o identificador antigo do paciente passa a apontar para ninguém, ou pior, para outra pessoa.

2. Os webhooks apontam para o endereço antigo. Cada integração publica evento para uma URL. Enquanto o sistema antigo responde, a rotina parece viva. Quando ele é desligado, o disparo vira erro silencioso que ninguém monitora.

3. Os templates aprovados ficam presos à conta antiga. Mensagem de utilidade no WhatsApp passa por aprovação prévia e vive dentro de uma conta específica. Se a conta era do fornecedor antigo, você recomeça do zero, inclusive a reputação dela.

Some a isso os campos customizados sem correspondência no destino (o "motivo de não fechamento" que virou texto livre), os formatos de telefone e data que divergem, e os status de agenda que não batem um para um.

É por isso que a automação costuma quebrar exatamente no ponto de contato entre dois sistemas, não dentro de um deles. O detalhamento desse ponto está em onde a automação quebra quando CRM e agenda não conversam.

Faça o inventário da camada de automação antes de tocar em qualquer coisa

Você não consegue proteger o que não listou. O inventário é a primeira tarefa, antes de escolher fornecedor, antes de pedir demonstração.

Levante cada régua ativa com estas colunas:

Campo do inventário	O que registrar	Por que importa
Nome da régua	"Confirmação da véspera"	Sem nome, ninguém cobra o religamento
Gatilho	Status, data, tag, evento de agenda	Diz se o gatilho existe no sistema novo
Canal e conta	WhatsApp, SMS, e-mail, e de qual conta sai	Define o que precisa ser reaprovado
Volume mensal	Quantos disparos saem por mês	Separa régua viva de régua decorativa
Impacto medido	Efeito em comparecimento, retomada ou agendamento	Define a ordem de religamento
Dono	Quem configura e quem cobra o resultado	Evita órfã na virada

O inventário sempre revela automação morta

Aqui vem o subproduto mais útil do exercício: boa parte das réguas que você acha que existem está desligada, duplicada ou disparando para lista vazia.

Não reconstrua automação morta no sistema novo. Isso é dívida técnica que você está pagando para carregar.

A pergunta de corte é simples: se essa régua parasse hoje, alguém da clínica perceberia falta? Se a resposta é não, ela não entra no plano de migração.

Portabilidade na LGPD é direito do paciente, não da clínica

Muito dono de clínica acredita que a LGPD garante o direito de sacar o próprio banco do fornecedor. Não é o que a lei diz.

A Lei 13.709/2018, no Art. 18, V, garante ao titular dos dados a "portabilidade dos dados a outro fornecedor de serviço ou produto, mediante requisição expressa, de acordo com a regulamentação da autoridade nacional, observados os segredos comercial e industrial" (redação dada pela Lei nº 13.853, de 2019).

Titular, na sua clínica, é o paciente. Não é você, não é o CNPJ, não é o contratante do software.

Na mesma Lei 13.709/2018, o Art. 19, §3º prevê que, quando o tratamento tem origem no consentimento ou em contrato, o titular pode solicitar "cópia eletrônica integral de seus dados pessoais, observados os segredos comercial e industrial, nos termos de regulamentação da autoridade nacional, em formato que permita a sua utilização subsequente". E o Art. 19, II fixa prazo de até 15 dias, contado da data do requerimento, para a declaração clara e completa sobre o tratamento.

O que a lei te dá como clínica é outra coisa, e é importante: você é a controladora. O Art. 39 determina que o operador realize o tratamento segundo as instruções fornecidas pelo controlador, que verificará a observância dessas instruções e das normas sobre a matéria.

Traduzindo para a mesa de negociação: você manda na finalidade do tratamento, mas o formato do arquivo, o prazo de entrega e o preço do export não caem do céu. Eles vêm do contrato.

Nota: quem decide o que a clínica pode sacar do fornecedor é a cláusula de saída do contrato, não a LGPD. Trate a discussão de propriedade do dado como item comercial, decidido antes da assinatura.

Consentimento e opt-in não migram como se fossem campo de cadastro

Esse é o erro que mais gera risco jurídico na troca, e o mais fácil de cometer.

A equipe importa a planilha com a coluna "aceita receber mensagens" marcada como verdadeira e considera o opt-in resolvido. Não está.

O aceite não é o valor do campo. É o registro de como, quando e para qual finalidade o paciente concordou, dentro da base legal que sustenta aquele contato.

A LGPD coloca o ônus onde dói. O Art. 8º, §2º estabelece que cabe ao controlador o ônus da prova de que o consentimento foi obtido em conformidade com o disposto na lei (Planalto). Quem tem que provar é a clínica, não o fornecedor.

E o consentimento é revogável: o Art. 8º, §5º garante revogação a qualquer momento, mediante manifestação expressa do titular, por procedimento gratuito e facilitado. Ou seja, a lista de descadastro do sistema antigo precisa atravessar a migração intacta, ou você vai disparar para quem já pediu para sair.

Faça três coisas no plano de migração:

1. Exporte o registro do aceite, não só o campo booleano: data, origem, texto apresentado e canal.
2. Exporte a lista de opt-out antes de qualquer outra tabela e importe primeiro no destino.
3. Registre as operações de tratamento. O Art. 37 determina que o controlador e o operador mantenham registro das operações de tratamento de dados pessoais que realizarem. A migração é uma operação.

As cláusulas de saída que você exige antes de assinar o sistema novo

A hora de resolver a próxima troca é agora, quando você ainda é o cliente que está prestes a assinar. Depois da assinatura, o seu poder de negociação cai.

Coloque no contrato, por escrito:

1. Formato do export. Formato aberto e legível (CSV, XML, JSON, PDF/A para documentos), não um dump proprietário que só o próprio sistema lê.
2. Escopo do export. Cadastro, prontuário, evoluções, anexos, imagens, áudios, documentos assinados, financeiro, agenda e logs de auditoria. Anexo e imagem são o que mais fica de fora.
3. Prazo de entrega contado a partir do pedido formal, com prazo também para o caso de rescisão por inadimplência.
4. Custo. Defina se o export está incluso ou tem preço, e qual. Export sem preço no contrato é preço definido depois, por quem não quer te ver sair.
5. API aberta e documentada durante toda a vigência, para que a sua camada de automação não dependa de exportação manual.
6. Ambiente de homologação (sandbox) para testar a migração e as réguas sem tocar em dado de produção.
7. Devolução e eliminação. O Art. 16 da LGPD trata da eliminação dos dados após o término do tratamento, com as hipóteses de conservação previstas na própria lei. Peça devolução completa e declaração de eliminação.
8. Responsabilidade. O Art. 42, §1º, I prevê que o operador responde solidariamente pelos danos causados pelo tratamento quando descumprir as obrigações da legislação de proteção de dados ou quando não tiver seguido as instruções lícitas do controlador.

Um teste rápido de maturidade do fornecedor: peça um export de teste antes de assinar. Quem entrega em dias tem export de verdade. Quem enrola já te respondeu.

O prazo de guarda do prontuário impede desligar o sistema antigo

Tem uma trava legal que a decisão comercial costuma ignorar: o prontuário não é seu para descartar quando o contrato acabar.

A Lei 13.787/2018, no Art. 6º, estabelece que, decorrido o prazo mínimo de 20 (vinte) anos a partir do último registro, os prontuários em suporte de papel e os digitalizados poderão ser eliminados. Antes disso, não.

O Código de Ética Odontológica, no Art. 17, exige "a elaboração e a manutenção de forma legível e atualizada de prontuário e a sua conservação em arquivo próprio seja de forma física ou digital" (CFO). Arquivo próprio, note bem: a obrigação é da clínica, não do fornecedor de software.

Isso muda a ordem das coisas. Você não cancela o sistema antigo e depois resolve o acervo. Você resolve o acervo e só então cancela.

E o que sai precisa sair íntegro. A mesma Lei 13.787/2018, no Art. 2º, §2º, determina que no processo de digitalização seja utilizado certificado digital emitido no âmbito da Infraestrutura de Chaves Públicas Brasileira (ICP-Brasil) ou outro padrão legalmente aceito. O Art. 5º dá ao documento digitalizado em conformidade com a lei o mesmo valor probatório do original.

Um export que perde anexo, corta evolução antiga ou entrega imagem em resolução degradada não é arquivo: é um problema adiado para o dia em que alguém pedir aquele registro. O caminho técnico completo está em digitalização de prontuários.

Manter o sistema antigo em modo leitura ou exportar tudo?

Essa é a decisão de arquivo, e ela tem custo recorrente de um lado e trabalho concentrado do outro.

Critério	Sistema antigo em modo leitura	Export completo e arquivo próprio
Custo	Mensalidade reduzida, por anos	Trabalho concentrado uma vez
Risco	Fornecedor pode encerrar, mudar preço ou sumir	Depende do seu backup e da sua governança
Acesso no dia a dia	Duas telas, equipe entra no lugar errado	Uma tela só, acervo fora da rotina
Integridade	Continua no formato original	Exige processo com integridade verificável
Prazo de guarda	Você terceiriza a obrigação que é sua	Você assume a obrigação que já era sua

Na prática, a combinação costuma vencer: export completo com integridade verificável para o seu arquivo, mais uma janela curta de leitura no sistema antigo enquanto a equipe valida o que ficou faltando.

O que não funciona é escolher o modo leitura por prazo indefinido e chamar isso de plano. Isso é dependência de fornecedor com aparência de prudência.

Dependência de fornecedor único: o contrato é a mitigação, não a esperança

Sistema integrado de fornecedor único resolve muita dor operacional e cria uma nova: quanto mais o seu fluxo depende de um só ambiente, menor a sua autonomia para trocar.

Não é argumento contra integrar. É argumento a favor de integrar com saída desenhada.

Três decisões práticas que preservam autonomia:

1. Mantenha a camada de contato fora do sistema de gestão sempre que possível. Conta de WhatsApp Business API no CNPJ da clínica, CRM com base exportável, orquestrador com as rotinas versionadas.
2. Documente a régua fora do fornecedor. Um documento com gatilho, texto e janela de disparo de cada régua transforma reconstrução em tarefa de dias, não de meses.
3. Trate export periódico como rotina. Se você só descobre que o export é ruim no dia da saída, descobriu tarde.

Para quem chegou até aqui procurando alternativa à troca, vale ler como automatizar a clínica sem trocar o software de gestão.

A janela de risco operacional: o que acontece enquanto a régua está fora do ar

Migração tem um custo que não aparece na proposta comercial: os dias em que a sua operação roda sem a automação que segurava resposta, confirmação e retomada.

E a demanda não espera o seu cronograma. Segundo dados internos da Odonto Results (2026), 46,0% dos leads de clínica odontológica chegam fora do horário comercial. Base: 16.719 leads com mensagem registrada no WhatsApp. Janela: 25 de março a 25 de agosto de 2026.

O paciente também decide rápido quando é bem atendido. Ainda segundo dados internos da Odonto Results (2026), entre os leads que agendam, metade fecha em até 34 minutos e 53,6% em menos de 1 hora. Base: 3.148 agendamentos. Janela: 25 de março a 25 de agosto de 2026.

Traduzindo para a semana da virada: quem chega de madrugada com a régua desligada não recebe resposta, e quem responderia em minutos esfria. O custo não é "um transtorno". É agenda que não existe nas semanas seguintes.

Por isso a virada não pode ser um evento surpresa para a recepção. Ela precisa de contingência escrita.

Virada em paralelo (dual-run): data de corte, congelamento e rollback

O padrão que funciona é operar os dois sistemas por uma janela curta e definida, com regra clara de quem manda em quê.

Monte assim:

1. Escolha a data de corte no ponto de menor volume da agenda (exemplo: virada de sábado, com corte na sexta ao fim do expediente).
2. Congele a configuração do sistema antigo alguns dias antes. Nada de criar régua nova ali durante a migração.
3. Carregue uma base de teste no sistema novo e homologue cada régua com disparo real para números da própria equipe.
4. Defina a fonte da verdade durante o dual-run. Agenda nova manda; sistema antigo vira consulta. Sem isso, a recepção marca nos dois e você perde a reconciliação.
5. Coloque a contingência manual no ar. Lista de confirmação do dia impressa ou em planilha, com responsável nomeado por turno.
6. Escreva o critério de rollback antes de começar. Exemplo: se a agenda do dia seguinte não reconciliar, ou se a régua de confirmação não disparar no teste, a virada volta para o sistema antigo no mesmo dia.

Critério de rollback decidido no calor da virada vira discussão. Decidido antes, vira procedimento.

Ordem de religamento das automações depois da virada

Não religue tudo de uma vez. Automação ligada sem conferência dispara para a base errada, e a sua clínica vira remetente de mensagem indevida.

Onda	O que religar	Critério para liberar a próxima onda
1	Lembrete de consulta e confirmação pré-atendimento	Disparo correto para a agenda do dia seguinte, sem duplicidade
2	Resposta ao lead novo e triagem de urgência	Tempo de primeira resposta estável e roteamento correto
3	Retomada de orçamento aberto e reagendamento de falta	Lista conferida por amostragem, sem paciente já tratado
4	Nutrição de lead frio, pós-operatório e NPS	Base higienizada e opt-out importado e testado

A lógica da ordem é o custo do erro. Lembrete errado gera confusão pontual. Nutrição disparada para a base inteira gera bloqueio de número e reclamação.

Quem está trocando o fornecedor da camada de atendimento, e não o sistema de gestão, encontra o roteiro específico em troca de fornecedor de IA de atendimento sem perder histórico e treino.

Higienize a base antes de carregar a régua nova

A migração é a melhor janela que você vai ter para limpar o que está sujo. Depois de importado, o lixo vira rotina.

Resolva, na ordem:

• Duplicados. Mesmo paciente com dois cadastros gera mensagem dobrada e histórico partido.
• Telefones inválidos. Número desatualizado consome disparo e polui a sua taxa de entrega.
• Opt-out. Importe a lista de descadastro antes de qualquer outra tabela e teste o fluxo de saída antes de ligar régua.
• Inativos antigos. Decida com critério de tempo e de base legal quem entra na régua de reativação e quem fica só no arquivo.

Higienizar não é apagar. Prontuário continua sob o prazo legal de guarda, mesmo quando o paciente sai da régua de comunicação.

Treine por função, ou a base nova vira gargalo de agenda

Sistema novo com equipe destreinada produz o mesmo sintoma de sistema ruim: fila na recepção, agenda com buraco e dado preenchido errado.

Treine separado, porque cada função usa outra parte:

• Recepção e CRC: cadastro, agendamento, status, registro de contato e o que dispara régua.
• Dentista: evolução, anexo de imagem, plano de tratamento e assinatura.
• Financeiro: parcelas, recebimento, conciliação e relatório.

Faça o treino com a base real já migrada, não com ambiente de demonstração. A dúvida que trava a recepção aparece no dado da sua clínica, não no dado de exemplo do fornecedor.

Checklist de aceite pós-virada

A migração só termina quando você consegue provar que ela deu certo. Prova é contagem e amostra, não sensação.

O que conferir	Como conferir	Critério de aprovação
Pacientes	Contagem total no antigo contra o novo	Diferença explicada item a item
Prontuários e evoluções	Amostragem aleatória, comparando lado a lado	Conteúdo completo, com anexos abrindo
Financeiro	Total de parcelas em aberto e recebido	Soma idêntica, sem parcela órfã
Agenda futura	Todos os compromissos marcados no novo	Nenhum horário perdido ou duplicado
Réguas	Disparos por régua na primeira semana	Volume compatível com o inventário
Taxa de resposta	Antes e depois da virada, mesmo recorte	Sem queda não explicada

Guarde esse comparativo. Ele é o que te permite cobrar o fornecedor novo enquanto a migração ainda está fresca, e é o registro das operações de tratamento que a LGPD pede.

Quando a resposta certa é não trocar ainda

Nem toda insatisfação com o sistema atual justifica migrar. Antes de decidir, compare duas contas.

De um lado, o custo total da transição: licenças em paralelo, horas da equipe, reconstrução das réguas, treinamento, queda de produtividade nas primeiras semanas e o risco de janela sem automação.

Do outro, a limitação real do sistema atual: ela impede alguma operação que você precisa fazer, ou é incômodo de interface que a equipe aprendeu a contornar?

Troque quando houver trava estrutural: sem API, sem export, sem suporte, sem conformidade, ou um limite que impede o seu modelo de operação (multiunidade, especialidades, volume).

Não troque ainda quando o problema for processo, e não software. Sistema novo não conserta cadastro mal preenchido nem recepção sem roteiro. Ele só muda o lugar onde o problema aparece.

Lembre: a decisão de trocar é de negócio, não de TI. O que decide é custo total de transição contra trava estrutural, e quem paga a conta dos dois lados é a agenda.

Seu próximo passo

1. Faça o inventário da camada de automação esta semana. Liste cada régua com gatilho, canal, volume, impacto e dono. Você vai descobrir automação morta e vai saber exatamente o que precisa renascer do outro lado.
2. Leve as oito cláusulas de saída para a mesa antes de assinar. Export em formato aberto com anexos, prazo, custo, API, sandbox, devolução, eliminação e responsabilidade. E peça um export de teste antes da assinatura.
3. Escreva o plano de virada com data de corte, contingência manual e critério de rollback. Religue por onda, comece por confirmação de consulta e só avance quando a onda anterior passar no aceite.

Quer trocar de sistema sem abrir buraco na agenda, com a régua de captação e confirmação de pé do primeiro ao último dia da migração? Agende uma apresentação.