¿Cuáles son las cuatro estrategias de modernización de mainframes?

Rehospedar, replataformar, refactorizar y retener. Rehospedar traslada la carga de trabajo a un emulador o instancia en la nube sin cambiar el código. Replataformar cambia la capa de ejecución (base de datos, gestor de transacciones, planificador) mientras mantiene intacto el código de la aplicación. Refactorizar reescribe el código en un lenguaje moderno conservando la lógica de negocio. Retener mantiene deliberadamente la carga de trabajo en el mainframe. Las grandes instituciones normalmente aplican varias de estas estrategias en un mismo portafolio en lugar de elegir solo una.

¿Debería realojar o refactorizar mis aplicaciones COBOL?

Depende de la frecuencia con la que cambia el código y del costo de un error. Realojar es más rápido y de menor riesgo, pero conserva tanto el código heredado como la dependencia de personal especializado, por lo que se adapta bien a cargas de trabajo estables bajo presión de hardware o del centro de datos. La refactorización elimina la dependencia de COBOL de forma permanente y es adecuada para cargas de trabajo con una lista activa de cambios pendientes, pero es más costosa y fracasa si las reglas de negocio originales nunca se documentaron. Tome la decisión para cada carga de trabajo utilizando el historial de cambios en lugar de hacerlo a nivel de todo el portafolio.

¿Cuánto tiempo lleva la modernización de mainframes?

Depende mucho más de lo bien que se comprenda el sistema existente que de la cantidad de código que haya. Los portafolios con documentación actualizada y expertos en la materia disponibles avanzan en cuestión de trimestres. Los portafolios donde las reglas de negocio solo existen como comportamiento dedican la mayor parte del tiempo al descubrimiento antes de iniciar cualquier trabajo de migración. Por eso, la documentación y la captura de conocimiento son requisitos previos en lugar de flujos de trabajo paralelos.

¿Es correcto en algún caso dejar una carga de trabajo en el mainframe?

Sí. Las cargas de trabajo estables y de alto rendimiento que rara vez cambian y son económicas de operar (la liquidación por lotes es el ejemplo más claro) a menudo ya cumplen su propósito, y moverlas añade riesgo sin aportar nuevas capacidades. Retener es una estrategia legítima cuando se elige deliberadamente y se documenta. Lo que no es una estrategia es retener una carga de trabajo que nadie sabe explicar, porque el conocimiento desaparecerá de todos modos cuando el equipo se jubile.

Cómo modernizar un mainframe COBOL

Cuatro estrategias, lo que realmente cuesta cada una y cómo saber cuál necesita una carga de trabajo específica. Escrito para quienes tienen que aprobar la decisión.

La mayoría de los consejos sobre la modernización de mainframes se reduce a una sola pregunta: migrar o no. Este enfoque es la razón por la que tantos programas se estancan. Una gran institución no tiene una sola carga de trabajo en el mainframe; tiene cientos, y no todas merecen el mismo tratamiento. La decisión útil se toma según la carga de trabajo, y existen cuatro respuestas justificables.

Las cuatro estrategias

Rehospedar

Mover la carga de trabajo tal cual a un emulador o instancia en la nube sin cambiar el código.

Good for: Cargas de trabajo donde la lógica de negocio sigue siendo correcta y la presión es el costo del hardware, la capacidad o la salida de un centro de datos.
What it costs: La más rápida y de menor riesgo por carga de trabajo. El código sigue ejecutándose, por lo que el comportamiento se conserva casi por diseño.
The catch: Ha movido el problema, no lo ha resuelto. COBOL sigue siendo COBOL, las reglas de negocio no documentadas siguen sin documentarse y las personas que lo entienden siguen siendo las únicas que lo entienden. Rehospedar una carga de trabajo que no puede explicar solo sirve para ganar tiempo y nada más.

Cambio de plataforma

Cambia la capa de ejecución (base de datos, gestor de transacciones, planificador) dejando el código de la aplicación prácticamente intacto.

Good for: Dejar atrás las licencias por MIPS o un subsistema al final de su vida útil cuando la lógica de la aplicación es sólida.
What it costs: Un punto intermedio. Menos riesgo que una reescritura y más beneficios que un lift-and-shift.
The catch: Las interfaces entre el código de la aplicación y el entorno de ejecución albergan décadas de suposiciones no documentadas. Pasar de Db2 a PostgreSQL no es un simple buscar y reemplazar; los niveles de aislamiento, las secuencias de intercalación y el manejo de valores nulos difieren de tal modo que los errores se manifiestan como cifras incorrectas en lugar de caídas del sistema.

Refactorización

Reescribir el código en un lenguaje moderno manteniendo la lógica de negocio.

Good for: Cargas de trabajo que deben cambiar con frecuencia, donde la escasez de COBOL es la limitación en la hoja de ruta y no en el manual de operaciones.
What it costs: El mayor costo y el mayor potencial. Si se hace correctamente, elimina la dependencia de personal especializado de forma permanente.
The catch: Esta es la estrategia que fracasa públicamente. El modo de fallo nunca es la sintaxis, ya que los transpiladores se encargan de ella. El problema es que la especificación nunca se documentó, por lo que nadie puede decir si el nuevo sistema es correcto. No está migrando código; está recuperando una especificación que solo existe como comportamiento.

Retener

Dejar deliberadamente la carga de trabajo en el mainframe.

Good for: Cargas de trabajo estables y de alto rendimiento que son económicas de operar y rara vez cambian. La liquidación por lotes suele ser el ejemplo más claro.
What it costs: Nada, si se elige deliberadamente y se documenta el motivo.
The catch: Retener es una estrategia real y está subutilizada, porque es difícil de incluir en una presentación para la junta directiva. Pero la retención sin documentación no es una estrategia, es un aplazamiento. El conocimiento se sigue perdiendo cuando el equipo se jubila.

Cómo elegir según la carga de trabajo

Cuatro preguntas separan las cargas de trabajo que necesitan cada estrategia. Respóndalas por aplicación, no por portafolio.

¿Con qué frecuencia cambia realmente este código?: Consulte el historial de cambios, no las opiniones. Un código que no se ha modificado en ocho años es candidato a conservarse o realojarse, sin importar la antigüedad del lenguaje. El código con una cola de cambios pendientes es donde la refactorización se amortiza sola.
¿Alguien puede explicar actualmente qué hace?: Si la respuesta depende de una o dos personas específicas, ninguna estrategia de migración es segura todavía. La documentación y la captura de conocimiento son requisitos previos, no entregables que se deban generar durante el proceso.
¿Cuál es el coste de equivocarse?: Un cálculo de intereses mal contabilizado y un informe lento no representan el mismo riesgo. Cuanto mayor sea el coste de una diferencia de comportamiento inadvertida, más verificación necesitará la migración y más se inclinará la viabilidad económica hacia mantener o realojar.
¿Qué está forzando realmente el cambio?: El costo del hardware, los plazos de cumplimiento normativo, la escasez de talento y la hoja de ruta del producto apuntan a estrategias diferentes. Los programas que no logran identificar el factor determinante tienden a elegir por defecto la opción más costosa.

Por qué fracasan las migraciones de COBOL a Java

La ruta de la refactorización merece su propio tratamiento, porque es la que genera los titulares. Los modos de fallo recurrentes son consistentes en todas las instituciones.

La especificación nunca se escribió

Cuarenta años de modificaciones viven en el código y en ningún otro lugar. Por lo tanto, cada reescritura es primero un acto de arqueología y luego de ingeniería. Los equipos que omiten la arqueología descubren las reglas faltantes en producción.

La desviación de comportamiento es silenciosa

La aritmética decimal empaquetada de COBOL y el punto flotante de Java no redondean de forma idéntica. Las diferencias de un centavo por transacción no lanzan excepciones; generan errores de conciliación al cierre del trimestre, mucho después de que la migración se haya declarado completa.

Las pruebas codifican el comportamiento actual, no el correcto

Un conjunto de pruebas diseñado para el sistema heredado que se ejecuta con éxito demuestra que el nuevo sistema reproduce lo que hacía el anterior en las rutas que alguien pensó en probar. Los portafolios reales tienen rutas que nadie ha ejecutado deliberadamente en una década.

La recertificación regulatoria no es gratuita

En banca, seguros y sector público, un sistema reescrito suele ser un sistema nuevo a efectos de auditoría. Ese costo debe incluirse en el caso de negocio desde el principio, no como un descubrimiento en el mes nueve.

Los expertos se van a mitad del programa

Los programas plurianuales se topan directamente con la curva de jubilación de las personas de las que dependen. Es necesario capturar el conocimiento antes de que comience el programa, porque no estará disponible cuando más se necesite.

La pregunta que cambia la economía

Todas las estrategias anteriores están limitadas por la misma restricción: ¿puede demostrar que el sistema sigue haciendo lo que hacía? Las pruebas toman muestras del espacio de entrada. La verificación formal razona sobre todo el espacio, demostrando que para cada entrada, la ruta modernizada produce el mismo resultado que la heredada. Cuando se dispone de esta prueba, la refactorización deja de ser un acto de fe y se convierte en un ejercicio de ingeniería delimitado, y la pregunta anterior sobre el costo de equivocarse cambia de respuesta. Cuando no es así, el conservadurismo es la postura correcta.

Dónde encaja Hypercubic

Construimos para la arqueología y la prueba, en ese orden. HyperDocs reconstruye la documentación a partir del código fuente de COBOL, PL/I y JCL. HyperTwin captura lo que saben tus ingenieros sénior antes de que se jubilen. Hopper ejecuta las operaciones diarias de z/OS. HyperLoop realiza la propia migración con pruebas de corrección a nivel de línea. Si estás en una etapa lo suficientemente temprana como para que los dos primeros importen más que los dos últimos, esa es la secuencia honesta.

Preguntas frecuentes

¿Cuáles son las cuatro estrategias de modernización de mainframes?: Rehospedar, replataformar, refactorizar y retener. Rehospedar traslada la carga de trabajo a un emulador o instancia en la nube sin cambiar el código. Replataformar cambia la capa de ejecución (base de datos, gestor de transacciones, planificador) mientras mantiene intacto el código de la aplicación. Refactorizar reescribe el código en un lenguaje moderno conservando la lógica de negocio. Retener mantiene deliberadamente la carga de trabajo en el mainframe. Las grandes instituciones normalmente aplican varias de estas estrategias en un mismo portafolio en lugar de elegir solo una.
¿Debería realojar o refactorizar mis aplicaciones COBOL?: Depende de la frecuencia con la que cambia el código y del costo de un error. Realojar es más rápido y de menor riesgo, pero conserva tanto el código heredado como la dependencia de personal especializado, por lo que se adapta bien a cargas de trabajo estables bajo presión de hardware o del centro de datos. La refactorización elimina la dependencia de COBOL de forma permanente y es adecuada para cargas de trabajo con una lista activa de cambios pendientes, pero es más costosa y fracasa si las reglas de negocio originales nunca se documentaron. Tome la decisión para cada carga de trabajo utilizando el historial de cambios en lugar de hacerlo a nivel de todo el portafolio.
¿Por qué fracasan las migraciones de COBOL a Java?: Rara vez es por la sintaxis. Fracasan porque la especificación nunca se documentó, por lo que nadie puede demostrar que el sistema reescrito sea correcto; porque la aritmética difiere entre el decimal empaquetado de COBOL y el punto flotante de Java, lo que produce una desviación silenciosa por redondeo en lugar de caídas del sistema; porque los conjuntos de pruebas codifican el comportamiento actual en las rutas que alguien pensó en probar en lugar del comportamiento correcto en todas las rutas; porque los costos de recertificación regulatoria se descubren tarde; y porque los expertos que entienden el sistema se jubilan durante el programa.
¿Cuánto tiempo lleva la modernización de mainframes?: Depende mucho más de lo bien que se comprenda el sistema existente que de la cantidad de código que haya. Los portafolios con documentación actualizada y expertos en la materia disponibles avanzan en cuestión de trimestres. Los portafolios donde las reglas de negocio solo existen como comportamiento dedican la mayor parte del tiempo al descubrimiento antes de iniciar cualquier trabajo de migración. Por eso, la documentación y la captura de conocimiento son requisitos previos en lugar de flujos de trabajo paralelos.
¿Es correcto en algún caso dejar una carga de trabajo en el mainframe?: Sí. Las cargas de trabajo estables y de alto rendimiento que rara vez cambian y son económicas de operar (la liquidación por lotes es el ejemplo más claro) a menudo ya cumplen su propósito, y moverlas añade riesgo sin aportar nuevas capacidades. Retener es una estrategia legítima cuando se elige deliberadamente y se documenta. Lo que no es una estrategia es retener una carga de trabajo que nadie sabe explicar, porque el conocimiento desaparecerá de todos modos cuando el equipo se jubile.

Determina qué cargas de trabajo mover primero.

Hable con nuestro equipo sobre cómo mapear su cartera frente a las cuatro estrategias, o comience por el glosario si está creando un vocabulario interno.

Solicitar demo Lee el glosario