Obsolescencia Tecnológica: La amenaza silenciosa.

English Português

La obsolescencia tecnológica es una amenaza latente en empresas de todos los sectores. Qué es, cuáles son los riesgos reales y qué estrategias existen para modernizar sistemas de misión crítica con el corte acotado y bajo control.

La obsolescencia tecnológica es una amenaza silenciosa que está presente en organizaciones de todos los sectores de actividad. La tecnología legada (“legacy” en inglés) hace referencia a infraestructura IT, sistemas, procesos de negocios que [1]:

  • Son imposibles de actualizar.
  • No son soportados por el proveedor.
  • El costo/beneficio ya no es viable para el contexto de la organización.
  • Están por encima de los umbrales de riesgo aceptables.

Una referencia obligada cuando se habla de legacy es el lenguaje de programación COBOL [2]. Miles de millones de líneas de código COBOL siguen operando de manera discreta pero eficiente en sectores vitales como la banca, salud y el transporte a nivel mundial.

Digital Equipment Corporation (DEC) tuvo la visión audaz de democratizar las computadoras de alta performance. Habilitó a que científicos, emprendedores y la industria pudieran acceder a capacidades de cómputo a costos mucho menores que las alternativas que ofrecían las grandes corporaciones [3]. Habiendo pasado por muchas manos, el hardware DEC y su último sobreviviente, el sistema operativo OpenVMS, ya son irreversiblemente historia.

Otros que brillaron en su momento fueron SUN Microsystems y su sistema operativo Solaris [4], cuya tecnología fue relevante en la evolución de Internet; pero también les llegó su ocaso [5].

Más allá del COBOL, DEC y Solaris, hay multitud de lenguajes, sistemas operativos y dispositivos (hardware) que fueron tecnologías innovadoras y referentes de mercado en su momento. En muchos más casos de los que el común de la gente se imagina, estas y otras tecnologías legacy siguen siendo, en Uruguay y en el mundo, pilares fundamentales en la operación de empresas financieras, de seguros, de salud e instituciones estatales aún hoy en 2025 pese a ya no estar soportadas.

Ninguna entidad que tenga obsolescencia tecnológica va a disfrutar compartiendo sus desafíos, pero hay casos que terminan tomando estado público como lo fue la iniciativa de Elon Musk con DOGE para reescribir millones de líneas de código del Seguro Social de Estados Unidos [6].

Riesgos de la obsolescencia

Mantener infraestructuras informáticas antiguas implica exponer a la organización a múltiples amenazas. Los sistemas legacy fueron diseñados en contextos de seguridad y funcionalidad muy distintos a los actuales, lo que los convierte en objetivos prioritarios para ataques cibernéticos. La falta de actualizaciones y parches de seguridad, sumada a la incompatibilidad con tecnologías modernas, abre la puerta a fallos graves, pérdida de datos, disrupciones operativas y altos costes de remediación.

La situación se agrava cuando la tecnología obsoleta convive con sistemas modernos, ya que un solo punto vulnerable puede comprometer el resto del entorno TI. Según datos recientes, el primer semestre de 2025 registró un aumento del 256% en incidentes de seguridad informática en Uruguay [7], siendo los sistemas legacy el eslabón más débil [8].

Un informe reciente de la U.S. Government Accountability Office (GAO) [9] señala que el gobierno de EE. UU. gasta más de $100 mil millones anualmente en TI, destinando la mayor parte al mantenimiento de sistemas legacy obsoletos y vulnerables. Una revisión de 11 de los sistemas federales más críticos reveló que solo tres agencias tenían planes de modernización bien documentados.

Pero los riesgos van mucho más allá del cibercrimen. Quedar atado a estas tecnologías legacy hace que muchas veces las empresas no puedan seguir el ritmo de las necesidades del mercado y pierdan competitividad. También la dependencia de aplicaciones de décadas de antigüedad se ve afectada por la escasez de habilidades necesarias para mantenerlas, ya que el soporte tradicional está desvaneciéndose. Esto crea una cultura de navegación a ciegas y dependencia de unos pocos “guardianes” del conocimiento esencial, perdiendo la intención original del programador que construyó el sistema.

Opciones estratégicas para afrontar la obsolescencia

Las razones por las que se llega a esta situación de “Deuda Técnica” [10] son muchas, pero una de las más fuertes es evitar el riesgo asociado al cambio. Los temores al cambio no son infundados. Pese a no haber estadísticas concluyentes, hay múltiples casos en los cuales las migraciones a nuevos entornos fueron un total fracaso; por ejemplo, el de TSB en 2018 [11].

A continuación, comentamos algunas de las estrategias consideradas para enfrentar la obsolescencia:

Comprar

Muchas empresas desarrollaron sus propias aplicaciones dado que en el momento que iniciaron no había ofertas de productos en el mercado. Actualmente existen productos “world class” que atienden las mejores prácticas de la industria, pero el desafío de adaptar la cultura y personalizaciones de una operación de décadas hace que implementar estos productos sea un desafío mayor.

Tercerizar

Con la evolución de la nube (SaaS [12]), hay una tendencia a “alquilar” el derecho a uso de soluciones de terceros. Esta opción, aunque tentadora, tiene consideraciones críticas de cumplimiento legal, soberanía y secretos industriales [13].

Modernizar

Esta opción reconoce que estos sistemas son el “ADN digital” de la empresa. No todos los componentes en un entorno legacy están necesariamente obsoletos. Modernizar implica:

  • Refactorizar: mejorar la calidad y mantenibilidad del código sin cambiar su funcionalidad.
  • Reescribir: sustituir la aplicación por una nueva solución desde cero.
  • Re-plataformar: migrar la aplicación a una nueva plataforma (ej. Mainframe a Nube) con cambios mínimos.

Conclusión

La obsolescencia tecnológica es una amenaza que puede poner en jaque la seguridad, resiliencia y competitividad. No existe una receta única: cada plataforma y cada empresa tiene necesidades específicas. Es fundamental que estos proyectos se encaren con equipos que posean experiencia probada en modernizaciones y migraciones de alto impacto.

Afrontar este reto es clave para garantizar la continuidad del negocio y estar preparados para la creciente sofisticación del cibercrimen.


Publicación Original (AIU)


Este artículo fue publicado originalmente en la revista de la Asociación de Ingenieros del Uruguay (AIU).

JAAB Tech + EBS

Desde JAAB Tech, potenciados por la experiencia internacional de EBS, podemos apoyar a su organización a superar estos desafíos de obsolescencia con estrategias probadas de modernización.

Conozca nuestra solución de Modernización

Preguntas frecuentes

¿Qué es la obsolescencia tecnológica?
Es la condición de un sistema que dejó de ser sostenible por su costo, su riesgo o su falta de soporte, no simplemente la de un sistema viejo. El gobierno británico define cinco criterios y alcanza con cumplir uno: que el producto haya llegado al fin de su vida útil, que no tenga soporte del proveedor, que sea imposible de actualizar, que tenga una mala relación costo-beneficio, o que esté por encima del riesgo aceptable para la organización. Un sistema de 40 años con soporte y riesgo controlado no es obsoleto; uno de 8 años sin nadie que lo entienda, sí.
¿Qué es un sistema legacy?
La definición más útil es la de Michael Feathers: código que da miedo cambiar porque ya no se comprenden del todo sus efectos colaterales. Lo importante de esa formulación es que el problema no está en la antigüedad del código sino en el conocimiento que se perdió sobre él. Por eso legacy no es sinónimo de viejo: es una posición frente al riesgo y al costo.
¿Por qué siguen funcionando sistemas de hace décadas?
Por tres razones que suelen subestimarse. Rendimiento, porque para cargas transaccionales con garantías ACID el mainframe todavía sostiene volúmenes y latencias difíciles de igualar. Lógica de negocio, porque el código acumula reglas, regulaciones y excepciones de 30 o 40 años, a veces escritas por personas que ya se jubilaron y sin documentar en ningún otro lado. Y costo de reemplazo, porque reescribir algo que funciona se percibe como un suicidio financiero. Quien dejó ese sistema en pie muchas veces tomó la decisión correcta para su contexto; el problema es el tiempo transcurrido desde entonces.
¿Cuándo conviene modernizar un sistema crítico?
El disparador casi nunca es una decisión técnica interna, sino un evento externo. Los cuatro más frecuentes son la obsolescencia del hardware, cuando escasean los repuestos y se termina el soporte del fabricante; la pérdida de competitividad, cuando el time-to-market se vuelve lento o resulta imposible integrar capacidades nuevas; una fusión o adquisición que obliga a unificar plataformas; y la regulación, cuando aparece una normativa que el sistema actual no puede cumplir. Esperar al evento significa modernizar bajo presión, que es la peor condición posible.
¿Se puede modernizar sin detener la operación?
No se puede prometer que no exista ningún corte, y quien lo promete está vendiendo. Lo que sí se puede es acotarlo, ensayarlo y dejarlo reversible. Eso implica descartar el reemplazo total en una sola entrega, que tiene tasas de fracaso de hasta el 70% y cuyo caso canónico es el banco británico TSB, con 330 millones de libras en pérdidas tras una migración de fin de semana sin ejecución en paralelo ni vuelta atrás. La alternativa es la modernización continua: ciclos cortos, incrementales y reversibles, donde cada entrega reduce riesgo en lugar de acumularlo hasta un único día crítico.
¿La inteligencia artificial puede migrar COBOL sola?
La IA acelera estos procesos, sin ninguna duda, y es especialmente buena para leer, mapear y documentar un sistema que ya nadie termina de comprender. Lo que no reemplaza es la experiencia y la responsabilidad humana sobre el resultado, y hay mediciones que lo respaldan: un análisis de marzo de 2026 sobre programas COBOL reales del sistema Medicare encontró que la herramienta cubrió entre el 24% y el 35% de los párrafos, introdujo nueve errores en montos regulatorios al ignorar una condición, y produjo un 42% de variación entre ejecuciones idénticas sobre el mismo código. Además, migrar una plataforma que lleva décadas en producción es mucho más que traducir de un lenguaje a otro. Hay reglas de negocio que no están escritas en ningún lado, obligaciones regulatorias, dependencias con terceros, procesos y personas alrededor del sistema, y sobre todo una gestión del riesgo que alguien tiene que asumir y sostener durante todo el recorrido.
Etiquetas
  • leadership
  • legacy
  • security

← Volver al blog

Agendar una reunión