technology 9 min de lectura

Por qué las empresas japonesas siguen fracasando en la retirada de mainframes

Una nueva predicción de Gartner sitúa el fracaso de los proyectos de retirada de mainframes por encima del 70 %, y la sobreconfianza en la IA generativa es una de las causas principales. La escasez de talento especializado en sistemas legacy y de consultores en Japón revela un problema más hondo que el sector TI empresarial ha estado ignorando.

  • mainframe
  • IA generativa
  • modernización legacy
  • Gartner
  • Hitachi

El número del que nadie habla

El setenta por ciento. Esa es la cifra que Gartner manejó en junio de 2026 para los proyectos de jubilación de mainframes lanzados ese año que no lograrían entregar los beneficios esperados. No se trata de una proyección a cinco años vista. No es una estimación para migraciones ambiciosas desde cero. Habla de proyectos ya en marcha, de aquellos en los que los ejecutivos firmaron presupuestos, establecieron cronogramas y apostaron su reputación bajo la suposición de que la parte difícil —la migración del código— ahora era resoluble con un nuevo conjunto de herramientas.

La herramienta en cuestión es la inteligencia artificial generativa. La suposición era que la IA podía leer décadas de COBOL y JCL, entender la lógica de negocio oculta en su interior y reescribirla en lenguajes modernos con suficiente fidelidad como para que el verdadero trabajo fuera la validación, no la reconstrucción. Sobre el papel, esta era la vía más plausible hasta ahora para escapar de la trampa del legado. En la práctica, parece haber empeorado las cosas al convencer a los líderes de que la trampa ya se había abierto.

Lo que Gartner dijo realmente

Alessandro Galinberti, vicepresidente y analista de Gartner, no enmarcó esto como un fracaso de la inteligencia artificial generativa. Lo enmarcó como una brecha de confianza. En su evaluación, la narrativa del mercado sobre la capacidad de la IA para traducir y migrar código complejo de legado está desconectada de la realidad. Los vendedores, dijo, están incrustando IA en sus ofertas de migración no porque la evidencia sea sólida, sino porque la presión de los inversores lo exige. El resultado es un ciclo de productos que avanza más rápido que la prueba.

Ese patrón es familiar en toda la industria del software empresarial. Pero golpea de manera distinta cuando el sistema que se jubila procesa nóminas, cadena de suministro o banca central para una empresa que ha sobrevivido treinta años sobre él. Una migración fallida de una aplicación web es costosa. Una migración fallida de un mainframe es existencial. Y el pool de personas que entienden qué hace realmente el mainframe se encoge más rápido de lo que el código puede ser traducido.

Hitachi cierra la puerta

El anuncio de Hitachi esta primavera fue un choque estructural. La empresa confirmó que pondría fin a las ventas de VOS3, su sistema operativo doméstico de mainframe, en noviembre de 2027 y daría por terminada toda la mantenimiento para diciembre de 2034. Fujitsu y Japan IBM lanzaron un esfuerzo conjunto apuntando directamente a la modernización de activos COBOL alrededor del mismo tiempo. Durante décadas, las empresas japonesas tuvieron una vía: quedarse en mainframes nacionales, depender de vendedores que los mantendrían funcionando y diferir la decisión difícil.

Esa vía ahora está cerrada. Las rampas de salida restantes son estrechas, y todas conducen a través del mismo cuello de botella.

El vacío de consultores

Hiroaki Kato, de Japan Tata Consultancy Services, describió el cuello de botella en términos crudos. Su firma estaba trabajando en una migración de SAP ECC 6.0 cuando el socio consultor que supervisaba el proyecto retiró su equipo de desarrollo para otro compromiso. El cliente entonces se acercó a quince vendedores nacionales capaces de tomar el relevo. Los quince declinaron. El proyecto valía cientos de millones de yenes.

Esto no es un problema de reclutamiento. Es un problema de capacidad. Los consultores que pueden navegar migraciones de SAP a la nube, reescrituras de mainframe a distribuido, y la reingeniería de procesos de negocio que las acompaña son pocos, y la demanda del mercado en todas las grandes empresas supera con creces la oferta. Kato señaló que el rechazo incluso de un compromiso de varios millones de yenes señalaba cuán profunda es la escasez. Cuando las personas que usualmente absorben riesgo e incertidumbre en estos proyectos no se encuentran por ningún lado, el riesgo no desaparece. Se traslada al balance de la empresa que los contrató.

La habilidad perdida real

Aquí está la idea que choca contra el titular imperante de TI: la escasez no es sobre programadores COBOL. Eimei Goto de Hitachi, quien lidera el Centro de Excelencia en Modernización de la empresa, lo afirmó de forma directa. El problema, dijo, es que cada vez hay menos personas que entienden por qué el sistema actual existe en su forma actual. Los documentos de especificaciones capturan qué hace el código. Rara vez capturan por qué fue diseñado así, qué compromisos se aceptaron, cuáles reglas de negocio son flexibles y cuáles irrennegociables, y cuáles dependencias fuera de la aplicación son las restricciones reales.

Esta distinción importa porque la inteligencia artificial generativa es excelente haciendo coincidir patrones dentro del código, y pésima razonando sobre intenciones que viven en ningún documento. Una IA puede traducir un programa COBOL a Java. No puede decirte si el comportamiento peculiar de redondeo de ese programa era un bug o un requisito de cumplimiento negociado cuidadosamente en 1998. No puede entrevistar a un gerente de operaciones retirado y recuperar el conocimiento institucional que explica por qué el sistema legado procesa el cierre de mes en el orden que lo hace.

El paso de planificación que todos saltan

La receta de Kato era sencilla y ampliamente ignorada en la práctica: dedicar tiempo desproporcionado a la concepción del proyecto y la definición de requisitos antes de que cualquier código cambie de manos. Construir un cronograma realista. Mapear el modelo de dotación de personal. Producir una estimación precisa de costos. Asegurar el presupuesto bajo esos términos. Si la empresa tiene personal interno con experiencia en modernización de sistemas centrales, armarlos en una unidad de planificación conceptual que redacte el requerimiento de propuesta y evalúe vendedores en base a capacidad, no a marketing.

Esta no es una idea nueva. Simplemente es la que la inteligencia artificial generativa hizo sentir a las personas que podían saltarse. La suposición era que la IA realizaría el trabajo pesado de análisis y traducción, dejando a los humanos revisar el producto. La tasa de falla del 70 por ciento sugiere lo contrario: sin una planificación rigurosa inicial, las migraciones generadas por IA producen sistemas que se ven correctos y fallan bajo carga real, o peor, se comportan correctamente hasta que un caso borde aparece meses después del lanzamiento.

La frase diabólica

Yoshihiko Murawaki de SCSK escribió sobre un patrón que llamó “garantía de función existente”—una frase que se convirtió, en sus palabras, en demoníaca. Aparece en solicitudes de propuestas y negociaciones contractuales cuando los clientes piden a los vendedores asegurarles que cada funcionalidad existente funcionará idénticamente en el nuevo sistema. El problema es estructural. Después de diez o más años, incluso los constructores originales no recuerdan por qué ciertas funciones existen. Exigir una garantía de comportamiento idéntico es exigir certeza sobre un sistema cuya lógica está parcialmente documentada y parcialmente en poder de personas que ya se retiraron.

La observación de Murawaki importa porque explica un modo de falla común en proyectos de modernización: el nuevo sistema pasa las pruebas de aceptación pero falla en producción porque algo sutil y no probado dependía de un comportamiento legado que nadie documentó. Cuanto más especula el nuevo sistema al viejo, más probable es preservar bugs junto con funcionalidades. Cuanto más flojo sea el requisito, mayor el riesgo de regresión funcional. No hay un camino limpio por esto, solo una mejor planificación.

Dónde Hitachi está usando IA realmente

El patrón de adopción propio de Hitachi ofrece una pista sobre dónde la inteligencia artificial generativa encaja sin exagerar promesas. La empresa la está usando para pruebas de comparación presente-nuevo—alimentando salidas de ambos sistemas, el viejo y el nuevo, en un modelo de IA y pidiéndole que identifique discrepancias y posibles causas. Esto es un estrechamiento del alcance frente a la ambiciosa afirmación de que la IA puede reemplazar el análisis humano del código legado. También es una aplicación más honesta: la IA está actuando como un multiplicador de fuerza para revisores humanos, no como un sustituto de ellos.

Incluso este caso de uso acotado reconoce un límite. Los materiales de Hitachi señalan que ciertos juicios de valor permanecen firmemente en territorio humano. Las discrepancias que parecen bugs pueden ser diferencias de diseño intencionales. Las diferencias que parecen seguras pueden exponer brechas de cumplimiento. La IA surfacea las preguntas. Los humanos responden.

Qué significa esto globalmente

Las empresas japonesas no son únicas al luchar con la modernización de legado. Pero la combinación de Japón de dependencia de mainframes nacionales, una fuerza laboral técnica rápidamente envejecida y la escasez actual de consultores hace que los datos sean especialmente nítidos. La tasa de falla del 70 por ciento es una señal de advertencia para cualquier mercado donde los líderes hayan concluido que la inteligencia artificial generativa resuelve la parte difícil de la migración.

La parte difícil nunca fue el código. Era el contexto. Y el contexto no se transfiere a través de un prompt.

La jugada restante

Con Hitachi saliendo del hardware de mainframe doméstico y Fujitsu-Japan IBM coordinando en modernización COBOL, la ventana para una migración ordenada se cierra. Las empresas que ingresen en los próximos seis meses sin un equipo interno capaz de definición rigurosa de requisitos, modelado de costos realista y evaluación de vendedores estarán negociando desde una posición de escasez aguda. Los consultores que necesitan estarán indisponibles o cotizados más allá del presupuesto. Las herramientas de IA producirán salidas que se ven suficientes y fallan bajo escrutinio.

Las empresas que sobrevivan este período serán las que trataron la fase de planificación como el proyecto, no como el preludio. Tendrán personal que entiende no solo qué hacen sus sistemas, sino por qué. Usarán la inteligencia artificial generativa como ayuda analítica, no como estrategia. E ingresarán contratos con vendedores que puedan demostrar competencia en migración, no solo marketing habilitado por IA.

La alternativa es una segunda ola de fracasos, esta vez culpando a las herramientas en lugar del enfoque.

La línea de tiempo que importa

La fecha de fin de mantenimiento de VOS3 de Hitachi es diciembre de 2034. El soporte de SAP ECC 6.0 termina en 2027 para escenarios de mantenimiento extendido y antes para soporte estándar. Cada trimestre de retraso reduce el conjunto de vendedores viables, aumenta el costo de la migración y estrecha la ventana para pruebas bajo condiciones realistas. Las empresas que comiencen planificación sustantiva ahora tienen una ventaja estructural. Las empresas que esperan a que la IA haga el trabajo más fácil están esperando algo que, según los datos hasta ahora, no existe.

La cifra del 70 por ciento es una proyección, no un veredicto. Pero las proyecciones basadas en proyectos ya en movimiento son tan cercanas a un veredicto como llega la TI empresarial.