Aplicaciones sin soporte: El riesgo de la obsolescencia que aparece hasta la auditoría

Introducción

La mayoría de las aplicaciones que sostienen la operación de una organización funcionan. Registran, calculan, concilian y generan reportes todos los días. Justamente por eso es fácil perder de vista una fecha que no aparece en ningún tablero de operación: el día en que el fabricante deja de dar soporte a la plataforma sobre la que corren.

Ese día no pasa nada visible. La aplicación sigue encendida y los usuarios no notan el cambio. El riesgo aparece después, cuando alguien compara el inventario de aplicaciones con los calendarios de soporte: una auditoría, una revisión de seguridad o la respuesta a un incidente.

Un ejemplo cercano: según la política de soporte de Microsoft, .NET 8 y .NET 9 dejan de tener soporte el 10 de noviembre de 2026. Si tienes aplicaciones en esas versiones, a partir de esa fecha ya no hay correcciones del fabricante para ellas. En este artículo revisamos qué significa operar sin soporte, por qué se vuelve visible hasta la auditoría y cómo decidir qué hacer con cada aplicación.

Sin soporte no es lo mismo que sin funcionar

Cuando una versión llega al fin de su soporte, el fabricante deja de publicar correcciones para ella. La aplicación no se apaga, pero queda expuesta de varias formas:

• Vulnerabilidades sin corrección: lo que se descubra después de esa fecha no se corrige para esa versión.

• Compatibilidad: los sistemas operativos, las bases de datos, los navegadores y las bibliotecas siguen avanzando, y la aplicación se queda atrás.

• Atención de incidentes: si algo falla en la plataforma, ya no hay a quién escalarlo con el fabricante.

• Dependencia de personas: con el tiempo, menos gente conoce la tecnología y cada cambio depende de una o dos personas.

Además, una aplicación no es una sola pieza. Corre sobre un entorno de ejecución (.NET o Java), un sistema operativo, una base de datos y un conjunto de bibliotecas, y cada uno tiene su propio calendario. Basta con que una de esas piezas pierda el soporte para que la aplicación completa quede en riesgo.

Fechas que conviene tener a la vista

Estas son algunas fechas de los calendarios oficiales de Microsoft y Oracle, consultadas el 30 de octubre de 2026:

Dos precisiones. Primero, los fabricantes pueden cambiar sus fechas, así que conviene consultarlas en la fuente al momento de decidir. Segundo, si tu organización usa distribuciones de Java de otros proveedores, cada una tiene su propio calendario. Lo importante no es memorizar la tabla, sino saber en qué fila está cada una de tus aplicaciones. 

Por qué el riesgo aparece hasta la auditoría

La obsolescencia no provoca una caída ni una queja de los usuarios, así que no aparece en los indicadores de operación. Se vuelve visible cuando alguien la busca, y las auditorías de TI y de seguridad la buscan porque los marcos de referencia que usan lo piden de forma explícita:

• CIS Controls v8, salvaguarda 2.2: solo el software con soporte vigente debe estar autorizado en el inventario. Si una aplicación sin soporte es necesaria para la operación, se documenta una excepción con sus controles de mitigación y el riesgo residual aceptado. La lista se revisa al menos una vez al mes.

• NIST SP 800-53, control SA-22: los componentes sin soporte del fabricante se reemplazan o se respaldan con una fuente alternativa de soporte, interna o externa.

Por eso, las preguntas de una auditoría suelen ser muy concretas: ¿tienes un inventario de aplicaciones con la versión de cada componente? ¿Sabes cuáles ya no tienen soporte? ¿Hay una excepción documentada para cada una? ¿Quién aceptó el riesgo? ¿Existe un plan con fecha para resolverlo?

Para las áreas de Cumplimiento, Riesgos y Gobierno, el hallazgo rara vez es "usan tecnología antigua". Lo que se observa es que no hay una decisión documentada. Ayuda a definir responsabilidades claras: TI mantiene el inventario y el estado de soporte; Riesgos o Cumplimiento válida la excepción y el riesgo que se acepta; la dirección aprueba el plan y el presupuesto. Con eso, una aplicación sin soporte deja de ser una sorpresa y se convierte en un riesgo administrado.

El costo de esperar

Posponer la decisión también cuesta, aunque no aparezca en el presupuesto del año. En un estudio de 2020, McKinsey reporta que los directores de TI estimaron que la deuda técnica equivale a entre el 20 y el 40 % del valor de todo su portafolio tecnológico, y que entre el 10 y el 20 % del presupuesto destinado a productos nuevos se desvía a resolver problemas relacionados con esa deuda.

En la práctica, el costo de esperar se ve así: cambios que tardan más de lo que el negocio necesita, integraciones que no se pueden actualizar porque la plataforma no lo permite, conocimiento concentrado en pocas personas y, al final, una actualización que se hace con prisa porque llegó un hallazgo o un incidente. Una migración urgente casi siempre sale más cara y más riesgosa que una planeada.

Actualizar, contener o modernizar: cómo decidir

No todas las aplicaciones sin soporte necesitan el mismo tratamiento. Hay tres caminos razonables:

Si la aplicación se va a retirar en pocos meses o el salto de versión es menor, no necesitas un proyecto de modernización: actualiza o documenta la excepción. La modernización se justifica cuando la plataforma ya no tiene una ruta de actualización razonable o cuando la aplicación tiene que seguir evolucionando y ya no puede hacerlo al ritmo del negocio.

Para empezar, cuatro pasos sencillos:

1. Haz el inventario de tus aplicaciones críticas con la versión de cada componente.

2. Cruza ese inventario con los calendarios oficiales de soporte.

3. Clasifica cada aplicación por criticidad y por la fecha de fin de soporte.

4. Decide el camino para cada una y documenta la decisión, el responsable y la fecha.

Cómo ayuda Quality Consulting

En Quality Consulting modernizamos sistemas legados a Java y .NET: actualizamos aplicaciones obsoletas o sin soporte conservando sus procesos y reglas de negocio, sin detener la operación, y en el mismo proyecto las evolucionamos para que atiendan lo que el negocio necesita hoy.

• Fortaleza técnica en los ecosistemas Java y .NET.

• Modernización que conserva los procesos y las reglas de negocio que ya funcionan.

• Trabajo planeado para que la operación no se detenga durante el proyecto.

• Procesos de desarrollo con certificación CMMI vigente.

• Experiencia en sistemas críticos del sector financiero: más de 15 años de conocimiento de la plataforma de Nafin y proyectos con otras instituciones financieras.

Cierre

La pregunta no es si tus aplicaciones funcionan, sino si sabes cuáles ya no tienen soporte y qué decidiste hacer con cada una. Es mejor responderla antes de que la haga un auditor.

Si ya identificaste una aplicación en esta situación y quieres revisar tus opciones, platiquemos. Conoce cómo trabajamos en https://cequalityconsulting.mx/desarrollo-de-software

Fuentes de referencia:

• Microsoft. Política de soporte de .NET y .NET Framework. https://dotnet.microsoft.com/platform/support/policy (consultada el 30/10/2026).

• Microsoft. Ciclo de vida de Windows Server 2016. https://learn.microsoft.com/lifecycle/products/windows-server-2016 (consultada el 30/10/2026).

• Microsoft. Ciclo de vida de SQL Server 2016. https://learn.microsoft.com/lifecycle/products/sql-server-2016 (consultada el 30/10/2026).

• Oracle. Oracle Java SE Support Roadmap. https://www.oracle.com/java/technologies/java-se-support-roadmap.html (consultada el 30/10/2026).

• Center for Internet Security. CIS Controls v8, salvaguarda 2.2 "Ensure Authorized Software is Currently Supported". https://controls-assessment-specification.readthedocs.io/en/latest/control-2/control-2.2.html

• NIST. SP 800-53 Rev. 5, control SA-22 "Unsupported System Components". https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

• McKinsey & Company. "Tech debt: Reclaiming tech equity", 6 de octubre de 2020. https://www.mckinsey.com/capabilities/operations/our-insights/tech-debt-reclaiming-tech-equity