Tempo estimado de leitura: 12 minutos
Toda instituição com sistemas legados precisa tomar uma decisão em cada um de seus sistemas: manter, isolar, modernizar ou substituir. Essa escolha direciona o capital dos próximos anos, define onde as equipes vão concentrar esforço e determina quanto risco a operação vai carregar durante a transição.
Cada caminho tem um custo diferente:
- Manter um sistema que já limita a operação adia o investimento e empurra o custo para o próximo incidente;
- Isolar sem definir claramente suas fronteiras pode apenas deslocar a complexidade para outras partes da arquitetura;
- Modernizar o legado sem medir dependências e acoplamento aumenta o risco de descobrir o escopo completo só depois que o projeto começou;
- Substituir um sistema que ainda cumpre seu papel consome capital sem criar vantagem competitiva.
Este artigo transforma essa decisão em critérios mensuráveis. Mostra quais indicadores apontam para manter, isolar, modernizar ou substituir cada sistema e como registrar a escolha para orientar investimentos, execução e governança.
Quais métricas revelam a dívida de um sistema legado
Avaliar um sistema legado vai além da mera impressão de obsolescência. Um sistema não é legado apenas porque a linguagem envelheceu, a equipe original saiu ou pela falta de documentação.
O peso do legado pode ser medido por dados da operação: custo e frequência de incidentes em produção, tempo para colocar uma nova funcionalidade no ar e taxa de retrabalho por falhas estruturais. Outro indicador é quanto a operação depende do conhecimento de poucas pessoas. Quando esse conhecimento fica concentrado, a ausência de uma pessoa pode travar a operação.
A diferença de percepção aparece nos dados. O relatório 2025 Architecture in Software Development, pesquisa independente encomendada pela vFunction, ouviu 629 lideranças e profissionais de tecnologia nos Estados Unidos e no Reino Unido. Entre lideranças executivas, 52% afirmam que a documentação de arquitetura corresponde ao que roda em produção. Entre profissionais de engenharia e arquitetura, esse número cai para 36%. Quem toma a decisão sobre o sistema pode estar trabalhando com uma visão diferente de quem lida com ele no dia a dia.
Isso, por si só, não significa que o sistema seja instável ou caro de operar. Idade tecnológica e dívida técnica são coisas diferentes. A idade é neutra. A dívida técnica passa a importar quando aumenta custos, reduz a velocidade de entrega ou eleva o risco da operação.
Por isso, a decisão precisa partir de métricas, não de percepção. Esses dados já costumam existir no ambiente: em ferramentas de integração contínua (CI), registros de incidentes e rateios de custo.
| Categoria | O que medir | Onde o dado já existe |
|---|---|---|
| Entrega | Frequência de deploy, lead time de mudança, tempo de recuperação de deploy falho, taxa de falha em mudança e taxa de retrabalho de deploy, as cinco métricas atuais de software delivery performance do DORA | Pipeline de CI e registro de release |
| Confiabilidade | Disponibilidade contra os SLOs acordados, MTTR, volume e severidade de incidentes atribuídos ao sistema | Ferramenta de incidente e painel de SLO |
| Risco estrutural | Blast radius (quantos sistemas param se este parar), número de integrações, concentração de conhecimento (bus factor), componentes fora de suporte, CVEs conhecidos | Mapa de dependências e inventário de versões |
| Economia | Custo anual de sustentação contra custo de evolução, licenciamento, infraestrutura, custo de especialista raro | Rateio de infraestrutura e alocação de time |
A transição acontece quando a dívida passa a consumir a capacidade de entrega. Mesmo sem reclamações explícitas, um sistema de baixo desempenho limita diretamente a velocidade do negócio.
Qual caminho cada perfil de sistema legado pede
O erro clássico reduz a decisão a refatorar contra reescrever. O isolamento merece figurar entre as opções reais, porque é a decisão mais frequente na prática.
- Manter: Continuar operando sem investimento de evolução. Indicado para sistema estável, comoditizado, com baixo custo de operação e sem demanda de mudança;
- Isolar: Encapsular o sistema atrás de uma interface com contrato de integração, limites e monitoramento, passando a integrá-lo por ali. Cabe a sistemas de valor alto expostos de forma arriscada, com grande raio de impacto a conter. Padrões estabelecidos para isso incluem encapsulamento, Strangler Fig Pattern e camada anticorrupção;
- Modernizar: Evoluir por etapas, com refatoração, replatform ou nova arquitetura de partes do sistema, preservando a operação. É a escolha para sistema que sustenta receita e precisa mudar com frequência;
- Substituir: Construir ou adquirir um sistema novo e desligar o atual. Justifica-se quando o legado bloqueia uma capacidade crítica que o negócio precisa oferecer e nenhuma evolução incremental entrega esse resultado.
A regra de ordenação é simples: escolher o caminho de menor risco que resolve o problema. A substituição tende a concentrar mais risco de execução e de transição, razão pela qual normalmente deve ser considerada depois das alternativas incrementais.
Para o caso extremo existe um limiar objetivo, proposto pela McKinsey em estudo com 50 CIOs de serviços financeiros e tecnologia (2020).
Quando a dívida técnica de uma área supera 50% do valor do ativo tecnológico dela, o risco e o custo dos sistemas atuais começam a superar o benefício, e a construção de um stack novo entra em discussão.
Tech debt: Reclaiming tech equity
O mesmo estudo recomenda evitar a abordagem de big bang, porque megaprojetos de TI concentram risco de execução e travam a capacidade de competir enquanto estão em curso.
Como ler os números e escolher entre isolar e substituir
| Leitura predominante | Caminho indicado |
|---|---|
| Métricas de entrega estáveis, custo baixo, nenhuma demanda de mudança | Manter |
| Valor alto, blast radius grande, necessidade de integrar sem reescrever | Isolar, começando pelas interfaces mais críticas |
| Receita dependente do sistema, lead time alto, mudança frequente exigida | Modernizar por etapas |
| Capacidade de negócio bloqueada, sem caminho incremental, componentes sem suporte | Substituir, com plano de transição e operação em paralelo |
| Dívida acima de metade do valor do ativo da área | Avaliar stack novo, com faseamento e sem big bang |
| Bus factor de um, sem runbook | Tratar o risco antes da arquitetura: runbook, redundância de conhecimento e monitoramento |
Quando resta um único especialista e nenhum runbook, o risco operacional supera qualquer argumento sobre qualidade de código. Esse risco entra no preço da decisão.
Sinais de que a modernização está dando resultado
Cada caminho tem sinal de acerto e sinal de erro. Acompanhar os dois evita que a escolha se transforme em projeto sem fim.
| Caminho | Sinal de acerto | Sinal de erro |
|---|---|---|
| Manter | Continua barato, estável e sem incidente atribuído | Vulnerabilidade crítica sem correção disponível |
| Isolar | Integrações novas entram sem tocar o núcleo | A camada de isolamento vira um segundo sistema a manter |
| Modernizar | Métricas DORA melhoram fatia por fatia | A migração estagna e a empresa opera dois sistemas por tempo indefinido |
| Substituir | O sistema novo assume tráfego sem indisponibilidade | Escopo cresce, o prazo escorrega e não existe caminho de rollback |
Por que agentes de IA mudam a urgência da modernização
A decisão de portfólio legado existe desde muito antes da IA agêntica. O que mudou é o custo de postergá-la.
A expectativa dominante vai na direção oposta. No mesmo levantamento, 65% acreditam que desenvolvimento acelerado por IA vai simplificar a arquitetura da empresa. O relatório conclui o contrário: código gerado rápido, sem decisão arquitetural por trás, acelera a fragmentação.
Coloque um agente para ler e escrever nesse sistema e ele herda tudo o que existe lá dentro: dependência que ninguém documentou, interface frágil, falha que acontece em silêncio. Na velocidade dele, e na escala dele.
Uma pessoa que conhece a mania do sistema contorna e segue. Um agente integrado sobre interfaces frágeis ou comportamentos implícitos tende a amplificar esses problemas: pode falhar, executar uma sequência inesperada ou produzir um resultado difícil de auditar.
A Gartner registra que integrar agentes a sistemas legados costuma ser tecnicamente complexo, com fluxos de trabalho interrompidos e modificações custosas (junho de 2025). O volume de iniciativas agênticas que não chegam à produção está mapeado em Como escalar agentes de IA em bancos.
As condições abaixo indicam que um sistema existente suporta exposição a agente com risco administrável
- Interfaces explícitas e versionadas, com contrato de integração, sem acesso direto ao banco de dados.
- Identidade máquina a máquina, com credencial de curta duração e menor privilégio.
- Operações críticas idempotentes ou protegidas por chave de idempotência.
- Limites transacionais claros, de modo que o agente não deixe o sistema em estado inconsistente.
- Log, métrica e tracing suficientes para auditar e reverter o que o agente fez.
- Dado acessível com governança e classificação definidas.
- Caminho de revogação rápida de credencial, com prazo acordado.
Sistema que falha nesses itens pede isolamento antes da exposição. A especificação do Model Context Protocol alerta que ferramentas expostas a agentes podem representar execução arbitrária de código e estabelece requisitos de consentimento e controle para sua invocação.
Portanto, encapsular um legado sem contrato de integração, autorização, limites operacionais e trilha de auditoria apenas desloca o risco para uma nova camada.
A camada de identidade e integração que esses agentes atravessam é o tema de Agentic Enterprise: identidade e integração de agentes de IA.
O custo de modernizar depois que o agente está em produção
| Caminho | Escopo do trabalho | O que para | Evidência exigida |
|---|---|---|---|
| Isolar a interface antes | Uma camada de integração, com contrato de integração e limites definidos | Nada em produção | Mapa de acoplamento do sistema |
| Pausar o projeto em produção | Retrabalho de arquitetura, com o agente já integrado | A iniciativa agêntica e os fluxos que ela toca | Investigação de incidente, com prazo de regulador |
O primeiro caminho consome tempo de planejamento. O segundo consome orçamento de execução, atenção de liderança e confiança do time no roadmap.
Como registrar a decisão de arquitetura para auditoria
Para que uma decisão de arquitetura suporte uma auditoria, ela deve registrar o sistema avaliado, as métricas e a data da análise, o caminho escolhido e o responsável pela execução. Sem esse histórico, a discussão se torna cíclica: a cada novo orçamento, as mesmas opiniões ressurgem sem qualquer dado novo para embasar o avanço.
Empresas que tratam a dívida técnica como um desafio de negócio adotam uma prática consolidada pela McKinsey: cada aplicação é vinculada aos seus custos operacionais e ao seu propósito estratégico. Assim, a decisão de investir, manter ou descontinuar um sistema fica formalmente registrada para cada ativo.
Perguntas frequentes
Isolar significa encapsular o sistema atrás de uma interface com contrato de integração e passar a integrar por ali, sem alterar o núcleo. Modernizar significa evoluir o próprio sistema por etapas, com refatoração, replatform ou nova arquitetura de partes dele. Isolamento contém risco; modernização muda o sistema.
As cinco métricas DORA para capacidade de entrega, cumprimento de SLO e MTTR para confiabilidade, blast radius e bus factor para risco estrutural, e custo de sustentação contra custo de evolução para economia. Idade, isolada, não indica nada.
Não. Idade tecnológica é neutra. O que pesa é dívida que afeta o negócio, medida em velocidade de entrega, confiabilidade, risco estrutural e custo.
Segundo a McKinsey, quando a dívida técnica de uma área supera 50% do valor do ativo tecnológico dela, risco e custo dos sistemas atuais começam a superar o benefício. O mesmo estudo recomenda faseamento em vez de big bang.
Porque o agente herda as dependências e os modos de falha do sistema que ele acessa. A Gartner registra que essa integração costuma exigir modificações custosas e interromper fluxos existentes. Decidir depois transfere o custo para a execução, quando corrigir é mais caro.
Seu desafio merece uma conversa estratégica
A prática de Modernização de Aplicações da TreeID conduz a revisão de arquitetura que produz essas métricas. Mapeamos acoplamento e dependências sistema por sistema. Avaliamos risco operacional contra o histórico real de incidentes. E entregamos o caminho de decisão registrado, com dono e critério, antes de qualquer iniciativa agêntica ser dimensionada.
Fontes
- vFunction. “2025 Architecture in Software Development Report: Rethinking the Role of Architecture”. 2025. Pesquisa independente encomendada pela vFunction, com 629 líderes e profissionais de tecnologia (315 nos Estados Unidos, 314 no Reino Unido).
- McKinsey & Company. “Tech debt: Reclaiming tech equity”. Outubro de 2020. Levantamento de julho de 2020 com 50 CIOs de empresas de serviços financeiros e tecnologia com receita acima de US$ 1 bilhão. Citado aqui pelo limiar de decisão e pela recomendação contra big bang, que permanecem referência na prática.
- Model Context Protocol. “Specification”. Documentação oficial do protocolo, 2026.
- Gartner. “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027”. Junho de 2025.
- Google Cloud. DORA, programa de pesquisa DevOps Research and Assessment.