Toda organização que tenha uma certa idade já se deparou, ou provavelmente irá se deparar, com um projeto nada charmoso, mas necessário, que é o da Migração de Dados. Uma das razões decorre das mudanças de tecnologia, que envelhecem muito rápido frente às inovações que são incorporadas nesta área. Outro motivo para a migração, acontece por conta dos processos de reestruturação societária, envolvendo incorporações, fusões e cisões, que trazem à tona sistemas legados que deixam de existir, mas que implicam em migração do seu acervo de dados para a nova plataforma. Por se tratar de uma atividade não muito atrativa, o fato de ser necessário que ela seja realizada uma única vez, com 100% de acerto, com riscos seríssimos em caso de falhas, somado a um conjunto de problemas inerentes a essa classe de projeto, faz com que a definição e a utilização de uma metodologia apropriada para a migração sejam os pontos cruciais para o êxito do empreendimento.

 

Migração de Dados envolve sempre dois repositórios distintos: base de dados de origem (“de”) e de destino (“para”). A substituição de uma solução de TI por outra, passa, necessariamente, por contemplar que as informações dispostas no ambiente de origem, segundo uma determinada modelagem de dados, passem a compor as novas estruturas de dados do sistema de destino, resguardados os seus significados, independentemente de como fisicamente elas estejam dispostas nos ambientes de origem e destino. Implementar este “de-para” requer usualmente que algumas transformações sejam feitas nos dados de origem para atenderem às novas especificações do destino, mas envolve também lidar com outros obstáculos.

 

Um dos problemas mais comuns reside no cenário em que se desconhece (ou há uma falta relevante de informações) o ambiente de origem (“de”). Este caso, tanto pode ser originário de um legado absorvido pela organização, quanto de um sistema já operacional há anos, mas que os mantenedores atuais desconhecem diversos porquês, tanto em relação à implantação quanto ao modelo de dados. Neste quadro, há uma ausência de documentação de qualidade ou até mesmo ausência de documentação para subsidiar um entendimento correto do modelo de dados e de seu conteúdo. Nestas situações necessita-se um “mergulho” nos dados e, por vezes, nos programas fonte para sanar dúvidas que se farão presentes.

 

Não raro nos deparamos com uma situação na qual a incógnita está no ambiente de destino (“para”). A aquisição de uma plataforma mais moderna ou um outro ambiente decorrente de uma reestruturação societária podem conduzir, por falta de documentação apropriada e/ou por carência de interlocutores responsáveis pelo novo ambiente (quer por pouca disponibilidade ou mesmo ausência de conhecimentos mais profundos) à uma necessidade semelhante a do caso anterior na qual o encaminhamento de solução passa pela necessidade de se “debruçar” sobre a implementação física do novo sistema (dados e programas).

 

Recentemente, participei de um projeto de migração de dados de um sistema legado para um novo sistema, com baixa quantidade e qualidade de informações tanto no “de” quanto no “para”, em um cenário crítico. As poucas “bússolas” que existiam eram as bases de dados dos dois sistemas e acesso aos respectivos códigos fonte, em que a documentação era para lá de precária. Os interlocutores responsáveis pela manutenção tinham baixa disponibilidade. Os usuários detentores do conhecimento sobre as regras de negócio, embora com boa disponibilidade, careciam de clareza e, às vezes, até de conhecimento.  Neste cenário, a definição de uma metodologia que propiciasse ir conhecendo o terreno foi fundamental para o sucesso da empreitada.

 

Partindo da constatação empírica de que não há uma única “receita de bolo” que possa ser aplicada em todas as situações, algumas boas práticas podem nos ajudar na elaboração de uma metodologia eficaz que tenha como premissa básica possibilitar o entendimento do “de” e/ou do “para”. Por exemplo, elaborar questões que nos auxiliem a identificar com quais tabelas iniciar a análise (Maior volume de dados? Maior número de atributos? Maior quantidade de chaves estrangeiras?), levantar os conceitos chave e validá-los com a área de negócios, planejar como abordar o conhecimento do sistema, elaborar tabelas auxiliares que propiciem uma validação dos diversos mapeamentos “de-para”, planejamento para validação dos testes e para “acionar o interruptor” e desligar o “de”, são algumas orientações saudáveis para  efetuar uma migração o mais suave possível.

 

O passado e a certeza de que teremos um futuro próximo diferente do presente nos indica que a migração de dados é uma classe de problema que o setor de TI das organizações irá se defrontar. Embora não haja uma “receita de bolo”, alguns ingredientes são essenciais para o sucesso. Organização e planejamento, portando uma metodologia robusta, são ingredientes essenciais, possibilitando redução de riscos, tempo, custo e imagem. O tempero fundamental para o sucesso é contemplar a fase de elicitação de requisitos com todo o rigor e profundidade que esta demanda. Adicionar, sem medo de economia, uma grande dosagem de testes e fazê-la de forma estruturada, pois isto sem dúvida se reverte em ganho e traz a segurança necessária para a qualidade do produto final. Uma boa pitada de desconfiança em relação ao entendimento dos dados permite retirar o gosto amargo de se concluir, após o produto pronto, que o que em “de” significava laranja, em “para” era banana. Com boas práticas, experiência e conhecimento, o resultado deste processo será eficaz e os responsáveis poderão saborear o sucesso de uma migração bem-sucedida. Bon apetit!

 

*Mauro Herson é sócio-fundador da RSI Redes.