Las migraciones de mainframes fallan por una razón predecible. No porque la arquitectura de la nube de destino sea incorrecta. No porque las herramientas de conversión de COBOL a Java sean insuficientes. No porque el equipo carezca de intención o presupuesto. Fallan porque el equipo comienza a mover cosas antes de saber qué son las cosas, antes de poder responder con evidencia en lugar de suposiciones qué hace cada programa, qué programas dependen de qué otros, cómo fluyen los datos a través del sistema y qué fallará cuando algo cambie. El modo de fallo es casi siempre el mismo: una dependencia descubierta a mitad de la migración que nadie sabía que existía, una regla de negocio oculta en un copybook incluido por 400 programas, un trabajo por lotes que alimenta doce sistemas posteriores a través de un archivo que nadie pensó en documentar.
El proceso de migración de mainframes requiere una planificación y ejecución meticulosas para minimizar riesgos y garantizar la continuidad del negocio. Si bien esta afirmación es cierta, resulta incompleta. La planificación crucial no se limita a la hoja de ruta, la selección de proveedores o el cronograma por fases, sino que se centra en el análisis estructural previo a la toma de decisiones. Este análisis revela el contenido real del sistema y su funcionamiento, en contraposición a la documentación y su diseño original. Estas dos descripciones difieren considerablemente en cualquier entorno de mainframes de gran tamaño, a menudo en un margen que determina el éxito o el fracaso de la migración.
Mapea todo tu sistema central
SMART TS XL Analiza cada programa COBOL, trabajo JCL, copybook y esquema SQL en su entorno mainframe.
Aprende más¿Por qué fallan las migraciones de mainframes?: La brecha en el análisis
Las migraciones de mainframe no fallan porque el código sea antiguo, sino porque nadie sabe realmente qué hace el código hasta que es demasiado tarde. Lógica oculta. Casos límite no documentados. Flujos olvidados. Estos no son riesgos teóricos, sino obstáculos prácticos que paralizan los proyectos, provocan problemas en producción y erosionan silenciosamente la confianza en el plan de migración.
La brecha de análisis tiene una estructura específica. Las organizaciones que han utilizado sistemas mainframe durante veinte o treinta años han acumulado cambios que nunca se reflejaron en la documentación, dependencias que se formaron de manera orgánica a medida que los programas se acoplaban mediante archivos compartidos en lugar de interfaces explícitas, y lógica de negocio que solo existe en la mente de desarrolladores ya jubilados. Los equipos que tratan los datos del mainframe como archivos estándar se llevan desagradables sorpresas durante la migración cuando se dan cuenta de que los "datos" incluyen décadas de lógica de negocio dispersa en sentencias condicionales y nombres de condiciones de nivel 88.
Existen cuatro lagunas de conocimiento específicas que dificultan las migraciones. Cada una tiene una técnica de análisis que permite subsanarlas. Ninguna de ellas puede resolverse únicamente mediante la revisión de la documentación o las entrevistas con los desarrolladores.
Brecha 1: Inventario de programas desconocido. Las organizaciones suelen descubrir que la cantidad real de programas que manejan es significativamente mayor que la cantidad documentada. Programas escritos para necesidades comerciales específicas, programas de prueba que se convirtieron en programas de producción, programas de utilidad que nadie recuerda haber creado: todos ellos se encuentran en la biblioteca de carga y pueden ser invocados por trabajos JCL que aparecen en los planes de producción.
Brecha 2: Dependencias no documentadas. Los mainframes alimentan docenas de sistemas a través de complejas redes de middleware como WebSphere, CICS Transaction Gateway, Enterprise Service Bus, además de utilidades compartidas, planificadores y procesos de negocio. El error radica en demorarse demasiado en mapear todas estas conexiones, especialmente los flujos de datos descendentes y los patrones de consumo.
Brecha 3: Lógica de negocio integrada. Los programas COBOL acumulan reglas de negocio a lo largo de décadas. Un cálculo que era sencillo en 1985 ha sido modificado por doce desarrolladores desde entonces, cada uno añadiendo lógica condicional que refleja un cambio en las reglas de negocio que nunca se documentó en ningún otro lugar. Migrar el programa sin comprender la lógica produce un sistema migrado que calcula resultados diferentes al original, correctos desde la perspectiva del código, pero incorrectos desde la perspectiva del negocio.
Brecha 4: Acoplamiento entre formato de datos y esquema. Los programas que comparten datos mediante archivos en lugar de API están acoplados a través de contratos de formato de datos que solo existen en sus declaraciones FD y COPY. Un cambio en la estructura de registro de un archivo compartido afecta a todos los programas que lo leen, incluidos los programas incluidos en el ámbito de la migración y los que permanecerán en el sistema central, lo que genera un fallo de integración silencioso.
Los ocho análisis que deben realizarse antes de la migración
Los siguientes análisis deben completarse antes de tomar cualquier decisión sobre la migración y antes de modificar el código. No son pasos preliminares que deban realizarse rápidamente, sino la base sobre la que se sustenta toda decisión posterior.
1. Inventario completo del programa
El primer análisis consiste en un censo: determinar qué programas, flujos de trabajo, archivos de copia, procedimientos y definiciones de datos existen realmente en el entorno. No se trata de una revisión de la documentación, sino de un análisis de las bibliotecas de carga, de código fuente y de procedimientos para generar un inventario fidedigno.
El inventario debe incluir: cada programa fuente con su lenguaje y tamaño aproximado; cada copybook y los programas que lo incluyen; cada procedimiento catalogado y los trabajos que lo invocan; cada conjunto de datos que aparece en las sentencias DD y los programas que lo producen o consumen; cada tabla, vista y procedimiento almacenado de DB2 al que se hace referencia en SQL incrustado.
En la mayoría de los entornos de grandes sistemas centrales, este inventario revela programas desconocidos para el equipo de planificación de la migración, a veces con una diferencia de entre el 20 % y el 30 % del total. Los planes de migración diseñados en función de inventarios incompletos generan sobrecostos cuando se descubren los programas faltantes a mitad del proyecto.
2. Mapeo de dependencias en todos los lenguajes
Una vez creado el inventario, el mapeo de dependencias muestra cómo se conecta cada componente con los demás. El mapa de dependencias es el análisis previo a la migración más importante, ya que define el alcance de cada cambio posterior.
Un mapa de dependencias completo abarca:
- Llamadas de programa a programa: Llamadas, Ejecuciones, Enlaces, Adjuntos y llamadas dinámicas que se resuelven en tiempo de ejecución.
- Invocaciones de JCL a programas: cada instrucción EXEC PGM= en cada flujo de trabajo JCL, incluidas las invocaciones PROC con sustitución de parámetros simbólicos resuelta
- Cadenas de inclusión de cuadernos de ejercicios: qué programas incluyen qué libros de copia, incluidos los libros de copia anidados incluidos por otros libros de copia
- Relaciones productor-consumidor del conjunto de datos: qué programas escriben en qué conjuntos de datos, qué programas leen de esos conjuntos de datos y las dependencias de la cadena de trabajos secuenciales que esto crea
- Referencias de esquemas DB2: qué programas leen o escriben en qué tablas, qué tablas comparten esquema con qué otras tablas
El resultado es un grafo dirigido. Cualquier cambio propuesto en cualquier nodo de ese grafo puede analizarse para determinar su impacto recorriendo las aristas para enumerar todos los demás nodos que dependen de él. Sin este grafo, el análisis de impacto es pura especulación.
Antes de modificar cualquier código, es fundamental tener una visibilidad completa. Confiar en documentación obsoleta es un error fatal; las herramientas automatizadas deben mapear el estado actual escaneando automáticamente JCL, COBOL y PL/I, y mapeando todas las aplicaciones, flujos de datos, dependencias y tareas ocultas.
3. Extracción y documentación de la lógica de negocio
Los programas COBOL contienen lógica de negocio que no existe en ningún otro lugar de la organización. Este es el análisis que más se suele pasar por alto en la planificación de la migración y el que genera los fallos posteriores a la migración más costosos.
La extracción de la lógica empresarial produce documentación sobre: las reglas de decisión codificadas en las estructuras IF/THEN/ELSE y EVALUATE; las fórmulas de cálculo en las sentencias COMPUTE; las reglas de validación de datos en los párrafos PROCEDURE DIVISION; las rutas de manejo de errores y su significado empresarial; y la lógica dependiente de la secuencia, donde el orden de las operaciones es importante para la corrección del resultado.
Este análisis no requiere la lectura manual de cada línea de cada programa. Las herramientas de análisis estático que entienden COBOL pueden identificar las estructuras de decisión, extraer la lógica condicional y generar documentación estructurada de las reglas que codifican. Este resultado cumple dos propósitos: proporciona al equipo de migración la especificación necesaria para validar que el sistema migrado produce resultados correctos y ofrece a la empresa la primera documentación sistemática de reglas de negocio que, durante décadas, solo habían existido en código.
4. Identificación de código muerto
No es necesario migrar todo en el mainframe. Los programas que nunca son llamados por ningún flujo de trabajo, los párrafos que nunca son ejecutados por ninguna ruta de llamada, los miembros del copybook que nunca se referencian, todo esto representa un esfuerzo de migración que no genera ningún valor comercial.
La identificación de código muerto analiza el gráfico de dependencias para encontrar componentes sin referencias entrantes de ningún flujo de trabajo de producción. Estos componentes pueden excluirse del alcance de la migración, lo que reduce los costos sin disminuir la funcionalidad. En grandes entornos heredados, el código muerto suele representar entre el 10 % y el 25 % del inventario total, lo que supone una reducción significativa del alcance cuando se identifica sistemáticamente en lugar de descubrirse accidentalmente.
El análisis debe distinguir entre código realmente inactivo (inaccesible desde cualquier ruta de ejecución en producción) y código de ejecución poco frecuente (accesible pero rara vez activado). El código de ejecución poco frecuente, como las rutinas de procesamiento de fin de año, los programas de informes regulatorios o los procedimientos de recuperación ante desastres, puede ser crítico a pesar de su ejecución infrecuente. Excluirlo de la migración da como resultado un sistema que funciona correctamente el 99 % del tiempo y falla precisamente cuando más se necesita.
5. Clasificación de la complejidad y el riesgo
Una vez que se dispone del inventario de programas y el mapa de dependencias, cada programa puede clasificarse según su complejidad y riesgo de migración. Esta clasificación determina la secuencia de migración: los programas de baja complejidad y con pocas dependencias se migran primero; los de alta complejidad y con muchas dependencias se migran al final, con la cobertura de pruebas más exhaustiva.
Métricas de complejidad para el riesgo de migración a COBOL:
| Factor de complejidad | Qué Medir | Umbral de alto riesgo |
|---|---|---|
| Complejidad ciclomática | Número de ramas de decisión por programa | Más de 50 por programa |
| Recuento de dependencias de Copybook | Número de cuadernos incluidos | Más de 20 cuadernos |
| Recuento de llamados | Número de programas que llaman a este programa | Más de 15 personas que llaman |
| Referencias de conjuntos de datos | Número de conjuntos de datos leídos o escritos | Más de 30 conjuntos de datos |
| SQL integrado | Número de sentencias SQL | Más de 100 declaraciones |
| Llamadas de EXEC CICS | Acoplamiento del servidor de transacciones | Cualquier dependencia de CICS |
| Llamadas dinámicas | Las llamadas se resuelven en tiempo de ejecución. | Cualquier llamada dinámica |
| Invocaciones del ensamblador | Lógica no COBOL integrada | Cualquier llamada de ensamblador |
Los programas que obtienen puntuaciones altas en múltiples factores representan los componentes de migración de mayor riesgo. Requieren el análisis más exhaustivo, los ingenieros de migración más experimentados y la cobertura de pruebas más completa.
6. Análisis de dependencias de ventanas de procesamiento por lotes y planificación.
Los trabajos por lotes del mainframe se ejecutan en ventanas programadas con complejas cadenas de dependencias: el trabajo B no puede comenzar hasta que el trabajo A finalice correctamente; el trabajo C se ejecuta solo el último día hábil del mes; el trabajo D tiene una restricción de tiempo máximo de ejecución que afecta la hora de inicio del trabajo E. Estas dependencias de programación forman parte del comportamiento operativo del sistema y deben replicarse en el entorno de destino.
El análisis de la ventana de procesamiento por lotes documenta: la cadena de ejecución completa para cada ejecución de lote de producción; las restricciones de tiempo en cada paso; la lógica de ejecución condicional (qué sucede cuando un paso falla o produce un código de retorno distinto de cero); los conjuntos de datos que fluyen entre los pasos; y los disparadores y notificaciones externos que produce el sistema de procesamiento por lotes.
En los entornos nativos de la nube, esto se traduce en: la configuración equivalente de la canalización de CI/CD o la orquestación del flujo de trabajo; la configuración del manejo de errores y las alertas; la configuración de la supervisión y los acuerdos de nivel de servicio (SLA); y la integración con los sistemas posteriores que reciben los resultados por lotes.
7. Evaluación de la calidad y el formato de los datos
Los sistemas heredados suelen incluir miles de líneas de código escritas en COBOL, PL/I o lenguaje ensamblador, muchas de las cuales pueden estar mal documentadas o estar estrechamente acopladas. Utilice herramientas de análisis estático para detectar deuda técnica, código redundante y módulos que se pueden modularizar o eliminar.
La evaluación de la calidad de los datos examina los datos reales en los conjuntos de datos de producción comparándolos con las definiciones de formato en las definiciones de COBOL FD y copybook. Las discrepancias son comunes: campos decimales empaquetados que contienen patrones de bits no válidos para ciertos tipos de registros, campos de longitud variable donde el indicador de longitud está fuera de rango para un subconjunto de registros, campos de caracteres EBCDIC que contienen valores no visualizables en posiciones específicas.
Estas discrepancias deben identificarse y resolverse antes de la migración, no descubrirse durante las pruebas. Una migración de datos que transfiere 500 millones de registros y luego descubre que el 0.1 % de ellos tienen formatos no válidos presenta un defecto que afecta a la producción, presente en los datos de origen y desconocido hasta la fase de validación.
8. Integración y mapeo de sistemas externos
El linaje de sus datos debe abarcar todos los sistemas que consumen datos del mainframe, desde las herramientas de generación de informes hasta las integraciones con socios, porque los proyectos de modernización no pueden ponerse en marcha cuando los equipos descubren, en una fase avanzada del desarrollo, que preservar estas fuentes de datos era esencial pero no estaba previsto.
El mapeo de integración identifica todos los sistemas externos al mainframe que reciben datos de él o le envían datos: aplicaciones posteriores que consumen salidas por lotes mediante transferencia de archivos; interfaces en tiempo real a través de MQ, CICS o llamadas API; integraciones con socios que dependen de formatos de archivo y cronogramas de transmisión específicos; sistemas de informes que consultan directamente tablas DB2; y fuentes de almacenamiento de datos que ingieren datos transformados del mainframe.
Cada punto de integración representa un riesgo potencial de transición: un sistema migrado que produce datos en un formato que un sistema posterior no espera generará una falla silenciosa que podría pasar desapercibida hasta que un usuario posterior reporte una anomalía. El mapeo de la integración es el análisis que permite que la planificación de la transición sea integral, en lugar de optimista.
Selección de una estrategia de migración basada en los resultados del análisis.
El análisis previo a la migración no solo reduce los riesgos, sino que también determina la estrategia de migración más adecuada para cada componente. Los equipos migran las cargas de trabajo de los sistemas centrales de diferentes maneras, según la magnitud del cambio que puedan gestionar. Los resultados del análisis influyen directamente en esa decisión.
| Hallazgo del análisis | Estrategia recomendada | Razón fundamental |
|---|---|---|
| Baja complejidad, pocas dependencias, sin llamadas dinámicas. | Reubicación (migración de datos) | Mínimo riesgo; equivalencia conductual alcanzable rápidamente. |
| Complejidad moderada, lógica empresarial bien documentada. | Cambio de plataforma | Se aceptan algunas modificaciones; se entiende la lógica. |
| Grafo de dependencias de alta complejidad y densidad | Figura estranguladora en fase | Extraer de forma incremental; mantener el mainframe como núcleo mientras se moderniza a su alrededor. |
| Programa compartido de vital importancia, más de 100 personas que llaman. | envoltura de API | Exponer como servicio; migrar a los consumidores sin tocar el programa. |
| Programas con datos no válidos o problemas de formato. | Primero, la corrección de datos. | La migración no puede completarse hasta que los datos estén limpios. |
| El análisis confirma que el código está muerto. | Retirarse | No es necesaria ninguna migración; eliminar del alcance |
| Lógica empresarial no documentada, no hay expertos disponibles. | Se requiere un análisis profundo | No se puede migrar de forma segura hasta que se extraiga y documente la lógica. |
Creación de la secuencia de migración a partir del grafo de dependencias
Una vez completado, el gráfico de dependencias define directamente la secuencia de migración. Los componentes que no dependen de otros componentes del sistema central pueden migrarse de forma independiente y temprana. Los componentes de los que dependen muchos otros deben migrarse al final, una vez que todos sus dependientes estén listos.
Un enfoque práctico de secuenciación:
Fase 1: Programas de utilidad y trabajos por lotes independientes. Programas sin llamadas ni conjuntos de datos compartidos. Estos pueden migrarse de forma aislada sin necesidad de coordinación.
Fase 2: Programas hoja en el árbol de dependencias. Programas que llaman a otros, pero que no son llamados por muchos. Al migrarlos, se eliminan del ámbito de dependencias para los programas restantes.
Fase 3: Programas con datos acoplados. Los grupos de programas que comparten conjuntos de datos pueden migrarse juntos como una unidad, resolviendo el contrato de formato de datos dentro del grupo migrado.
Fase 4: Programas de servicio compartido. Los programas con muchos llamadores, los nodos de alta conectividad en el gráfico de dependencias, se migran solo después de que todos los llamadores hayan sido validados con respecto a la implementación migrada.
Fase 5: Programas de transacciones principales. Los componentes de mayor riesgo, migrados al final con la cobertura de pruebas más completa y el proceso de transición más controlado.
Esta secuencia no es una heurística general, sino que se deriva del grafo de dependencias específico del sistema que se está migrando. Dos entornos de mainframe con el mismo número de programas tendrán secuencias de migración óptimas completamente diferentes debido a que sus estructuras de dependencias difieren.
Cómo SMART TS XL Genera el análisis previo a la migración.
SMART TS XL Realiza automáticamente los ocho análisis descritos en este artículo, analizando el código fuente de cada componente del entorno. No depende de la documentación, las entrevistas con los desarrolladores ni los diagramas existentes; deriva el modelo estructural del propio código, por lo que el modelo es preciso incluso para programas que nunca se documentaron y dependencias que se formaron sin que nadie lo previera.
El análisis de modernización del legado comienza con la generación de un inventario completo: cada programa COBOL, flujo de trabajo JCL, copybook, PROC y esquema SQL se cataloga con su ubicación de origen, tamaño, versión de lenguaje y puntuación de complejidad preliminar. El mapeo de dependencias de la aplicación construye el gráfico de dependencias completo, resolviendo los parámetros simbólicos JCL mediante la capacidad de expansión de JCL para mostrar los programas invocados realmente, en lugar de referencias a plantillas sin resolver.
La capacidad de análisis de impacto permite consultar el gráfico de dependencias: antes de migrar cualquier componente, el equipo puede preguntar qué se verá afectado al eliminarlo del sistema central y recibir una lista estructurada y enumerada de todos los componentes dependientes que requieren validación o coordinación. La capacidad de búsqueda empresarial permite buscar en todo el inventario simultáneamente en todos los lenguajes, encontrar en segundos cada programa que lee un conjunto de datos específico, cada copybook que define un campo específico y cada instrucción SQL que hace referencia a una columna específica, en un código fuente de millones de líneas.
El resultado del análisis previo a la migración no es un plan de proyecto. Es evidencia estructural: el grafo de dependencias, la clasificación de complejidad, el inventario de código muerto, la documentación de la lógica de negocio y el mapa de integración, que en conjunto le indican al equipo de migración con precisión con qué están trabajando. Esta evidencia es lo que marca la diferencia entre una migración que descubre problemas inesperados en producción y otra que los descubre durante el análisis, cuando el costo de encontrarlos y resolverlos se reduce a semanas en lugar de meses.
El análisis no es un gasto adicional, es la migración.
La objeción más común al análisis exhaustivo previo a la migración es el plazo: la organización se ha comprometido con una fecha de inicio, la presión de la dirección es alta y dedicar de seis a ocho semanas al análisis antes de tocar cualquier código se percibe como una demora. Este razonamiento invierte el cálculo de riesgos. Una vez que las reglas son visibles y los flujos están mapeados, el proyecto pasa de la especulación a la ingeniería. Las herramientas de automatización hacen visible lo invisible, y eso es lo que realmente importa.
Una migración que comienza sin un análisis completo no se inicia más rápido, sino que comienza con un alcance desconocido. Un alcance desconocido genera sorpresas en el cronograma, sobrecostos y problemas de producción cuando se revelan las dependencias no descubiertas. La fase de análisis no retrasa la migración; es la migración misma. Cada dependencia descubierta durante el análisis, en lugar de durante la transición, es un problema de producción que no se produjo. Cada programa identificado como código muerto antes de la migración es un esfuerzo no invertido. Cada regla de negocio documentada antes de la conversión es un criterio de validación que se puede probar en lugar de adivinar.
Las organizaciones que triunfan son aquellas que abordan la complejidad de forma proactiva, identifican las dependencias desde el principio, democratizan el conocimiento, se centran en el valor para el negocio y se alinean en torno a objetivos claros desde el primer día. Estas no son solo buenas prácticas, sino que marcan la diferencia entre los proyectos de transformación que generan un retorno de la inversión cuantificable y aquellos que se convierten en ejemplos de lo que no se debe hacer.
