¿Buenas prácticas con respecto al software descontinuado en producción (OpenDS)?

¿Qué tan malo es usar OpenDS , que no se mantiene activamente, y tuvo el último parche en 2010, y requiere JDK6 (que también es obsoleto) en un entorno de producción? (Aunque en el backend y no directamente expuesto a los usuarios finales )

Si ya está allí, ¿generalmente vale la pena el tiempo y el dinero necesarios para encontrar un reemplazo, ejecutar pruebas de integración y demás? ¿Cuáles son los criterios comunes para dar este paso con respecto al software obsoleto en la producción en general?

Le sugiero que evalúe esto en términos de riesgo comercial / operativo.

El uso de software antiguo y no compatible a menudo conlleva estos riesgos potenciales.

• Sin soporte de proveedores
• No hay actualizaciones de errores.
• Sin parches de seguridad
• Las actualizaciones del sistema operativo pueden ser incompatibles
• Las opciones de recuperación ante desastres pueden ser limitadas.
• Los problemas de licencia pueden causar problemas operativos / de recuperación.
• Incapacidad para escalar / expandir operaciones basadas en este servicio.

Los dos últimos a menudo se pasan por alto.

Hace años, tuve un caso en el que un cliente usaba software MTA heredado y propietario. Aseguraron un nuevo contrato importante de marketing por correo electrónico y necesitaron aumentar rápidamente su granja de servidores de correo.

No pudieron obtener una licencia para su MTA. La MTA tenía ciertas características y una API especial que se integraba profundamente en su plataforma de marketing por correo electrónico.

Tuvimos que clonar discos manualmente y colocarlos en nuevos servidores más potentes para escalar el sistema. Hacer girar un nuevo servidor habría tenido más sentido, pero no era una solución viable debido al software heredado.

Entonces, si no planea actualizar pronto, es posible que deba evaluar los riesgos y al menos tener planes tentativos sobre cómo mitigar los problemas en caso de que surjan.

La gente suele mencionar la seguridad. Sin embargo, el software antiguo, siempre que no tenga exploits activos conocidos, no es inherentemente más seguro que un reemplazo moderno.

El riesgo de seguridad no es que el software pueda ser explotado, sino que no tiene un recurso fácil si se identifica un problema de seguridad.

Personalmente, preferiría actualizar algún componente clave de las operaciones de manera planificada que tratar de diseñar con urgencia una nueva solución.