MIGRAR DADOS ENTRE BANCOS TOTALMENTE DIFERENTES

LUIS.HERRERA 18/10/2017 11:30:14
#477220
Bom dia!
Tenho um sistema em C# com SQL Server 2008 R2 Express
Alguns potenciais clientes estão solicitando migração dos dados de seus ERPs para meu sistema, mas tenho alguns problemas:

Quem faz a implantação é o TI do cliente, pois minha licença de uso não cobre locomoções até os clientes, e tem clientes com muitas limitações técnicas de acesso remoto ou cujo TI não possui acesso aos banco de dados, pois estes são geridos pelos fornecedores dos ERPs (é cada situação inusitada que vocês devem conhecer bem).

Ouvi que existem programas que fazem essa migração entre bancos diferentes e até ferramentas gratuitas, porém não estou encontrando. Parece que é possível criar até a estrutura do meu banco numa planilha com os campos e o cliente faz as associação dos campos no banco dele e essa ferramenta faz e integração, migração e validação antes de gravar no meu banco que já terá toda estrutura pronta.

Há alguns problemas que vejo: pois não será simplesmente copiar uma tabela da origem para o destino.

1) Nenhum banco desses ERPs terá a estrutura de dados semelhante a minha, onde poderá ser necessário usar mais de uma tabela da Origem para montar os registros que serão gravados no meu Banco. Também poderá ocorrer de não existirem vários campos indispensáveis no meu sistema, não sendo permitido gravar campo NuLL. Assim seria necessário montar toda uma estrutura de cada registro antes da gravação, que além de seguir uma hierarquia de tabelas, também terá de levar em conta os IDs criados no meu banco para fazer essas gravações, uma vez que o ID do departamento na Origem, será diferente do ID do Departamento no meu banco (campo autoincremento);

Alguém conhece algumas ferramentas que possam indicar que sejam práticas, confiáveis e sejam bem flexíveis para montar essas migrações?

Uma alternativa que estava pensando era criar manualmente uma pasta do Excel e em cada planilha incluir a estrutura pronta dos meus campos necessários, e deixar por conta do Cliente extrair os dados do seu banco de dados e montar essas planilhas com todos os dados necessários. Então eu criaria um pequeno utilitário para fazer a leitura dessa planilha para o banco SQL já pronto, porém surgiram alguns dúvidas críticas nesse cenário:

- o cliente alterar a estrutura das planilhas e comprometer o meu utilitário de leitura (pois seria necessário criar infindáveis validações para cada importação, tanto das planilhas, suas colunas e dos respectivos dados e tipos.

- o cliente não preencher todos os campos corretamente, pois todos os meus registros são 100% indexados e relacionados entre suas tabelas

- a ordem de gravação dos dados no meu sistema deve seguir uma hierarquia entre as tabelas, pois primeiro tenho de ter a empresa, depois departamentos, cargos, funcionários etc...sendo que cada tabela está relacionada com diversas outras por seus respectivos IDs. Como cada tabela tem seu id (AUTOINCREMENTO), os IDs vindos do banco de ORIGEM não seriam usado, mas sim os gerados pelos meu SQL Server, com isso antes de gravar cada registro de um funcionário por exemplo, deveria checar qual o ID do departamento e do cargo gravado, para alterar os dados contidos na planilha.

O assunto é bem complexo.

Agradeço a ajuda antecipadamente.

MARCOSLING 18/10/2017 21:48:35
#477234
Programas que fazem migração? Acho improvável que existam. Como esses programas iriam saber como a sua aplicação funciona?

O que vc pode fazer é como vc mesmo sugeriu: usar planilhas
Eu mesmo faço isso para importar dados para o meu sistema.

Será necessário travar a estrutura para que usuario não faça modificações.
Vc terá que importar as planilhas na sequencia que precisa ser feito.
Eu costumo importar os dados da planilha para uma tabela temporária, validar os dados, validar relacionamentos e depois importar das tabelas temporárias para as tabelas definitivas.

Durante esse processo de importação e validação vc pode gerar logs de erros.
FUTURA 19/10/2017 09:00:20
#477238
Eu ja fiz algumas importações, todas no [Ô]braço[Ô], pego o banco ( sql, firebird, access,dbf, etc..) coloco pra rodar, interpreto os campos, escrevo código pra ler do banco de origem e gravar no destino. Fácil não é não, da um baita trabalho, só compensa pra vc poder manter um novo cliente, e olhe la....
LUIS2014 19/10/2017 09:21:49
#477239
é como o FUTURA falou, serviço [Ô]braçal[Ô], não tem fórmula pronta, são estruturadas diferentes para cada migração, se o cliente quer migrar os dados vai pagar um extra pelo serviço.
FUTURA 19/10/2017 11:57:20
#477246
E olha que pra fazer, tem que compensar muito viu... porque vc vai garimpar dados em estrutura que não conhece, montar rotinas pra importar, tentar adivinhar alguns [Ô]status[Ô], depois ainda validar tudo isso.. e caso algo de errado, vc é o responsável, porque se propôs a fazer. Em alguns casos é mais recomendado importar apenas cadastros ( clientes, produtos, etc). e começar uma nova movimentação.
LUIS.HERRERA 19/10/2017 12:17:32
#477248
Bom amigos a idéias é só importar alguns cadastros mesmo, nenhum registro de processo. Porém apesar disso, só os cadastros já são complicados, pois meu sistema é diferente de tudo que outros software tenham. Assim por mais que eu tenha uma tabela de funcionários, há campos que não haverá em outros software e relacionamentos que implicarão em associação de indices que só serão criados após inclusão dos dado no meu banco, não sendo mais compatíveis com os do sistema atual do cliente, e isso ele teria de fazer manualmente para acertar, mas acho impossível que alguém consiga fazer essa associação sem cometer nenhum erro, sendo talvez mais trabalhoso que digitar tudo, pois certamente haverá a necessidade de se editar cada registro para incluir os dados faltantes e que não são poucos.

Estou aguardando uma conferência via Skype onde um TI irá me passar um software que disse fazer algo bem interessante. Depois digo o que achei.
Tópico encerrado , respostas não são mais permitidas