Durante mucho tiempo se asumió que modernizar el mainframe era sinónimo de migrar. La lógica incluso parecía sencilla: cuanto más aplicaciones salieran del entorno legado, más moderna sería la arquitectura.
El mercado está empezando a revisar esa premisa.
El State of Mainframe Modernization 2025, de Kyndryl, consultó a 500 líderes de negocios y tecnología y encontró un escenario mucho menos lineal: el 80% de las organizaciones cambió su estrategia de modernización en los últimos 12 meses.
Esto no significa que las empresas hayan renunciado a cloud, replatforming o arquitecturas distribuidas. Significa algo más interesante: la modernización está dejando de ser una discusión sobre el destino tecnológico para convertirse en una decisión sobre cada workload.
Migrar es una de las posibilidades de modernización, pero no es su definición.
Un workload puede permanecer en IBM Z y, aun así, modernizarse profundamente mediante APIs, nuevas interfaces, automatización, prácticas DevOps, integración con cloud y nuevas formas de acceder a los datos.
Del mismo modo, una aplicación puede trasladarse a otra plataforma y seguir arrastrando procesos ineficientes, dependencias antiguas y una arquitectura difícil de mantener.
Mover no significa necesariamente modernizar.
Esta diferencia importa porque una estrategia basada en el volumen migrado tiende a tratar aplicaciones muy distintas como si tuvieran el mismo problema. Y no lo tienen.
Los sistemas varían en:
criticidad para el negocio;
volumen transaccional;
necesidad de baja latencia;
dependencia de datos y aplicaciones existentes;
requisitos regulatorios;
frecuencia de cambios;
costo operativo;
integración con otros entornos.
El workload que soporta millones de transacciones financieras no debería evaluarse con los mismos criterios que una aplicación periférica de bajo volumen.
Cuando la estrategia comienza por la plataforma de destino, estas diferencias aparecen tarde. Cuando comienza por el workload, son ellas las que definen la decisión.
Quedarse también puede ser una decisión de modernización
El dato de Kyndryl es especialmente relevante porque muestra una aparente contradicción: mientras muchas organizaciones continúan migrando parte de sus portafolios, el 95% afirmó que el uso del mainframe se mantuvo estable o aumentó durante el último año.
La investigación también señala que el 56% de los workloads considerados mission-critical continúa ejecutándose en la plataforma.
Esto ayuda a desmontar una lectura binaria bastante antigua: mainframe o cloud.
En la práctica, la arquitectura empresarial actual se parece mucho más a mainframe y cloud y APIs y datos distribuidos y aplicaciones digitales.
No se trata de elegir un ganador, sino de determinar dónde cada componente ofrece la mejor combinación de rendimiento, riesgo, costo, disponibilidad y capacidad de evolución.
En algunos casos, eso significa migrar. En otros, integrar. Y en muchos, modernizar allí donde el workload ya se encuentra.
La propia investigación de Kyndryl identifica este movimiento al señalar el modelo híbrido como predominante y mostrar que las organizaciones están combinando modernización en el propio mainframe, integración con cloud y migración selectiva de aplicaciones.
Toda migración tiene un business case explícito. El problema son los costos que suelen aparecer después.
Mover una aplicación crítica puede exigir reconstruir:
integraciones;
controles de seguridad;
mecanismos de disponibilidad;
lógica operativa;
procesos de recuperación;
monitoreo;
conocimiento acumulado durante décadas de operación.
Además, una aplicación rara vez existe de forma aislada.
Accede a datos, llama a otros programas, participa en procesos batch, responde a APIs y depende de comportamientos construidos a lo largo del tiempo. Cuanto mayor sea ese nivel de acoplamiento, mayor será la posibilidad de que una decisión aparentemente localizada produzca efectos en otras partes de la arquitectura.
Por eso, el costo correcto de la modernización no es únicamente el costo de la plataforma de destino.
También es necesario incluir el costo de reconstruir aquello que ya funcionaba, operar la transición y mantener las nuevas dependencias posteriormente.
Ese cálculo puede seguir favoreciendo la migración, pero debe hacerse antes de que migrar se convierta en un objetivo en sí mismo.
¿Quedarse, integrar o salir?
Una estrategia más pragmática comienza clasificando los workloads antes de definir las tecnologías.
Existen, al menos, tres caminos.
1. Modernizar en el mainframe
Tiene sentido cuando el workload depende en gran medida de las características del entorno existente: alto volumen transaccional, proximidad a datos críticos, disponibilidad, seguridad, integración profunda con otros sistemas del core o requisitos específicos de rendimiento.
En este caso, modernizar puede significar habilitar APIs, mejorar el ciclo de desarrollo, automatizar pruebas, evolucionar interfaces, optimizar código y facilitar la integración con el resto de la arquitectura.
El sistema permanece. Lo que cambia es la forma de trabajar con él.
2. Integrar con nuevas plataformas
En muchos casos, el valor está precisamente en la combinación.
El mainframe continúa realizando el procesamiento transaccional crítico mientras cloud, analytics, IA o nuevas aplicaciones digitales utilizan servicios e información provenientes de ese core.
El desafío pasa a ser la interoperabilidad, la gobernanza, la observabilidad y la capacidad de hacer que estos entornos funcionen como una única arquitectura para el negocio.
3. Migrar de forma selectiva
Existen workloads cuyo business case favorece claramente otra plataforma.
Aplicaciones menos acopladas al core, sistemas con requisitos distintos de escalabilidad o componentes cuya evolución está limitada por la arquitectura existente pueden justificar replatforming, refactorización o sustitución.
En esos casos, migrar es modernizar porque el cambio resuelve un problema concreto.
La palabra clave es: selectivamente.
El workload adecuado depende de hacer mejores preguntas
Antes de definir hacia dónde va una aplicación, algunas preguntas son más útiles que discutir sobre tecnología.
¿Dónde están los datos de los que depende? Mover el procesamiento mientras los datos permanecen en otro entorno puede generar latencia, integraciones adicionales y nuevos costos.
¿Cuál es el impacto de una indisponibilidad? Cuanto mayor sea el costo de una interrupción, mayor debe ser el peso de la resiliencia y la previsibilidad en la decisión.
¿Cuánto necesita cambiar la aplicación? Un workload estable y altamente crítico puede requerir una estrategia completamente distinta a la de una aplicación en evolución constante.
¿Qué problema estamos tratando de resolver?¿Costo? ¿Time-to-Market? ¿Escalabilidad? ¿Disponibilidad de profesionales? ¿Integración? ¿Experiencia del desarrollador?
Sin una respuesta objetiva, la modernización corre el riesgo de convertirse en un cambio de tecnología en busca de un problema.
¿Y cuál es el costo de mantenerla?
Esa pregunta también debe formar parte del análisis. Defender un análisis más riguroso de la migración no significa defender automáticamente la permanencia. Los workloads ineficientes, difíciles de mantener o incapaces de acompañar las necesidades del negocio también generan costos que deben abordarse.
El punto no es quedarse. Es elegir.
La arquitectura híbrida no es necesariamente una etapa intermedia
Las arquitecturas híbridas suelen presentarse como una fase de transición: mantener parte del legado mientras no se completa la migración total. Esa visión también está envejeciendo.
Los datos de Kyndryl muestran organizaciones modernizando simultáneamente en el mainframe, con el mainframe y fuera de él, y reportando ROI en los tres caminos.
Según el enfoque, los encuestados reportaron retornos de entre el 288% y el 362% sobre sus iniciativas de modernización.
Esto sugiere que no existe una única arquitectura de llegada.
Para algunas organizaciones, un entorno híbrido bien integrado no es una etapa incompleta de la modernización. Es la arquitectura final más racional.
El desafío deja de ser eliminar plataformas diferentes y pasa a ser reducir la fricción entre ellas.
Modernizar es tomar mejores decisiones sobre lo que ya existe
El dato más interesante de la investigación de Kyndryl no es el aumento del uso del mainframe. Es el hecho de que el 80% de las organizaciones haya cambiado de estrategia en apenas un año.
Esto muestra un mercado menos dispuesto a seguir roadmaps rígidos definidos cinco años atrás y más dispuesto a reevaluar decisiones a medida que cambian la tecnología, la regulación, los costos y las necesidades del negocio.
En entornos de misión crítica, eso es madurez.
La modernización no debería ser una campaña para mantener todo en el mainframe. Tampoco debería ser una campaña para sacar todo de él.
Es un proceso continuo de evaluación: qué se queda, qué se integra, qué cambia y qué realmente necesita salir.
La experiencia de Eccox en entornos críticos parte de esta lógica. Antes de sustituir una arquitectura, es necesario comprender las dependencias, los riesgos, los costos y el papel que desempeña cada workload dentro de la operación.
La modernización más costosa no siempre es aquella que exige la mayor inversión. A veces, es la que mueve el workload equivocado por el motivo equivocado.
Si la estrategia de su organización todavía mide el progreso por la cantidad de aplicaciones que han salido del mainframe, es hora de cambiar la métrica.
About Post Author
