Cómo estimar el impacto de una dependencia tecnológica sin soporte

Confirma la situación exacta

Registra fabricante, producto, versión, edición y fecha de fin de soporte desde su información oficial. Comprueba si hay un acuerdo aplicable que cambie la cobertura y qué cubre realmente. No confundas que el proveedor responda consultas con que publique correcciones de seguridad. Microsoft explica que al terminar el soporte ordinario dejan de publicarse nuevas actualizaciones, incluidas las de seguridad, y que las opciones de actualización extendida existen solo para determinados productos. Comprueba la política del fabricante concreto.

Sigue las dependencias hacia el negocio

Localiza las aplicaciones que utilizan el componente y los procesos que consumen sus resultados. Incluye integraciones indirectas, tareas programadas y conocimiento que solo conserva una persona. Pregunta qué ocurre si deja de funcionar durante un día relevante: qué operaciones se detienen y cuáles pueden hacerse manualmente. Evita inventar pérdidas económicas; pide al propietario del proceso que valide cantidades, plazos y límites de la alternativa.

Valora exposición y recuperación por separado

Revisa desde dónde puede alcanzarse, qué identidades lo administran y qué datos maneja. Después comprueba copia, instalación disponible, credenciales custodiadas y posibilidad de restaurar en un entorno compatible. Aislarlo puede reducir exposición, pero no crea parches ni garantiza que puedas recuperarlo. Una copia de archivos tampoco demuestra que una aplicación antigua arrancará con hardware o dependencias nuevas. Ensaya una recuperación cuando resulte viable y autorizado.

Presenta una decisión con fecha

Compara actualización, sustitución, retirada y continuidad temporal. Para cada opción incluye dependencias, coste estimado y prueba de aceptación. Si mantienes el componente, nombra al responsable que acepta el riesgo, fija medidas concretas y una fecha de salida o revisión. No conviertas una limitación temporal en permiso indefinido. Escala antes si cambia la exposición, falla una recuperación o aparece información que invalida las condiciones con las que se aceptó continuar.

Una ficha de dependencia que evite falsas certezas

La ficha debe incluir componente, versión, servicio consumidor, exposición, fecha de soporte, recuperación probada y alternativa. En un ejemplo hipotético, una aplicación antigua depende de un motor que no puede actualizarse sin cambiar el conector. El plan no puede terminar en «actualizar motor»: necesita validar el conector, migrar los datos pertinentes y ensayar las operaciones que lo utilizan. Registra qué proveedor debe confirmar cada compatibilidad.

Si mantienes temporalmente la dependencia, define qué cambios invalidan la aprobación: una nueva conexión externa, un proceso adicional o una copia que deja de restaurar. Comprueba estas condiciones en la revisión prevista. Aceptar riesgo no es una tarea exclusiva del técnico que mantiene el sistema; debe participar quien responde por el proceso afectado y puede asignar recursos a la salida. Evita compensar todas las carencias con la palabra «aislado». Describe las conexiones que siguen existiendo y qué medida concreta reduce cada exposición, junto con los riesgos que permanecen.

Fuentes y documentación

• Microsoft: fin de soporte y retirada de productos — El fin de soporte ordinario termina nuevas actualizaciones y soporte asistido; las opciones ESU solo existen para determinados productos.
• NIST SP 800-34 Rev. 1: contingencia — Marco voluntario de análisis de impacto, recuperación, pruebas y mantenimiento de planes.