Integração de sistemas legados: como modernizar sem parar a operação

Modernizar um sistema legado sem interromper a operação exige substituí-lo em partes, com o sistema antigo funcionando até que cada função tenha um substituto testado. É o princípio do padrão strangler fig, descrito por Martin Fowler e documentado hoje nos guias de arquitetura da Microsoft e da AWS. A alternativa, reescrever tudo e trocar de uma vez, concentra o risco em um único dia de virada. O custo de não fazer nada também é alto: o Government Accountability Office (GAO), órgão de controle do Congresso dos Estados Unidos, calculou em 2025 que o governo federal americano gasta cerca de 80% do orçamento de TI, que passa de US$ 100 bilhões por ano, com operação e manutenção de sistemas existentes.

Por que sistemas legados são difíceis de substituir

O relatório GAO-25-107795, publicado em 17 de julho de 2025, é um retrato útil do problema, embora trate do governo americano. O GAO identificou os 11 sistemas legados mais necessitados de modernização, mantidos por 10 agências com missões de saúde, infraestrutura crítica, arrecadação e segurança nacional. Os sistemas foram classificados por 16 atributos, entre eles idade, risco de cibersegurança e custo de operação.

O diagnóstico:

8 dos 11 sistemas usam linguagens de programação ultrapassadas;
4 dependem de hardware ou software sem suporte do fabricante;
7 operam com vulnerabilidades de segurança conhecidas.

O dado mais revelador é o de execução. Das 10 modernizações que o GAO havia apontado como críticas em 2019, só 3 estavam concluídas em fevereiro de 2025. Quatro tinham conclusão prevista para os anos seguintes, duas para cinco anos ou mais, e uma não tinha prazo definido. Mesmo com orçamento e prioridade política, substituir sistemas centrais leva anos.

A situação é comum a governos e empresas: o sistema antigo concentra regras de negócio que ninguém documentou, está ligado a dezenas de outros sistemas e não pode parar. Por isso a estratégia de integração vem antes da estratégia de substituição.

O padrão strangler fig

O nome vem das figueiras-estranguladoras que Fowler observou em florestas de Queensland, na Austrália: a planta cresce em volta de uma árvore hospedeira até substituí-la por completo. Aplicado a software, o padrão cria um sistema novo em torno do antigo e transfere funções de forma incremental.

O Azure Architecture Center, da Microsoft, descreve o mecanismo central: uma fachada (façade) recebe todas as requisições dos clientes e decide, função por função, se encaminha para o sistema legado ou para o novo. No início, quase tudo vai para o legado. A cada entrega, uma rota passa para o sistema novo. Quando nada mais é roteado para o legado, ele pode ser desligado. Segundo a Microsoft, o padrão permite que a aplicação existente continue funcionando durante todo o esforço de modernização.

A AWS Prescriptive Guidance documenta o mesmo padrão para a migração de monólitos para microsserviços: extrair funcionalidades aos poucos, colocando proxies nos pontos em que outros sistemas dependem de serviços do monólito.

Três condições tornam o strangler fig viável:

É possível interceptar as chamadas ao sistema legado (por rede, API, fila ou interface de usuário).
As funções podem ser separadas em fatias com fronteira clara.
Existe uma forma de manter os dados consistentes enquanto os dois sistemas convivem.

Quando o legado é uma aplicação monolítica acessada só por terminal, sem nenhum ponto de interceptação, o primeiro projeto costuma ser justamente criar essa camada de acesso.

A camada anticorrupção

O segundo padrão essencial é a camada anticorrupção (anti-corruption layer, ACL). Ela vem do domain-driven design e resolve outro problema: evitar que o modelo de dados e as limitações do sistema antigo contaminem o desenho do sistema novo.

Segundo a documentação da Microsoft, a ACL é uma fachada entre a aplicação nova e a legada que traduz chamadas e formatos, de modo que o novo sistema não fique preso às dependências do antigo. A Microsoft cita serviços como Azure API Management e Azure Functions para implementar a tradução de protocolo. A AWS Prescriptive Guidance descreve a ACL como um adaptador que traduz a semântica do monólito para o microsserviço e observa que ela pode ser implementada inclusive dentro do próprio monólito, como uma classe.

Na prática, a ACL é o lugar onde se resolve, por exemplo, que o campo "COD_SIT = 3" do sistema antigo significa "contrato suspenso" no modelo novo. Sem essa tradução centralizada, cada serviço novo reinventa a conversão, e as inconsistências se multiplicam.

APIs como contrato de integração

A exposição de funções legadas por APIs é o terceiro elemento. Uma API bem definida separa quem consome o dado de como ele é armazenado, e permite trocar o sistema por trás sem alterar os consumidores.

O programa Conecta gov.br, do governo federal, mostra o efeito em escala. Em 2025, a plataforma processou mais de 1,1 bilhão de transações de dados entre órgãos públicos, segundo o Ministério da Gestão e da Inovação em Serviços Públicos (MGI). O programa reúne 299 órgãos federais que usam 53 APIs desenvolvidas com a Secretaria de Governo Digital e já alcança 20 estados. Minas Gerais usa 15 das 20 APIs disponibilizadas para entes estaduais. O MGI estima que a integração gerou redução de custos de cerca de R$ 6,31 bilhões em 2025 para cidadãos e administração pública, e de aproximadamente R$ 8 bilhões entre o início de 2023 e o primeiro semestre de 2025.

O ganho vem de substituir a troca manual de documentos e certidões por consultas automáticas entre sistemas, muitos deles antigos. Os sistemas de origem não precisaram ser reescritos para participar: bastou expor os dados por uma interface padronizada.

Comparação dos padrões

Padrão	Problema que resolve	Quando usar	Cuidado principal
Strangler fig	Substituir o legado sem virada única	Sistema grande, com funções separáveis	Não deixar a convivência se arrastar indefinidamente
Camada anticorrupção	Isolar o modelo novo do modelo antigo	Legado com dados e regras mal estruturados	A camada pode virar gargalo se concentrar lógica de negócio
API sobre o legado	Dar acesso padronizado a dados e funções	Muitos consumidores dependem do mesmo sistema	Versionamento e segurança das APIs
Reescrita completa	Recomeçar do zero	Sistema pequeno ou sem condições de manutenção	Risco concentrado na virada e regras perdidas

Passo a passo para modernizar sem parar

Inventarie o sistema legado: funções, integrações de entrada e saída, volumes de transação, janelas críticas e quem conhece as regras de negócio.
Classifique as funções por valor e risco. Comece por uma fatia de risco baixo e visibilidade alta, que prove o método sem ameaçar a operação.
Crie o ponto de interceptação: fachada, gateway de API ou camada de roteamento pela qual todas as chamadas passem.
Implemente a camada anticorrupção para traduzir modelos de dados entre o legado e o novo.
Defina a estratégia de dados durante a convivência: qual sistema é a fonte de verdade para cada entidade e como as alterações são sincronizadas.
Migre a primeira fatia e mantenha a possibilidade de reverter o roteamento para o legado em caso de falha.
Compare resultados dos dois sistemas em paralelo antes de desligar a função antiga, quando o processo permitir.
Meça a entrega de software com indicadores objetivos. O relatório DORA 2025, do Google Cloud, usa cinco métricas: frequência de implantação, tempo de espera para mudanças, tempo de restauração, taxa de falha de mudanças e a nova taxa de retrabalho, que mede quantas implantações são correções não planejadas.
Desligue formalmente cada parte do legado substituída, incluindo licenças, servidores e rotinas. Sem desligamento, o custo de manutenção dobra em vez de cair.

Erros comuns

O erro mais frequente é tratar a convivência entre sistemas como estado permanente. O strangler fig só reduz custo quando o legado efetivamente encolhe; se as rotas nunca migram, a organização passa a manter dois sistemas.

Outro erro é colocar regras de negócio dentro da camada de integração. A ACL deve traduzir, e não decidir. Quando ela passa a conter lógica própria, vira um novo sistema legado, desta vez sem dono.

Um terceiro ponto envolve o uso de ferramentas de IA para acelerar a modernização. O relatório DORA 2025 constatou que mais de 90% dos profissionais de tecnologia já usam IA no trabalho diário e que a adoção se correlaciona com maior vazão de entregas, mas também com mais instabilidade, incluindo mais falhas de mudança e retrabalho. A conclusão do estudo é que a IA amplifica a situação existente da equipe. Em projetos de legado, onde o conhecimento das regras é escasso, gerar código mais rápido sem testes de comparação com o sistema antigo aumenta o risco.

Por fim, subestimar o inventário. As integrações não documentadas, como exportações noturnas de arquivos ou acessos diretos ao banco de dados por outros sistemas, costumam aparecer só quando algo para de funcionar.

O que definir antes de começar

Antes do primeiro sprint, a organização precisa ter decidido o escopo da primeira fatia, a arquitetura do ponto de interceptação, a fonte de verdade de cada dado durante a convivência e os indicadores que vão medir o avanço. Com isso, a modernização passa a ser uma sequência de entregas pequenas e reversíveis, e o sistema antigo segue atendendo enquanto é substituído.

Integração de sistemas legados: como modernizar sem parar a operação

Por que sistemas legados são difíceis de substituir

O padrão strangler fig

A camada anticorrupção

APIs como contrato de integração

Comparação dos padrões

Passo a passo para modernizar sem parar

Erros comuns

O que definir antes de começar

Fontes

Artigos relacionados

Drex e Open Finance: o que vem depois do Pix e o status em 2026

Pix em números: 80 bilhões de transações e o que muda em 2026

5G no Brasil: cobertura, municípios e o que muda para empresas

Qual sistema sua empresa precisa?