Google Cloud Rejeita o Big Bang de Mainframe por um Caminho de Migração Guiado por IA

O Google Cloud apresentou uma alternativa em quatro etapas às arriscadas migrações de mainframe, usando análise por IA, geração de código, conversão de dados e validação paralela antes da transição.

A proposta questiona uma escolha conhecida. As empresas podem continuar mantendo sistemas antigos ou tentar uma grande migração cujas dependências só se tornam visíveis depois que o trabalho começa. O Google argumenta que nenhuma das opções resolve o problema mais difícil: entender o que o sistema existente realmente faz.

Sua resposta conecta o Mainframe Assessment Tool, o Gemini CLI, o Mainframe Connector e o Dual Run em um processo contínuo. As equipes primeiro recuperam regras de negócio e dependências. Em seguida, desenvolvem aplicações em nuvem com base em requisitos revisados, movem os dados relevantes e comparam os dois ambientes sob cargas de trabalho reais.

Essa sequência faz disso mais do que outro anúncio de conversão de código. A principal disputa é entre a modernização iterativa e a migração big bang, não entre infraestrutura em nuvem e hardware de mainframe.

O Google também enfrenta alternativas consolidadas. A IBM está aplicando IA enquanto preserva um papel central para o IBM Z. A AWS promove um serviço agêntico que rastreia requisitos e código gerados até as fontes do mainframe. Cada fornecedor reconhece que a geração de código, por si só, não pode determinar se um sistema substituto está correto.

A questão crítica, portanto, não é se o Gemini consegue traduzir COBOL. É se o fluxo de trabalho conectado do Google consegue preservar décadas de comportamento de negócio oculto enquanto permite que as empresas se modernizem em partes gerenciáveis.

Google Cloud Transforma Quatro Ferramentas em um Caminho de Migração

A mudança importante é a conexão entre avaliação, geração, movimentação de dados e validação em produção.

A estrutura de modernização do Google começa com engenharia reversa. O Mainframe Assessment Tool examina código-fonte, estruturas de banco de dados, monitores de transações, configurações de agendadores e relações entre ativos.

Ele oferece suporte a programas COBOL, copybooks, jobs JCL, procedimentos, inclusões e artefatos relacionados. A ferramenta usa o Gemini para gerar resumos, especificações técnicas e regras de negócio propostas a partir desse material.

Regras de negócio são as políticas codificadas dentro de uma aplicação, como condições de elegibilidade, cálculos de juros ou decisões de roteamento de transações. Elas importam porque o comportamento observável de um programa antigo frequentemente vai além da documentação que sobreviveu.

O Google afirma que as equipes podem revisar, filtrar e validar regras extraídas antes de exportá-las. Esse ponto de controle humano diferencia a proposta de uma simples instrução para traduzir cada linha para Java ou outra linguagem moderna.

A avaliação também pode dividir um ambiente em domínios de negócio e unidades migráveis menores. Uma unidade migrável é uma coleção delimitada de programas, dados e dependências que pode ser movida em conjunto sem interromper serviços adjacentes.

Esse particionamento cria a base para um programa iterativo. Um banco pode isolar um fluxo de relatórios antes de mexer na autorização de pagamentos. Uma seguradora pode mover um serviço de processamento de documentos enquanto mantém a liquidação de sinistros no mainframe.

Após a avaliação, o Gemini CLI oferece suporte à engenharia direta. Isso significa que as equipes usam requisitos validados para planejar uma arquitetura de destino e gerar novo código, em vez de tratar a base de código antiga como o projeto de destino.

O fluxo de trabalho pode propor modelos de dados e serviços em Cloud Run, Google Kubernetes Engine, Compute Engine, BigQuery, Spanner, AlloyDB e Cloud SQL. Essas propostas ainda exigem revisão arquitetural, pois uma recomendação gerada não é uma decisão operacional.

O Mainframe Connector lida com outro problema frequentemente subestimado. Ele copia e converte dados de mainframe, incluindo registros codificados em EBCDIC, para formatos que os serviços do Google podem utilizar.

EBCDIC é uma codificação de caracteres associada a ambientes de mainframe da IBM. Convertê-la corretamente exige mais do que alterar a representação do texto, porque os registros podem conter decimais compactados, layouts de copybook e convenções específicas da aplicação.

O Dual Run completa o ciclo proposto. Ele executa cargas de trabalho no ambiente de mainframe existente e no ambiente de nuvem e, em seguida, compara os resultados antes da transição para produção.

O processo conectado muda onde as equipes depositam sua confiança. Em vez de confiar em uma conversão única, elas acumulam evidências ao longo da descoberta, revisão de regras, implementação, testes de dados e execução paralela.

Essa é a afirmação central do evento. O Google está apresentando a modernização como um sistema controlado de evidências, não como um único projeto de transformação.

Por Que a Modernização de Mainframes Não É um Trabalho de Tradução de Código

Uma conversão sintaticamente correta ainda pode reproduzir o sistema de negócio errado.

Grandes ambientes de mainframe raramente se comportam como coleções organizadas de aplicações independentes. Um job em lote noturno pode atualizar dados consumidos por uma transação online na manhã seguinte. Um copybook compartilhado pode moldar registros usados em várias unidades de negócio.

Algumas dependências vivem no código. Outras estão em agendadores, convenções de banco de dados, runbooks operacionais ou no conhecimento de funcionários que mantêm uma carga de trabalho há décadas.

Isso torna a tradução direta de código um modelo incompleto. Um modelo de linguagem pode produzir Java plausível a partir de uma rotina COBOL, mas não compreender por que essa rotina é executada depois de outro job. Ele também pode preservar uma lógica que a empresa já não deseja.

O risco oposto é igualmente sério. Uma substituição gerada pode simplificar um comportamento que parece redundante, mas que lida com uma exceção regulatória pouco comum. Essa falha pode surgir apenas durante uma transação rara ou um processo de fechamento trimestral.

O projeto de avaliação em primeiro lugar do Google tenta tornar essas relações inspecionáveis. Sua documentação afirma que a ferramenta produz árvores de chamadas, relatórios de dependências, resumos de regras de negócio e unidades migráveis propostas.

O sistema de avaliação também oferece suporte a um servidor MCP, que permite que agentes de IA consultem dados de avaliação por meio do Model Context Protocol. MCP é uma interface padrão para conectar modelos a ferramentas externas e contexto estruturado.

Essa arquitetura dá ao Gemini mais do que uma pasta de arquivos-fonte. Ele pode trabalhar com relações descobertas, especificações revisadas e regras de negócio vinculadas a um domínio específico da aplicação.

No entanto, um contexto mais rico não garante uma interpretação precisa. Especificações geradas podem omitir casos extremos, e a análise estática não consegue observar todas as dependências criadas por configuração em tempo de execução ou operações externas.

A revisão humana, portanto, continua fazendo parte do mecanismo. Especialistas do domínio devem decidir se uma regra de negócio proposta é válida, obsoleta, incompleta ou mal compreendida.

Isso cria uma restrição prática para empresas que enfrentam perda de pessoal. O fluxo de trabalho precisa de operadores experientes justamente quando seu conhecimento é mais difícil de substituir. A IA pode organizar a revisão deles, mas não pode recuperar retroativamente a memória institucional perdida.

A abordagem do Google também muda o propósito do código legado. Em vez de tratar cada instrução como algo a ser preservado, as equipes podem tratar o ambiente como evidência do comportamento de negócio pretendido.

Essa distinção favorece o redesenho nativo da nuvem. Um monitor de transações não precisa de uma contrapartida literal se um serviço gerenciado puder atender ao mesmo requisito revisado. Um processo em lote pode se tornar um serviço orientado a eventos quando as restrições de tempo e consistência permitirem.

No entanto, o redesenho amplia a carga de validação. Quanto mais a arquitetura de destino se afasta da implementação original, menos útil se torna a comparação linha a linha.

As equipes devem comparar resultados, efeitos colaterais, tempo, integridade dos dados e recuperação de falhas. É por isso que o Dual Run é central, e não opcional, na narrativa do Google.

A promessa não é uma tradução perfeita. É uma cadeia rastreável que vai da evidência legada às regras revisadas, à implementação gerada e à equivalência medida.

A Verdadeira Disputa É a Modernização Iterativa Contra o Big Bang

O argumento mais forte do Google é organizacional: unidades de migração menores limitam as consequências da incerteza.

Uma migração big bang concentra muitas suposições em uma única transição. As equipes devem entender dependências, transformar código, mover dados, testar interfaces, treinar operadores e preparar procedimentos de reversão em um escopo amplo.

Uma única dependência interpretada incorretamente pode atrasar todo o programa. Pior ainda, um defeito pode chegar à produção apenas depois que o ambiente original se tornou difícil de restaurar.

A modernização iterativa reduz esse raio de impacto. As equipes podem escolher um domínio delimitado, documentar suas relações, desenvolver uma implementação de destino e validá-la enquanto as cargas de trabalho vizinhas permanecem inalteradas.

Isso não torna a modernização simples. Muda a forma como a falha se comporta.

Um problema descoberto durante uma unidade de migração pode aprimorar as regras de avaliação para a unidade seguinte. Divergências em testes podem revelar comportamentos não documentados antes que a empresa se comprometa com uma transição mais ampla.

O Dual Run fornece a ponte operacional. O modelo de testes paralelos anterior do Google mantém o mainframe como sistema principal enquanto uma cópia em nuvem executa a mesma carga de trabalho como sistema secundário.

A saída da nuvem pode então ser comparada ao resultado estabelecido. Diferenças repetidas expõem defeitos na lógica transformada, na conversão de dados ou em suposições ambientais.

Isso é particularmente relevante para sistemas com alto volume de transações. Um teste unitário pode verificar um cálculo conhecido, mas não consegue reproduzir cada interação entre padrões de entrada reais, condições de agendamento e integrações posteriores.

A execução paralela fornece evidências mais amplas sem conceder imediatamente ao novo sistema autoridade de produção. As equipes podem definir limites de aceitação, investigar diferenças e repetir os testes antes de transferir a responsabilidade.

A contrapartida é a coexistência prolongada. Executar dois ambientes exige sincronização, monitoramento, controles de processamento duplicado e uma decisão clara sobre qual sistema é responsável por cada saída.

Os custos também podem se sobrepor durante a transição. O Google não elimina essa carga operacional. Ele argumenta que essa carga compra um caminho mais seguro para longe de um evento de tudo ou nada.

O modelo incremental também introduz questões de governança. As equipes precisam de regras para escolher unidades de migração e decidir quando uma aplicação demonstrou equivalência suficiente.

Elas devem rastrear quais regras de negócio foram aceitas, quem as aprovou, quais evidências de teste as sustentam e o que mudou após a validação. Sem esse registro, o trabalho iterativo pode criar um ambiente híbrido fragmentado.

A disciplina arquitetural importa aqui. Uma sequência de projetos isolados em nuvem pode reproduzir a complexidade do mainframe por meio de novos serviços, filas, bancos de dados e interfaces não documentadas.

As ferramentas do Google podem mapear e gerar artefatos, mas uma empresa ainda precisa de uma arquitetura de destino coerente. Ela também precisa de um plano de desativação para cada componente de mainframe substituído pela nuvem.

A abordagem tem sucesso quando a iteração produz simplificação cumulativa. Ela falha quando cada unidade migrada adiciona outra ponte permanente de volta ao ambiente legado.

É por isso que a disputa não é velocidade contra cautela. Um big bang apressado pode falhar de forma dramática, enquanto um programa incremental interminável pode falhar silenciosamente.

A medida significativa é a capacidade de negócio concluída. Cada unidade de migração deve alcançar uma operação de produção validada e eliminar a responsabilidade correspondente do legado.

Google Cloud Enfrenta IBM e AWS em Termos Diferentes

Os três fornecedores agora usam IA, mas diferem quanto a onde a carga de trabalho modernizada deve residir e como a equivalência é estabelecida.

A posição da IBM parte do valor contínuo do mainframe. Seu watsonx Code Assistant for Z oferece descoberta, explicação, refatoração, geração de código, otimização e transformação, mantendo o IBM Z como um ambiente de execução importante.

A IBM afirma que seu assistente consegue explicar COBOL, PL/I, REXX, Assembler e JCL. Ele também pode refatorar programas selecionados em serviços modulares ou transformar COBOL em Java orientado a objetos.

As ferramentas de modernização com IA da empresa incluem testes unitários automatizados para equivalência semântica. Esse termo significa que o novo código deve produzir o mesmo comportamento pretendido que o original, mesmo quando sua estrutura muda.

Esse caminho pode servir a empresas que desejam melhores práticas de desenvolvimento sem comprometer cada carga de trabalho com uma nuvem de hiperescala. Ele também permite que as equipes modernizem ao redor de um mainframe, em vez de tratar a plataforma como um prazo final.

A AWS adota uma posição mais próxima do destino em nuvem do Google, mas sua mensagem atual enfatiza execução agêntica e rastreabilidade. O AWS Transform for mainframe abrange avaliação, extração de regras de negócio, requisitos, geração de código, testes e implantação.

A AWS afirma que cada saída gerada pode ser rastreada, passando pelos requisitos, até o código-fonte original. Seu fluxo de trabalho agêntico também se integra a agentes de programação como o Kiro e a ambientes de desenvolvimento existentes por meio de protocolos abertos.

Essa rastreabilidade busca resolver a mesma lacuna de confiança do Dual Run do Google. Ela oferece aos revisores um caminho de auditoria que mostra a origem de um requisito ou componente gerado.

A diferenciação do Google está na combinação de avaliação contextual com conversão de dados e validação paralela no nível da carga de trabalho. O Gemini ajuda na compreensão e na geração, enquanto o Dual Run testa o comportamento em relação ao sistema operacional de referência.

Essas não são categorias de produtos claramente separadas. A IBM também oferece descoberta e testes. A AWS também afirma oferecer validação automatizada de equivalência funcional. Cada fornecedor está se expandindo por todo o ciclo de vida.

A pressão competitiva, portanto, passará a se concentrar em evidências de implementação. Os compradores precisam saber quais linguagens, agendadores, bancos de dados, sistemas de transação e formatos de dados cada fluxo de trabalho suporta em seu ambiente.

Eles também precisam distinguir a capacidade do produto da entrega de serviços. Programas de mainframe frequentemente envolvem integradores de sistemas, especialistas internos, especialistas dos fornecedores e anos de histórico de aplicações.

Nenhum modelo opera independentemente dessa estrutura de entrega. A IA pode reduzir a análise manual, elaborar especificações e gerar código, mas as decisões de integração continuam específicas de cada ambiente.

A dependência de fornecedor é outra consideração. Uma arquitetura gerada pode favorecer os bancos de dados, as plataformas de computação, os sistemas de monitoramento e os serviços de IA de um único provedor.

Esse alinhamento pode simplificar a implantação. Também pode elevar os custos de mudança quando uma empresa altera posteriormente sua estratégia de nuvem ou mantém cargas de trabalho em vários ambientes.

As empresas devem, portanto, avaliar artefatos, e não apenas demonstrações. Regras exportáveis, especificações legíveis, testes portáveis e aprovações rastreáveis são importantes além da transformação inicial.

O mercado está convergindo para a modernização assistida por IA. A concorrência ainda não resolvida diz respeito a onde os humanos verificam o trabalho, como os fornecedores medem a equivalência e qual plataforma detém o resultado.

O que o Fluxo de Trabalho de IA do Google Cloud Ainda Não Pode Garantir

O fluxo de trabalho reduz riscos específicos de migração, mas não estabelece que as regras de negócio geradas ou o código de destino estejam corretos.

A primeira incerteza surge durante a descoberta. A análise estática pode identificar relações no código-fonte e chamadas declaradas, mas o comportamento dinâmico pode depender de valores em tempo de execução, escolhas do operador ou sistemas externos.

Um resumo gerado por IA também pode parecer mais certo do que as evidências permitem. Revisores podem aprovar uma explicação clara por ser legível, mesmo quando ela omite uma ramificação pouco frequente.

Isso cria viés de automação, que ocorre quando as pessoas depositam confiança excessiva na recomendação de um sistema. Uma especificação bem elaborada pode aumentar esse risco porque oculta a ambiguidade presente no ambiente subjacente.

O próprio fluxo de trabalho do Google preserva uma etapa de revisão para regras extraídas. As empresas devem tratar essa etapa como um controle, e não como uma verificação administrativa.

A revisão precisa de responsáveis nomeados, evidências vinculadas e decisões explícitas. Uma regra deve ser marcada como aceita, rejeitada, revisada ou não resolvida antes de orientar o código gerado.

A segurança acrescenta outra camada. O Google afirma que o Mainframe Assessment Tool mantém os dados de avaliação coletados dentro de sua máquina virtual implantada. Sua documentação também afirma que o código-fonte é enviado para a Gemini Enterprise Agent Platform.

A mesma documentação declara que o modelo não é enriquecido com informações extraídas desse código. As organizações ainda precisam verificar controles regionais, políticas de acesso, comportamento de retenção e requisitos contratuais para suas cargas de trabalho.

Os testes também têm limites. O Dual Run pode detectar diferenças entre saídas observadas, mas a equivalência depende da cobertura e da qualidade da comparação.

Se ambos os ambientes receberem apenas transações comuns, casos raros permanecerão sem teste. Se a lógica de comparação ignorar tempo, ordenação ou efeitos colaterais posteriores, duas saídas podem parecer iguais enquanto os sistemas se comportam de maneira diferente.

Os testes paralelos também podem reproduzir um comportamento legado inadequado. Corresponder ao mainframe é útil durante a migração, mas não prova que toda regra herdada seja desejável ou esteja em conformidade com a política atual.

As equipes devem separar duas perguntas. A implementação em nuvem se comporta como a original, e o comportamento original deve ser preservado?

A segunda pergunta exige julgamento de negócio, jurídico, segurança e operações. A análise de código por si só não consegue respondê-la.

As alegações de desempenho também exigem evidências semelhantes às de produção. Um serviço gerado pode passar em testes funcionais enquanto cria latência inaceitável, consumo de infraestrutura ou contenção de banco de dados no volume de pico.

A recuperação operacional merece a mesma atenção. As equipes devem testar tentativas de repetição, falhas parciais, mensagens atrasadas, transações duplicadas e procedimentos de reversão antes de transferir a responsabilidade.

Por fim, o fluxo de trabalho não pode garantir a conclusão do programa. Uma empresa pode produzir excelentes avaliações e protótipos sem desativar uma única carga de trabalho de mainframe.

O sucesso exige critérios de saída para cada unidade de migração. Esses critérios devem abranger evidências funcionais, prontidão operacional, reconciliação de dados, aprovação de segurança, expectativas de custo e desativação efetiva do legado.

A estratégia do Google é mais segura porque torna a incerteza visível mais cedo. Ela não é segura apenas porque a IA participa.

O que Observar à Medida que o Google Cloud Passa do Método à Evidência

O próximo teste é saber se o método em etapas produz transições repetíveis para produção, e não apenas código gerado mais convincente.

O primeiro sinal são evidências de clientes vinculadas a unidades de migração concluídas. Os compradores devem procurar cargas de trabalho de produção identificadas que tenham passado por testes paralelos e transferido a responsabilidade pelo sistema de referência.

Um estudo de caso útil explicaria o escopo, os artefatos compatíveis, as dependências descobertas, a duração da validação, o tratamento das divergências e os componentes de mainframe finalmente desativados. Declarações gerais sobre análises mais rápidas revelam menos.

Transições repetidas fortaleceriam o argumento do Google de que o fluxo de trabalho escala além de uma aplicação cuidadosamente selecionada. Avaliações sem desativação em produção o enfraqueceriam.

O segundo sinal é uma rastreabilidade mais profunda em toda a cadeia de ferramentas. O histórico de versões do Google mostra trabalho contínuo em extração de regras de negócio, acesso MCP, cobertura de linguagens e análise de ambientes de grande porte.

O avanço importante conectaria cada regra aprovada à evidência no código-fonte, aos componentes gerados, aos testes, aos resultados de comparação e às aprovações humanas. Essa cadeia facilitaria a revisão durante auditorias e a manutenção posterior.

Ela também ajudaria as equipes a identificar onde um erro entrou no processo. Uma divergência poderia apontar para extração defeituosa, um requisito alterado, código gerado, dados convertidos ou a estrutura de validação.

Uma rastreabilidade clara fortaleceria o modelo iterativo porque o conhecimento se acumularia entre as unidades de migração. Artefatos fragmentados fariam cada unidade parecer um projeto separado.

O terceiro sinal é como IBM e AWS respondem com evidências comparáveis de validação. As listas de recursos já se sobrepõem, portanto os fornecedores precisarão mostrar como seus métodos lidam com dependências reais e transições difíceis.

A IBM pode argumentar que a modernização não exige abandonar o IBM Z. A AWS pode enfatizar a rastreabilidade do código-fonte à saída e os testes automatizados. O Google precisa provar que a avaliação contextual combinada ao Dual Run oferece uma fronteira de risco melhor.

Essa concorrência deve beneficiar os compradores empresariais. Ela desloca a discussão de demonstrações brutas de geração de código para evidências, governança, portabilidade e resultados concluídos.

Para líderes de tecnologia, a ação imediata não é aprovar uma migração de todo o ambiente. É selecionar um domínio significativo e testar toda a cadeia.

O domínio deve conter dependências reais e consequências de negócio sem se tornar um primeiro movimento irreversível. Sua avaliação deve incluir código, dados, agendas, interfaces e conhecimento operacional.

As equipes devem registrar quantas regras extraídas exigem correção, com que frequência os resultados paralelos divergem e quanto tempo cada divergência leva para ser resolvida. Essas métricas revelam mais do que o volume de código gerado.

Elas também devem decidir o que termina após uma transição bem-sucedida. Uma unidade de migração está incompleta se a carga de trabalho original, o ônus de licenciamento, o processo operacional e a responsabilidade de suporte permanecerem.

O Google Cloud oferece às empresas uma rota entre manutenção indefinida e um big bang perigoso. A rota é crível porque trata a modernização como descoberta, reconstrução e comprovação.

Seu valor dependerá de os clientes conseguirem repetir esse ciclo em ambientes complexos sem criar um labirinto híbrido permanente. As próximas transições para produção importarão mais do que a próxima demonstração gerada por IA.