Como Migrar de ATS sem Perder Candidatos

Migrar de ATS sem perder candidatos exige três coisas na ordem certa: exportar tudo enquanto o contrato antigo ainda está ativo, mapear campo por campo para saber o que não tem equivalente no sistema novo e validar contagens fechadas antes de desligar a plataforma anterior. A maior parte da perda de dados numa migração de ATS não acontece durante a importação. Acontece semanas depois, quando alguém tenta abrir o histórico de um candidato e descobre que o anexo, o comentário do gestor ou a nota da entrevista final simplesmente não vieram junto.

Este artigo cobre o que costuma dar errado numa migração de ATS: o que nunca migra limpo entre dois sistemas, por que exportar antes de cancelar não é opcional, o que a LGPD exige quando milhares de currículos mudam de plataforma, e um checklist de contagens para fechar antes do corte. A AjustaCV não é um ATS e não vende esse tipo de sistema para empresas. Ela analisa currículos e descrições de vaga do lado do candidato, contra os mesmos parsers que sistemas como o Gupy usam para filtrar candidaturas, o que ajuda a entender como o lado de quem se candidata é afetado quando o sistema de recrutamento muda por baixo dos panos.

O que nunca migra limpo entre dois ATS?

Cinco tipos de dado raramente sobrevivem intactos a uma migração de ATS: anexos além do currículo principal, histórico de e-mails trocados dentro da plataforma, comentários internos de recrutadores, notas de entrevista e o vínculo entre um candidato e a vaga específica em que ele estava. Nenhum desses itens é exótico. São justamente os que um gestor de contratação vai procurar seis meses depois, quando reabrir uma posição parecida.

Migração de ATS: processo de mover a base de candidatos, vagas e histórico de recrutamento de uma plataforma para outra, geralmente motivado pela troca de fornecedor ao final de um contrato.

Anexos secundários como portfólio, certificado ou teste técnico costumam ficar amarrados a um ID interno do sistema antigo que a API de exportação não expõe da mesma forma que expõe o currículo principal. Histórico de e-mail trocado dentro do próprio ATS raramente é tratado como campo de dado: é uma funcionalidade de caixa de entrada embutida, não algo pensado para ser exportado em lote. Comentários internos de recrutador ficam de fora com frequência porque o modelo de permissão do sistema antigo trata esse texto como observação privada, não como parte do registro do candidato.

Notas de entrevista sofrem o mesmo problema, multiplicado pelo número de entrevistadores que preencheram scorecards diferentes ao longo dos anos. E o vínculo entre candidato e vaga quebra quando a vaga antiga já foi encerrada e o sistema novo não tem onde recriá-la, deixando o candidato órfão de contexto, como se tivesse aparecido do nada na base nova.

Antes de confiar na exportação completa, rode um teste com uma amostra pequena e deliberada: escolha vinte candidatos finalistas do último ano, de vagas diferentes, e confira manualmente se cada anexo, comentário e nota sobreviveu ao ciclo de exportação e importação. Se a amostra falhar, o lote inteiro provavelmente também vai falhar, só que em uma escala que ninguém vai auditar a tempo.

Por que você precisa exportar antes de cancelar, não depois?

Você precisa exportar antes de cancelar porque o acesso à plataforma antiga normalmente termina no segundo em que o contrato termina, não quando alguém do time lembra de puxar os dados. Fornecedores de ATS não têm obrigação padrão de manter uma janela de acesso pós-cancelamento, a menos que isso esteja escrito no contrato original ou seja negociado explicitamente antes da rescisão.

Fornecedores brasileiros de ATS, como o Gupy, publicam informações sobre como tratam dados de candidatos sob a LGPD em seus próprios portais de privacidade, segundo o Portal de Privacidade da Gupy. Mas a forma exata de exportar a base completa de candidaturas antigas, com anexos e histórico, varia por contrato comercial e precisa ser negociada com o time de conta, não presumida a partir da política de privacidade voltada ao candidato final.

Na prática, isso significa colocar duas cláusulas por escrito antes de assinar o cancelamento: um prazo mínimo de acesso somente leitura após o fim do contrato, de trinta a sessenta dias, e o formato exato em que os dados serão entregues (CSV, JSON, ou exportação direta via API). Sem isso registrado, a empresa depende da cortesia do fornecedor que está prestes a perder o cliente, e cortesia não é uma estratégia de continuidade de dados.

Migração de dados de candidatos é uma operação de tratamento sob a LGPD, não só um projeto de TI

Migrar dados de candidatos de um ATS para outro é uma operação de tratamento de dados pessoais como qualquer outra sob a LGPD, o que significa que a política de retenção viaja junto com o dado, e um candidato que já pediu exclusão não pode ser trazido de volta pela importação. Trocar de sistema não reinicia o relógio da finalidade do tratamento.

O Art. 16 da Lei 13.709/2018, texto oficial disponível no portal do Planalto, determina que dados pessoais sejam eliminados após o término do tratamento, com exceções específicas para obrigação legal, pesquisa, transferência a terceiros dentro das regras da lei, ou uso exclusivo do controlador com dados anonimizados. Migração para um novo fornecedor não está nessa lista de exceções por si só.

LGPD Art. 16 (Lei 13.709/2018): determina a eliminação de dados pessoais após o fim do tratamento, dentro do âmbito e dos limites técnicos das atividades, salvo hipóteses específicas de conservação previstas em lei.

O Art. 18 da mesma lei garante ao titular o direito de solicitar a eliminação de dados pessoais tratados com consentimento, a qualquer momento. Se um candidato já exerceu esse direito no sistema antigo, o registro da solicitação precisa ser cruzado contra o arquivo de exportação antes da importação, e o ID desse candidato precisa ficar de fora do lote novo. O inciso V do mesmo artigo prevê ainda o direito à portabilidade de dados a outro fornecedor, mas essa portabilidade ainda depende de regulamentação específica da Autoridade Nacional de Proteção de Dados para produzir efeito prático, segundo a análise do LGPD Brasil. Na prática, isso quer dizer que não existe hoje um mecanismo padronizado e obrigatório de transferência de dados entre ATS: a responsabilidade de fazer a exportação corretamente é inteira da empresa que está migrando.

Vale também revisitar retenção durante a migração, não só depois dela. A regra da LGPD para dados de candidato reprovado é funcional, não um prazo fixo em dias: o tratamento deve terminar quando a finalidade for atingida, segundo a análise da Quickin. Migrar é o momento natural para aplicar essa regra, retirando do lote quem já deveria ter sido eliminado antes mesmo de a migração começar. Para o tratamento completo dessa obrigação, veja ATS e LGPD: como tratar dados de candidatos.

Como mapear campo por campo entre o ATS antigo e o novo?

O mapeamento de campos define o que sobrevive à migração antes mesmo de qualquer arquivo ser exportado. Fazer isso depois da exportação, tentando encaixar os dados no sistema novo por tentativa e erro, é o motivo mais comum de perda silenciosa.

A regra geral quando não existe campo equivalente é simples de enunciar e fácil de esquecer sob pressão de prazo: nunca descartar o dado por falta de lugar para colocá-lo. Guarde em um campo de observações genérico ou em um arquivo externo referenciado pelo ID do candidato, mesmo que o sistema novo não saiba usar essa informação automaticamente. Um dado arquivado e pouco acessível é recuperável. Um dado descartado não é.

O que é o Checklist das 6 Contagens e como aplicar antes do corte?

O Checklist das 6 Contagens é um conjunto de seis números que precisam bater entre o sistema antigo e o sistema novo antes de qualquer decisão de desligar a plataforma anterior. A lógica é simples: uma migração não falha de forma visível, ela falha em silêncio, e a única forma de detectar isso a tempo é comparar contagens fechadas, não amostras aleatórias.

1. Candidatos ativos totais: o número de perfis com candidatura em andamento no sistema antigo precisa corresponder ao número importado no sistema novo, sem margem de diferença não explicada.
2. Vagas abertas totais: cada vaga em aberto no momento do corte precisa existir no sistema novo com o mesmo conjunto de candidatos vinculados.
3. Anexos por candidato: uma amostra de candidatos com múltiplos anexos deve mostrar o mesmo número de arquivos nos dois sistemas, não só o currículo principal.
4. Comentários internos: o volume de comentários por candidato em uma amostra recente deve refletir o que existia no sistema antigo, ainda que reformatado.
5. Solicitações de exclusão pendentes: todo pedido de exclusão LGPD registrado e ainda não processado precisa aparecer como excluído do lote de importação, não como candidato ativo no sistema novo.
6. Candidaturas em etapa final: quem está em entrevista final ou com oferta em andamento no momento do corte exige checagem individual, porque é o grupo onde um erro de migração custa mais caro.

Qualquer divergência entre as duas colunas precisa de explicação registrada, nunca de um “deve ser arredondamento” informal. Se dez candidatos sumiram entre a contagem antiga e a nova, alguém precisa nomear exatamente quais dez são e por quê.

Como rodar a semana do corte sem confundir quem já está no processo?

A semana do corte exige rodar os dois sistemas em paralelo por um período curto e bem definido, em vez de migrar tudo de uma vez e torcer para que funcione. Isso evita o cenário mais comum de confusão: um candidato recebendo dois e-mails de dois sistemas diferentes no mesmo dia, ou um link de entrevista que aponta para uma plataforma que já foi desligada.

Três práticas reduzem esse risco de forma concreta. Primeiro, mantenha o sistema antigo em modo somente leitura durante a transição, sem receber novas candidaturas, mas ainda acessível para consulta. Segundo, direcione candidaturas novas para o sistema novo a partir de uma data definida, mas deixe quem já está no meio de um processo terminar no sistema onde começou, sem transferir pipelines ativos no meio de uma etapa de entrevista. Terceiro, nomeie uma única pessoa responsável por resolver divergências durante a semana do corte, para que perguntas não fiquem circulando entre RH, TI e o fornecedor sem dono definido.

Para quem está montando o sistema novo do zero e não só migrando de um antigo, vale revisar como configurar um ATS do zero, porque decisões como etapas do funil e motivos de reprovação precisam existir antes da primeira importação, exatamente como precisam existir antes da primeira vaga publicada.

O que fica quando a migração termina

A migração de ATS bem-sucedida não é medida por quantos registros entraram no sistema novo, é medida por quantos ainda respondem corretamente a uma pergunta feita meses depois: quem foi esse candidato, em qual vaga, com quais anexos, e por que a decisão final foi aquela. Pular a exportação antecipada, o mapeamento campo a campo ou a validação por contagens não economiza tempo, só transfere o custo para o dia em que alguém precisar dessa resposta e ela não existir mais.

Comece negociando o acesso de exportação antes de assinar qualquer cancelamento, e trate a limpeza de dados por LGPD como parte da migração, não como uma etapa separada para depois. Para aprofundar a parte legal, veja ATS e LGPD: como tratar dados de candidatos. E se a preocupação do seu time também passa pelo lado de quem se candidata, entender como o parser do sistema novo vai ler um currículo é o primeiro teste prático: a análise gratuita de ATS da AjustaCV mostra isso do ponto de vista de quem envia a candidatura, o mesmo lado que sua migração está tentando não perder pelo caminho.

Perguntas frequentes