Migração de dados para um novo software: porque contamos os registos três vezes

Quando uma organização muda para um novo sistema, fala-se sobretudo das funcionalidades do novo sistema. Os ecrãs, os relatórios, a aplicação móvel. A forma de migrar os dados do sistema antigo costuma ficar para o fim, e despacha-se com um «fazemos uma transferência».

É aí que os projetos realmente encravam. O código funciona, os ecrãs estão prontos, mas parte dos registos de clientes chega incompleta e ninguém sabe quantos faltam nem porquê.

Neste artigo conto o que verificamos antes, durante e depois da migração.

Primeiro, o inventário

Não começamos a migração com a primeira linha de código, mas com uma lista. Que tabelas existem no sistema antigo, quantos registos tem cada uma, o que significa cada campo, qual deles já não é usado.

A surpresa mais frequente nesta lista é a mesma informação estar guardada em dois sítios. A morada do cliente está tanto na tabela de clientes como na tabela de faturas, e as duas não coincidem. Decidir qual se considera correta não é uma decisão técnica. É uma decisão da organização. É preciso perguntá-lo antes da migração.

A segunda surpresa é o sistema antigo ser um ficheiro Excel. No Excel, qualquer campo sem regras é um campo onde, um dia, alguém escreveu outra coisa «temporariamente». Aparecem linhas com «não há» na coluna da data e células com dois números na coluna do telefone.

Mapeamento de campos

Dois sistemas não guardam os dados da mesma forma. O sistema antigo pode ter um único campo «nome completo» e o novo ter dois campos separados. A cidade, que no sistema antigo era texto livre, pode ser escolhida de uma lista no novo.

Para cada campo escrevemos uma regra de mapeamento: o campo antigo, o campo novo e a conversão entre eles. Os registos que não cumprem a regra não são corrigidos em silêncio. Vão para uma lista à parte. Essa lista é revista com a organização, registo a registo.

A correção silenciosa parece tentadora, mas é a pior coisa que se pode fazer numa migração. Um registo errado já estava errado no sistema antigo. Se for corrigido por palpite durante a migração, passa a ser no novo sistema um registo que parece certo mas está errado. Ninguém voltará a dar por isso.

Contar três vezes

Quando a migração termina, para dizer que está «concluída», contamos os registos em três pontos.

O primeiro é a origem. O número de registos a migrar no sistema antigo, tabela a tabela.

O segundo é a transferência. O número de registos que o script de migração leu, converteu e separou para a lista à parte.

O terceiro é o destino. O número de registos realmente criados no novo sistema.

A origem tem de ser igual à soma dos transferidos com os separados. E os transferidos têm de ser iguais ao destino. Se estas duas igualdades não se verificam, a migração não terminou, por pequena que seja a diferença. Uma diferença de umas centenas de registos significa perder o histórico de umas centenas de clientes.

Os números baterem certo não chega por si só. Os números podem bater certo e o conteúdo estar corrompido. Por isso abrimos lado a lado, nos dois sistemas, registos escolhidos ao acaso e comparamo-los campo a campo. Para campos críticos, como montantes e datas, calculamos também à parte, dos dois lados, totais e valores de resumo.

Migração de teste e plano de reversão

Não fazemos a migração real pela primeira vez no dia real. Primeiro fazemos pelo menos duas migrações de teste com uma cópia dos dados. Em cada teste medimos o tempo, analisamos os registos separados e corrigimos as regras de mapeamento.

Antes da migração real, o plano de reversão fica por escrito. O que se faz se a migração ficar a meio ou se os números não baterem certo, até que ponto se pode voltar ao sistema antigo, quem toma essa decisão. Quando estas perguntas se fazem no dia da migração, as respostas são dadas à pressa.

Os dois sistemas juntos durante pouco tempo

Sempre que possível, depois de o novo sistema arrancar, o sistema antigo fica também disponível durante pouco tempo, só em modo de leitura. Se um registo parecer incompleto ou errado, é possível consultar o sistema antigo e comparar.

O fim desse período é definido desde o início. Se não for, os dois sistemas convivem lado a lado durante meses e volta a discutir-se qual deles está certo.

Não migrar também é uma decisão

Nem todos os registos antigos têm de passar para o novo sistema. Migrar dados cujo prazo de conservação expirou obriga a organização a continuar a guardá-los sem necessidade. No caso dos dados pessoais, isto pode ainda tornar-se uma violação de uma obrigação legal.

A migração é um bom momento para fazer esta triagem. Identificamos os registos cujo prazo de conservação expirou, deixamo-los fora da migração com a aprovação da organização e registamos a eliminação. Assim, o novo sistema começa limpo.

Em resumo

A migração de dados não é uma transferência. É um pequeno projeto. Uma migração feita sem inventário, mapeamento, contagem em três fases, migração de teste e plano de reversão faz o novo sistema perder a confiança logo no primeiro dia.