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.