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

O que precisa ser migrado — e o que não precisa

A distinção entre o que migrar e o que arquivar é o primeiro passo para um plano de migração bem dimensionado. Tentar migrar tudo para o novo sistema aumenta a complexidade sem necessariamente agregar valor operacional.

O que precisa ser migrado para o novo sistema (dados operacionais ativos):

• Cadastros de colaboradores ativos: dados pessoais (nome, CPF, data de nascimento, PIS), contratuais (cargo, salário, data de admissão, regime de jornada), bancários (banco, agência, conta para crédito) e dados de dependentes com elegibilidade a benefícios.
• Colaboradores inativos recentes: colaboradores desligados nos últimos 2 a 3 anos podem precisar ser migrados se houver reclamações trabalhistas pendentes, revisões de folha em curso ou obrigações de eSocial ainda não encerradas.
• Afastamentos em andamento: colaboradores em licença-maternidade, auxílio-doença ou outros afastamentos com data de retorno prevista — com tipo, data de início e informações do INSS quando aplicável.
• Férias programadas e em gozo: períodos de férias já concedidos que ainda serão pagos ou que estão em andamento.
• Adiantamentos e débitos em aberto: valores de adiantamento de salário ou 13º ainda não descontados; benefícios com coparticipação parcelada; empréstimos consignados em folha.
• Saldo de banco de horas: o saldo positivo ou negativo acumulado por cada colaborador, se o controle de banco de horas for gerenciado pelo sistema de folha.

O que não precisa ir para o novo sistema (mas precisa ser arquivado):

• Histórico de folhas já processadas — holerites, totalizadores, recibos de férias, rescisões concluídas. Esses dados ficam no sistema antigo em modo leitura ou são exportados em formato consultável (PDF, planilha, XML).
• Comprovantes de pagamento e guias já quitadas — arquivados pelo prazo legal.
• Histórico de eventos do eSocial transmitidos — os recibos ficam no portal do eSocial e não precisam ser migrados para o novo sistema.

Ponto de corte no eSocial: como funciona a transição entre sistemas

O ponto de corte é a competência a partir da qual o novo sistema passa a enviar os eventos ao eSocial — e o sistema antigo para de transmitir. Definir o ponto de corte corretamente é crítico: a Receita Federal não aceita que dois sistemas enviem eventos para a mesma competência do mesmo estabelecimento.

Como funciona a transição no eSocial:

1. Definição da competência de corte: a empresa define qual será a primeira competência processada no novo sistema. O padrão de mercado é que o novo sistema assuma a partir do mês M+1, com o sistema antigo processando até o mês M inclusive.
2. Encerramento dos eventos abertos no sistema antigo: antes da virada, todos os eventos em aberto no sistema antigo precisam ser fechados — afastamentos sem data de retorno, admissões transmitidas mas não concluídas, rescisões com eventos pendentes.
3. Migração dos recibos de período anterior: o novo sistema pode precisar registrar internamente as competências processadas pelo sistema antigo para calcular corretamente valores cumulativos (como o 13º e as férias proporcionais). Esse processo é feito na fase de carga de dados — não é transmissão ao governo, é configuração interna.^[3]
4. Primeiro envio no novo sistema: na competência M+1, o novo sistema transmite os eventos do eSocial pela primeira vez. O S-1200 (remuneração do período) e quaisquer eventos não periódicos (admissão, desligamento, afastamento) da competência devem ser enviados dentro dos prazos normais — o fato de ser o primeiro mês não isenta a empresa de multas por atraso.

O ponto de corte mais seguro é o início de um mês cheio, sem eventos complexos previstos — evitar mudar de sistema em meses com 13º, PLR, dissídio ou outros eventos que aumentam a complexidade.

Quando o fornecedor antigo não libera os dados

Um dos cenários mais desafiadores na troca de sistema é quando o fornecedor antigo — seja um software ou um escritório contábil — dificulta ou recusa a entrega dos dados no encerramento do contrato. Esse cenário é mais comum do que parece, especialmente em pequenas empresas.

O direito da empresa aos seus dados: os dados de folha de pagamento pertencem à empresa, não ao fornecedor do sistema. A LGPD garante o direito de portabilidade de dados — o titular (a empresa, no caso dos dados dos colaboradores) pode solicitar a entrega em formato interoperável. Na prática, a principal alavanca é verificar se o contrato com o fornecedor antigo tem cláusula de entrega dos dados ao encerrar. Se não houver, a negociação fica mais difícil mas a empresa ainda tem respaldo legal.

Alternativas quando o banco de dados não é liberado:

1. XMLs do eSocial como fonte alternativa: os XMLs transmitidos ao eSocial contêm dados de remuneração, admissão, desligamento e afastamento de todos os colaboradores. Esses arquivos são da empresa — o acesso ao portal do eSocial pode ser solicitado diretamente à Receita Federal, independentemente do fornecedor. Como referência de mercado, especialistas em migração de folha usam os XMLs do eSocial como fonte alternativa quando o banco de dados do sistema antigo não está disponível.^[1]
2. Relatórios básicos exportados: mesmo sem acesso ao banco de dados, a maioria dos sistemas permite exportar relatórios em planilha ou PDF — folhas por competência, fichas financeiras, demonstrativos de férias. Esse material pode ser suficiente para reconstruir o histórico necessário manualmente.
3. Extração direta do banco de dados: em casos extremos, com autorização jurídica, é possível contratar uma consultoria técnica especializada em migração de folha para extrair os dados diretamente do banco de dados do sistema antigo, sem depender da cooperação do fornecedor.^[2]

Retrocálculo de folha na migração: o que é e como tratar

Retrocálculo é o recálculo de uma competência já processada para corrigir um valor que estava errado — diferença de salário, benefício concedido retroativamente, enquadramento de convenção coletiva com efeito retroativo. Na migração de sistema, o retrocálculo cria um problema específico: a competência original foi processada no sistema antigo, e a correção precisa ser feita no sistema novo.

O desafio técnico: o retrocálculo que envolve competências processadas no sistema antigo pode gerar inconsistências no eSocial quando processado no novo sistema — porque os eventos originais foram transmitidos com os valores do sistema antigo, e a correção transmitida pelo novo sistema pode conflitar com o histórico registrado.^[4]

Como tratar o retrocálculo na migração:

• Antes da virada: sempre que possível, processar os retrocálculos pendentes no sistema antigo antes de migrar. É a solução mais simples e que evita conflitos no eSocial.
• Após a virada, para competências do sistema antigo: o retrocálculo precisa ser processado pelo novo sistema com os totais corretos, gerando os eventos de eSocial de diferença (S-1202 ou S-1210, conforme o tipo). O fornecedor do novo sistema precisa orientar o procedimento correto para esse cenário.
• Documentação: registrar formalmente todos os retrocálculos pendentes na data da virada — valores, competências e motivo — para que não sejam esquecidos e para ter evidência do histórico em caso de fiscalização.

Como validar que a migração foi feita corretamente

A validação da migração é uma etapa formal — não basta "confiar que o fornecedor fez certo". O time de DP precisa executar uma série de verificações antes de aceitar formalmente a migração.

O checklist de validação da migração:

1. Contagem de registros: o número de colaboradores cadastrados no novo sistema bate com o número exportado do sistema antigo? Para cada colaborador faltante, identificar o motivo.
2. Comparação de dados cadastrais: verificar uma amostra aleatória de colaboradores — salário base, cargo, data de admissão, dados bancários, dependentes. Erros nessa camada causam erros de cálculo e de pagamento.
3. Verificação de afastamentos: todos os colaboradores em afastamento no sistema antigo aparecem corretamente no novo? Com o tipo correto e a data de início correta?
4. Verificação de saldos: adiantamentos em aberto, banco de horas e férias programadas estão corretos nos valores e nas datas?
5. Simulação de cálculo: processar uma folha de teste com os dados migrados e comparar com o último mês processado no sistema antigo — as diferenças devem ser apenas as variações normais do período (faltas, variações de benefícios), não diferenças de salário base ou verbas fixas.

A validação precisa resultar em um documento formal — termo de aceite de migração — assinado pelo responsável de DP e pelo responsável técnico do projeto. Esse documento registra o que foi migrado, o que ficou no sistema antigo, as divergências encontradas e como foram tratadas.