Convencionou-se tratar a modernização de mainframe como sinônimo de migração. A lógica até parecia simples: quanto mais aplicações saíssem do ambiente legado, mais moderna seria a arquitetura.
O mercado começa a rever essa premissa.
O State of Mainframe Modernization 2025, da Kyndryl, ouviu 500 líderes de negócios e tecnologia e encontrou um cenário menos linear: 80% das organizações mudaram sua estratégia de modernização nos últimos 12 meses.
Ao mesmo tempo, 56% aumentaram o uso do mainframe, enquanto a parcela média de aplicações planejadas para sair da plataforma caiu de 36%, em 2024, para 28% em 2025.
Não significa que as empresas desistiram de cloud, replatforming ou arquiteturas distribuídas. Significa algo mais interessante: a modernização está deixando de ser uma discussão sobre destino tecnológico e passando a ser uma decisão sobre workload.
Migrar é uma das possibilidades de modernização, mas não é sua definição.
Um workload pode permanecer no IBM Z e ainda assim, ser profundamente modernizado por meio de APIs, novas interfaces, automação, práticas DevOps, integração com cloud e novas formas de acesso aos dados.
Da mesma forma, uma aplicação pode ser transferida para outra plataforma e continuar carregando processos ineficientes, dependências antigas e uma arquitetura difícil de manter.
Mover não significa necessariamente modernizar.
Essa distinção importa porque uma estratégia baseada em volume migrado tende a tratar aplicações muito diferentes como se tivessem o mesmo problema. Só que não têm.
Sistemas variam em:
criticidade para o negócio;
volume transacional;
necessidade de baixa latência;
dependência de dados e aplicações existentes;
exigências regulatórias;
frequência de mudança;
custo operacional;
integração com outros ambientes.
O workload que sustenta milhões de transações financeiras não deveria ser avaliado com os mesmos critérios de uma aplicação periférica de baixo volume.
Quando a estratégia começa pela plataforma de destino, essas diferenças aparecem tarde. Quando começa pelo workload, elas definem a decisão.
Ficar também pode ser uma decisão de modernização
O dado da Kyndryl é especialmente relevante porque mostra uma aparente contradição: enquanto muitas organizações continuam migrando parte de seus portfólios, 95% disseram que o uso do mainframe permaneceu estável ou aumentou no último ano.
A pesquisa também aponta que 56% dos workloads considerados mission-critical continuam rodando na plataforma.
Isso ajuda a desmontar uma leitura binária bastante antiga: mainframe ou cloud.
No dia a dia, a arquitetura empresarial atual é muito mais parecida com mainframe e cloud e APIs e dados distribuídos e aplicações digitais.
Não é caso de escolher um vencedor, mas de definir onde cada componente entrega a melhor combinação de performance, risco, custo, disponibilidade e capacidade de evolução.
Em alguns casos, isso significa migrar. Em outros, integrar. Em muitos, modernizar onde o workload já está.
A própria pesquisa da Kyndryl identifica esse movimento ao apontar o modelo híbrido como predominante e mostrar que organizações estão combinando modernização no próprio mainframe, integração com cloud e migração seletiva de aplicações.
Toda migração possui um business case explícito. O problema são os custos que costumam aparecer depois dele.
Mover uma aplicação crítica pode exigir reconstruir:
integrações;
controles de segurança;
mecanismos de disponibilidade;
lógica operacional;
processos de recuperação;
monitoramento;
conhecimento acumulado em décadas de operação.
Além disso, uma aplicação raramente existe sozinha.
Ela acessa dados, chama outros programas, participa de processos batch, responde a APIs e depende de comportamentos construídos ao longo do tempo. Quanto maior esse nível de acoplamento, maior a possibilidade de uma decisão aparentemente localizada produzir efeitos em outras partes da arquitetura.
É por isso que o custo correto da modernização não é apenas o custo da plataforma de destino.
É necessário incluir o custo de reconstruir o que já funcionava, operar a transição e manter as novas dependências depois dela.
Essa conta pode continuar favorecendo a migração, mas precisa ser feita antes de a migração virar objetivo por si mesma.
Ficar, integrar ou sair?
Uma estratégia mais pragmática começa classificando workloads antes de definir tecnologias.
Há pelo menos três caminhos.
1. Modernizar no mainframe
Faz sentido quando o workload depende fortemente das características do ambiente existente: grande volume transacional, proximidade com dados críticos, disponibilidade, segurança, integração profunda com outros sistemas do core ou requisitos específicos de performance.
Nesse caso, modernização pode significar abrir APIs, melhorar o ciclo de desenvolvimento, automatizar testes, evoluir interfaces, otimizar código e facilitar integração com o restante da arquitetura.
O sistema permanece. A forma de trabalhar com ele muda.
2. Integrar com novas plataformas
Em muitos casos, o valor está especificamente na combinação.
O mainframe continua realizando processamento transacional crítico enquanto cloud, analytics, IA ou novas aplicações digitais utilizam serviços e informações provenientes desse core.
O desafio passa a ser interoperabilidade, governança, observabilidade e capacidade de fazer esses ambientes funcionarem como uma arquitetura única para o negócio.
3. Migrar seletivamente
Existem workloads cujo business case favorece claramente outra plataforma.
Aplicações menos acopladas ao core, sistemas com requisitos diferentes de escalabilidade ou componentes cuja evolução está limitada pela arquitetura existente podem justificar replatforming, refatoração ou substituição.
Nesse caso, migrar é modernizar porque a mudança resolve um problema concreto.
A palavra-chave é seletivamente.
O workload certo depende de perguntas melhores
Antes de definir para onde uma aplicação vai, algumas perguntas são mais úteis do que discutir tecnologia.
Onde estão os dados de que ela depende? Mover processamento enquanto os dados continuam em outro ambiente pode criar latência, integrações adicionais e novos custos.
Qual é o impacto de indisponibilidade? Quanto maior o custo de uma interrupção, maior precisa ser o peso de resiliência e previsibilidade na decisão.
Quanto a aplicação precisa mudar? Um workload estável e altamente crítico pode exigir uma estratégia completamente diferente de uma aplicação em evolução constante.
Qual problema estamos tentando resolver? Custo? Time-to-Market? Escalabilidade? Skills? Integração? Experiência do desenvolvedor?
Sem uma resposta objetiva, a modernização corre o risco de virar uma troca de tecnologia em busca de um problema.
E qual é o custo de manter?
Essa pergunta também precisa existir. Defender uma análise mais criteriosa de migração não significa defender permanência automática. Workloads ineficientes, difíceis de manter ou incapazes de acompanhar o negócio também carregam custos que precisam ser enfrentados.
O ponto não é ficar, é escolher.
A arquitetura híbrida não é necessariamente uma etapa intermediária
Arquiteturas híbridas costumam ser apresentadas como uma fase de transição: manter parte do legado enquanto a migração completa não termina. Essa visão também está envelhecendo.
Os números da Kyndryl mostram organizações modernizando simultaneamente no mainframe, com o mainframe e fora dele, e relatando ROI nos três caminhos.
Dependendo da abordagem, os respondentes reportaram retornos entre 288% e 362% sobre suas iniciativas de modernização.
Isso sugere que não existe uma única arquitetura de chegada.
Para algumas organizações, um ambiente híbrido bem integrado não é uma etapa incompleta de modernização. É a arquitetura final mais racional.
O desafio deixa de ser eliminar plataformas diferentes e passa a ser reduzir a fricção entre elas.
Modernizar é tomar decisões melhores sobre o que já existe
O dado mais interessante da pesquisa da Kyndryl não é o aumento no uso do mainframe. É o fato de 80% das organizações terem mudado de estratégia em apenas um ano.
Isso mostra um mercado menos disposto a seguir roadmaps rígidos definidos cinco anos antes e mais disposto a reavaliar decisões conforme tecnologia, regulação, custos e necessidades de negócio mudam.
Em ambientes de missão crítica, isso é maturidade.
Modernização não deveria ser uma campanha para manter tudo no mainframe. Também não deveria ser uma campanha para tirar tudo dele.
É um processo contínuo de avaliar: o que fica, o que integra, o que muda e o que realmente precisa sair.
A experiência da Eccox em ambientes críticos parte dessa lógica. Antes de substituir arquitetura, é necessário entender dependências, riscos, custos e o papel que cada workload exerce dentro da operação.
A modernização mais cara nem sempre é aquela que exige maior investimento. Às vezes, é aquela que move o workload errado pelo motivo errado.
Se a estratégia da sua organização ainda mede progresso pela quantidade de aplicações que deixaram o mainframe, está na hora de mudar a métrica.
About Post Author
