A Portaria SGD/MGI nº 5.395, publicada em 1º de julho de 2026, revisou as recomendações da Estratégia Nacional de Governo Digital para o ciclo de 2024 a 2027. Entre as diretrizes estão a construção de uma infraestrutura moderna, segura, escalável e robusta e a adoção de arquiteturas capazes de integrar e orquestrar serviços entre diferentes entes federados.

A diretriz aponta para o futuro, mas sua execução esbarra em uma contradição: o sistema que mais precisa ser modernizado costuma ser justamente aquele que a organização menos pode interromper.

Aplicações antigas ainda calculam benefícios, processam pagamentos, consolidam dados empresariais, movimentam estoques e registram operações essenciais. Algumas foram construídas quando a nuvem, os microsserviços e a automação de infraestrutura sequer faziam parte do vocabulário corporativo. Mesmo assim, continuam funcionando todos os dias e carregam regras de negócio acumuladas ao longo de anos.

Paulo Renan dos Santos Ferrari Bessa conhece esse impasse em diferentes camadas da infraestrutura. Sua trajetória reúne a migração de uma aplicação monolítica para microsserviços, a atualização de uma plataforma corporativa de dados e a troca da base operacional sobre a qual outros componentes dependiam.

O sistema antigo não pode simplesmente ser desligado

A palavra “legado” costuma ser usada como sinônimo de tecnologia ultrapassada, mas a idade, isoladamente, não determina o risco de uma aplicação. Um ambiente antigo pode permanecer estável e cumprir sua função. O problema surge quando ele deixa de receber atualizações, depende de profissionais difíceis de substituir, não suporta o crescimento da demanda ou impede a integração com ferramentas mais recentes.

Também existe um custo crescente para manter tecnologias fora do ciclo regular de suporte.

O Red Hat Enterprise Linux 7, por exemplo, saiu da fase normal de manutenção em 30 de junho de 2024. Desde então, instalações sem cobertura adicional não recebem novos pacotes regulares de correção de falhas e segurança. A Red Hat oferece um suporte estendido opcional e limitado para a versão 7.9 até maio de 2029, mas recomenda a migração para gerações mais recentes do sistema operacional.

A proximidade de uma data de fim de manutenção não significa que todos os servidores deixarão de funcionar de uma hora para outra. O risco é mais silencioso: o ambiente continua disponível, mas a capacidade de corrigir novas vulnerabilidades, falhas e incompatibilidades diminui.

Uma pesquisa global do IBM Institute for Business Value mostra como projetos de renovação tecnológica podem escapar do planejamento mesmo em organizações com grandes orçamentos.

O estudo ouviu mais de 500 diretores de tecnologia e quase 200 líderes de dados e inteligência artificial de bancos com ativos superiores a US$ 10 bilhões. Segundo o levantamento, 94% das iniciativas de modernização do núcleo bancário ultrapassaram os prazos planejados. Mais da metade dos executivos também relatou custos acima do previsto. 

Entre os fatores associados ao aumento das despesas, 53% dos entrevistados apontaram dificuldade para resolver dependências críticas durante a alteração do núcleo tecnológico. Outros 52% mencionaram a disponibilidade de profissionais com conhecimentos adequados de nuvem. Nos projetos plurianuais, 38% relacionaram os atrasos à complexidade subestimada e 37% à resistência organizacional à mudança. 

O levantamento está concentrado no setor bancário e não representa, isoladamente, todas as empresas ou instituições públicas brasileiras. Ainda assim, expõe uma característica recorrente das grandes migrações: a plataforma antiga raramente está sozinha.

Um sistema central pode alimentar relatórios, receber arquivos de parceiros, executar rotinas noturnas, consultar bases externas e enviar informações para aplicações que não aparecem na documentação original. Uma alteração aparentemente restrita pode alcançar processos que nenhuma equipe havia incluído no primeiro inventário.

Por isso, orientações técnicas da AWS recomendam que as ondas de migração sejam organizadas a partir dos grupos de dependência entre aplicações, bancos de dados e funções de negócio. O planejamento deve considerar quais componentes precisam ser transferidos juntos e quais equipes devem estar disponíveis durante a janela de mudança. 

Construir uma aplicação nova permite definir a arquitetura a partir de requisitos atuais. Renovar uma solução existente exige descobrir requisitos que já estão em produção, alguns documentados, outros preservados apenas na rotina das equipes.

Experiência em três camadas da transformação

O arquiteto de sistemas Paulo Renan dos Santos Ferrari Bessa vivenciou esse desafio em operações de naturezas diferentes. Na Dafiti, então vinculada ao Global Fashion Group, Paulo participou da migração de um monólito mantido em infraestrutura própria para uma arquitetura de microsserviços na AWS. Durante sua atuação na Semantix, trabalhou na atualização de uma plataforma corporativa de dados da Fiserv nos ambientes de desenvolvimento e homologação, recuperação de desastre e produção. No SPC Brasil, participou da transição do sistema operacional RHEL 7 para o RHEL 8.

As três experiências representam camadas distintas do legado: a aplicação monolítica, a plataforma de dados e o sistema operacional que sustenta outros componentes. Em cada uma delas, alterar uma peça exige conhecer as dependências que permanecem ao redor.

Além dessas experiências, o histórico de Paulo inclui atuação anterior com a Dataprev e, na data desta reportagem, o trabalho como Arquiteto de Sistemas Sênior na Spread, em projeto para a Caixa Econômica Federal. Essas passagens conectam sua trajetória ao debate sobre a modernização tecnológica de instituições que prestam serviços de grande alcance econômico e social.

Entrevista com Paulo Renan

Por que renovar um sistema existente costuma ser mais difícil do que construir outro do zero?

Paulo Renan: Em uma solução nova, a equipe começa com requisitos conhecidos e pode escolher a arquitetura de acordo com o objetivo atual. No legado, existem anos de regras de negócio, integrações e exceções acumuladas. Muitas vezes, parte desse conhecimento não está na documentação, mas na experiência das pessoas que mantêm o ambiente. O desafio é mudar a tecnologia sem perder um comportamento do qual a operação ainda depende.

Qual deve ser o primeiro passo antes de definir uma janela de migração?

Paulo Renan: O primeiro passo é mapear as dependências. É preciso saber quem consome e quem fornece dados, quais rotinas são executadas em determinados horários, quais equipes precisam participar e quais testes demonstram que o serviço está funcionando. Sem esse inventário, a janela é baseada em estimativa, não em evidência.

Por que o plano de rollback pode ser mais importante do que o próprio roteiro de execução?

Paulo Renan: O roteiro de execução mostra o caminho esperado. O rollback protege a operação quando a realidade se afasta desse caminho. A equipe precisa saber qual é o ponto de decisão, quanto tempo pode continuar tentando e como voltar sem perder dados. Uma migração não está pronta quando todos sabem avançar; ela está pronta quando também sabem interromper e retornar com segurança.

O que costuma dar errado nas grandes atualizações?

Paulo Renan: Os problemas mais perigosos geralmente estão nas dependências que não foram identificadas, na diferença entre os ambientes de teste e produção e em procedimentos que nunca foram ensaiados de ponta a ponta. Também existe a pressão para continuar depois que o tempo planejado terminou. Sem critérios objetivos, a equipe pode insistir em uma mudança e reduzir cada vez mais a margem disponível para a reversão.

É necessário substituir todo sistema antigo?

Paulo Renan: Não. A decisão precisa considerar criticidade, custo, segurança, frequência de mudança e valor para o negócio. Algumas aplicações podem ser mantidas com controles adequados; outras podem ser transferidas para uma plataforma suportada; e determinadas soluções precisam ser redesenhadas em etapas. Modernizar não significa reescrever tudo, mas retirar riscos e limitações de forma planejada.

O setor público enfrenta uma dificuldade diferente da iniciativa privada?

Paulo Renan: Existem exigências próprias, como prestação de contas, regras de contratação, proteção de dados e continuidade de serviços usados pela população. Nas grandes empresas, também há compromissos regulatórios, financeiros e operacionais. O ponto comum é que a tecnologia não pode ser alterada isoladamente: a transição precisa considerar pessoas, processos, integrações e o impacto de uma interrupção.

O que caracteriza uma migração realmente bem-sucedida?

Paulo Renan: Não é apenas concluir a virada dentro da janela. O novo ambiente precisa ser estável, documentado, operável e capaz de produzir sinais claros quando algo foge do comportamento esperado. Também é necessário verificar se a plataforma antiga pode ser desativada com segurança. Quando ela permanece funcionando indefinidamente por falta de confiança na substituição, parte do risco e do custo continua existindo.

A revisão da estratégia brasileira de governo digital estabelece uma direção, mas não elimina o impasse: serviços públicos e corporativos precisam evoluir enquanto aplicações antigas ainda processam dados, receitas e direitos que não podem esperar por uma reconstrução completa.

O estudo da IBM mostra que orçamento elevado e acesso à tecnologia não neutralizam dependências ocultas, complexidade subestimada ou resistência organizacional. A trajetória de Paulo Renan em uma migração de monólito, na atualização de uma plataforma de dados e na troca de um sistema operacional reúne três faces desse mesmo problema.

Modernizar com responsabilidade não é apagar o passado de uma vez, e sim construir o futuro sem desligar o presente antes da hora.