Modernizar sistema legado sem substituí-lo
“Legado” não significa ruim. Significa que funciona, que acumulou durante anos regras que ninguém voltou a escrever em lugar nenhum, e que substituí-lo inteiro é um projeto com mais risco do que a empresa consegue absorver de uma vez.
Existe uma pessoa que sabe como aquilo funciona. Às vezes já nem trabalha mais aqui e é chamada quando algo quebra. O sistema não tem ambiente de testes, a documentação é um manual de oito anos atrás, e cada mudança é testada direto em produção às sete da manhã.
Por que a reescrita completa quase sempre dá errado
A proposta de refazer tudo é atraente porque promete acabar com o problema. Na prática exige manter dois sistemas em paralelo durante meses, redescobrir regras de negócio que só existem dentro do código velho e aguentar a pressão de um projeto longo sem entregas visíveis. A alternativa que funciona é chata: envolve-se o sistema antigo, coloca-se à frente dele uma camada que traduz, e vão-se retirando funções uma a uma. Cada passo entrega valor e é reversível. O sistema velho se apaga quando já não faz nada, não numa data marcada num plano.
Os fluxos que precisam ser resolvidos
Cada um com a decisão de projeto que define se aguenta produção.
Camada de tradução à frente
Constrói-se uma interface moderna que funciona como fachada. Os sistemas novos falam com ela e nunca com o legado, de modo que as esquisitices dele — códigos numéricos, campos com duplo significado, datas em formatos próprios — ficam encapsuladas num único lugar.
Sem essa camada, cada nova integração aprende as esquisitices do legado e as herda. Na terceira, já não dá para substituí-lo sem mexer em tudo.
Captura de mudanças em vez de consultas periódicas
Quando o legado não emite eventos, as mudanças são detectadas no banco de dados dele — por marca de tempo, por tabela de auditoria ou lendo o log de transações — e publicadas para fora como eventos.
Consultar a cada minuto um banco de produção castiga os usuários e descobre as mudanças tarde. E só com marca de tempo perdem-se as exclusões, que é justamente o que ninguém testa.
Substituição por partes
As funções saem do legado uma a uma, começando pelas que têm menos dependências e mais dor. A fachada decide a cada momento se uma requisição vai para o sistema novo ou para o velho.
Começar pelo módulo central porque “é o importante” é a forma mais rápida de o projeto parar na metade. Começa-se pelas bordas.
Quando não há nenhuma via de dados
Restam sistemas que só se deixam usar por tela. Aí cabem arquivos de intercâmbio numa pasta combinada, ou automação de interface como último recurso.
A automação de tela quebra com qualquer mudança visual e não dá garantia de transação. É uma solução-ponte com prazo de validade, e tem de ser tratada assim desde o primeiro dia.
O que você recebe
- ▪ Documentação das regras de negócio recuperadas do sistema antigo
- ▪ Camada de tradução com contrato de dados estável
- ▪ Publicação de mudanças para o resto do ecossistema
- ▪ Plano de substituição por fases, com ordem justificada e pontos de retorno
- ▪ Redução medida da dependência de pessoas específicas
Como construímos
Idempotência por padrão
Toda operação pode ser repetida sem duplicar nada. É o que permite reprocessar sem medo, e sem isso nenhuma integração sobrevive à primeira queda de rede.
Estado observável
Cada mensagem tem estado consultável: pendente, enviada, confirmada, falhada. Uma integração que só aparece quando falha já tinha falhado antes.
Um único dono por dado
Para cada campo há um sistema que manda e os outros obedecem. Sincronização bidirecional sem essa regra termina em loops e em dados que mudam sozinhos.
IA onde se decide, não onde se calcula
Classificar, extrair e redigir são tarefas de modelo. Somar, validar e encaminhar são tarefas de código. Trocar isso de lugar sai caro e fica impossível de auditar.
Como abordamos o problema
Quem diagnostica é quem constrói, sem hand-offs pelo caminho. O método completo e o resto das capacidades estão na página de integração de sistemas.
- 01 Diagnóstico · 3–5 dias
Mapeamos sistemas, fluxos de dados e dependências reais, inclusive as que ninguém documentou. Saída: escopo fechado e a lista do que hoje está quebrado.
- 02 Desenho da integração · 1 semana
Contratos de dados, direção da sincronização, política de retentativas e quem é dono de cada campo. Decide-se antes de escrever código porque é o caro de mudar depois.
- 03 Implementação e testes · 2–6 semanas
Construção com a casuística real, não com o caminho feliz. Testes contra os sistemas de verdade e implantação em fases.
- 04 Produção e observabilidade · contínuo
Painel de estado, alarmes quando algo passa tempo demais sem confirmação e manutenção das integrações quando as APIs de terceiros mudam.
Relacionado a este caso
O que costuma vir antes ou depois, com o motivo do link.
Radiografia Digital
O passo prévio obrigatório: sem saber o que o legado faz, qualquer plano de substituição é uma aposta.
Ver →APIs e webhooks
O que se constrói à frente do legado, uma vez que a camada de tradução existe.
Ver →Roadmap tecnológico
Para ordenar o que sai primeiro do sistema antigo e com que critério.
Ver →Radiografia de uma rede hoteleira
Um caso real de mapeamento de sistemas antigos e desconectados: mostra como se levanta o que existe, não como se reescreve.
Ver →Perguntas deste caso
Quando convém integrar e quando convém substituir? +
Integrar quando o sistema cumpre sua função e o problema é estar isolado, quando ele contém regras de negócio que ninguém documentou, ou quando a operação não pode se dar ao luxo de uma parada. Substituir quando o fornecedor desapareceu e não há quem mantenha, quando a tecnologia impede cumprir uma obrigação que não dá para resolver por fora, ou quando o custo de manter já supera o de refazer. A maioria dos casos reais é o primeiro, embora a conversa comece sempre pelo segundo.
Dá para integrar um sistema sem API nem documentação? +
Quase sempre sim, ainda que com mais trabalho e por caminhos menos elegantes: acesso de leitura ao banco de dados, detecção de mudanças, arquivos de intercâmbio ou — quando não sobra alternativa — automação de tela. O que decide a viabilidade não é a idade do sistema, é se existe alguma forma controlada de ler e de escrever. Isso é verificado no diagnóstico, e é a primeira pergunta que fazemos.
Quanto tempo leva? +
A camada de tradução e a primeira integração costumam estar em produção em quatro a oito semanas. A substituição completa, se a decisão for fazê-la, mede-se em trimestres e por desenho não tem uma data única de corte: cada função que sai é uma entrega em si mesma. Essa é justamente a vantagem frente à reescrita, não um efeito colateral.
E se a pessoa que conhece o sistema já não estiver? +
Então a primeira fase deixa de ser técnica e passa a ser arqueológica: as regras são reconstruídas a partir dos dados e do comportamento observado, não do código. É mais lento e convém dizer isso de antemão. É também a razão pela qual documentar o que se descobre é um entregável do projeto e não uma cortesia.
Comece pelo diagnóstico
Três a cinco dias para saber o que se conecta primeiro, com escopo e preço fechados antes de escrever uma linha de código.
Falar com um especialista ↗Outros casos