Migração de Dados entre Sistemas de Folha de Pagamento: diferentes plataformas, arquiteturas e estratégias
Uma empresa decide trocar seu sistema de Folha de Pagamento.
O sistema atual possui anos de informações de colaboradores, históricos, férias, afastamentos, estruturas organizacionais e ficha financeira.
O novo sistema possui outra arquitetura, outros códigos, outras regras de importação e outra forma de organizar essas informações.
Surge então uma dúvida bastante comum:
É possível migrar dados entre sistemas de Folha de Pagamento completamente diferentes?
Sim.
A origem e o destino não precisam utilizar o mesmo banco de dados, a mesma tecnologia ou sequer disponibilizar os dados da mesma forma.
Ao longo de projetos de migração, é possível encontrar informações armazenadas em bancos SQL Server, Oracle, PostgreSQL, Firebird e outras tecnologias, além de arquivos TXT, DBF, planilhas Excel, XMLs, relatórios, APIs e formatos proprietários.
O desafio não é fazer duas tecnologias diferentes conversarem diretamente.
O objetivo é extrair, interpretar e transformar os dados da origem em uma estrutura que possa ser convertida para o sistema de destino.
Guia Definitivo da Migração de Dados de RH e Folha de Pagamento
Cada sistema de Folha armazena os dados de uma forma diferente?
Sim.
Mesmo que dois sistemas armazenem informações sobre os mesmos trabalhadores, suas estruturas internas podem ser completamente diferentes.
Um sistema pode possuir uma tabela específica para históricos salariais.
Outro pode distribuir essas informações em diferentes estruturas.
Um sistema pode identificar determinado evento financeiro pelo código 101.
Outro pode utilizar o código 001 para representar informação equivalente.
Também podem mudar:
-
códigos de empresas;
-
matrículas;
-
cargos;
-
departamentos;
-
centros de custo;
-
sindicatos;
-
horários;
-
rubricas;
-
tipos de cálculo;
-
estruturas de históricos;
-
relacionamentos entre tabelas.
Por isso, uma migração profissional não consiste simplesmente em copiar registros de um banco para outro.
É necessário interpretar o significado dos dados na origem e reconstruí-los conforme as regras do destino.
Conversão de Dados de Folha de Pagamento
A origem e o destino precisam utilizar o mesmo banco de dados?
Não.
Uma migração pode ocorrer entre tecnologias completamente diferentes.
Por exemplo, uma origem baseada em Oracle pode fornecer dados para uma implantação cujo destino recebe informações por layouts.
Da mesma maneira, dados provenientes de:
-
SQL Server;
-
PostgreSQL;
-
Oracle;
-
Firebird;
-
arquivos TXT;
-
arquivos DBF;
-
planilhas Excel;
-
XMLs;
-
APIs;
-
relatórios;
-
arquivos nativos;
podem ser transformados em uma estrutura intermediária para posteriormente serem convertidos para o novo sistema.
O princípio pode ser representado assim:
Sistema de origem → Extração → Estruturação → Conversão → Sistema de destino
Como exportar dados de um sistema de Folha de Pagamento para uma migração
O banco de dados determina se uma migração é possível?
Não.
Ter acesso ao banco normalmente representa uma excelente fonte para o projeto, mas não é a única possibilidade.
Existem projetos em que o banco não está disponível.
Nesses casos, podem existir outras fontes:
Sistema → planilhas
Sistema → arquivos TXT
Sistema → arquivos nativos
Sistema → APIs
Sistema → relatórios
eSocial → XMLs
PDFs → dados estruturados
Em determinados cenários, diferentes fontes também podem ser combinadas.
8 formas de extrair dados de sistemas legados
Por isso, antes de concluir que uma migração é inviável porque determinado banco não está disponível, é necessário analisar quais outras fontes contêm as informações necessárias.
Sistemas diferentes exigem projetos de migração completamente diferentes?
A estratégia de obtenção dos dados pode mudar bastante.
Entretanto, depois que essas informações são interpretadas e transformadas em uma estrutura controlada, diversas etapas da metodologia podem ser reutilizadas.
Um projeto pode começar assim:
Backup SQL → banco restaurado
Outro:
TXT → engenharia reversa → banco estruturado
Outro:
Excel → banco estruturado
Outro:
DBF → conversão → banco estruturado
Outro:
XML eSocial → interpretação → banco estruturado
A fonte muda.
A arquitetura muda.
Mas o objetivo é semelhante:
transformar diferentes origens em dados estruturados que possam ser tratados, convertidos e preparados para o destino.
Tecnologias e Motores de Migração de Dados
Experiências da Audpay com diferentes sistemas e arquiteturas
Ao longo dos projetos realizados pela Audpay, diferentes sistemas exigiram estratégias distintas de obtenção e estruturação dos dados.
Os exemplos a seguir ajudam a demonstrar como uma migração pode mudar conforme o ambiente encontrado.
Nota importante: as arquiteturas, bancos de dados e formas de extração apresentadas abaixo representam cenários encontrados pela Audpay em projetos já realizados. Produtos, versões, ambientes, modelos de contratação e recursos disponibilizados pelos fabricantes podem mudar ao longo do tempo. Portanto, estas informações não devem ser interpretadas como documentação técnica oficial dos respectivos fornecedores. A estratégia de extração precisa ser avaliada individualmente em cada projeto.
Portfólio Técnico de Migração de Sistemas de RH e Folha de Pagamento
Experiências da Audpay em projetos envolvendo Senior
Em projetos envolvendo Senior, a Audpay já trabalhou com diferentes formas de obtenção dos dados.
Em alguns cenários, foi disponibilizado backup do banco de dados.
Em outros, a estratégia envolveu acesso às estruturas por meio do CBDS – Central de Banco de Dados Senior.
Também já foram utilizadas possibilidades de obtenção das informações por meio de recursos disponíveis na própria aplicação.
Isso permite encontrar diferentes caminhos:
Senior → backup → extração
Senior → CBDS → extração
Senior → aplicação → exportação
A estratégia escolhida depende do ambiente disponível no projeto e principalmente das informações que precisam ser migradas.
Esse exemplo demonstra por que a ausência de um determinado tipo de acesso não significa automaticamente que o projeto seja inviável.
Experiências da Audpay em projetos envolvendo ADP
Em projetos envolvendo ADP, a Audpay já recebeu dados disponibilizados por meio de arquivos TXT.
Nesse tipo de cenário, o trabalho não consiste apenas em abrir os arquivos e transformá-los em layouts do destino.
Primeiro é necessário compreender as estruturas recebidas.
A Audpay realiza a interpretação dos arquivos e, quando necessário, utiliza técnicas de engenharia reversa para reconstruir seus relacionamentos em uma base estruturada.
O processo pode seguir:
ADP → arquivos TXT → engenharia reversa → banco estruturado → conversão → destino
Depois que os dados estão estruturados, podem ser aplicadas regras de transformação e DE/PARAs conforme a plataforma que irá recebê-los.
Conversão de Dados de Folha de Pagamento
Experiências da Audpay em projetos envolvendo SAP HCM
Em projetos envolvendo SAP HCM, a Audpay também já trabalhou com dados disponibilizados em arquivos contendo estruturas extraídas do ambiente de origem.
Nesses cenários, as informações recebidas precisam ser interpretadas e relacionadas antes de serem utilizadas na migração.
O princípio é semelhante:
SAP HCM → arquivos extraídos → interpretação das estruturas → banco intermediário → conversão → destino
Esse modelo é especialmente interessante porque demonstra que a equipe responsável pela migração não precisa necessariamente possuir acesso direto ao ambiente produtivo para conseguir trabalhar os dados.
Quando as estruturas necessárias são corretamente disponibilizadas, elas podem ser reconstruídas em um ambiente controlado de migração.
Experiências da Audpay em projetos envolvendo LG FPw
Em projetos envolvendo LG FPw, a Audpay já encontrou diferentes ambientes e arquiteturas.
Em determinados cenários, o projeto pôde trabalhar diretamente com estruturas de banco disponibilizadas para a migração.
Depois da restauração ou acesso aos dados, inicia-se a análise das informações necessárias ao escopo.
Podem ser tratados, por exemplo:
-
colaboradores;
-
históricos;
-
estruturas organizacionais;
-
férias;
-
afastamentos;
-
eventos;
-
ficha financeira.
O ponto central é que a arquitetura precisa ser identificada no início do projeto para definir a melhor estratégia de extração.
Experiências da Audpay em projetos envolvendo LG Nuvem
Em projetos de LG Nuvem atendidos pela Audpay nos quais não havia acesso direto ao banco de dados, a estratégia utilizada foi diferente.
As informações foram obtidas por meio de recursos disponíveis na própria aplicação, com geração de planilhas contendo os dados necessários ao projeto.
Mas o processo não precisa permanecer baseado em dezenas de planilhas durante toda a migração.
A Audpay transforma essas informações em uma base de dados estruturada.
O fluxo pode ser:
LG Nuvem → planilhas → banco estruturado → tratamento → conversão → destino
Depois dessa estruturação, é possível realizar cruzamentos, DE/PARAs, saneamentos, validações e geração das estruturas necessárias ao novo sistema.
Experiências da Audpay em projetos envolvendo TOTVS Protheus
Em projetos envolvendo TOTVS Protheus, a Audpay já trabalhou com cenários em que a fonte disponibilizada para a migração foi o banco de dados do ambiente legado.
A disponibilização da base permite analisar as estruturas necessárias ao escopo e construir as extrações.
Entretanto, ter acesso ao banco não elimina o trabalho de engenharia.
É necessário identificar como informações como:
-
colaboradores;
-
dependentes;
-
cargos;
-
departamentos;
-
históricos;
-
férias;
-
afastamentos;
-
eventos;
-
ficha financeira;
estão estruturadas e relacionadas.
Depois da extração, essas informações precisam ser transformadas conforme o sistema de destino.
Experiências da Audpay em projetos envolvendo TOTVS RM
Em projetos TOTVS RM já atendidos pela Audpay, também foram utilizados cenários baseados em acesso ou restauração de banco de dados.
Dependendo do ambiente disponibilizado, outras possibilidades de obtenção das informações também podem ser avaliadas.
Depois que a fonte é definida, o trabalho passa pela identificação e interpretação das estruturas necessárias à migração.
Isso é particularmente importante quando o escopo contempla informações históricas, como:
-
alterações salariais;
-
alterações de cargo;
-
férias;
-
afastamentos;
-
estruturas organizacionais;
-
ficha financeira.
Experiências da Audpay em projetos envolvendo TOTVS Datasul
Em projetos envolvendo TOTVS Datasul, a Audpay já encontrou ambientes nos quais foi necessária uma estratégia diferente daquela utilizada em bancos SQL convencionais.
Em um desses cenários, a obtenção dos dados envolveu acesso remoto ao ambiente e utilização dos recursos disponíveis para consulta e extração das informações.
Os dados obtidos foram então levados para uma estrutura intermediária utilizada no processo de migração.
De forma simplificada:
TOTVS Datasul → acesso ao ambiente → extração → estrutura intermediária → conversão → destino
Esse tipo de projeto demonstra a importância de possuir diferentes motores de obtenção dos dados.
Experiências da Audpay em projetos envolvendo Benner
A Audpay também já participou de projetos envolvendo ambientes Benner.
Nos cenários encontrados, a estratégia foi definida a partir da arquitetura efetivamente disponibilizada pelo cliente.
Quando existe acesso estruturado à base, os dados podem ser analisados, extraídos e levados para o ambiente intermediário de migração.
O mais importante não é presumir antecipadamente qual banco ou arquitetura estará disponível.
É realizar o diagnóstico do ambiente e identificar qual fonte oferece maior cobertura para o escopo contratado.
Diagnóstico Estratégico da Migração
Experiências da Audpay em projetos envolvendo Metadados
Em projetos envolvendo Metadados, a Audpay já trabalhou com acesso estruturado aos dados do sistema de origem.
A partir da base disponibilizada, são identificadas as informações necessárias ao projeto e construídas as rotinas de extração.
Depois disso, os dados seguem para tratamento e transformação conforme a plataforma de destino.
O mesmo princípio vale para qualquer migração baseada em banco:
possuir acesso à base é diferente de conhecer a base.
A engenharia da migração precisa identificar corretamente tabelas, campos, relacionamentos, históricos e regras de negócio.
Experiências da Audpay em projetos envolvendo Sankhya
A Audpay também possui experiência em projetos envolvendo Sankhya.
Nos ambientes já atendidos, a estratégia de extração foi definida a partir da base e dos acessos disponibilizados no projeto.
Esses dados foram analisados e estruturados para posteriormente serem convertidos conforme as necessidades da plataforma de destino.
Como em qualquer outro sistema, a tecnologia encontrada em um projeto não deve ser tratada como uma característica permanente de todos os ambientes Sankhya.
Versão, infraestrutura e modelo de disponibilização podem mudar.
Por isso, o diagnóstico técnico continua sendo o primeiro passo.
Experiências da Audpay em projetos envolvendo SCI Practice
Em projetos envolvendo SCI Practice, a Audpay já trabalhou com arquivos nativos DBF contendo diferentes estruturas utilizadas pela aplicação.
Nesse cenário, a estratégia não depende de um backup SQL tradicional.
Os arquivos são interpretados e transformados em uma estrutura adequada ao processo de migração.
O fluxo pode ser:
SCI Practice → arquivos DBF → conversão → banco estruturado → transformação → destino
Essa experiência demonstra como arquivos nativos também podem funcionar como uma fonte completa para determinados projetos.
Experiências da Audpay em projetos envolvendo SCI Único
Em projetos envolvendo SCI Único, a Audpay já trabalhou com ambientes nos quais foi possível obter a base de dados e restaurá-la em um ambiente controlado de migração.
A partir dessa restauração, as estruturas necessárias foram analisadas e utilizadas para extração.
Um ponto interessante é que dois produtos do mesmo fornecedor podem exigir estratégias completamente diferentes.
Por isso, perguntar apenas “qual é o fabricante?” não é suficiente.
É necessário identificar:
-
produto;
-
versão;
-
arquitetura;
-
ambiente;
-
acessos disponíveis;
-
escopo da migração.
Experiências da Audpay em projetos envolvendo Domínio
Em projetos envolvendo Domínio, a Audpay já trabalhou com cenários nos quais o backup da base foi disponibilizado para o processo de migração.
Depois da restauração em ambiente controlado, a base pode ser analisada para identificação das informações contempladas pelo projeto.
O fluxo segue o princípio:
backup → restauração → análise → extração → transformação → destino
Experiências da Audpay em projetos envolvendo Alterdata
A Audpay também já executou projetos envolvendo Alterdata nos quais o trabalho partiu da disponibilização de uma base para restauração e análise.
Uma vez reconstruído o ambiente de dados, são identificadas as estruturas necessárias para o projeto.
Posteriormente, essas informações são extraídas e convertidas para a plataforma de destino.
Novamente, a tecnologia encontrada naquele projeto representa o cenário atendido, e não necessariamente todos os ambientes existentes do produto.
Experiências da Audpay em projetos envolvendo Folhamatic
Em projetos envolvendo Folhamatic, a Audpay também já trabalhou com bases disponibilizadas para restauração e extração.
Depois da recuperação da base, as informações necessárias ao escopo podem ser identificadas e estruturadas.
Cadastros e históricos seguem posteriormente para as etapas de tratamento, conversão e preparação para o novo sistema.
Experiências da Audpay em projetos envolvendo Contmatic
A Audpay já encontrou projetos envolvendo Contmatic em que o acesso direto à estrutura original do banco não era a alternativa utilizada para a migração.
Nesses cenários, informações puderam ser obtidas por meio de recursos da própria aplicação e relatórios/exportações em planilha.
As planilhas foram então utilizadas como fonte para estruturação dos dados.
O fluxo pode ser:
Contmatic → aplicação → Excel → banco estruturado → conversão → destino
Esse exemplo é particularmente importante porque demonstra que uma limitação de acesso ao banco não encerra necessariamente as possibilidades de migração.
A arquitetura atual e os recursos disponíveis precisam sempre ser avaliados no momento do projeto.
Experiências da Audpay em projetos envolvendo Minerion
Em projetos Minerion já atendidos pela Audpay nos quais o banco de dados não foi disponibilizado como fonte para a migração, a obtenção das informações ocorreu por meio de arquivos e planilhas disponibilizados para o projeto.
Esses dados puderam posteriormente ser estruturados e conectados ao processo de transformação.
Mais uma vez:
não receber o banco não significa necessariamente não conseguir migrar.
O que precisa existir é uma fonte capaz de fornecer as informações previstas no escopo.
Experiências da Audpay em projetos envolvendo Viasoft
A Audpay também já trabalhou com projetos envolvendo Viasoft nos quais houve acesso estruturado à base utilizada como fonte para a migração.
A partir dos dados disponibilizados, as estruturas necessárias foram analisadas, extraídas e transformadas conforme o sistema de destino.
Como nos demais exemplos, a arquitetura precisa ser confirmada no início de cada novo projeto, sem presumir que o ambiente atual será igual aos projetos anteriores.
E quando a origem é o eSocial?
O eSocial merece um tratamento diferente porque, nesse caso, não estamos falando de um sistema tradicional de Folha de Pagamento utilizado como banco legado.
A fonte são os XMLs dos eventos transmitidos ao ambiente nacional.
Em projetos realizados pela Audpay, esses XMLs podem ser obtidos e posteriormente processados para transformar informações originalmente estruturadas por evento em uma base de dados organizada para utilização na migração.
O fluxo pode ser:
eSocial → XMLs → leitura e interpretação → banco estruturado → relacionamentos → conversão → destino
Dependendo dos eventos disponíveis, podem ser recuperadas informações relacionadas a trabalhadores, contratos, alterações cadastrais e contratuais, afastamentos, remunerações e outros dados.
Migração de Dados de Folha usando XMLs do eSocial
Link Base Estruturada do eSocial
O eSocial, entretanto, não deve ser tratado como uma cópia completa do sistema de Folha.
Ele pode ser a fonte principal em determinados projetos, mas também pode atuar como fonte complementar ou de validação.
O que essas experiências mostram sobre migração de dados?
Quando colocamos esses projetos lado a lado, fica evidente que migração de dados de Folha de Pagamento não pode depender de uma única tecnologia de extração.
Em um projeto, a origem pode entregar um backup.
Em outro, arquivos TXT.
Em outro, DBFs.
Em outro, planilhas.
Em outro, XMLs do eSocial.
Em outro, o acesso precisa ocorrer diretamente no ambiente.
Por isso, uma estrutura de migração precisa estar preparada para trabalhar com diferentes entradas:
Backup de banco
↓
Acesso remoto
↓
Arquivos nativos
↓
TXT/CSV
↓
Excel
↓
APIs
↓
XML eSocial
↓
PDF
↓
Fontes híbridas
↓
Base estruturada para migração
Tecnologias e Motores de Migração de Dados
O sistema nunca foi mapeado pela Audpay. Ainda é possível migrar?
Possivelmente, sim.
Conhecer previamente uma arquitetura acelera determinadas etapas, mas uma metodologia de migração não pode depender exclusivamente de possuir um conector pronto para cada sistema existente no mercado.
Quando uma nova arquitetura aparece, o processo começa pela análise da fonte.
É necessário descobrir:
Onde estão os dados?
Como podem ser obtidos?
Como as estruturas se relacionam?
Quais informações fazem parte do escopo?
Como essas informações precisam chegar ao destino?
A partir daí, pode ser realizado o mapeamento da nova arquitetura.
Portfólio Técnico de Migração de Sistemas de RH e Folha de Pagamento
O que acontece depois que os dados são extraídos?
A extração resolve apenas uma parte do problema.
Depois dela, normalmente começa a etapa mais importante da engenharia:
a conversão.
Os dados precisam ser transformados conforme o sistema de destino.
Imagine:
Origem:
Empresa 01
Matrícula 1257
Cargo 015
Evento 101
Destino:
Empresa 100
Matrícula 458
Cargo 320
Evento 001
É necessário construir os relacionamentos entre essas estruturas.
Esse trabalho pode envolver:
-
DE/PARAs;
-
saneamento;
-
padronização;
-
transformação de códigos;
-
reconstrução de históricos;
-
tratamento de datas;
-
tratamento de valores;
-
unificação de empresas;
-
unificação ou alteração de matrículas;
-
conversão de eventos;
-
preparação para layouts de importação.
Conversão de Dados de Folha de Pagamento
E a ficha financeira?
A ficha financeira merece atenção especial porque normalmente concentra um dos maiores volumes de informações de uma migração.
Anos de histórico podem representar milhões de registros envolvendo:
-
trabalhadores;
-
competências;
-
eventos;
-
referências;
-
valores;
-
bases;
-
diferentes tipos de cálculo.
Além de extrair esses dados, é necessário relacionar eventos da origem com o destino e garantir que o histórico financeiro permaneça associado ao trabalhador correto.
Ficha Financeira na Migração de Folha de Pagamento
Como saber se os dados chegaram corretamente ao novo sistema?
A última etapa não deve ser simplesmente:
“o sistema importou sem erro.”
Uma carga tecnicamente aceita não comprova que o conteúdo está correto.
Depois da migração, é necessário comparar origem e destino.
Dependendo do escopo, podem ser validados:
-
quantidade de trabalhadores;
-
cadastros;
-
históricos;
-
férias;
-
afastamentos;
-
estruturas organizacionais;
-
ficha financeira;
-
competências;
-
eventos;
-
valores;
-
totais.
Homologação de Dados em Migrações de Folha de Pagamento
O fluxo completo passa a ser:
Origem → Extração → Estruturação → Saneamento → Conversão → Importação → Homologação
Conhecer Folha de Pagamento é tão importante quanto conhecer banco de dados
Uma migração de Folha não é exclusivamente um projeto de tecnologia.
Também não é exclusivamente um projeto funcional.
Ela está no encontro das duas áreas.
É necessário compreender banco de dados para localizar e relacionar informações.
Mas também é necessário compreender Folha de Pagamento para saber o que aquelas informações significam.
Um campo pode armazenar um código.
Conhecimento técnico permite encontrar esse código.
Conhecimento funcional permite compreender se ele representa um cargo, sindicato, evento, tipo de cálculo, afastamento ou outra informação.
É justamente essa combinação que permite reconstruir históricos em arquiteturas diferentes.
Mais de um sistema pode ser utilizado como fonte no mesmo projeto?
Sim.
Existem projetos em que nenhuma fonte isolada contém tudo o que é necessário.
Nesses casos, diferentes fontes podem ser combinadas.
Por exemplo:
Banco legado + eSocial
Banco + planilhas
XML + planilhas
Arquivos nativos + relatórios
Banco + PDFs
Essa estratégia permite utilizar a melhor fonte disponível para cada conjunto de informações.
Motor Híbrido de Migração de Dados
Qual é a melhor forma de iniciar uma migração entre sistemas diferentes?
Antes de preparar dezenas de planilhas ou solicitar qualquer exportação, vale responder:
Qual é exatamente o sistema de origem?
Qual versão e ambiente estão sendo utilizados?
Qual é o sistema de destino?
Existe acesso ao banco?
Existe backup?
Existem exportadores na aplicação?
Existem APIs?
Existem arquivos nativos?
Quais dados precisam ser migrados?
Quantos anos de histórico?
A ficha financeira será migrada?
Ativos e desligados fazem parte do escopo?
Existem empresas ou matrículas que serão unificadas?
Quem realizará os DE/PARAs?
Quem fará a conversão?
Quem homologará os dados depois das cargas?
Essas respostas permitem escolher a tecnologia depois de compreender o problema — e não tentar adaptar o problema a uma tecnologia previamente escolhida.
Link Diagnóstico Estratégico da Migração
Sistemas mudam. A metodologia de migração precisa acompanhar.
Bancos de dados mudam.
Produtos evoluem.
Sistemas migram para a nuvem.
Fabricantes criam novas APIs.
Exportadores são modificados.
Arquiteturas antigas deixam de existir.
Novas versões aparecem.
Por isso, uma empresa especializada em migração não pode depender apenas de conhecer a arquitetura de uma versão específica de determinado software.
Ela precisa desenvolver capacidade para analisar novas fontes, interpretar estruturas e transformar diferentes formatos em dados utilizáveis.
É por isso que as experiências apresentadas neste artigo não são uma documentação permanente dos sistemas citados.
São exemplos reais de diferentes cenários que uma engenharia de migração precisa estar preparada para enfrentar.
Portfólio Técnico de Migração de Sistemas de RH e Folha de Pagamento
Migração de dados entre sistemas com a Audpay
A Audpay atua exclusivamente com dados de RH, Departamento Pessoal e Folha de Pagamento.
Ao longo dos projetos realizados, diferentes sistemas, bancos, arquivos e arquiteturas já foram utilizados como fonte para processos de migração.
Essa experiência permite avaliar diferentes cenários e definir a estratégia adequada conforme:
-
sistema de origem;
-
ambiente disponível;
-
fontes acessíveis;
-
qualidade dos dados;
-
volume;
-
históricos;
-
sistema de destino;
-
escopo contratado.
A atuação pode contemplar somente determinadas etapas, como extração e conversão, ou todo o processo de migração.
Para software houses, canais, consultorias e BPOs, a Audpay também pode atuar integrada à equipe responsável pela implantação.
White Label para Migração de Dados
Precisa migrar dados entre sistemas de Folha de Pagamento?
Não importa apenas de qual sistema os dados estão saindo.
É necessário entender:
onde estão as informações;
como podem ser extraídas;
como estão relacionadas;
como precisam ser transformadas;
e como serão homologadas no novo ambiente.
Se o sistema de origem possui banco, backup, arquivos, planilhas, XMLs, APIs ou outra fonte de dados, a primeira etapa é avaliar tecnicamente o cenário.
Sua equipe implanta. A Audpay cuida dos dados.
