Modernização de sistemas legados: como decidir o que substituir e em que ordem

Os bancos brasileiros preveem aplicar R$ 50,4 bilhões em tecnologia ainda em 2026, segundo a Pesquisa Febraban de Tecnologia Bancária, conduzida pela Deloitte com 25 instituições que respondem por 85% dos ativos do sistema financeiro, e esse orçamento cresceu 58% em cinco anos.  

Entretanto, o que esses valores não mostram é quanto desse investimento é destinado para plaraformas que já estavam em produção antes de a maior parrteO que a cifra não mostra é quanto desse dinheiro sustenta plataformas que já estavam em produção antes de a maior parte dessas iniciativas existir, e que continuam processando as transações do dia a dia. 

Essa é a tensão que define a agenda de infraestrutura de boa parte das empresas brasileiras, dentro e fora do setor financeiro. O orçamento cresce, a lista de projetos novos cresce junto, e uma fatia que ninguém consegue reduzir permanece presa à manutenção de sistemas que funcionam, entregam o resultado esperado e não podem parar, mas que travam qualquer mudança que dependa deles. 

A modernização desse conjunto não costuma começar por uma decisão técnica tomada em reunião de arquitetura. Esse processo começa quando um projeto de negócio esbarra em uma integração que não existe, quando o fornecedor anuncia o fim do suporte de uma versão ou quando a pessoa que entendia determinado módulo se aposenta, e a empresa descobre que a documentação nunca foi escrita. 

O que caracteriza um sistema legado 

Sistemas legados não se definem pela idade do código, e essa confusão atrapalha a priorização. Um sistema com 15 anos de operação, documentado, com testes automatizados, interfaces bem definidas e uma equipe que sabe alterá-lo com segurança, é um ativo maduro. Outro com 5 anos, escrito sob pressão de prazo, sem documentação e com regras de negócio espalhadas por procedimentos de banco de dados, já nasce com as características que tornam a mudança cara e arriscada. 

A principal característica que define o legado é o acoplamento entre as partes, e ele aparece em sinais concretos. A regra de negócio fica embutida na camada de apresentação, outros sistemas leem diretamente as tabelas em vez de consumir uma interface e rotinas noturnas dependem da ordem de execução de arquivos. Nesse arranjo, qualquer alteração se propaga para pontos que ninguém mapeia antes de mexer, e uma pequena mudança pode ocasionar até mesmo a paralisação de todo o sistema.  

A concentração de conhecimento agrava esse quadro e costuma ser o que trava a manutenção no dia a dia. Sistemas antigos dependem de poucas pessoas que entendem as exceções, as gambiarras históricas e as razões pelas quais determinado campo não pode ser alterado.  

Esse conhecimento quase nunca está escrito, e a saída de um profissional transforma uma manutenção trivial em um projeto de arqueologia. A dificuldade se agrava quando a tecnologia é pouco ensinada hoje, o que estreita o mercado de quem pode assumir a sustentação. 

A situação de suporte fecha o conjunto de características que tornam um sistema difícil de sustentar. Versões fora do ciclo de manutenção do fabricante deixam de receber correções de segurança, e isso muda a natureza do risco: o sistema continua funcionando igual, mas cada vulnerabilidade descoberta a partir dali permanece aberta. Em ambientes sujeitos à Lei Geral de Proteção de Dados, operar com software sem correção enfraquece a demonstração de que a empresa adotou medidas de segurança adequadas, exigência estabelecida no art. 46 dessa lei. 

Por que a modernização de sistemas legados entrou na pauta dos gestores 

A pressão mais imediata vem do modelo de consumo do software corporativo, que mudou de lugar. O Relatório Setorial 2025, Macrossetor de TIC, publicado pela Brasscom, registra que quase 30% das implementações de ERP já ocorrem em modelo de software como serviço. A atualização da plataforma central de gestão deixou de ser projeto interno e passou a seguir o calendário do fornecedor. Empresas que mantêm versões customizadas em servidores próprios descobrem que as customizações são justamente o que impede a migração. 

A adoção de nuvem exerce a mesma pressão por outro caminho e atinge as aplicações que nasceram em outro contexto. O mesmo relatório aponta que a nuvem teve a maior taxa de crescimento entre os segmentos do mercado interno de TIC, com alta de 35,5% e R$ 85 bilhões.  

Boa parte desse movimento consiste em levar para a nuvem cargas que não foram desenhadas para ela. Sistemas acoplados ao sistema operacional, a caminhos fixos de arquivo ou a bibliotecas antigas não se movem sem alteração, e é nesse ponto que o projeto de migração vira projeto de modernização. 

Há ainda a pressão de integração, que costuma ser a mais visível para as áreas de negócio. Segundo o indicador G2 da pesquisa TIC Empresas 2025, do Cetic.br, feita com 4.174 empresas com dez ou mais funcionários, 36% das organizações usavam ERP, proporção que chega a 76% entre as que têm 250 ou mais funcionários. Cada iniciativa de comércio digital, de análise de dados ou de automação depende de conversar com esse núcleo, e a ausência de interfaces transforma cada integração nova em um trabalho sob medida, que se soma à dívida existente. 

O custo de manter sistemas legados em operação 

A parcela do orçamento consumida pela sustentação é o custo mais fácil de enxergar e o mais difícil de reduzir. Equipes que passam a maior parte do tempo atendendo chamados, corrigindo rotinas que falham e aplicando ajustes pontuais não estão disponíveis para projetos novos, e a empresa acaba contratando capacidade adicional para entregar o que a capacidade existente não alcança. 

Os custos de licenciamento e de infraestrutura formam a segunda camada, e ela cresce sozinha. Versões antigas de banco de dados e de sistema operacional costumam exigir suporte estendido, cobrado à parte e com valor crescente a cada renovação.  

O hardware compatível com essas versões sai das matrizes de compatibilidade dos fabricantes, o que empurra a empresa para equipamentos fora de linha ou para contratos de manutenção especiais. 

O custo menos contabilizado de todos é o de oportunidade, e ele aparece no calendário do negócio. Quando uma integração leva quatro meses porque depende de alterar um sistema que ninguém quer tocar, o projeto que dependia dela é adiado ou entregue por fora.  

A saída informal costuma ser uma planilha ou um sistema paralelo, que resolve o problema imediato e acrescenta mais um ponto de acoplamento ao ambiente. Esse padrão explica por que ambientes legados costumam vir acompanhados de uma camada informal de sistemas departamentais que ninguém governa. 

Caminhos de modernização de sistemas legados 

Nem toda aplicação precisa do mesmo tratamento, e a decisão começa por classificar o portfólio. As opções vão de aposentar a aplicação e retê-la como está até  a troca de plataforma, a recompra por uma solução de mercado e a refatoração completa.  

Aposentar aplicações é o caminho mais barato e o que costuma ficar de fora da discussão. Inventários de portfólio costumam revelar aplicações que sobrevivem por inércia, com poucos usuários ativos e função já coberta por outro sistema, e desligá-las reduz custo de licença, de infraestrutura e de superfície de ataque sem esforço de desenvolvimento. Reter também é uma decisão legítima, desde que consciente: um sistema estável, isolado e sem demanda de mudança pode ficar como está enquanto a energia vai para o que trava o negócio. 

Quando a substituição é necessária, a reescrita completa é o caminho de maior risco. A viabilidade dessa convivência depende de encontrar as junções do sistema, que são os pontos nos quais é possível interceptar uma chamada e redirecioná-la para a implementação nova sem que o resto perceba.  

Quando essas junções não existem, o trabalho inicial da modernização é criá-las, expondo por interface o que hoje é acessado diretamente, e essa etapa costuma ser a que menos aparece no cronograma e a que mais determina o sucesso do restante. 

Dados e integrações na modernização de sistemas legados 

A parte mais difícil de mover não é o código, e sim o dado. Sistemas antigos acumulam décadas de registros com regras que mudaram no meio do caminho, campos reaproveitados para finalidades diferentes, valores preenchidos por convenção e não por validação, e histórico que o negócio precisa manter por obrigação legal. Levar isso para um modelo novo exige decidir o que migra, o que fica em uma base de consulta e o que é descartado, decisão que nunca é apenas técnica. 

A convivência entre as duas versões durante a transição cria o problema de manter os dados coerentes nos dois lados. Enquanto parte das operações grava no sistema antigo e parte no novo, é preciso definir qual é a fonte de verdade para cada informação, como a sincronização acontece e o que fazer quando ela falha. Projetos que subestimam essa etapa costumam descobrir o problema em fechamento contábil, quando os dois sistemas apresentam números diferentes para a mesma pergunta. 

As integrações existentes precisam do mesmo mapeamento antes de qualquer corte, já que são o ponto mais frágil da transição. O levantamento se faz observando as conexões de rede dos servidores ao longo de um período que cubra as rotinas mensais e o fechamento contábil, porque dependências acionadas uma vez por mês não aparecem em uma medição de poucos dias. Em ambientes legados, esse trabalho costuma expor consumidores que a área de TI não sabia que existiam, como relatórios departamentais, planilhas que consultam a base diretamente e rotinas de parceiros que leem as tabelas sem passar por nenhuma interface. 

O licenciamento entra na conta pelo mesmo motivo e costuma ser descoberto tarde demais. Bancos de dados e sistemas operacionais que acompanham a aplicação legada seguem regras próprias quando a carga sai do servidor físico para a nuvem, porque a base de contagem muda. O que era licenciado por processador físico passa a ser contado por unidade virtual de processamento, e a equivalência entre as duas medidas varia conforme o fabricante do software e o provedor escolhido. Levantar essas condições antes de definir o destino de cada carga evita que a economia projetada desapareça já na fatura seguinte. 

Como a Faiston apoia a modernização de sistemas legados 

Sustentar o que está em produção enquanto o novo é construído exige capacidade em duas frentes ao mesmo tempo, e é essa simultaneidade que costuma faltar em equipes internas dimensionadas para a operação. A Faiston atua nas duas pontas. Os serviços de banco de dados administram, ajustam desempenho e conduzem a migração das bases que sustentam as aplicações antigas, e os serviços de middleware mantêm e evoluem as camadas de integração que ligam esses sistemas ao restante do ambiente. 

Para os projetos de transição, a alocação de especialistas por meio de professional services permite reforçar o time com quem já conduziu migrações semelhantes, sem que a empresa precise contratar em definitivo um perfil que será necessário apenas durante o percurso. Quando a modernização envolve mudar a infraestrutura que hospeda o sistema, a jornada para cloud cobre a avaliação de adequação, o gerenciamento da migração e a otimização posterior. 

A decisão de modernizar sistemas legados tende a ser adiada enquanto tudo funciona, e a conta aparece no momento em que o negócio precisa de algo que o ambiente atual não entrega. Empresas que tratam o portfólio como um conjunto a ser classificado, com aplicações a aposentar, a manter, a migrar e a substituir aos poucos, chegam a esse momento com um plano em andamento. Se a sua empresa está nesse ponto, fale com a Faiston para avaliar por qual ponto começar.