Migração de dados do sistema legado: os erros que só aparecem depois da virada

Dado sujo não é detalhe técnico

Os erros mais comuns na migração de dados de um sistema legado são três: deixar o saneamento para depois da carga, fazer a virada sem ensaio e não ter um plano de volta. Os três aparecem com o sistema novo já no ar, quando a correção custa mais. E o que evita cada um é trabalho que precisa ser feito antes da virada.

Migrar é copiar os dados do sistema antigo para o novo, convertendo o formato no caminho. O processo costuma ser chamado de ETL (extrair, transformar e carregar). A parte difícil raramente é a cópia.

O primeiro erro é tratar a qualidade da base antiga como detalhe a resolver "quando der". O sistema novo é validado com dados bonitos, entra no ar com dados reais, e é aí que os problemas se mostram.

O que costuma estar escondido na base antiga

Um sistema usado por muitos anos acumula marcas do que as pessoas fizeram para contornar suas limitações. Alguns exemplos frequentes:

• cadastros duplicados, com grafias diferentes para a mesma pessoa ou a mesma unidade;
• campos obrigatórios no sistema novo que, no antigo, ficavam em branco;
• um campo de observação livre usado para guardar uma informação que merecia coluna própria;
• códigos que mudaram de significado ao longo do tempo, sem que o histórico fosse corrigido;
• registros que ninguém usa mais, mas que continuam ligados a processos antigos.

Imagine, como exemplo hipotético, um cadastro em que o número do processo foi digitado com pontos, com traços ou sem formatação, dependendo de quem preencheu. O sistema novo exige um padrão. Na carga, parte dos registros é rejeitada ou, pior, aceita errada e passa a não ser encontrada nas buscas.

Quem decide o que é o dado certo

Limpar dado exige decisão de negócio, não só de TI. Quando há dois cadastros para a mesma entidade, qual vale? Quando um campo está vazio, o registro é descartado, preenchido com um valor padrão ou devolvido para a área corrigir?

A equipe técnica lista as inconsistências. Quem responde é o dono do processo. Defina esse responsável no início: dúvida sem dono vira espera no caminho da virada.

Limpar antes ou durante a carga

Há dois caminhos. Limpar na origem, antes da carga, deixa a base antiga mais correta e dá à área tempo de revisar. Limpar durante a carga, com regras de transformação, é mais rápido, mas esconde decisões dentro de um script que só quem o escreveu entende.

Não há regra única. A escolha depende de quanta decisão humana cada problema exige. Correção por regra clara (padronizar um formato) cabe na carga. Correção que exige julgamento (qual dos dois cadastros é o verdadeiro) pede revisão antes. O que não funciona é nenhuma das duas: carregar e ver o que acontece.

Ensaiar a migração antes do dia da virada

O segundo erro é tratar a virada como um evento único, que será executado pela primeira vez no dia em que valer. Se a primeira carga completa acontece com o sistema antigo desligado, qualquer surpresa vira urgência.

A consequência é previsível: a carga demora mais do que se imaginava, falha num registro que ninguém previu e a equipe decide, sob pressão, entre atrasar e seguir com dado incompleto.

Ensaio completo em ambiente separado

O ensaio é uma migração inteira, feita em um ambiente à parte, com uma cópia recente da base real. Não é uma amostra pequena. Uma amostra não revela o que só aparece em volume, como lentidão e registros com formato inesperado.

O ensaio responde a uma pergunta prática: quanto tempo a carga leva? Esse dado define a janela da virada e o momento em que o sistema antigo deixa de receber alterações. Meça, não estime. Repita o ensaio depois de cada correção relevante, até a carga rodar sem intervenção manual.

Conferir o que chegou: contagem, amostra, casos de borda

Carga concluída não significa carga correta. Há três conferências que valem a pena:

• Contagem. O total de registros por tabela no destino bate com a origem, descontados os que foram descartados de propósito e documentados.
• Amostra. Um grupo de registros, escolhido por quem conhece o processo, é comparado campo a campo entre os dois sistemas.
• Casos de borda. Os registros mais estranhos: os mais antigos, os mais longos, os com caracteres especiais, os que passaram por todas as etapas do fluxo.

Quem aprova a virada

Defina antes do ensaio o que significa "pronto": quais conferências precisam passar, com qual margem de diferença aceitável e quem assina. Esse critério de aceite, escrito antes, impede que a decisão seja tomada sob a pressão do dia.

Quando os dois sistemas precisam conviver

Nem toda migração cabe em um fim de semana. Em sistemas com muitos usuários, processos longos ou dependência de outros sistemas, a troca pode precisar acontecer por etapas, com o antigo e o novo rodando juntos por algum tempo.

O erro aqui é tratar a convivência como um estado provisório sem regras. Quando ninguém define o que cada sistema faz, as informações divergem e a equipe passa a conferir manualmente o que deveria estar sincronizado.

Por que a virada única nem sempre cabe

A virada única é mais simples quando o sistema pode ficar parado durante a troca. Deixa de servir quando o serviço não pode parar, quando há muitos módulos dependentes entre si ou quando as áreas precisam ser treinadas em momentos diferentes. Migrar por módulo, por unidade ou por tipo de registro reduz o risco de cada passo.

Qual sistema é a fonte da verdade em cada momento

Para cada tipo de dado, só um sistema pode ser o oficial em um dado momento. Os cadastros de pessoas podem já viver no sistema novo, enquanto os processos em andamento ainda estão no antigo. Escreva essa divisão e comunique a todos. Quem não sabe onde alterar um dado acaba alterando nos dois, ou em nenhum.

Sincronização e conflito

Se os dois sistemas trocam informação durante a convivência, decida como: em tempo real ou em lotes, em uma direção ou nas duas. A pergunta mais difícil é o que fazer quando o mesmo registro é alterado dos dois lados. Defina a regra antes (vale a alteração mais recente? a do sistema oficial? vai para revisão manual?), porque conflito sem regra vira dado errado sem ninguém perceber.

Esse tipo de troca entre sistemas é trabalho de integração de API, e merece desenho próprio, com teste, monitoramento e alguém responsável quando falhar.

Plano de volta: o item que ninguém quer escrever

O terceiro erro é o mais confortável: não escrever o plano de volta. Falar nele parece admitir que a migração pode dar errado. Na prática, é o contrário. Um plano de volta (o termo técnico é rollback) é o que permite à equipe seguir com mais segurança, porque o pior cenário deixa de ser improvisado.

Sem ele, o problema descoberto horas depois da virada obriga a escolher entre consertar tudo ao vivo ou aceitar o prejuízo.

O que significa voltar

Voltar não é só reativar o sistema antigo. É responder a perguntas concretas:

• quem decide voltar, e com base em qual sinal?
• como o sistema antigo é restaurado ao estado de antes da virada?
• o que aconteceu no sistema novo desde a virada, e o que será feito com esses registros?
• como as pessoas são avisadas?

A terceira pergunta é a que mais derruba planos. Se o sistema novo recebeu cadastros e alterações antes da decisão de voltar, esses dados precisam ir para o antigo, ou serão perdidos.

Ponto de não retorno

Existe um momento a partir do qual voltar deixa de ser viável, porque os dados já divergem demais ou outros sistemas passaram a depender do novo. Identifique esse ponto antes: até aqui voltamos, depois disso corrigimos para a frente. Assim a equipe não descobre, no meio do problema, que a porta já fechou.

Sistema antigo em modo leitura por um período

Uma prática comum é manter o sistema antigo ligado depois da virada, só para consulta, sem aceitar alterações. Ele serve para comparar dados, resolver dúvidas e dar tranquilidade enquanto o novo se estabiliza. Por quanto tempo depende do caso: do volume de dúvidas, do ciclo dos processos e do custo de manter o ambiente. Retenção e descarte de dados antigos são assunto para validar com o encarregado de dados ou o jurídico do órgão.

Checklist antes de desligar o sistema antigo

Antes da virada, confirme cada item:

• o responsável por decidir sobre dado duplicado ou incompleto está definido;
• as regras de limpeza estão escritas, seja na origem ou na carga;
• houve pelo menos um ensaio completo, com a duração da carga medida;
• contagem, amostra e casos de borda foram conferidos e documentados;
• o critério de aceite foi escrito antes e tem alguém que assina;
• está definido qual sistema é a fonte da verdade para cada tipo de dado;
• o plano de volta está escrito, com responsável e ponto de não retorno;
• o sistema antigo tem destino definido depois da virada.

Se algum item está sem resposta, a virada ainda não está pronta.

Migração faz parte do projeto, não vem depois dele

Na Evo Tech, a migração dos dados existentes e a integração com outros sistemas fazem parte do projeto de sistemas sob medida, e não de uma etapa à parte. Para entender como o pedido de migração entra na proposta, veja como orçar um sistema. E, se o escopo ainda não está claro, o levantamento de requisitos é o ponto de partida.