Google Cloud rechaza el big bang de mainframe en favor de una ruta de migración guiada por IA

Google Cloud ha presentado una alternativa de cuatro etapas para las arriesgadas migraciones de mainframes, que utiliza análisis de IA, generación de código, conversión de datos y validación en paralelo antes de la transición.

La propuesta cuestiona una elección habitual. Las empresas pueden seguir manteniendo sistemas obsoletos o intentar una gran migración cuyas dependencias solo se hacen visibles una vez iniciado el trabajo. Google sostiene que ninguna de las dos opciones aborda el problema más difícil: comprender qué hace realmente el sistema existente.

Su respuesta conecta Mainframe Assessment Tool, Gemini CLI, Mainframe Connector y Dual Run en un único proceso continuo. Los equipos primero recuperan reglas de negocio y dependencias. Después crean aplicaciones en la nube basadas en requisitos revisados, trasladan los datos relevantes y comparan ambos entornos con cargas de trabajo reales.

Esa secuencia hace que esto sea más que otro anuncio de conversión de código. La competencia principal es entre la modernización iterativa y la migración big bang, no entre la infraestructura en la nube y el hardware de mainframe.

Google también se enfrenta a alternativas consolidadas. IBM está aplicando IA mientras preserva un papel central para IBM Z. AWS promueve un servicio agéntico que rastrea los requisitos y el código generados hasta sus fuentes de mainframe. Cada proveedor reconoce que la generación de código por sí sola no puede determinar si un sistema de reemplazo es correcto.

Por tanto, la cuestión crítica no es si Gemini puede traducir COBOL. Es si el flujo de trabajo conectado de Google puede preservar décadas de comportamiento empresarial oculto mientras permite a las empresas modernizarse en partes manejables.

Google Cloud convierte cuatro herramientas en una sola ruta de migración

El cambio importante es la conexión entre evaluación, generación, movimiento de datos y validación en producción.

El marco de modernización de Google comienza con ingeniería inversa. Mainframe Assessment Tool examina código fuente, estructuras de bases de datos, monitores de transacciones, configuraciones de planificadores y relaciones entre activos.

Admite programas COBOL, copybooks, trabajos JCL, procedimientos, inclusiones y artefactos relacionados. La herramienta utiliza Gemini para generar resúmenes, especificaciones técnicas y reglas de negocio propuestas a partir de ese material.

Las reglas de negocio son las políticas codificadas dentro de una aplicación, como condiciones de elegibilidad, cálculos de intereses o decisiones de enrutamiento de transacciones. Son importantes porque el comportamiento observable de un programa antiguo suele superar la documentación que ha sobrevivido.

Google afirma que los equipos pueden revisar, filtrar y validar las reglas extraídas antes de exportarlas. Ese punto de control humano distingue la propuesta de una simple instrucción de traducir cada línea a Java u otro lenguaje moderno.

La evaluación también puede dividir un patrimonio tecnológico en dominios de negocio y unidades migrables más pequeñas. Una unidad migrable es una colección delimitada de programas, datos y dependencias que pueden trasladarse juntos sin interrumpir servicios adyacentes.

Esta partición crea la base de un programa iterativo. Un banco podría aislar un flujo de generación de informes antes de abordar la autorización de pagos. Una aseguradora podría trasladar un servicio de procesamiento de documentos mientras mantiene la liquidación de siniestros en el mainframe.

Tras la evaluación, Gemini CLI admite la ingeniería directa. Esto significa que los equipos utilizan requisitos validados para planificar una arquitectura de destino y generar código nuevo, en lugar de tratar la base de código antigua como el diseño objetivo.

El flujo de trabajo puede proponer modelos de datos y servicios en Cloud Run, Google Kubernetes Engine, Compute Engine, BigQuery, Spanner, AlloyDB y Cloud SQL. Estas propuestas aún requieren revisión arquitectónica, porque una recomendación generada no es una decisión operativa.

Mainframe Connector aborda otro problema que suele subestimarse. Copia y convierte datos de mainframe, incluidos registros codificados en EBCDIC, a formatos que pueden utilizar los servicios de Google.

EBCDIC es una codificación de caracteres asociada a los entornos de mainframe de IBM. Convertirla correctamente exige más que cambiar la representación del texto, porque los registros pueden contener decimales empaquetados, diseños de copybooks y convenciones específicas de cada aplicación.

Dual Run completa el ciclo propuesto. Ejecuta cargas de trabajo en el entorno de mainframe existente y en el entorno de nube, y luego compara sus resultados antes de la transición a producción.

El proceso conectado cambia dónde depositan su confianza los equipos. En lugar de confiar en una conversión única, acumulan evidencia a lo largo del descubrimiento, la revisión de reglas, la implementación, las pruebas de datos y la ejecución en paralelo.

Esa es la afirmación central del evento. Google presenta la modernización como un sistema controlado de evidencia, no como un único proyecto de transformación.

Por qué la modernización de mainframes no es un trabajo de traducción de código

Una conversión sintácticamente correcta aún puede reproducir el sistema empresarial equivocado.

Los grandes patrimonios de mainframes rara vez se comportan como colecciones ordenadas de aplicaciones independientes. Un trabajo por lotes nocturno puede actualizar datos consumidos por una transacción en línea a la mañana siguiente. Un copybook compartido puede estructurar registros utilizados por varias unidades de negocio.

Algunas dependencias residen en el código. Otras están en planificadores, convenciones de bases de datos, manuales operativos o el conocimiento de empleados que han mantenido una carga de trabajo durante décadas.

Eso hace que la traducción directa de código sea un modelo incompleto. Un modelo de lenguaje puede producir Java plausible a partir de una rutina COBOL y, aun así, pasar por alto por qué esa rutina se ejecuta después de otro trabajo. También puede preservar una lógica que la empresa ya no desea.

El riesgo opuesto es igual de grave. Un reemplazo generado podría simplificar un comportamiento que parece redundante, pero que gestiona una excepción regulatoria poco habitual. Ese fallo podría aparecer solo durante una transacción infrecuente o un proceso de cierre trimestral.

El diseño de Google, que prioriza la evaluación, intenta hacer inspeccionables esas relaciones. Su documentación indica que la herramienta genera árboles de llamadas, informes de dependencias, resúmenes de reglas de negocio y unidades migrables propuestas.

El sistema de evaluación también admite un servidor MCP, que permite a los agentes de IA consultar datos de evaluación mediante Model Context Protocol. MCP es una interfaz estándar para conectar modelos con herramientas externas y contexto estructurado.

Esa arquitectura ofrece a Gemini más que una carpeta de archivos fuente. Puede trabajar con relaciones descubiertas, especificaciones revisadas y reglas de negocio vinculadas a un dominio de aplicación concreto.

Sin embargo, un contexto más rico no garantiza una interpretación precisa. Las especificaciones generadas pueden omitir casos límite, y el análisis estático no puede observar todas las dependencias creadas mediante configuración en tiempo de ejecución u operaciones externas.

Por tanto, la revisión humana sigue formando parte del mecanismo. Los expertos en la materia deben decidir si una regla de negocio propuesta es válida, obsoleta, incompleta o malinterpretada.

Esto crea una restricción práctica para las empresas que enfrentan la pérdida de personal. El flujo de trabajo necesita operadores experimentados precisamente cuando su conocimiento es más difícil de reemplazar. La IA puede organizar su revisión, pero no puede recuperar retrospectivamente la memoria institucional perdida.

El enfoque de Google también cambia el propósito del código heredado. En lugar de tratar cada instrucción como algo que debe preservarse, los equipos pueden considerar el patrimonio como evidencia del comportamiento empresarial previsto.

Esta distinción respalda el rediseño nativo de la nube. Un monitor de transacciones no necesita un equivalente literal si un servicio gestionado puede satisfacer el mismo requisito revisado. Un proceso por lotes podría convertirse en un servicio orientado a eventos cuando las restricciones de tiempo y consistencia lo permitan.

Sin embargo, el rediseño amplía la carga de validación. Cuanto más se aleja la arquitectura de destino de la implementación original, menos útil resulta la comparación línea por línea.

Los equipos deben comparar resultados, efectos secundarios, tiempos, integridad de datos y recuperación ante fallos. Por eso Dual Run es central, en lugar de opcional, en la propuesta de Google.

La promesa no es una traducción perfecta. Es una cadena rastreable que va desde la evidencia heredada hasta las reglas revisadas, la implementación generada y la equivalencia medida.

La verdadera competencia es entre la modernización iterativa y el big bang

El argumento más sólido de Google es organizativo: las unidades de migración más pequeñas limitan las consecuencias de la incertidumbre.

Una migración big bang concentra muchas suposiciones en una única transición. Los equipos deben comprender dependencias, transformar código, mover datos, probar interfaces, capacitar a operadores y preparar procedimientos de reversión en un ámbito amplio.

Una dependencia mal interpretada puede retrasar todo el programa. Peor aún, un defecto puede llegar a producción solo después de que el entorno original se haya vuelto difícil de restaurar.

La modernización iterativa reduce ese radio de impacto. Los equipos pueden elegir un dominio delimitado, documentar sus relaciones, crear una implementación de destino y validarla mientras las cargas de trabajo vecinas permanecen sin cambios.

Esto no simplifica la modernización. Cambia la forma en que se comporta el fallo.

Un problema descubierto durante una unidad de migración puede mejorar las reglas de evaluación para la siguiente unidad. Las discrepancias en las pruebas pueden revelar comportamientos no documentados antes de que la empresa se comprometa con una transición más amplia.

Dual Run proporciona el puente operativo. El anterior modelo de pruebas en paralelo de Google mantiene el mainframe como sistema principal mientras una copia en la nube ejecuta la misma carga de trabajo como sistema secundario.

La salida de la nube puede compararse entonces con el resultado establecido. Las diferencias repetidas revelan defectos en la lógica transformada, la conversión de datos o las suposiciones sobre el entorno.

Esto es especialmente relevante para sistemas con un alto volumen de transacciones. Una prueba unitaria puede verificar un cálculo conocido, pero no puede reproducir todas las interacciones entre patrones de entrada reales, condiciones de programación e integraciones posteriores.

La ejecución en paralelo aporta evidencia más amplia sin otorgar inmediatamente al nuevo sistema autoridad de producción. Los equipos pueden establecer umbrales de aceptación, investigar diferencias y repetir pruebas antes de transferir la responsabilidad.

La contrapartida es una coexistencia prolongada. Ejecutar dos entornos requiere sincronización, supervisión, controles de procesamiento duplicado y una decisión clara sobre qué sistema es propietario de cada resultado.

Los costes también pueden superponerse durante la transición. Google no elimina esa carga operativa. Sostiene que esa carga compra una ruta más segura que un evento de todo o nada.

El modelo incremental también introduce cuestiones de gobernanza. Los equipos necesitan reglas para elegir unidades de migración y decidir cuándo una aplicación ha demostrado una equivalencia suficiente.

Deben hacer seguimiento de qué reglas de negocio fueron aceptadas, quién las aprobó, qué evidencia de pruebas las respalda y qué cambió después de la validación. Sin ese registro, el trabajo iterativo puede crear un patrimonio híbrido fragmentado.

La disciplina arquitectónica importa aquí. Una secuencia de proyectos aislados en la nube puede reproducir la complejidad del mainframe mediante nuevos servicios, colas, bases de datos e interfaces no documentadas.

Las herramientas de Google pueden mapear y generar artefactos, pero una empresa aún necesita una arquitectura de destino coherente. También necesita un plan de retirada para cada componente de mainframe sustituido por la nube.

El enfoque tiene éxito cuando la iteración produce una simplificación acumulativa. Fracasa cuando cada unidad migrada añade otro puente permanente hacia el patrimonio heredado.

Por eso la competencia no es velocidad frente a cautela. Un big bang apresurado puede fracasar de forma espectacular, mientras que un programa incremental interminable puede fracasar silenciosamente.

La medida significativa es la capacidad empresarial completada. Cada unidad de migración debe alcanzar una operación de producción validada y eliminar la responsabilidad heredada correspondiente.

Google Cloud se enfrenta a IBM y AWS en condiciones distintas

Los tres proveedores usan ahora IA, pero difieren en dónde debería residir la carga de trabajo modernizada y cómo se establece la equivalencia.

La posición de IBM parte del valor continuo del mainframe. Su watsonx Code Assistant for Z admite descubrimiento, explicación, refactorización, generación de código, optimización y transformación, al tiempo que mantiene IBM Z como un entorno de ejecución importante.

IBM afirma que su asistente puede explicar COBOL, PL/I, REXX, Assembler y JCL. También puede refactorizar programas seleccionados en servicios modulares o transformar COBOL en Java orientado a objetos.

Las herramientas de modernización con IA de la empresa incluyen pruebas unitarias automatizadas para la equivalencia semántica. Ese término significa que el nuevo código debe producir el mismo comportamiento previsto que el original, incluso cuando su estructura cambie.

Esta vía puede adaptarse a empresas que buscan mejores prácticas de desarrollo sin comprometer todas las cargas de trabajo con una nube de hiperescala. También permite a los equipos modernizar en torno a un mainframe, en lugar de tratar la plataforma como una fecha límite.

AWS adopta una posición más próxima al destino en la nube de Google, pero su mensaje actual hace hincapié en la ejecución agéntica y la trazabilidad. AWS Transform for mainframe abarca evaluación, extracción de reglas de negocio, requisitos, generación de código, pruebas y despliegue.

AWS afirma que cada resultado generado puede rastrearse, a través de los requisitos, hasta el código fuente original. Su flujo de trabajo agéntico también se integra con agentes de programación como Kiro y con entornos de desarrollo existentes mediante protocolos abiertos.

Esa trazabilidad aborda la misma brecha de confianza que Dual Run de Google. Ofrece a los revisores una ruta de auditoría que muestra de dónde procede un requisito o componente generado.

La diferenciación de Google radica en combinar una evaluación contextual con la conversión de datos y la validación paralela a nivel de carga de trabajo. Gemini ayuda a comprender y generar, mientras que Dual Run prueba el comportamiento frente al sistema de registro.

No son categorías de productos claramente separadas. IBM también ofrece descubrimiento y pruebas. AWS también afirma ofrecer validación automatizada de equivalencia funcional. Cada proveedor está ampliando su oferta a lo largo de todo el ciclo de vida.

Por tanto, la presión competitiva se desplazará hacia la evidencia de implementación. Los compradores necesitan saber qué lenguajes, planificadores, bases de datos, sistemas transaccionales y formatos de datos gestiona cada flujo de trabajo en su entorno.

También deben distinguir la capacidad del producto de la prestación del servicio. Los programas de mainframe suelen involucrar integradores de sistemas, expertos internos, especialistas del proveedor y años de historial de aplicaciones.

Ningún modelo opera independientemente de esa estructura de prestación. La IA puede reducir el análisis manual, redactar especificaciones y generar código, pero las decisiones de integración siguen siendo específicas de cada entorno.

La dependencia del proveedor presenta otra consideración. Una arquitectura generada puede favorecer las bases de datos, plataformas de cómputo, sistemas de monitorización y servicios de IA de un proveedor.

Esa alineación puede simplificar el despliegue. También puede elevar los costes de cambio cuando una empresa modifica posteriormente su estrategia de nube o mantiene cargas de trabajo en varios entornos.

Por tanto, las empresas deberían evaluar los artefactos, no solo las demostraciones. Las reglas exportables, las especificaciones legibles, las pruebas portables y las aprobaciones trazables importan más allá de la transformación inicial.

El mercado converge hacia la modernización asistida por IA. La competencia sin resolver se refiere a dónde verifican el trabajo las personas, cómo miden los proveedores la equivalencia y qué plataforma se queda con el resultado.

Lo que el flujo de trabajo de IA de Google Cloud aún no puede garantizar

El flujo de trabajo reduce riesgos específicos de migración, pero no establece que las reglas de negocio generadas o el código de destino sean correctos.

La primera incertidumbre aparece durante el descubrimiento. El análisis estático puede identificar relaciones de código fuente y llamadas declaradas, pero el comportamiento dinámico podría depender de valores en tiempo de ejecución, decisiones de operadores o sistemas externos.

Un resumen generado por IA también puede sonar más seguro de lo que permite su evidencia. Los revisores pueden aprobar una explicación clara porque es legible, incluso cuando omite una rama poco frecuente.

Eso genera sesgo de automatización, que se produce cuando las personas depositan una confianza excesiva en la recomendación de un sistema. Una especificación pulida puede aumentar este riesgo porque oculta la ambigüedad presente en el entorno subyacente.

El propio flujo de trabajo de Google conserva un paso de revisión para las reglas extraídas. Las empresas deberían tratar ese paso como un control, no como un punto de control administrativo.

La revisión necesita responsables identificados, evidencia vinculada y disposiciones explícitas. Una regla debe marcarse como aceptada, rechazada, revisada o sin resolver antes de orientar el código generado.

La seguridad añade otra capa. Google afirma que Mainframe Assessment Tool conserva los datos de evaluación recopilados dentro de la máquina virtual en la que se despliega. Su documentación también indica que el código fuente se carga en Gemini Enterprise Agent Platform.

La misma documentación afirma que el modelo no se enriquece con información extraída de ese código. Las organizaciones aún deben verificar los controles regionales, las políticas de acceso, el comportamiento de retención y los requisitos contractuales para sus cargas de trabajo.

Las pruebas también tienen límites. Dual Run puede detectar diferencias entre resultados observados, pero la equivalencia depende de la cobertura y de la calidad de la comparación.

Si ambos entornos reciben únicamente transacciones comunes, los casos poco frecuentes permanecen sin probar. Si la lógica de comparación ignora los tiempos, el orden o los efectos secundarios posteriores, dos resultados pueden parecer iguales mientras los sistemas se comportan de manera diferente.

Las pruebas paralelas también pueden reproducir un comportamiento heredado deficiente. Igualar el mainframe es útil durante la migración, pero no demuestra que cada regla heredada sea deseable o cumpla con la política actual.

Los equipos deben separar dos preguntas. ¿La implementación en la nube se comporta como la original y debería conservarse el comportamiento original?

La segunda pregunta requiere criterio empresarial, jurídico, de seguridad y operativo. El análisis de código por sí solo no puede responderla.

Las afirmaciones sobre rendimiento también requieren evidencia similar a la producción. Un servicio generado puede superar pruebas funcionales y, aun así, crear una latencia inaceptable, consumo de infraestructura o contención de bases de datos en volúmenes máximos.

La recuperación operativa merece la misma atención. Los equipos deberían probar reintentos, fallos parciales, mensajes retrasados, transacciones duplicadas y procedimientos de reversión antes de transferir la responsabilidad.

Por último, el flujo de trabajo no puede garantizar la finalización del programa. Una empresa puede producir evaluaciones y prototipos excelentes sin retirar una sola carga de trabajo de mainframe.

El éxito necesita criterios de salida para cada unidad de migración. Esos criterios deberían abarcar evidencia funcional, preparación operativa, conciliación de datos, aprobación de seguridad, expectativas de costes y desmantelamiento efectivo de los sistemas heredados.

La estrategia de Google es más segura porque hace visible la incertidumbre antes. No es segura simplemente porque participe la IA.

Qué observar mientras Google Cloud pasa del método a la evidencia

La siguiente prueba es si el método por etapas produce transiciones a producción repetibles, no código generado más convincente.

La primera señal es la evidencia de clientes vinculada a unidades de migración completadas. Los compradores deberían buscar cargas de trabajo de producción identificadas que hayan superado pruebas paralelas y transferido la responsabilidad del sistema de registro.

Un caso de estudio útil explicaría el alcance, los artefactos compatibles, las dependencias descubiertas, la duración de la validación, la gestión de discrepancias y los componentes de mainframe finalmente retirados. Las afirmaciones generales sobre análisis más rápido revelan menos.

Las transiciones repetidas reforzarían el argumento de Google de que el flujo de trabajo escala más allá de una aplicación cuidadosamente seleccionada. Las evaluaciones sin retirada de sistemas en producción lo debilitarían.

La segunda señal es una trazabilidad más profunda a lo largo de toda la cadena de herramientas. El historial de versiones de Google muestra trabajo continuo en extracción de reglas de negocio, acceso MCP, cobertura de lenguajes y análisis de grandes entornos.

El avance importante conectaría cada regla aprobada con evidencia de origen, componentes generados, pruebas, resultados de comparación y aprobaciones humanas. Esa cadena facilitaría la revisión durante las auditorías y el mantenimiento posterior.

También ayudaría a los equipos a identificar dónde se introdujo un error en el proceso. Una discrepancia podría remontarse a una extracción defectuosa, un requisito modificado, código generado, datos convertidos o el entorno de validación.

Una trazabilidad clara reforzaría el modelo iterativo porque el conocimiento se acumularía entre las unidades de migración. Los artefactos fragmentados harían que cada unidad pareciera un proyecto independiente.

La tercera señal es cómo responden IBM y AWS con evidencia de validación comparable. Las listas de funciones ya se solapan, por lo que los proveedores deberán demostrar cómo sus métodos gestionan dependencias reales y transiciones difíciles.

IBM puede sostener que la modernización no exige abandonar IBM Z. AWS puede enfatizar la trazabilidad desde el código fuente hasta el resultado y las pruebas automatizadas. Google debe demostrar que la evaluación contextual junto con Dual Run proporciona un mejor límite de riesgo.

Esa competencia debería beneficiar a los compradores empresariales. Desplaza el debate de las demostraciones de generación de código en bruto hacia la evidencia, la gobernanza, la portabilidad y los resultados completados.

Para los líderes tecnológicos, la acción inmediata no es aprobar una migración de todo el entorno. Es seleccionar un dominio significativo y probar toda la cadena.

El dominio debería contener dependencias reales y consecuencias empresariales sin convertirse en un primer paso irreversible. Su evaluación debería incluir código, datos, calendarios, interfaces y conocimiento operativo.

Los equipos deberían registrar cuántas reglas extraídas requieren corrección, con qué frecuencia divergen los resultados paralelos y cuánto tarda en resolverse cada discrepancia. Esas medidas revelan más que el volumen de código generado.

También deberían decidir qué termina tras una transición exitosa. Una unidad de migración está incompleta si la carga de trabajo original, la carga de licencias, el proceso operativo y la responsabilidad de soporte permanecen.

Google Cloud ofrece a las empresas una vía entre el mantenimiento indefinido y un peligroso cambio radical. La vía es creíble porque trata la modernización como descubrimiento, reconstrucción y prueba.

Su valor dependerá de si los clientes pueden repetir ese ciclo en entornos complejos sin crear un laberinto híbrido permanente. Las próximas transiciones a producción importarán más que la próxima demostración generada por IA.