Migração de dados entre sistemas de RH: riscos e boas práticas

Migração vs. Integração: entenda a diferença

Migração é movimento único: você pega dados do legacy, transforma, carrega no novo sistema, e pronto — legacy é desativado. Histórico fica no novo sistema. Se houver erro, você descobre meses depois quando precisa auditoria de 2023.

Integração é contínuo: dados fluem entre sistemas em tempo real ou períodico. Você tem sistema A e sistema B sincronizados. Se erro em A, você pode correção em B. Legacy continua rodando em paralelo (útil durante pilot de novo sistema).

Qual usar? Migração é necessária em go-live (você precisa carregar histórico). Integração é útil during pilot (você roda novo sistema em paralelo com legacy, sincroniza, e quando confiar, faz cutover). Muitas grandes implementações usam ambas: primeiro integração em paralelo, depois migração final ao cutover.

Fases de migração: do planejamento à validação

Fase 1: Planejamento (1–2 semanas). Reunir stakeholders, mapear dados no legacy, definir escopo (você migra tudo ou apenas alguns anos?), identificar gaps. Decisão: qual é o cutover date? Você migra histórico completo ou apenas saldo inicial? Critério: complexidade de transformação vs. valor de histórico. Exemplo: migrar 10 anos de avaliações de desempenho é complexo e tem pouco valor; migrar 2 anos de folha é crítico.

Fase 2: Assessment (2–3 semanas). Extrair amostra de dados do legacy, examinar qualidade. Quantos registros têm CPF inválido? Quantos salários estão zero? Quantas datas estão no formato errado? Assessment revela tamanho do problema. Ruim aqui significa limpeza pesada à frente.

Fase 3: Cleansing (2–4 semanas). Corrigir dados ruins no legacy antes de migrar. Preencher campos vazios, normalizar formatos, corrigir erros óbvios (salário negativo, data de nascimento no futuro). Quem faz? Geralmente tim de RH + data analyst. Ferramenta: Excel, SQL, ou especialista em data quality. Custo é invisível mas real — tempo do RH em limpeza em vez de outras prioridades.

Fase 4: Mapeamento (1–2 semanas). Definir correspondência campo-a-campo entre legacy e novo sistema. Legacy tem "departamento", novo tem "centro de custo + unidade de negócio". Legacy tem "categoria de renda", novo tem "faixa salarial". Mapeamento é lógica que transforma origem em destino. Documentar em matriz de mapeamento.

Fase 5: Transformação (2–4 semanas). Escrever script/ETL que implementa mapeamento. Script extrai dados do legacy, aplica transformações (conversão de formato, cálculos, lookups), e prepara output para carga. Testo script em dados históricos para validar resultado. Iterar até que transformação está correta.

Fase 6: Carga (1–2 dias). Executar script em dados reais, carregar no novo sistema. Primeiro load é paralelo (ninguém usando novo sistema ainda). Validar que carregar funcionou (não há erros de constraint, foreign keys estão corretos). Se problema, rollback (volta à última cópia boa) e reexecuta com correções.

Fase 7: Validação (2–4 semanas). Verificar que dados migraram corretamente. Testes incluem: amostragem (pegar 100 registros ao acaso, comparar legacy vs. novo), agregação (total de colaboradores, folha agregada), e spot checks (procurar erros óbvios). Relatório de validação documenta: quantos registros foram carregados, quantos erros foram encontrados, quais foram corrigidos. Assinatura de business owner: "Sim, dados estão corretos, podemos ir para production".

Riscos principais: o que pode dar errado

Perda de dados. Arquivo corrompe durante export, campo não foi mapeado, dados são sobrescrevidos. Prevenção: backup em triplo (original, cópia antes de cleansing, cópia antes de migração).

Inconsistência de dados. Colaborador tem dois registros com salários diferentes. Departamento não existe no novo sistema. Data de demissão é anterior a data de admissão. Prevenção: limpeza rigorosa, validação de regras de negócio antes de carga.

Corrupção de dados. Caracteres especiais não são encodados corretamente, números são truncados. Prevenção: testo script com dados reais (com acentos, caracteres especiais).

Incompletude de dados. Histórico de colaboradores está incompleto. Campos críticos estão vazios. Prevenção: assessment rigoroso em fase 2, decisão clara sobre o que migrar.

Mudança de scope durante migração. "Ah, agora queremos migrar dados de avaliação 360 feedback também". Scope cresce, complexidade aumenta. Prevenção: congelar escopo antes de iniciar transformação.

Boas práticas que mitigam riscos

1. Backup em triplo. Backup do legacy antes de cleansing, cópia da origem, cópia antes de migração. Se algo der errado, você volta rapidamente.

2. Cleansing rigoroso. Investir tempo em limpeza de dados upfront economiza tempo e risco na transformação. "Lixo entra, lixo sai" — se dados legacy estão ruins, o novo sistema também estará.

3. Validação em amostra antes de produção. Transformação de 100 registros primeiro, valida resultado, depois roda com 10000. Problema descoberto em 100 é fácil de corrigir.

4. Testes de integridade de dados. Checklist de validação: total de registros, soma de folha agregada, datas válidas, relacionamentos íntegros. Automatizar validação em vez de conferir manualmente.

5. Documentação de mapeamento e transformação. Matriz explicando cada campo legacy ? novo. Se surge dúvida pós-migração, documentação tem resposta. Também ajuda auditoria.

6. Sign-off de negócio antes de go-live. Business owner (CFO para folha, CHRO para RH) assina: "Validei dados, estão corretos, autorizo go-live". Sem isso, você tem surpresa no mês 2 e alguém culpa TI.

7. Rollback plan documentado. Se descobrir problema pós-go-live, qual é o plano B? Você volta ao legacy? Em quanto tempo? Quem aprova? Ter plano antes de precisar.

Diferença entre migração e integração em RH

Migração é movimento único (cutover). Integração é sincronização contínua. Em implementação de HCM típica, você faz ambas: durante ramp-up, novo sistema roda em paralelo com legacy (integração, sincronização). Quando confiante, você cutover (migração final). Legacy é desligado. Novo sistema é fonte de verdade daqui em diante.

Benefício de paralelo: você reduz risco. Se novo sistema tem problema, você volta para legacy rapidamente. Custo: você roda dois sistemas simultaneamente (caro em TI, confuso em RH — "em qual sistema faço a mudança?").

Integração during paralelo típicamente é unidirecional: legacy ? novo (sincroniza dados do legacy ao novo para teste). Bidirectional (mudanças em novo volta ao legacy) é raro porque causa complicações de conformidade (qual é source of truth para folha?).