Leonardo Peron4 min de leitura
Toda migração de sistema tem um documento que ninguém quer escrever e que decide se o projeto vai dar certo. Ele não tem nome bonito: é o de-para — uma tabela que diz, campo a campo, de onde cada informação sai no sistema antigo e onde ela entra no novo.
Projetos que pulam esse documento não descobrem o problema no de-para. Eles descobrem depois do cutover, com a operação já rodando no sistema novo e o antigo desligado.
O que precisa estar nele
Um de-para útil tem cinco colunas, e a quarta é onde mora o trabalho de verdade.
Origem. Tabela e campo no sistema antigo, com o tipo real do dado — não o
tipo que a documentação diz. Em legado, data_cadastro sendo texto livre é
mais comum do que se imagina.
Destino. Onde aquilo entra no sistema novo. Às vezes um campo vira dois; às vezes dois viram um.
Regra de conversão. O que acontece no meio: recortar, normalizar, converter unidade, trocar código por descrição. Escrita de forma que outra pessoa consiga executar sem perguntar.
O que fazer com o que não tem equivalente. A coluna mais importante. Sempre sobra dado no sistema antigo que não cabe em lugar nenhum no novo, e a decisão sobre ele é de negócio, não de tecnologia: descarta, guarda em campo livre, vira anexo, ou obriga a criar campo novo.
Quem aprovou. Nome e data. Sem isso, na primeira divergência depois da virada a discussão vira memória contra memória.
Quem precisa aprovar
Não é o time de TI. É quem opera.
A pessoa que usa o campo todo dia é a única que sabe que status = 7 significa
"aguardando retirada" desde 2019, mas significava "cancelado" antes disso — e
que os registros antigos nunca foram corrigidos. Esse tipo de informação não
está em documentação nenhuma. Está na cabeça de quem opera, e só sai de lá se
alguém perguntar.
Na prática: o de-para é escrito pelo time técnico e revisado, linha a linha, por um responsável de cada área que usa o sistema. É lento. É a parte do projeto que mais parece burocracia. E é a que evita o desastre.
Por que ele previne o desastre
Porque força a conversa difícil antes de ela custar caro.
Sem de-para aprovado, o time técnico decide sozinho o que fazer com o dado ambíguo — e decide pelo caminho tecnicamente razoável, que quase nunca é o comercialmente correto. O resultado aparece semanas depois: um relatório de faturamento que não bate porque metade dos pedidos antigos entrou com o status errado, e agora o dado de origem já não existe mais.
Com de-para aprovado, a mesma ambiguidade vira uma linha no documento, uma pergunta para a área e uma decisão registrada. Custa uma reunião. Sem ele, custa um reprocessamento — quando ainda é possível reprocessar.
O erro mais comum
Começar pelo que é importante.
A tentação é mapear cadastro de cliente, produto e pedido, deixar o resto para depois e ganhar tempo. O problema é que o campo esquecido costuma ser o que amarra dois cadastros — uma referência antiga, um código de origem, uma marca de lote. Quando ele falta, a relação entre os registros migrados se perde, e recuperar isso depois exige o sistema antigo ligado, que já foi desligado.
O inventário vem antes do recorte. Levanta-se tudo que existe, inclusive o que ninguém usa há anos, e só então se decide o que migra, o que fica em consulta e o que se descarta. Decidir sem o inventário completo é decidir sem saber o que se está descartando.
Quanto tempo leva
Numa operação de porte médio, entre uma e três semanas para escrever, mais uma para revisar com as áreas. Parece muito perto de um projeto de dois meses — e é exatamente por isso que costuma ser cortado.
A conta que raramente é feita: uma migração que precisa ser refeita custa o dobro do projeto inteiro, porque a segunda tentativa acontece com a operação já no sistema novo, gerando dado novo em cima do dado errado. O de-para é a parte mais barata do seguro.
Para uma noção de ordem de grandeza antes de pedir proposta, o estimador de prazo e time devolve uma faixa a partir do escopo. Não substitui diagnóstico, mas evita a conversa começar com expectativas distantes demais.