Migração de dados na troca de sistema de RH

Por que a migração de dados é responsabilidade do RH, não só de TI

A migração de dados de RH exige decisões que só o RH pode tomar: o que migrar, o que descartar, o que sanear e como tratar campos sem correspondência entre os sistemas. TI executa a transferência técnica — ETL (extração, transformação e carga) — mas o RH define as regras e valida os resultados.

A separação de responsabilidades em um projeto de migração segue a lógica:

• RH decide: escopo do que migrar, critérios de qualidade dos dados, o que descartar, como tratar inconsistências, aprovação da migração antes do go-live.
• TI executa: extração dos dados do sistema antigo, transformação para o formato do novo sistema, carga no ambiente de homologação e no ambiente produtivo.
• Fornecedor do novo sistema orienta: mapeamento de campos, requisitos técnicos do sistema de destino, suporte durante a execução.

Como referência de mercado consolidada em projetos de migração, o coração do processo é o mapeamento "de x para" — a correspondência explícita entre cada campo do sistema antigo e o campo equivalente no sistema novo.^[1] Sem esse mapeamento, a migração técnica pode ser executada com sucesso enquanto os dados chegam ao lugar errado.

As quatro fases da migração de dados em RH

A migração de dados bem conduzida segue quatro fases sequenciais. Pular uma fase ou executar fora de ordem aumenta o risco de problemas que só aparecem depois do go-live — quando o custo de correção é maior.

Fase 1 — Diagnóstico e inventário

O diagnóstico mapeia o que existe antes de qualquer decisão sobre o que migrar. O resultado é um inventário completo dos dados do sistema atual, classificados por tipo e por qualidade.

1. Catalogar todos os dados existentes por tipo: cadastrais (nome, CPF, cargo, departamento), folha (histórico de pagamentos, benefícios), ponto (histórico de horas), contratos ativos e encerrados, documentos digitalizados.
2. Classificar cada grupo de dados: limpos (prontos para migrar), incompletos (faltam campos obrigatórios), duplicados (o mesmo registro aparece mais de uma vez), desatualizados (informações que já não correspondem à realidade).
3. Identificar o que está fora do prazo de retenção legal — esses dados não devem ser migrados.

O diagnóstico revela a dimensão real do trabalho de saneamento necessário — e evita surpresas durante a execução.

Fase 2 — Saneamento dos dados

O saneamento é a fase mais trabalhosa e a mais negligenciada. Dados duplicados ou incompletos migrados perpetuam o problema no novo sistema — e reabrir o assunto depois do go-live custa mais tempo e mais risco operacional.^[2]

1. Corrigir campos incompletos: completar CPF faltante, endereço incompleto, data de admissão sem registro.
2. Padronizar formatos: datas no mesmo padrão, nomes sem abreviações inconsistentes, cargos com nomenclatura unificada.
3. Eliminar duplicatas: manter apenas o registro mais completo e recente para cada colaborador.
4. Marcar registros obsoletos para descarte: ex-colaboradores com prazo de retenção expirado, candidatos não contratados fora do prazo de guarda.

O saneamento é liderado pelo RH — TI pode apoiar com scripts de verificação, mas a decisão sobre o que está correto e o que descartar é editorial, não técnica.

Fase 3 — Mapeamento e execução

O mapeamento cria a tabela "de x para": para cada campo do sistema antigo, a correspondência exata no sistema novo. Campos sem correspondência precisam de tratamento definido antes da execução.

1. Documentar o mapeamento campo a campo, com validação do fornecedor do novo sistema sobre os campos obrigatórios e os formatos aceitos.
2. Definir o tratamento para campos sem correspondência: descartar, migrar para campo livre (observações), ou solicitar campo personalizado no novo sistema.
3. Definir a janela de corte: a data a partir da qual o novo sistema passa a ser o sistema de registro. Transações após o corte só entram no novo sistema.
4. Executar primeiro em ambiente de homologação — nunca diretamente em produção. A homologação é o teste antes do go-live real.
5. Após validação bem-sucedida na homologação, executar a migração em produção na janela definida.

Fase 4 — Validação pós-migração

A validação confirma que os dados chegaram corretamente — e que o que chegou corresponde ao que foi enviado. Não basta confirmar que a migração executou sem erros técnicos; é preciso confirmar que o conteúdo está correto.

1. Auditoria por amostragem: selecionar registros do sistema antigo e comparar com os equivalentes no novo sistema — verificar se os dados batem campo a campo.
2. Checklist de dados críticos: folha do último mês, benefícios ativos, contratos vigentes, dados de saúde e segurança, escalas de trabalho.
3. Procedimento para divergências: quando um dado não bate, há protocolo definido para corrigir sem quebrar outros registros? Quem aprova a correção?
4. Prazo de operação paralela: período em que os dois sistemas funcionam simultaneamente para garantir continuidade operacional enquanto a validação ainda está em andamento.

O que é a janela de corte e como funciona a operação paralela

A janela de corte é a data e o horário a partir do qual o novo sistema passa a ser o sistema de registro oficial. Transações antes do corte estão no sistema antigo; transações após o corte só entram no novo sistema.

A operação paralela é o período em que os dois sistemas funcionam simultaneamente — o antigo ainda acessível para consulta histórica e o novo já sendo alimentado com as novas transações. Esse período reduz o risco de perda de informação durante a transição.

Como referência de mercado, o período de operação paralela varia de 1 a 3 meses dependendo da complexidade da migração. O encerramento do sistema antigo deve ser gradual e ocorrer somente após a validação completa dos dados críticos no novo sistema.

O que não migrar — e por que isso também é decisão do RH

Nem tudo que está no sistema antigo deve ir para o novo. Migrar dados desnecessários aumenta o volume, dificulta a organização e pode criar problemas de conformidade com a LGPD.

Dados que não devem ser migrados:

• Registros de colaboradores desligados cujo prazo de retenção legal já expirou
• Dados de candidatos não contratados com prazo de guarda expirado
• Duplicatas e registros obsoletos identificados no diagnóstico
• Dados históricos de processos que o novo sistema não vai dar continuidade (ex: módulo que não vai ser usado no novo sistema)
• Documentos digitalizados em formato incompatível ou com qualidade insuficiente para uso no novo sistema

A decisão sobre o que descartar precisa ser documentada — tanto pelo aspecto de auditoria interna quanto pela conformidade com a política de retenção de dados da empresa.