Leonardo Peron5 min de leitura
A pergunta aparece tarde em quase todo projeto de troca de sistema, e quando aparece já custou dinheiro: quantos anos de histórico vão junto?
Ela costuma ser respondida por reflexo, com "tudo". É a resposta que parece segura e é a que mais encarece, porque o histórico é justamente onde mora a sujeira: a convenção que mudou no meio do caminho, o campo reaproveitado, o cadastro que ficou órfão quando uma filial fechou. Cada ano a mais não é só volume: é mais regra de conversão para escrever, mais ambiguidade para decidir e mais linha para conferir.
Não são dois destinos, são três
A discussão trava porque as pessoas enxergam duas opções: migrar ou perder. Existe uma terceira, e é ela que resolve a maior parte do impasse.
Migrar. O dado entra no sistema novo, com estrutura, e passa a ser operável: dá para filtrar, somar, ligar a um registro atual, corrigir.
Arquivar consultável. O dado sai da origem numa extração fiel (arquivo, base separada, o que couber) e fica disponível para consulta sem depender do sistema antigo ligado. Não é operável, e não precisa ser. Responde "o que aconteceu com o pedido tal naquele ano" em minutos, que é para o que ele vai ser usado.
Descartar. Base de teste que ficou, log de integração, importação que nunca foi usada, rascunho. Descartar exige decisão registrada, com nome de quem decidiu, não silêncio.
A conta muda de tamanho quando essa terceira coluna entra no de-para. Muito do que parecia obrigatório era obrigatório consultar, não obrigatório operar.
O que precisa migrar de verdade
Três categorias, e só três.
O que tem estado aberto. Contrato vigente, título a receber, garantia dentro do prazo, saldo de estoque, parcelamento em curso, chamado não encerrado. A idade do registro é irrelevante aqui: se ele ainda produz consequência, ele é operação, não histórico. Um contrato assinado há doze anos e vigente hoje precisa estar inteiro no sistema novo.
O que a operação consulta na rotina. E isso é mensurável, não opinável. O sistema atual costuma ter como responder: log de acesso, relatório de uso, ou uma consulta simples sobre a data dos registros abertos no último ano. Perguntar ao time "vocês olham dado antigo?" devolve sempre sim; medir devolve um número, e o número costuma ser bem menor que o sim.
O que a lei ou o contrato obrigam a manter acessível. Aqui não invente prazo: ele depende do tipo de documento e de quem responde por ele. Quem define é o contador, o jurídico e o contrato com o cliente. E a exigência deles pode ser atendida pelo arquivo consultável, o que sai muito mais barato do que migrar.
Os dois riscos, em espelho
Migrar tudo custa nas três frentes ao mesmo tempo. O de-para cresce, porque cada convenção antiga vira uma regra de conversão para escrever e aprovar. A conferência cresce, porque tudo que entrou precisa ser comparado com a origem, e é a reconciliação que prova que nada se perdeu, não o script que rodou sem erro. E o sistema novo nasce com a sujeira antiga dentro: o cliente duplicado de dez anos atrás volta a aparecer na busca.
Migrar só o ano corrente custa em lugares menos óbvios, e todos aparecem depois da virada. A comparação com o mesmo período do ano anterior morre no primeiro mês. O cliente antigo vira cliente novo, e toda régua de relacionamento erra junto. E o pior: qualquer corte por data pega ciclo no meio. Um contrato antigo, com parcela vencendo agora, fica partido entre dois sistemas, e nenhum dos dois consegue mostrar o saldo certo.
A regra do corte: por estado, não por data
É a decisão que mais economiza trabalho e quase nunca é tomada explicitamente.
Data de corte só se aplica ao que já está encerrado. O que está aberto vai junto, inteiro, com o histórico que ele precisa para fazer sentido: não adianta migrar o contrato sem as parcelas já pagas dele, porque o saldo não fecha e alguém vai ter que remendar à mão.
Na prática vira uma frase por entidade: "pedidos encerrados antes de tal data vão para o arquivo consultável; pedido com qualquer pendência vai migrado, com todos os movimentos dele". Escrita assim, ela é executável por quem escreve o script e conferível por quem opera, que são as duas condições de uma regra de migração que sobrevive à revisão.
Como levantar isso em uma tarde
Para cada entidade principal (cliente, pedido, contrato, produto, título), três números:
Quantos registros existem, por ano. Quantos estão em estado aberto, independentemente do ano. E quantos foram lidos ou alterados nos últimos doze meses.
A terceira coluna é a que decide, e é a que ninguém tem. Ela costuma mostrar que a cauda longa é bem mais fina do que a intuição diz, e é dessa diferença que sai a redução de escopo.
Monte essa tabela antes da próxima reunião de escopo. O mapeador de de-para resolve a primeira passada dos campos, e o estimador de prazo e time mostra o efeito do recorte na faixa de esforço, mas nenhum dos dois decide: quem decide é quem responde pelo dado, e é por isso que essa conversa acontece antes da primeira linha de script, junto com o resto do método de migração.
Decidido o recorte, ele ainda precisa ser testado antes de valer. Rodar os dois sistemas em paralelo por um ciclo é o que revela o dado que ficou de fora e fazia falta, enquanto voltar atrás ainda é barato.