Uma empresa decidiu trocar seu sistema de Folha de Pagamento.

O novo ambiente está sendo configurado, a implantação começou e surge uma das primeiras questões práticas do projeto:

Como retirar os dados do sistema atual para levá-los ao novo sistema?

A resposta depende da plataforma, da arquitetura disponível, do tipo de acesso, do período histórico necessário e do escopo da migração.

Em alguns sistemas, a melhor alternativa pode ser um backup do banco de dados.

Em outros, os dados podem ser obtidos por recursos da própria aplicação, arquivos nativos, planilhas, APIs ou relatórios.

Existem ainda ambientes em nuvem nos quais o cliente não possui acesso direto ao banco, exigindo outra estratégia.

Por isso, exportar dados para uma migração não significa simplesmente procurar um botão “Exportar”.

Antes de gerar qualquer arquivo, é necessário saber quais informações precisam sair, onde elas estão, como estão estruturadas e como serão utilizadas no novo sistema.

Quais dados devem ser exportados de um sistema de Folha de Pagamento?

O primeiro passo é definir o escopo da migração.

Nem todo projeto precisa transportar exatamente as mesmas informações.

Uma migração pode contemplar, por exemplo:

• empresas e filiais;

• colaboradores ativos;

• colaboradores desligados;

• dependentes;

• cargos e funções;

• departamentos;

• centros de custo;

• sindicatos;

• horários e jornadas;

• históricos salariais;

• históricos de cargos;

• históricos contratuais;

• afastamentos;

• férias;

• benefícios;

• eventos e rubricas;

• ficha financeira;

• informações de Saúde e Segurança do Trabalho;

• outras informações de RH e Departamento Pessoal.

O escopo precisa ser definido antes da extração.

Caso contrário, existe o risco de descobrir durante a implantação que uma informação necessária não foi exportada.

Guia Definitivo da Migração de Dados de RH e Folha de Pagamento

Existe uma exportação padrão para sistemas de Folha de Pagamento?

Não.

Cada plataforma possui sua própria arquitetura.

Alguns sistemas possuem ferramentas específicas de exportação.

Outros permitem gerar planilhas ou arquivos.

Existem plataformas que disponibilizam APIs.

Em determinados ambientes, a melhor fonte pode ser o próprio banco de dados.

Também existem sistemas nos quais diferentes informações precisam ser obtidas de fontes diferentes.

Por isso, duas empresas que estão implantando exatamente o mesmo sistema de destino podem precisar de estratégias completamente diferentes para retirar os dados de seus sistemas atuais.

A arquitetura da origem determina como os dados podem ser obtidos.

A estrutura do destino determina como essas informações precisarão ser convertidas posteriormente.

Conversão de Dados de Folha de Pagamento

Quais são as formas de extrair dados de um sistema de Folha?

Existem diversas possibilidades.

Entre elas:

• acesso direto ao banco de dados;

• backup do banco;

• acesso remoto ao ambiente;

• APIs;

• arquivos nativos;

• ferramentas de exportação;

• planilhas;

• relatórios;

• XMLs do eSocial;

• PDFs e documentos estruturados;

• combinação de diferentes fontes.

A Audpay utiliza diferentes estratégias de extração conforme a arquitetura encontrada no projeto.

8 formas de extrair dados de sistemas legados

O ponto importante é entender que não existe um único método de extração capaz de atender todos os sistemas e todos os projetos.

Exportação e extração de dados são a mesma coisa?

Os termos são próximos, mas existe uma diferença útil.

Podemos chamar de exportação quando o próprio sistema disponibiliza algum mecanismo para gerar os dados.

Por exemplo:

Sistema → arquivo CSV

Sistema → planilha Excel

Sistema → arquivo TXT

Já a extração é um conceito mais amplo.

Ela pode envolver obter informações mesmo quando não existe uma exportação pronta.

Por exemplo:

Banco de dados → estrutura intermediária

API → banco intermediário

Arquivos nativos → banco estruturado

XML → estrutura relacional

Relatório → dados estruturados

Portanto, quando o sistema não possui uma exportação adequada, isso não significa necessariamente que os dados não possam ser migrados.

Pode ser necessário utilizar outra estratégia de extração.

Como exportar os dados dos colaboradores?

O cadastro do colaborador normalmente é um dos primeiros conjuntos de informações necessários em uma migração.

Dependendo do sistema, podem existir informações como:

• matrícula;

• CPF;

• nome;

• data de nascimento;

• data de admissão;

• situação;

• categoria;

• cargo;

• salário;

• departamento;

• centro de custo;

• sindicato;

• horário;

• dados bancários;

• endereço;

• contatos;

• documentos.

Um erro comum é exportar apenas a situação atual do colaborador.

Isso pode ser suficiente para determinados projetos.

Mas quando o objetivo é preservar históricos, o cadastro atual representa apenas uma parte da informação.

Como exportar os históricos dos colaboradores?

Imagine um trabalhador admitido há dez anos.

Hoje ele possui determinado salário, cargo e departamento.

Durante esses dez anos, porém, pode ter passado por:

• diversos salários;

• diferentes cargos;

• transferências;

• alterações de jornada;

• mudanças de sindicato;

• afastamentos;

• férias;

• outras alterações contratuais.

Se a exportação trouxer apenas os dados atuais, toda essa trajetória pode ficar de fora da migração.

Por isso, quando o escopo contempla histórico, é necessário identificar onde cada histórico está armazenado no sistema de origem.

Esse é um dos motivos pelos quais uma exportação cadastral simples nem sempre é suficiente para uma migração completa.

Como exportar a ficha financeira da Folha?

A ficha financeira costuma ser uma das estruturas mais relevantes de uma migração.

Ela pode envolver anos de:

• competências;

• eventos;

• referências;

• bases;

• proventos;

• descontos;

• valores;

• informações relacionadas ao processamento da Folha.

Não basta necessariamente exportar um relatório visual.

Para uma migração estruturada, normalmente é necessário conseguir relacionar cada informação a elementos como:

empresa + trabalhador + competência + evento + valor.

Dependendo do destino e do escopo, outros campos também podem ser necessários.

A ficha financeira apresenta outro desafio: os códigos dos eventos podem mudar entre os sistemas.

Por isso, depois da extração pode ser necessário realizar conversões e DE/PARAs.

Link Ficha Financeira na Migração de Folha de Pagamento

É melhor exportar por planilha ou acessar o banco de dados?

Depende do projeto.

Planilhas podem funcionar muito bem quando:

• o volume é administrável;

• o sistema gera informações completas;

• os históricos necessários estão disponíveis;

• a estrutura é consistente;

• existe uma quantidade administrável de layouts;

• o processo consegue ser validado.

O problema surge quando a equipe precisa preparar manualmente dezenas de arquivos, corrigir rejeições, refazer layouts e repetir o processo diversas vezes.

Nesses casos, aquilo que parecia ser a alternativa mais simples pode se transformar em meses de trabalho.

Implantação por Importação

Já o acesso ao banco pode permitir extrações mais amplas e automatizadas, mas exige conhecimento da estrutura existente.

Não existe, portanto, uma resposta universal.

A melhor fonte é aquela que consegue entregar os dados necessários com qualidade, rastreabilidade e esforço compatível com o projeto.

Tenho acesso ao banco de dados. Isso resolve a migração?

Não necessariamente.

Ter o banco é muito importante, mas o banco não explica sozinho o significado de cada informação.

Podem existir:

• centenas ou milhares de tabelas;

• campos sem documentação;

• códigos internos;

• relacionamentos complexos;

• estruturas técnicas;

• históricos distribuídos em diferentes tabelas.

Encontrar um campo que aparentemente representa um salário, por exemplo, não significa automaticamente que aquela estrutura contenha todo o histórico salarial necessário para a migração.

É necessário compreender o modelo.

Por isso, em muitos sistemas é necessária uma combinação de conhecimento de banco de dados + conhecimento funcional de Folha de Pagamento.

Portfólio Técnico de Migração de Dados

E quando o banco de dados não possui documentação?

Esse cenário pode acontecer principalmente em ambientes legados ou estruturas pouco documentadas.

Nesses casos, pode ser necessário realizar engenharia reversa.

O processo pode envolver:

• análise das tabelas;

• análise dos relacionamentos;

• identificação de chaves;

• comparação com relatórios;

• análise do conteúdo armazenado;

• cruzamento entre diferentes fontes;

• conhecimento funcional das informações de Folha.

A pergunta deixa de ser apenas:

“Onde está o campo?”

E passa a ser:

“O que esse dado representa e como ele se relaciona com os demais?”

É possível migrar sem acesso ao banco do sistema antigo?

Sim, em determinados cenários.

Banco de dados é apenas uma das fontes possíveis.

Uma migração pode utilizar:

• arquivos gerados pelo sistema;

• planilhas;

• APIs;

• relatórios;

• XMLs do eSocial;

• arquivos nativos;

• documentos;

• outras fontes estruturadas.

A viabilidade depende principalmente de quais dados precisam ser migrados e quais informações estão disponíveis nas fontes acessíveis.

8 formas de extrair dados de sistemas legados

É possível recuperar dados pelo eSocial?

Sim, determinados dados podem ser recuperados a partir dos eventos do eSocial.

Dependendo do período e dos eventos disponíveis, podem existir informações relacionadas a:

• vínculos;

• admissões;

• alterações cadastrais;

• alterações contratuais;

• remunerações;

• afastamentos;

• desligamentos;

• trabalhadores sem vínculo;

• outras informações transmitidas ao ambiente nacional.

Esses dados podem ser extraídos, tratados e transformados em uma estrutura utilizável em determinados projetos de migração.

Base Estruturada do eSocial

Entretanto, o eSocial não deve ser confundido com uma cópia completa do sistema de Folha.

Existem informações internas de RH e Folha que não fazem parte das informações transmitidas ao eSocial.

Por isso, dependendo do projeto, ele pode ser:

a fonte principal;

uma fonte complementar;

ou uma fonte de validação.

É possível usar mais de uma fonte na mesma migração?

Sim.

E em determinados projetos essa pode ser a melhor estratégia.

Por exemplo:

Banco de dados
→ dados cadastrais e históricos.

eSocial
→ complemento ou conferência de informações trabalhistas.

Relatórios
→ evidências para validação.

Planilhas do cliente
→ DE/PARAs e informações complementares.

Essa abordagem utiliza uma estratégia híbrida de extração.

Motor Híbrido de Migração de Dados

O objetivo não é escolher uma tecnologia por preferência.

É encontrar a combinação de fontes que ofereça a melhor cobertura para o escopo necessário.

Como exportar dados do Senior, LG, TOTVS, ADP e outros sistemas de Folha?

A estratégia de extração muda de acordo com o sistema de origem, sua arquitetura, versão, ambiente e tipo de acesso disponível.

A Audpay trabalha com diferentes sistemas e arquiteturas de Folha de Pagamento e RH.

Na prática, os caminhos para obtenção dos dados podem ser bastante diferentes.

A seguir estão alguns exemplos encontrados em projetos de migração.

Como extrair dados do Senior?

No Senior, existem diferentes possibilidades de extração, dependendo da arquitetura e dos acessos disponíveis no projeto.

Uma das alternativas é trabalhar com um backup tradicional do banco de dados. Dependendo do ambiente utilizado pelo cliente, podem ser encontradas tecnologias como SQL Server, PostgreSQL ou Oracle.

Outra possibilidade é utilizar o CBDS – Central de Banco de Dados Senior.

Com acesso adequado ao ambiente, o CBDS permite trabalhar com as estruturas da base por meio da própria aplicação, criando uma alternativa quando o backup não está diretamente disponível para a equipe responsável pela migração.

Uma terceira possibilidade é utilizar recursos disponíveis no próprio sistema para consultar e exportar informações, incluindo telas, consultas ou funcionalidades de exportação.

Assim, de forma simplificada, podemos ter:

Senior → backup do banco → extração

Senior → CBDS → extração

Senior → aplicação/exportadores → extração

Isso significa que a ausência de um backup em mãos não necessariamente impede a extração dos dados.

O primeiro passo é identificar qual ambiente está disponível e qual fonte oferece as informações necessárias ao escopo da migração.

Motor Híbrido

Como extrair dados da ADP?

Em projetos envolvendo ADP, o cenário pode ser diferente de uma migração baseada em backup tradicional.

Uma das formas encontradas é o recebimento de arquivos TXT contendo tabelas ou conjuntos de dados exportados da plataforma.

Entretanto, receber os arquivos não significa que os dados estejam prontos para serem importados pelo novo sistema.

É necessário interpretar suas estruturas e relacionamentos.

A Audpay pode realizar engenharia reversa sobre essas informações e transformar os arquivos recebidos em uma base de dados estruturada.

A partir dessa base intermediária, os dados podem ser conectados aos motores utilizados para extração, transformação e conversão.

De forma simplificada:

ADP → arquivos TXT → engenharia reversa → banco estruturado → conversão → sistema de destino.

Esse é um exemplo de como arquivos originalmente utilizados por uma aplicação podem ser transformados em uma estrutura controlada para uma migração.

Conversão de Dados de Folha de Pagamento

Como extrair dados do TOTVS Protheus?

No TOTVS Protheus, uma das possibilidades encontradas em projetos é trabalhar a partir do backup da base de dados.

A base é restaurada em um ambiente adequado e as estruturas relacionadas ao escopo da Folha de Pagamento são analisadas.

A partir disso, podem ser identificados:

• colaboradores;

• dependentes;

• estruturas organizacionais;

• históricos;

• férias;

• afastamentos;

• informações financeiras;

• demais dados contemplados pelo projeto.

As informações são extraídas e posteriormente convertidas conforme as estruturas exigidas pelo sistema de destino.

Por isso, receber o backup é apenas o começo.

É necessário compreender como os dados estão relacionados dentro do Protheus e como precisam chegar à nova plataforma.

Motor Backup

Como extrair dados do TOTVS RM?

No TOTVS RM, também é comum encontrar projetos baseados em backup do banco de dados, frequentemente em ambientes SQL Server.

Dependendo do ambiente e dos recursos disponíveis, também podem existir possibilidades de obtenção de informações por meio da própria aplicação.

Depois da extração, os dados precisam ser interpretados e transformados conforme a estrutura exigida pelo sistema de destino.

Esse processo ganha importância principalmente quando a migração contempla:

• históricos;

• férias;

• afastamentos;

• alterações contratuais;

• estruturas organizacionais;

• ficha financeira.

Como extrair dados do TOTVS Datasul?

O TOTVS Datasul apresenta características diferentes das arquiteturas tradicionais baseadas em SQL Server ou PostgreSQL.

Existem ambientes desenvolvidos sobre tecnologia Progress, o que pode exigir outra estratégia de acesso aos dados.

Em determinados projetos, a Audpay realiza conexão remota com o ambiente e utiliza recursos disponíveis na própria arquitetura para consultar e extrair as informações necessárias.

Os dados são então transportados para uma estrutura intermediária e conectados ao processo de transformação utilizado na migração.

O fluxo pode ser representado de forma simplificada:

TOTVS Datasul → acesso remoto → extração → banco intermediário → conversão → destino.

Esse é mais um exemplo de cenário em que não receber um backup tradicional não significa necessariamente que os dados não possam ser extraídos.

Motor Acesso Remoto

Como extrair dados do LG Nuvem?

Ambientes em nuvem exigem uma estratégia diferente de sistemas instalados na infraestrutura do próprio cliente.

No LG Nuvem, por exemplo, o acesso direto ao backup do banco não ocorre da mesma forma que em uma instalação local.

Uma alternativa é realizar as extrações utilizando recursos disponíveis na própria aplicação, gerando planilhas Excel com os dados necessários ao projeto.

Entretanto, a migração não precisa continuar sendo conduzida como um conjunto de planilhas independentes.

A Audpay pode transformar esses arquivos em uma base de dados estruturada.

A partir dela podem ser aplicados:

• tratamentos;

• relacionamentos;

• saneamentos;

• DE/PARAs;

• regras de conversão;

• validações.

De forma simplificada:

LG Nuvem → planilhas Excel → banco estruturado → conversão → sistema de destino.

Depois que os dados são estruturados, eles podem ser preparados para diferentes plataformas de destino.

Motor Planilhas

Como extrair dados do SCI Practice?

O SCI Practice apresenta outra arquitetura.

Nesse cenário, diferentes informações podem estar armazenadas em arquivos nativos DBF.

Cada arquivo pode representar determinada estrutura utilizada pela aplicação.

Em vez de trabalhar manualmente com cada arquivo durante toda a migração, esses dados podem ser convertidos e levados para uma base estruturada.

O processo pode seguir o fluxo:

SCI Practice → arquivos DBF → conversão → banco estruturado → transformação → sistema de destino.

A transformação dos arquivos em banco permite criar relacionamentos e utilizar uma estrutura adequada aos motores de migração.

Nativos na Migração de Dados

Como extrair dados do SCI Único?

Na linha SCI Único, a arquitetura é diferente do SCI Practice.

Existem ambientes utilizando banco de dados Firebird.

Quando o backup está disponível, a base pode ser restaurada em um ambiente de migração.

A partir daí, as estruturas necessárias são identificadas e os dados podem ser extraídos.

De forma simplificada:

SCI Único → backup Firebird → restauração → extração → conversão → sistema de destino.

A diferença entre SCI Practice e SCI Único demonstra uma questão importante:

conhecer somente o fabricante do sistema não é suficiente para definir a estratégia de migração.

É necessário identificar o produto, arquitetura e ambiente efetivamente utilizados pelo cliente.

Como extrair dados do Alterdata?

Em ambientes Alterdata, existem cenários em que a extração pode partir de um backup de banco PostgreSQL.

A base pode ser restaurada em ambiente controlado para análise das estruturas necessárias.

Depois disso, os dados contemplados pelo escopo são extraídos e preparados para o processo de conversão.

O fluxo pode ser:

Alterdata → backup PostgreSQL → restauração → extração → conversão → destino.

Como extrair dados do Folhamatic?

No Folhamatic, também existem cenários em que o processo pode partir de um backup de banco PostgreSQL.

Depois da restauração da base, as estruturas necessárias podem ser analisadas para obtenção de cadastros, históricos e demais informações previstas no projeto.

Posteriormente, os dados seguem para tratamento e conversão conforme a plataforma de destino.

Migração via Backup de Banco de Dados

Como extrair dados do Questor?

No Questor, a arquitetura encontrada pode variar conforme o ambiente.

Entre as tecnologias que podem ser encontradas estão Firebird e PostgreSQL.

Quando o backup é disponibilizado, a base pode ser restaurada para identificação das estruturas necessárias ao projeto.

O processo segue então para extração, transformação e conversão.

Por isso, antes de definir a estratégia de uma migração Questor, é importante identificar qual arquitetura está sendo utilizada naquele ambiente específico.

Migração via Backup de Banco de Dados

Como extrair dados do Domínio?

No Domínio, existem ambientes que utilizam SQL Anywhere.

Quando o backup é disponibilizado, a base pode ser restaurada e utilizada como fonte para a extração dos dados necessários à migração.

A partir dela, informações cadastrais, históricas e financeiras podem ser estruturadas conforme o escopo contratado.

O fluxo pode seguir:

Domínio → backup → restauração → extração → estruturação → conversão → destino.

Migração via Backup de Banco de Dados

Cada sistema exige uma estratégia diferente de extração?

Sim, mas isso não significa que cada projeto precise começar do zero.

Os exemplos anteriores mostram diferentes possibilidades:

Senior
→ backup, CBDS ou recursos da própria aplicação.

ADP
→ arquivos exportados, engenharia reversa e estruturação em banco.

TOTVS Protheus e RM
→ frequentemente backup de banco, além de outras possibilidades conforme o ambiente.

TOTVS Datasul
→ ambientes Progress e estratégias específicas de conexão e extração.

LG Nuvem
→ exportações pela aplicação e transformação das planilhas em banco estruturado.

SCI Practice
→ arquivos nativos DBF.

SCI Único
→ ambientes com Firebird.

Alterdata e Folhamatic
→ cenários com PostgreSQL.

Questor
→ diferentes arquiteturas, incluindo Firebird e PostgreSQL.

Domínio
→ cenários utilizando SQL Anywhere.

É justamente essa diversidade que torna importante conhecer não apenas Folha de Pagamento, mas também arquiteturas de dados.

Link Sistemas

Tecnologias e Motores de Migração de Dados

Preciso exportar tudo do sistema antigo?

Não necessariamente.

Migrar mais dados não significa automaticamente realizar uma migração melhor.

Dados desnecessários aumentam:

• volume;

• complexidade;

• tempo de transformação;

• necessidade de DE/PARAs;

• esforço de homologação.

O ideal é definir aquilo que realmente precisa estar disponível no novo ambiente.

Existem projetos que migram apenas trabalhadores ativos.

Outros preservam desligados.

Alguns transportam anos de ficha financeira.

Outros mantêm determinados históricos no legado ou em uma base de consulta.

A decisão precisa considerar o objetivo da implantação, as necessidades do cliente e o escopo definido para a migração.

É preciso limpar os dados antes de exportá-los?

Não necessariamente a correção precisa acontecer antes da extração.

Em muitos projetos é possível trabalhar com o fluxo:

extrair → identificar inconsistências → sanear → converter.

Isso evita depender exclusivamente de correções manuais diretamente no sistema legado.

Entre os problemas que podem aparecer estão:

• CPFs inválidos;

• registros duplicados;

• históricos sobrepostos;

• códigos sem correspondência;

• datas inconsistentes;

• campos obrigatórios vazios;

• estruturas organizacionais desatualizadas.

Saneamento de Dados antes de uma Migração de Folha

O importante é que o saneamento seja planejado antes das cargas definitivas.

Depois de exportar os dados, posso importá-los diretamente no novo sistema?

Em alguns cenários simples, pode ser possível.

Mas normalmente existe uma etapa intermediária.

Os dados precisam ser analisados e preparados conforme a estrutura exigida pelo destino.

O processo pode ser:

Origem → Extração → Estruturação → Saneamento → Conversão → Destino

Conversão de Dados de Folha de Pagamento

Isso acontece porque códigos, estruturas, regras e relacionamentos podem ser diferentes entre os sistemas.

Uma matrícula, um cargo, uma rubrica ou um centro de custo existente na origem não necessariamente possui o mesmo código ou representação no destino.

Como saber se todos os dados foram exportados?

Essa é uma pergunta fundamental.

Gerar um arquivo não comprova que ele contém todas as informações necessárias.

Algumas validações possíveis incluem:

• quantidade de trabalhadores;

• quantidade de dependentes;

• quantidade de históricos;

• períodos disponíveis;

• quantidade de registros financeiros;

• competências existentes;

• eventos;

• totais;

• datas mínimas e máximas;

• registros sem relacionamento.

Posteriormente, após a importação, essas informações também podem ser comparadas com o sistema de destino.

Homologação de Dados em Migrações de Folha de Pagamento

Isso cria uma linha de rastreabilidade:

o que existia → o que foi extraído → o que foi convertido → o que foi importado → o que foi homologado.

Quem é responsável por exportar os dados em uma implantação?

Isso depende do modelo definido para o projeto.

A atividade pode ficar com:

• cliente;

• fornecedor atual;

• fabricante do novo sistema;

• canal;

• consultoria de implantação;

• BPO;

• empresa especializada em migração.

Um modelo comum é o cliente ou fornecedor atual entregar os dados nos layouts solicitados pelo novo sistema.

Esse modelo pode funcionar muito bem quando os dados estão organizados, a quantidade de layouts é administrável e existe equipe disponível para realizar o trabalho.

Implantação por Importação

Porém, quando existem muitos históricos, diferentes fontes, dificuldades de acesso ou grande volume de informações, pode fazer sentido terceirizar a extração e conversão.

É possível terceirizar somente a extração dos dados?

Sim.

A empresa não precisa necessariamente terceirizar todo o projeto de implantação.

Uma empresa especializada pode assumir apenas determinadas etapas.

Por exemplo:

extração;

saneamento;

conversão;

migração completa;

ou homologação.

Isso permite adaptar o serviço à divisão de responsabilidades existente no projeto.

Para fabricantes, canais, consultorias e BPOs, esse trabalho também pode ser executado em modelo de parceria.

White Label para Migração de Dados

Antes de começar a exportar, responda estas perguntas

Antes de gerar dezenas de arquivos, vale responder:

Qual sistema está sendo substituído?

Qual produto e arquitetura estão sendo utilizados?

Qual é o sistema de destino?

Quais dados precisam ser migrados?

Quantos anos de histórico são necessários?

A ficha financeira será migrada?

Ativos e desligados serão transportados?

Existe acesso ao banco?

Existe backup?

Existem APIs ou ferramentas de exportação?

Existem arquivos nativos?

O eSocial pode complementar informações?

Quem fará os DE/PARAs?

Quem converterá os dados?

Quem realizará a homologação depois das cargas?

Essas respostas ajudam a definir a estratégia antes que a equipe comece a produzir arquivos sem saber exatamente como eles serão utilizados.

A melhor exportação é aquela pensada para a migração

O objetivo de uma exportação para migração não é simplesmente retirar o maior volume possível de informações do sistema antigo.

O objetivo é obter os dados necessários, com estrutura suficiente para que possam ser interpretados, saneados, convertidos, carregados e posteriormente homologados.

Por isso, a estratégia de extração deve considerar todo o processo:

Origem → Extração → Estruturação → Saneamento → Conversão → Importação → Homologação

Como Funciona a Migração Audpay

Quanto mais cedo essa estratégia é definida, menor tende a ser o risco de descobrir durante a implantação que faltam informações, históricos ou fontes importantes.

E, como vimos, a estratégia pode mudar completamente de uma arquitetura para outra.

Um projeto pode começar com um backup SQL.

Outro com arquivos TXT.

Outro com DBFs.

Outro com planilhas Excel.

Outro com acesso remoto.

Outro com XMLs do eSocial.

O formato da origem muda.

O objetivo continua sendo transformar essas diferentes fontes em dados estruturados, preparados para o novo sistema e capazes de serem homologados.

Precisa extrair dados de um sistema de Folha de Pagamento?

A Audpay atua exclusivamente com dados de RH, Departamento Pessoal e Folha de Pagamento e trabalha com diferentes arquiteturas e métodos de extração.

O serviço pode envolver desde a obtenção dos dados do sistema legado até estruturação, saneamento, conversão, preparação para carga e homologação.

Sistemas

Link Tecnologias e Motores de Migração de Dados

Link Fale Conosco

Sua equipe implanta. A Audpay cuida dos dados.