Todo projeto de sistema novo tem uma data que ninguém questiona em voz alta — e uma fase que costuma empurrar essa data. Não é o desenvolvimento, não é o teste integrado, não é o treinamento. É a conversão de dados: tirar o que existe no sistema antigo e colocar no novo de um jeito que o negócio reconheça como seu.

É a fase mais subestimada porque parece mecânica. Exportar, transformar, carregar. Na prática, cada coluna carrega uma decisão de negócio que ninguém documentou em vinte anos de operação, e a maioria dessas decisões só aparece quando a carga falha — ou pior, quando ela passa e o número sai diferente. A IA mudou a economia dessa fase, mas mudou onde é possível ganhar tempo, não onde é possível terceirizar responsabilidade.

Conversão não é tarefa técnica: é uma fila de decisões

Quando a conversão atrasa, o diagnóstico apressado é sempre o mesmo: “a extração está lenta” ou “a ferramenta é ruim”. Quase nunca é isso. O que trava é a fila de perguntas que ninguém consegue responder sozinho.

Qual é o saldo correto de um item que aparece em três lugares com valores diferentes? Aquele cliente cadastrado quatro vezes com grafias distintas é um cliente ou quatro? Documento aberto em 2011, sem movimento desde 2014 e sem baixa — vai? O campo livre onde o time começou a escrever o código do vendedor há oito anos vira o quê no modelo novo?

Nenhuma dessas perguntas é técnica. Todas dependem de alguém do negócio com autoridade para decidir e assumir o resultado. Por isso, o primeiro entregável de uma conversão bem conduzida não é um script: é a lista de decisões pendentes com dono e prazo. Enquanto ela não fecha, todo trabalho de carga é provisório.

O que realmente vai: escopo é a primeira economia

A pergunta que economiza mais dinheiro em conversão é também a mais impopular: o que não vai.

O reflexo do projeto é levar tudo — “por segurança”. Só que histórico convertido não é histórico de graça: ele precisa ser mapeado, limpo, carregado, validado e, depois, mantido. Cada ano extra de histórico multiplica o esforço das cinco etapas e, ainda por cima, engorda a base nova desde o primeiro dia.

Um escopo honesto costuma ter três camadas. Cadastro vai inteiro, mas depurado — cliente, fornecedor, material, plano de contas, centro de custo. Saldos vão na posição de corte, não movimento a movimento. Movimento histórico vai só onde existe obrigação legal ou uso operacional real; o resto fica consultável no ambiente antigo ou vai para arquivamento. É exatamente a mesma disciplina de archiving e volume de dados: decidir o que merece estar na base quente.

Quando o negócio entende que “não converter” não é “perder”, o escopo cai — e a fase inteira encolhe junto.

O de-para com IA: proposta, nunca veredito

O documento de de-para — campo da origem, campo do destino, regra de transformação — é o coração da conversão e, historicamente, semanas de planilha. É aqui que a IA muda a conta.

Com o esquema da origem, a documentação do destino e uma amostra real de dados, um assistente devolve em horas o que levava semanas: proposta de mapeamento campo a campo, justificativa de cada escolha, script de transformação, lista de valores que não encaixam em nenhum domínio do destino e as consultas de validação correspondentes. O ganho não é escrever mais rápido — é revisar em vez de redigir. Ler e corrigir mil linhas de proposta é muito mais barato do que produzi-las do zero.

Três usos rendem especialmente bem. Domínio de valores: a IA lê os valores distintos de um campo livre e propõe a classificação, revelando de quebra o que estava sendo usado fora do padrão. Deduplicação: em vez de comparação exata, comparação por similaridade de nome, endereço e documento, com pontuação — a IA sugere os grupos, o negócio confirma. Anomalia após a carga: apontar o que ficou estatisticamente estranho em relação à origem, que é onde erro de conversão se esconde melhor.

Limpeza acontece na origem — e antes

Existe uma tentação forte de limpar durante a carga, com regras no script de transformação. Funciona no primeiro ciclo e cobra caro depois: a regra vive só no código de conversão, ninguém do negócio a enxerga e, quando o dado chega errado no destino, a discussão é sobre a regra em vez de ser sobre o dado.

Limpar na origem é mais lento no começo e muito mais barato no fim. O cadastro duplicado é resolvido por quem é dono dele, com a decisão registrada onde o negócio consegue ver; o item sem classificação é classificado por quem sabe classificar. A conversão então carrega um dado que já é bom — e a validação passa a medir a carga, não a limpeza.

Vale uma regra prática: se a correção precisa de conhecimento de negócio, ela é da origem. Se é só formato — data, separador decimal, codificação de caracteres, tamanho de campo —, pode ser da transformação.

Validar em camadas, do barato para o caro

Conversão sem reconciliação é aposta com data marcada. Três camadas, nesta ordem, resolvem quase tudo.

1. Contagem — registros por objeto, origem contra destino, com a diferença explicada linha a linha. Barato, roda em todo ciclo e pega carga parcial e duplicação.
2. Totais que o negócio reconhece — saldo por conta, estoque por depósito, aberto por cliente. Esta é a camada que importa: se o controlador não reconhece o número, a conversão não está pronta, ainda que a contagem feche.
3. Amostragem dirigida às bordas — o maior valor, o mais antigo, o com mais casas decimais, o com acentuação, o com campo nulo, o registro que ninguém entende. Erro de conversão mora nas exceções, não na média.

Cada ciclo de carga precisa terminar com esse relatório assinado. Sem ele, a equipe descobre o problema no primeiro fechamento depois do go-live, que é o pior lugar possível para descobrir.

Ciclos de carga: ensaiar antes de valer

Conversão que roda uma única vez, no cutover, é aposta. O padrão que funciona é o oposto: vários ciclos completos antes da data real, cada um com escopo maior e mais gente do negócio olhando o resultado.

O primeiro ciclo mede a mecânica — tempo, ordem de dependência entre objetos, o que quebra. O segundo mede a qualidade, com o negócio reconciliando de verdade. O terceiro é ensaio de cutover cronometrado: começa e termina dentro da janela, com o mesmo pessoal e o mesmo roteiro que vão rodar no dia. Se o terceiro ciclo não cabe na janela, o problema é de cronograma, e essa é uma descoberta muito melhor de fazer três semanas antes do que na madrugada da virada.

Cada ciclo também melhora a origem: o que a validação reprova volta como tarefa de limpeza. É por isso que começar cedo compensa mesmo com escopo incompleto — o valor está no laço de correção, não na carga em si. Essa disciplina é a mesma que sustenta uma implementação de SAP sem sobressalto.

O que fica depois do go-live

Quando a conversão é bem feita, três coisas sobrevivem ao projeto e continuam valendo.

A rastreabilidade: para cada registro convertido, dá para dizer de onde veio e qual regra o transformou. Isso responde a auditoria e encerra em minutos a discussão de “esse número está errado” que, sem rastro, consome semanas.

As regras de qualidade: o que a validação da conversão testou vira verificação permanente. A base nova nasce com o critério de qualidade já definido, em vez de degradar em silêncio até a próxima migração.

E as decisões documentadas: o que ficou fora, por quê, onde consultar. Um ano depois, quando alguém perguntar por um documento de 2013, a resposta existe.

O limite honesto: a IA não converteu nada sozinha em nenhum projeto que conduzimos. Ela leu esquema, propôs de-para, gerou script e consulta, agrupou duplicados por similaridade e apontou anomalia depois da carga. As decisões que custam caro — o que é duplicado, o que pode arredondar, o que não precisa ir — continuaram sendo de gente que responde pelo dado. O que mudou é que essa gente passou a gastar o tempo decidindo, e não digitando planilha.

Para preparar essa fase, dois materiais da Inove Academy ajudam antes de começar. O guia rápido de migração para nuvem trata da mesma pergunta em outra escala — o que vai como está e o que merece redesenho antes de atravessar. E o e-book de implementação mostra por que a maioria dos problemas de projeto não é técnica, com a conversão de dados como exemplo recorrente.