Recibe toda la actualidad del sector tech y cloud en tu email de la mano de RevistaCloud.com.

Suscripción boletín

El desafío de reescribir el corazón digital de la Seguridad Social: ¿puede Estados Unidos abandonar COBOL sin provocar el caos?

El gobierno de Estados Unidos, a través del recién creado Departamento de Eficiencia Gubernamental (DOGE), ha lanzado una iniciativa que ha encendido todas las alarmas en la comunidad tecnológica: reescribir el código base de los sistemas de la Administración de la Seguridad Social (SSA) en un plazo de apenas unos meses. El anuncio ha generado preocupación entre ingenieros de software, especialistas en sistemas legacy y expertos en infraestructura crítica, que consideran el plan no solo apresurado, sino potencialmente desastroso.

El motivo de fondo es conocido: el núcleo del sistema que gestiona las pensiones y prestaciones sociales de más de 70 millones de personas en Estados Unidos está escrito en COBOL (Common Business Oriented Language), un lenguaje de programación creado en 1959 para aplicaciones de contabilidad, finanzas y procesamiento masivo de datos. Su diseño orientado a la legibilidad y fiabilidad lo convirtió en el estándar de facto para instituciones financieras y gubernamentales durante gran parte del siglo XX.

A lo largo de décadas, COBOL se ha consolidado como una piedra angular del software crítico. Según estimaciones del sector, más de 800.000 millones de líneas de código COBOL siguen activas en todo el mundo, muchas de ellas en sistemas que no pueden permitirse fallos: bancos, aseguradoras, aerolíneas, y, por supuesto, agencias estatales. En el caso de la Seguridad Social estadounidense, el sistema contiene decenas de millones de líneas escritas en COBOL, interconectadas con bases de datos, registros históricos y procesos automatizados que llevan funcionando sin interrupciones desde hace más de 40 años.

Una migración compleja y de alto riesgo

Cambiar este sistema por uno nuevo no es tan simple como traducir código. Implica recrear toda la lógica empresarial y las reglas de procesamiento, línea por línea, con extrema precisión. “Se trata de décadas de validaciones, cálculos actuariales, ajustes legales y gestión de excepciones codificadas cuidadosamente a lo largo del tiempo”, explica una experta en modernización de sistemas gubernamentales. “Cualquier error puede interrumpir pagos, duplicar prestaciones o incluso eliminar registros”.

Además, el conocimiento institucional sobre COBOL es cada vez más escaso. Muchos de los ingenieros que lo dominaron se han jubilado o han cambiado de sector. La falta de personal capacitado hace que cualquier migración requiera un esfuerzo adicional de documentación, ingeniería inversa y validación paralela. Intentar hacerlo en unos pocos meses, como plantea DOGE, contradice la experiencia acumulada en el sector, que recomienda procesos de entre 3 y 7 años para transiciones seguras en sistemas legacy críticos.

Un ejemplo reciente ilustra los riesgos: durante la pandemia de COVID-19, varios sistemas de prestaciones por desempleo escritos en COBOL colapsaron ante la avalancha de solicitudes, y la escasez de personal cualificado impidió adaptar el software con rapidez. A raíz de esa crisis, algunas agencias comenzaron proyectos piloto de modernización gradual, incorporando capas intermedias y APIs sin eliminar del todo el núcleo COBOL. Ese enfoque híbrido ha demostrado ser más seguro y sostenible que la reescritura total inmediata.

¿Por qué no simplemente “modernizar”?

Una de las razones por las que los sistemas COBOL siguen en funcionamiento es su fiabilidad probada. Se estima que muchas aplicaciones críticas escritas en COBOL tienen tasas de error inferiores al 0,1 %, una cifra que muchos desarrollos modernos aún no alcanzan. Además, al estar diseñado para ejecutar tareas secuenciales masivas, COBOL sigue siendo eficiente en operaciones de cálculo intensivo, como las que requiere la SSA.

La modernización puede tomar diversas formas: desde emulación en la nube, hasta reescritura modular por microservicios o integración progresiva de nuevas interfaces. Sin embargo, todos los enfoques comparten un principio: respetar el tiempo necesario para auditar, validar, probar y formar al personal técnico. El plan de DOGE, por el contrario, plantea una transición inmediata, lo que hace temer errores no detectados, pérdida de datos históricos o incluso brechas de seguridad.

Una cuestión de política tecnológica

El trasfondo de esta decisión es también político. Bajo el discurso de “eficiencia gubernamental” y modernización, DOGE intenta mostrar una administración ágil y orientada a resultados. Sin embargo, varios analistas advierten del peligro de confundir velocidad con eficacia, especialmente en contextos donde la estabilidad del sistema es una prioridad absoluta.

De hecho, la reescritura de sistemas en COBOL se ha convertido en uno de los grandes debates de la ingeniería de software en la administración pública. Países como Alemania o Japón han optado por mantener COBOL con refuerzos progresivos, mientras que otras naciones han fracasado en intentos de reemplazo completo, como fue el caso del sistema de impuestos de Canadá en la década de 2000, que tras una década y miles de millones de dólares invertidos, terminó retornando a su arquitectura COBOL.

Conclusión

En un momento en que la sociedad depende más que nunca de servicios digitales estables, la migración del código base de la Seguridad Social estadounidense debe afrontarse con responsabilidad técnica, visión a largo plazo y sin atajos. COBOL, pese a sus décadas de antigüedad, sigue cumpliendo su función con eficiencia y robustez.

La propuesta de DOGE, en lugar de representar un salto hacia la modernización, puede convertirse en una peligrosa apuesta con consecuencias incalculables. Como recuerdan muchos ingenieros veteranos: “Si no está roto, no lo reescribas a toda prisa”.

Fuente: COBOL y los sistemas críticos