Dónde COBOL en producción aún hace el trabajo real

COBOL sigue en producción allí donde una organización ha pasado décadas incorporando dinero, derechos y gestión de excepciones a una ruta operativa fiable. El lenguaje se ve en la biblioteca de fuentes, pero el sistema también incluye JCL, planificadores, archivos, bases de datos, monitores de transacciones, procedimientos operativos, informes de conciliación y acuerdos con todos los sistemas de su entorno. Sustituir solo los programas significa sustituir la parte menos difícil.

La conocida frase «los bancos todavía usan COBOL» es cierta y casi inútil. Oculta qué cargas siguen dependiendo de él y por qué sus propietarios continúan pagando por mantenerlas. COBOL se concentra en la liquidación por lotes, la administración de pólizas, los libros mayores de la banca y el cálculo de prestaciones públicas. Estos sistemas siguieron activos porque producían resultados empresariales correctos en condiciones difíciles. Cambian cuando el coste de hacerlo queda por debajo del riesgo combinado de perder personal, sufrir las restricciones de la plataforma, cambiar los productos con lentitud y depender de una frontera de interfaz que nadie puede ampliar con seguridad.

El mapa de producción sigue el dinero y los derechos

COBOL todavía se usa donde un registro grande y duradero debe sobrevivir a muchas transacciones y donde alguien tendrá que explicar el resultado después. Cuatro clases de carga reúnen buena parte de los entornos de producción serios.

La liquidación por lotes toma la actividad aceptada del día, aplica comisiones y ajustes, cuadra los totales de control, contabiliza resultados y emite archivos para los participantes posteriores. La interfaz en línea puede utilizar un lenguaje más reciente mientras que el estado financiero definitivo sigue saliendo de trabajos COBOL programados después de una hora de corte.

La administración de pólizas conserva el historial contractual de los productos de seguros. Calcula primas, aplica suplementos, renueva pólizas, produce facturas y documentos, y registra qué cobertura existía en una fecha concreta. Puede haber un portal web delante sin que este sustituya al sistema.

Los libros mayores bancarios centrales contabilizan débitos y créditos, mantienen saldos, devengan intereses, aplican reglas de contabilización y cierran periodos contables. Las aplicaciones móviles y las API de pagos son canales. El libro mayor decide qué considera el banco que ha sucedido.

El cálculo de prestaciones públicas aplica leyes y reglas del programa a solicitudes, historiales de ingresos, datos del hogar, fechas de efecto, cobros indebidos y recursos. Por ejemplo, el material presupuestario de la Social Security Administration describe la tramitación de solicitudes entre sistemas COBOL heredados y aislados. Se trata de una dependencia operativa concreta, no de nostalgia por un lenguaje antiguo.

Estas categorías se solapan. Una plataforma de prestaciones tiene libros mayores. Una aseguradora ejecuta lotes de liquidación. Un banco administra productos con fechas de efecto similares a las de una póliza. La distinción útil es la invariante empresarial: la liquidación debe cuadrar, una póliza debe reproducir la cobertura de una fecha, un libro mayor debe conservar la verdad contable y un sistema de prestaciones debe explicar una decisión sobre derechos.

La liquidación por lotes es una cadena controlada

Un entorno de liquidación es un grafo de dependencias sujeto a horarios cuya salida tiene consecuencias financieras. Una noche típica solo comienza después de que los canales cierren sus ventanas de entrada. Los trabajos validan el número de archivos, ordenan registros, enriquecen transacciones, calculan cargos, contabilizan resúmenes, comparan totales, crean archivos de salida y envían las excepciones a operaciones. Una repetición puede comenzar en un punto de control seguro en vez de hacerlo desde el principio.

La documentación de z/OS de IBM califica el procesamiento por lotes como una función fundamental de z/OS y explica cómo JES recibe los trabajos, los programa y controla su salida. La descripción importa porque corrige un error común de modernización: el ejecutable COBOL no controla todo el flujo. JCL nombra entradas y salidas, los procedimientos catalogados aportan pasos compartidos, el planificador aporta calendarios y dependencias, y los operadores interpretan códigos de retorno y la salida de spool.

Un fragmento pequeño de un trabajo muestra cuánto comportamiento vive fuera del código fuente de la aplicación:

//SETTLE   JOB CLASS=A,MSGCLASS=X
//POST     EXEC PGM=POSTDAY,PARM='RESTART=CHK7'
//INTRANS  DD DSN=BANK.CLEARING.ACCEPTED,DISP=SHR
//OUTPOST  DD DSN=BANK.LEDGER.POSTED(+1),
//            DISP=(NEW,CATLG,DELETE)
//EXCEPT   DD DSN=BANK.SETTLE.EXCEPT(+1),
//            DISP=(NEW,CATLG,DELETE)
//SYSOUT   DD SYSOUT=*

El sustituto debe responder las preguntas que plantea el fragmento. ¿Qué crea la generación (+1)? ¿Un paso fallido elimina la salida parcial? ¿Qué códigos de retorno permiten ejecutar el siguiente trabajo? ¿Qué significa CHK7 después de una contabilización parcial? ¿Quién decide si un archivo de excepciones está completo? Convertir POSTDAY a otro lenguaje sin recrear estos controles puede producir código válido y un proceso de liquidación inválido.

Los sistemas de liquidación permanecen porque están optimizados para respetar horas de corte, reiniciar y mover grandes volúmenes de entrada y salida. Por fin cambian cuando los canales nuevos exigen contabilizaciones más frecuentes, las contrapartes piden otras fronteras de archivo o API, las ventanas de lotes chocan con un horario global o quedan muy pocas personas que sepan recuperar una cadena fallida.

La administración de pólizas conserva el tiempo como dato

Un sistema de administración de pólizas debe responder «¿qué era cierto entonces?» y «¿qué es cierto ahora?». Fechas de efecto y transacción, suplementos retroactivos, cancelaciones, rehabilitaciones, renovaciones, reglas jurisdiccionales y versiones del producto afectan a la respuesta. Este modelo temporal explica por qué una simple migración de base de datos rara vez sustituye al sistema.

Pensemos en un suplemento introducido hoy pero efectivo antes de la última factura. El sistema quizá deba recalcular la prima de parte del periodo, conservar documentos ya emitidos, generar una cuenta por cobrar nueva y dejar una pista de auditoría que explique la diferencia. Un servicio ingenuo que solo almacena el estado más reciente de la póliza destruye pruebas. Un sustituto fiel trata por separado los eventos, los periodos de efecto, los valores derivados y los documentos emitidos.

COBOL encaja en este trabajo porque los registros empresariales fijos, la aritmética decimal, el procesamiento secuencial y las bifurcaciones explícitas encajan en el dominio. El entorno suele añadir copybooks compartidos por muchos programas, tablas mantenidas fuera del código, plantillas de documentos, módulos de tarificación y trabajos nocturnos de facturación. Algunas reglas aparecen dos veces porque la cotización en línea y la facturación de renovaciones evolucionaron por separado. Las dos lógicas quizá solo difieran en una versión poco común del producto, justo cuando una reescritura limpia puede alterar un resultado válido para el cliente.

Los propietarios no apagaron estos sistemas solo porque cambiaran los navegadores y servidores de aplicaciones. Añadieron portales, herramientas de flujo de trabajo y API a su alrededor. Era una decisión racional mientras los productos seguían estables y el núcleo producía resultados defendibles. La decisión cambia cuando lanzar o modificar un producto exige tocar programas antiguos, cada versión depende de un grupo de revisores cada vez menor o un componente de documentos o integración sin soporte bloquea toda la ruta.

Un sustituto debe demostrar el comportamiento temporal con casos fechados. Pruebe una póliza nueva, un suplemento a mitad del periodo, una corrección retroactiva, una cancelación seguida de rehabilitación y una renovación que cruce la frontera de una versión del producto. Compare importes, estado, periodos de cobertura, documentos, asientos y explicaciones. No basta con hacer coincidir la fila actual de una tabla de pólizas.

Los libros mayores sobreviven porque los errores se acumulan

Un libro mayor central sigue funcionando en COBOL porque cambiar el motor de contabilización puede alterar las cuentas de la entidad. El trabajo incluye mucho más que sumar y restar saldos. Interactúan el orden de contabilización, las fechas valor, las retenciones, los retrocesos, el devengo de intereses, las comisiones, la precisión de las monedas, las cuentas transitorias y los controles de cierre.

El sector suele confundir un libro mayor con un servicio de saldos. Un servicio de saldos responde con rapidez a una consulta. Un libro mayor registra asientos ordenados y duraderos y permite reconstruirlos. Si una migración copia los saldos actuales pero pierde el historial de contabilización o las relaciones de retroceso, las cifras pueden coincidir la mañana del cambio y resultar imposibles de explicar después de la primera disputa.

El procesamiento de transacciones en línea suele ejecutarse mediante CICS. La documentación de Enterprise COBOL de IBM explica que los programas que usan servicios CICS compilan las instrucciones CICS incrustadas mediante la interfaz de comandos CICS. Ese detalle señala otra frontera que una reescritura debe descubrir: el alcance de la transacción puede depender de recursos CICS, trabajo Db2, archivos, colas y tratamiento de errores, no solo de instrucciones COBOL.

La sustitución de un libro mayor falla de formas reconocibles. Un equipo asigna filas de cuentas a tablas nuevas, reimplementa las contabilizaciones del caso normal y valida un conjunto de pruebas unitarias. Durante la ejecución paralela llega un retroceso antiguo después de que su transacción haya cruzado una fecha contable. El sistema nuevo aplica la regla actual y el antiguo aplica la versión asociada al asiento original. Ambas ejecuciones parecen razonables. Solo una coincide con los libros reconocidos por la entidad.

La respuesta no consiste en conservar todos los defectos históricos de implementación. El equipo debe clasificar el comportamiento. Las invariantes contables y los resultados contractuales exigen paridad. Un formato accidental de pantalla quizá no. Una regla sospechosa necesita una decisión empresarial explícita, registrada antes de que alguien la «arregle». De lo contrario, los ingenieros toman decisiones de política en una revisión de código donde nadie puede ver la consecuencia financiera.

El cálculo de prestaciones une la ley y la historia operativa

Los sistemas públicos de prestaciones conservan COBOL porque las reglas ejecutables se apoyan en largos historiales de solicitantes y procedimientos administrativos. Un cálculo puede depender de periodos de ingresos, composición del hogar, discapacidad, resoluciones anteriores, interacciones entre programas, fechas de efecto, reglas de redondeo, límites, compensaciones y correcciones posteriores. Un recurso puede obligar al organismo a reproducir una decisión usando los hechos y reglas que regían entonces.

La ley no es la especificación ejecutable. Reglamentos, manuales de políticas, actualizaciones de tablas, calendarios de lotes, reglas de limpieza de datos y procedimientos de excepción cierran la brecha entre el texto jurídico y un pago. Dos registros que parecen equivalentes para un servicio nuevo pueden seguir rutas distintas porque un indicador antiguo recoge cómo resolvió el organismo una discrepancia previa.

Los programas de modernización se complican cuando consideran obsoletos los campos extraños antes de seguir su uso. Un código de un carácter puede seleccionar una rama de cálculo, suprimir un aviso, enviar un caso a revisión manual o conservar una resolución anterior. Eliminarlo puede cambiar el pago de una persona sin causar un error de software. El programa se ejecuta, la API responde con éxito y el defecto solo aparece cuando un solicitante o un funcionario cuestionan el resultado.

Por tanto, un sustituto para las prestaciones necesita pruebas a nivel de decisión. Para cada caso registrado, capture las entradas normalizadas, la versión de las reglas, los cálculos intermedios, el importe final, el periodo de efecto, los avisos, los códigos de motivo y el envío a revisión manual. Oculte o tokenice los datos personales antes de que salgan de su límite permitido. En un entorno regulado, la infraestructura de pruebas y los modelos quizá deban ejecutarse dentro del mismo perímetro que los datos de origen.

La presión para sustituir crece cuando los cambios legislativos tardan demasiado, las interfaces antiguas impiden unir registros con seguridad, el personal ya no puede explicar ciertas rutas o se reducen las opciones de compra de la plataforma. El escrutinio público hace especialmente peligrosa una reescritura apresurada. Cambiar más rápido importa, pero reproducir las decisiones importa más.

Estos sistemas siguieron porque el riesgo era asimétrico

Mantener un entorno COBOL que funcionaba fue a menudo la decisión con sentido financiero. El coste de esperar se acumulaba despacio como mantenimiento, entregas más lentas y exposición de personal. El coste de un sustituto defectuoso llegaba de golpe en forma de saldos incorrectos, liquidaciones fallidas, cobertura equivocada o pagos mal calculados.

Varias condiciones reforzaron esa asimetría. Las funciones de transacciones y lotes del mainframe ya gestionaban la planificación, el control de acceso, la recuperación y grandes volúmenes de entrada y salida. Las actualizaciones de hardware y compilador prolongaban la plataforma sin obligar a reescribir la aplicación. Los formatos estables de archivos permitían integrar canales nuevos en el borde. Y, sobre todo, el negocio tenía pruebas de producción de que la ruta antigua funcionaba, incluidas décadas de excepciones que ningún documento de requisitos recogía.

La afirmación popular de que COBOL sobrevivió porque la dirección temía el cambio es demasiado superficial. Los directivos financiaron muchos cambios alrededor de estos núcleos. Sustituyeron terminales por interfaces web, introdujeron intermediarios de mensajes, expusieron servicios y trasladaron los informes. Evitaron sustituir el centro con estado porque el caso de negocio no compensaba el riesgo.

Otra recomendación habitual es traducir cada párrafo COBOL a código equivalente en un lenguaje nuevo. Resulta atractiva porque genera una tasa de conversión medible y mantiene el comportamiento cerca del origen. Como estado final es una mala decisión. Una traducción de párrafo a función conserva estado global, fronteras con forma de archivo, supuestos de lotes y décadas de compromisos estructurales. La organización acaba teniendo un diseño de mainframe con una sintaxis desconocida y, a menudo, peores herramientas operativas.

Una decisión sensata separa tres preguntas. ¿Es la plataforma actual lo bastante fiable para el siguiente horizonte de planificación? ¿Puede la organización cambiar las reglas de negocio a la velocidad exigida? ¿Puede recuperar y explicar fallos sin depender de una o dos personas? Un «sí» a la primera no anula un «no» a cualquiera de las otras.

La longevidad también produce una confianza falsa en la documentación. Los manuales operativos suelen describir el horario normal y el último procedimiento de recuperación que alguien se molestó en escribir. No siempre dicen por qué un total de control excluye una fuente, por qué un archivo debe llegar antes que otro o por qué un operador acepta un código de retorno distinto de cero pero se detiene ante el siguiente. Esas decisiones perviven como costumbre. Una migración las descubre cuando la ejecución paralela difiere, un momento tardío y caro.

Trate el conocimiento operativo como lógica de producción. Observe un ciclo completo, incluidos el corte, el reinicio, la conciliación, una entrada tardía y una reparación manual. Pida a los operadores que expliquen las pruebas en las que confían y conecte esas pruebas con el trabajo y los datos que las produjeron. Si alguien mantiene una hoja de cálculo privada o una lista de comandos para cerrar el día, inclúyala aunque los diagramas de arquitectura no la muestren. El sustituto necesita un control con soporte o una decisión explícita de retirar esa práctica.

No confunda un sistema silencioso con uno sencillo. Los núcleos maduros suelen parecer tranquilos porque los operadores absorben la irregularidad antes de que llegue a la gestión de incidentes. Cuente las intervenciones manuales, repeticiones, anulaciones, conciliaciones y llamadas a antiguos miembros del equipo. Esas señales muestran si la estabilidad procede del software o de personas que compensan sus carencias.

El hecho que obliga suele estar fuera del compilador COBOL

COBOL rara vez fija el plazo por sí mismo. La decisión se vuelve inevitable cuando una restricción externa elimina la opción de esperar. Un proveedor deja de mantener una base de datos, capa de pantalla, planificador o producto de integración. Una fusión exige unir dos libros mayores incompatibles. Un producto nuevo necesita actividad intradía de un núcleo nocturno. Un cambio regulatorio exige una trazabilidad que el flujo actual no puede ofrecer a un coste razonable. Un mantenedor crítico se marcha y se lleva el conocimiento de recuperación.

El coste de la plataforma puede contribuir, pero una comparación de licencias por sí sola sustenta mal una migración. Los sustitutos distribuidos tienen costes propios de cómputo, observabilidad, almacenamiento, red, seguridad y personal. Si la propuesta depende de una infraestructura inverosímilmente barata, fallará cuando lleguen el volumen y la retención de producción.

El riesgo de personal también necesita precisión. «Los programadores COBOL se jubilan» no dice a un CTO qué debe aprobar. Mida la propiedad al nivel de la función de negocio. Identifique quién puede explicar el reinicio de fin de mes, quién puede cambiar una regla de prima, quién sabe por qué un código de contabilización evita una cola y quién puede conciliar una ejecución de prestaciones. El peligro es el conocimiento concentrado, no la edad media de la comunidad de un lenguaje.

La presión arquitectónica resulta decisiva cuando toda capacidad nueva debe pasar por unas pocas fronteras rígidas de archivos o transacciones. Los equipos añaden adaptadores, duplican datos de referencia y esperan la confirmación del lote. Con el tiempo, el coste aparece como retraso del producto y ambigüedad operativa en vez de hacerlo en una factura del mainframe. En ese momento, el sustituto tiene un responsable fuera de infraestructura: el ejecutivo encargado de lanzar productos, combinar operaciones o cumplir una fecha legal.

Use un memorando sobre el hecho que obliga antes de aprobar el trabajo. Nombre la restricción, la fecha o condición que la vuelve vinculante, los resultados empresariales afectados, el periodo aceptable de convivencia y las pruebas necesarias para el cambio. Si el memorando solo dice «deuda técnica», el alcance vagará porque nadie ha definido la decisión que debe permitir el proyecto.

El riesgo de migración vive entre los componentes

Una reescritura fiable comienza por descubrir el comportamiento observable de todo el entorno. El análisis del código importa, pero el código por sí solo no revela anulaciones del planificador, acciones de operadores, formas reales de los datos, consumidores sin documentar ni reglas incrustadas en tablas. El inventario debe conectar programas con trabajos, conjuntos de datos, objetos de base de datos, colas, pantallas, informes y acuses posteriores.

Empiece por las rutas de producción en vez de las carpetas del repositorio. Para un resultado empresarial, siga el evento inicial hasta la contabilización o aviso final. Registre cada componente, entrada, salida, efecto secundario, punto de control y acción de recuperación. Repita después para las excepciones: entrada duplicada, datos de referencia ausentes, fallo parcial de la base, llegada tardía, reinicio tras crear la salida y corrección manual.

Un registro de comportamiento puede tener esta forma sencilla:

{
  "case_id": "settlement-late-file-restart",
  "inputs": ["accepted-transactions", "fee-table-v17"],
  "pre_state": "checkpoint-6-complete",
  "action": "restart-from-checkpoint-7",
  "outputs": ["posted-generation", "exception-generation"],
  "invariants": ["debits-equal-credits", "no-duplicate-posting"],
  "evidence": ["job-log", "control-report", "ledger-query"]
}

El registro es independiente de la implementación a propósito. Dice qué debe seguir siendo cierto y de dónde procede la prueba. Cree registros a partir de variantes reales de producción y añada casos límite construidos para las fronteras que el tráfico quizá no haya ejercido durante la observación.

Ejecute las rutas antigua y nueva con la misma entrada aceptada y compare resultados normalizados. La normalización debe quitar valores que pueden diferir legítimamente, como identificadores generados o marcas de tiempo, y conservar importes, fechas, estado, orden cuando sea relevante, códigos de motivo y efectos secundarios. Guarde las diferencias como artefactos revisables. Un contador verde sin el diff real anima a descartar divergencias sin explicación.

El tráfico registrado aporta pruebas sólidas, pero no es una especificación completa. Solo demuestra los casos observados. Combínelo con ramas derivadas del código, valores de copybooks, dominios de tablas, entrevistas con operadores y procedimientos de conciliación. La diferencia importa: las pruebas de repetición miden compatibilidad con el uso observado, mientras que las pruebas de reglas cubren comportamientos válidos que no aparecieron durante la captura.

La seguridad y la privacidad determinan el método. Los registros de producción pueden incluir datos de cuentas, pólizas, salud o identidad. Mantenga la captura, la tokenización, la ejecución de modelos y la comparación dentro del entorno permitido cuando los datos no puedan salir. Conserve las relaciones referenciales en los casos tokenizados o muchas reglas entre registros no se podrán probar.

La representación de datos merece una superficie de pruebas propia. Los copybooks pueden describir decimales empaquetados, campos con signo, superposiciones, grupos repetidos y valores cuyo significado depende de otro campo. Los archivos pueden usar EBCDIC, longitudes fijas o convenciones locales para los valores ausentes. Un analizador que recorta espacios o normaliza una fecha no válida sin avisar puede fusionar estados que el sistema antiguo mantenía separados. Genere casos de frontera para cada forma declarada y compare los valores leídos y registros rechazados antes de probar reglas empresariales.

Compartir copybooks no garantiza compartir significado. Un programa puede tratar un código como estado de cuenta y otro interpretar los mismos bytes como decisión de enrutamiento. Siga lecturas y escrituras, no solo nombres. Cuando los formatos hayan cambiado con el tiempo, averigüe qué productores aún pueden enviar cada versión y cómo las distinguen los consumidores. Así se evita que un modelo canónico nuevo borre información que todavía necesita un archivo tardío o una repetición histórica.

La conversión de datos y el reemplazo de aplicaciones crean riesgos distintos. Convertir un almacén histórico prueba que los registros llegan a la forma de destino. No prueba que el procesamiento de mañana vaya a crear registros nuevos correctos. Pruebe saldos iniciales y conversión histórica separados del comportamiento transaccional y únalos en un ensayo general que cruce una frontera contable o de facturación real. Concilie recuentos, totales de control, saldos, referencias sin correspondencia y cada rechazo. Un total correcto puede ocultar dos errores iguales y opuestos, así que examine también asientos y clientes.

Las pruebas de rendimiento deben reproducir la forma del trabajo, no solo su volumen medio. Una liquidación tiene picos de llegada y una hora límite de finalización. Un libro en línea exige latencia y sufre contención en cuentas populares. Un recálculo de prestaciones puede leer mucha historia y emitir varios efectos. Conserve el orden y los conflictos de bloqueo en los datos, mida el tiempo de reinicio tras un fallo e incluya el consumo posterior. Un productor rápido que satura el siguiente sistema no mejora la ruta empresarial.

Trate los códigos de retorno y mensajes para operadores como interfaces hasta que se demuestre lo contrario. Los planificadores bifurcan con ellos, los equipos de soporte los buscan y los procedimientos los usan para decidir si una salida está completa. Asigne cada condición antigua a un error tipado, una regla de reintento, una alerta y una acción de recuperación en el destino. Haga explícita la idempotencia: repetir tras un tiempo de espera no debe duplicar dinero, documentos ni excepciones.

El grupo de revisión debe incluir a quienes concilian resultados, no solo a quienes mantienen el código. Operaciones financieras puede explicar qué totales certifican la liquidación. El personal de pólizas sabe qué documentos fechados deben poder reproducirse. Los funcionarios saben qué códigos llevan a revisión manual. Sus pruebas convierten un diff técnico en una decisión de cambio. Sin ellas, el equipo puede cerrar miles de diferencias y perder la única que modifica una obligación.

Por último, fije una política para el comportamiento desconocido. Cuando la ruta antigua produzca un resultado sin explicación, no lo copie de forma automática ni lo corrija en silencio. Aísle el caso, conserve entradas y pruebas, asigne un propietario empresarial y registre el comportamiento elegido para el destino. Esta cola contendrá defectos, reglas obsoletas y excepciones legítimas. Su ritmo de cierre mide mejor la preparación que el porcentaje de archivos convertidos.

Sustituya la frontera y demuestre el cambio

El destino debe modernizar la propiedad y las interfaces mientras conserva los resultados necesarios. Defina servicios acotados en torno a capacidades empresariales, elija un modelo de datos duradero y haga explícitas las responsabilidades de lotes y en línea. No deje que la estructura antigua de programas dicte cada módulo. Sí deje que su comportamiento limite todo resultado externo relevante hasta que la empresa apruebe un cambio.

Una secuencia práctica tiene cinco partes:

1. Congele un inventario de puntos de entrada de producción, trabajos programados, almacenes y consumidores para la porción empresarial elegida.
2. Cree el arnés de paridad antes que el sustituto para que todas las decisiones de implementación reciban las mismas pruebas.
3. Implemente la arquitectura nueva detrás de adaptadores estables, incluidos reinicio, conciliación y controles operativos.
4. Ejecute los casos históricos y el tráfico de producción registrado por ambas rutas, y clasifique todas las diferencias.
5. Cambie con criterios explícitos de reversión y mantenga activa la conciliación hasta que cierre el periodo de riesgo acordado.

Elija porciones que terminen en un resultado empresarial verificable. «Convertir 200 programas» no es una porción. «Procesar una fuente de liquidación hasta la contabilización y conciliación» sí lo es. La segunda expone dependencias y da a los directivos pruebas que pueden evaluar.

CodeHero aplica este método leyendo juntos COBOL, JCL y el resto del árbol, reescribiendo la arquitectura en Go, Rust, TypeScript y Postgres, y comprobando el comportamiento con un arnés de paridad frente al tráfico de producción registrado. Sus proyectos se entregan en menos de 30 días, incluida la ejecución aislada dentro del perímetro del cliente cuando el entorno lo requiere.

La rapidez no elimina las responsabilidades del propietario durante el cambio. La organización sigue decidiendo qué comportamientos son contractuales, qué anomalías deben corregirse, qué pruebas satisfacen a los equipos de riesgo y auditoría, y quién puede autorizar la reversión. No se pueden deducir esas decisiones con seguridad a partir del código fuente.

Un sistema COBOL no debe cambiar porque su sintaxis parezca antigua. Debe hacerlo cuando la frontera actual bloquee el negocio y el sustituto pueda demostrar, caso por caso, que el dinero, los derechos, el historial, la recuperación y la explicación siguen funcionando. Apruebe la reescritura cuando se cumplan ambas condiciones.