Modernização de sistemas legados
Um método para substituir sistemas legados que sustentam operações reais: preservar as regras de negócio, transformar dados em contratos verificáveis e trocar de sistema com critérios de aceite e caminho de volta.
- Software Engineer / método autoral
- Capacidade de engenharia, não um projeto de cliente
- Dados, regras de negócio e transição operacional
- Contratos de dados · Migração repetível · Saneamento · Rastreabilidade · Reconciliação · Cutover · Rollback
Este registro descreve um método, não um projeto específico. Não identifica clientes nem inclui dados, estruturas, volumes, valores ou cronologia de operações reais.
Problema
Sistemas legados costumam sustentar operações que não podem parar: vendas, cadastros, financeiro e controles do dia a dia dependem deles, mesmo quando evoluir ou manter o sistema já se tornou difícil.
Substituir esse tipo de sistema não é apenas reescrever o software. A troca precisa preservar o comportamento de que a operação depende e manter a consistência dos dados do primeiro ensaio até a virada.
Tratar a migração como uma cópia de banco transfere os problemas do legado para o sistema novo e só os revela depois da virada, quando corrigi-los custa mais.
Contexto
Em sistemas legados, parte das regras está na estrutura dos dados; outra parte existe apenas no comportamento do sistema, em validações, cálculos e fluxos que a operação já trata como naturais.
Os dados acumulam o histórico da operação, inclusive registros incompletos, duplicados ou fora do padrão. Eles precisam ser saneados sem perder a capacidade de explicar de onde cada valor veio.
E os números que importam, principalmente os financeiros, precisam fechar entre origem e destino. Isso exige reconciliação, não apenas transferência.
Decisões
Contratos de dados antes da migração
Antes de mover qualquer dado, o destino declara o que aceita: formatos, obrigatoriedades, relações e regras de consistência. A migração passa a ser a tradução do legado para esse contrato, e não uma cópia da estrutura antiga.
Mais trabalho antes da primeira carga, e o contrato expõe cedo o que o legado não cumpre.
Migração repetível
A migração é construída como um processo que pode ser executado novamente durante ensaios e validações, em vez de depender de uma única carga. Uma correção encontrada na validação é aplicada ao processo e testada de novo, e não ajustada à mão no destino.
Exige mais disciplina e ferramentas de validação antes da virada. A migração passa a ser um processo a manter, e não uma operação pontual.
Saneamento rastreável
Correções nos dados são regras aplicadas pelo processo de migração, registradas e reexecutáveis, e não edições manuais no destino. Cada valor alterado mantém a ligação com a origem e com a regra que o alterou.
Cada correção vira uma regra a manter, em vez de um ajuste rápido.
Reconciliação como critério de aceite
Origem e destino são comparados antes de considerar a migração pronta. A migração não é aceita por ter terminado sem erro, mas por produzir no destino o que a origem mostra.
Dados financeiros recebem verificações próprias, além da reconciliação geral, porque inconsistências pequenas podem alterar saldos e resultados.
Cada divergência vira trabalho de investigação: é preciso entender se a diferença está no dado de origem, na regra ou na própria migração.
Regras implícitas tornam-se explícitas
O comportamento observado no legado é identificado e convertido em regras verificáveis do novo sistema. O que antes dependia de como o sistema antigo reagia passa a ser uma regra declarada, que pode ser testada.
Antes de reescrever, é preciso levantar o comportamento atual, inclusive o que não estava descrito em lugar nenhum.
Cutover com rollback planejado
A entrada em operação tem critérios de validação e um caminho de retorno enquanto o novo sistema não estiver definitivamente aceito. A virada é tratada como uma decisão com condições, e não como uma data.
Enquanto o novo sistema não é aceito, o legado precisa continuar recuperável, o que prolonga o período em que os dois sistemas importam.
Arquitetura
O método organiza a modernização em partes com responsabilidades separadas: de onde os dados vêm, que contrato precisam cumprir, como chegam, como são verificados e como a operação muda de um sistema para o outro. A descrição é conceitual e não corresponde a uma implementação específica.
- Origem legada
- O sistema que sustenta a operação. Permanece como referência dos dados e do comportamento esperado até o novo sistema ser aceito.
- Contratos de dados
- O que o destino aceita. Toda entrada é verificada contra o contrato antes de fazer parte da operação.
- Migração e saneamento
- Processo repetível que extrai, transforma, saneia e carrega os dados, registrando cada regra aplicada para que qualquer valor possa ser rastreado até a origem.
- Reconciliação
- Compara origem e destino, com verificações próprias para os dados financeiros, e aponta divergências para investigação antes do aceite.
- Sistema de destino
- Concentra as regras de negócio de forma explícita e testável, incluindo as que antes existiam apenas no comportamento do legado.
- Cutover e rollback
- Critérios para o novo sistema assumir a operação e caminho de retorno ao legado enquanto a transição não estiver definitivamente aceita.
Evidência e limites
Cada afirmação abaixo aponta para o que a sustenta e para o que ela não mostra. O que não tem evidência não aparece aqui como resultado.
O saneamento V1 do produto é somente leitura: em teste, o banco permanece idêntico byte a byte e nenhuma instrução diferente de SELECT é emitida.
- Conhecer a qualidade dos dados migrados sem alterar nada na origem nem no destino.
- A etapa de saneamento pós-migração só lê: aplica regras puras de validação e lista as ocorrências por tenant, sem corrigir nada por conta própria.
- Suíte do saneamento pós-migração, com dados criados pelos próprios testes, executada e aprovada. Verificada em teste em 16/10/2026 · Testes automatizados · repositório privado
- Cobre a detecção, não a aplicação das correções. Usa dados de teste e não descreve a migração de um sistema ou cliente real.
O perfilamento da origem não escreve nela, e a reconciliação de estoque detecta as divergências injetadas sem corrigi-las automaticamente.
- Saber se o destino contém o que a origem mostra, em vez de aceitar uma migração só porque terminou sem erro.
- A origem é perfilada em modo somente leitura. A reconciliação de estoque compara o ledger com o saldo e é testada com divergência e corrupção injetadas de propósito, para provar que detecta e não corrige sozinha.
- Suítes do motor de migração (bases sintéticas criadas nos próprios testes) e da reconciliação de estoque, executadas e aprovadas. Verificada em teste em 16/10/2026 · Testes automatizados · repositório privado
- Demonstrado em módulo, com dados sintéticos. Não é afirmação sobre a migração de um sistema ou cliente real, nem sobre o resultado de uma virada.
O que este registro não afirma
- É um método: este registro não descreve a migração de um sistema ou de um cliente específico, nem o resultado de uma virada real.
- A evidência é de módulo e com dados sintéticos: testes automatizados do produto sobre bases criadas pelos próprios testes.
Resultado e aprendizado
O que o método sustenta
Migração, saneamento e reconciliação deixam de ser etapas manuais e passam a ser partes verificáveis do trabalho, que podem ser ensaiadas quantas vezes for preciso antes da virada.
No ecossistema Orena, a mesma disciplina orienta a entrada de dados vindos de sistemas anteriores no Orena One: os dados chegam por contrato, são validados e só então passam a fazer parte da operação.
Aprendizado
Modernizar um sistema legado exige entender comportamento, não apenas estrutura de dados. A estrutura mostra o que é guardado; o comportamento mostra o que a operação espera.
Reconciliação é parte do produto de migração, não uma checagem posterior. Quando ela entra apenas no fim, as divergências são descobertas mais tarde, quando investigá-las tende a custar mais.
Regras implícitas precisam virar regras verificáveis antes da substituição do sistema. Enquanto existem apenas no comportamento do legado, não há como confirmar que o sistema novo as preserva.