¿Cuándo cambio el sistema operativo o aplicación de backend?

¿Cuándo cambio el sistema operativo, la versión del motor de base de datos, el del correo electrónico, etc…?

Es una pregunta básica que todo buen administrador de sistemas se tiene que hacer y poner en planificación para el cambio porque el toro no lo coja por los cuernos. Es cierto que, al menos en este país, las empresas alargan al máximo la vida de los productos, pero al igual que comerse un alimento caducado, puede tener consecuencias graves. Las últimas las hemos visto con sistemas operativos Microsoft Windows Server 2003 o algún que otro Windows Server 2008 que se han visto afectados por 0-days (vulnerabilidades no conocidas) y que han sido aprovechados para colarse el ransomware (software malicioso) de cifrado de equipos.

Sí, los productos de software también tienen fecha de caducidad. Lo sabéis bien, los sistemas informáticos necesitan de mantenimiento. Ya sea mediante actualizaciones sobre la versión instalada o un cambio de la misma porque su ciclo de vida ya ha llegado a su fin. Al igual que cualquier otro elemento que podemos tener en nuestras oficinas o fábricas, nada es eterno. Y hoy en día, en la mayoría de empresas, el sistema informático se ha convertido en el corazón de la empresa. ¡No lo abandonéis a su suerte! ¿Cuántos de vosotros tenéis sistemas que no se pueden ni mirar porque están cogidos con pinzas y nadie responde ante un problema que pueda tener el mismo? Aquel equipo que controla la máquina de corte, la que hace las medidas químicas, la de formulación de las mezclas, la de control de bombas, la gestión de los TPVs, el propio ERP, etc…

Alargar la vida del producto se puede hacer dentro de unos márgenes razonables, pero poner en riesgo el negocio por un despiste de este tipo que puede tener consecuencias muy graves que no os lo podéis permitir.

¡Y aquí está la pregunta del millón! ¿Cuándo debo de hacer algo?

¿Cuáles son los márgenes razonables para decidir cuando cambio?

Los fabricantes de software, normalmente, trabajan con dos fechas: la fecha de fin de soporte del producto y la fecha de fin del mantenimiento extendido.

La primera, fecha de fin de soporte, hace referencia a la mayoría de actualizaciones y corrección de errores que pueda tener el software. Podemos decir que es su ciclo de vida normal, donde tiene que funcionar al 100%.

La segunda, fecha de fin del mantenimiento extendido, ya sólo se sacan actualizaciones muy críticas referentes a la seguridad del producto. Podemos decir que es el período de retirada del producto, donde todavía funciona al 90%, pero que cada día que pasa va de caída. Es en este período que se tiene que hacer la sustitución de los elementos.

Más allá de la fecha de fin del mantenimiento extendido, ya es territorio desconocido donde puede pasar cualquier cosa. Aquí nadie se hace responsable, menos tu, más sólo que la una, que tienes que responder delante de la dirección de lo que puede pasar, está pasando o ha pasado. Muchos os plantéais hacer el cambio en esta zona, porque el toro me está tocando con el cuerno. Por mi experiencia os diré que es eso, es vivir al límite, porque me gusta el riesgo. A algunos les sale bien, pero muchos otros tienen graves problemas por no haberlo hecho antes.

Quizás aquí soy un poco paternalista, pero por favor, sed previsores y haced vuestra planificación con antelación. Informando y trasladando la responsabilidad de los riesgos y posibles consecuencias que se derivan de la decisión a la dirección de la empresa, porque afecta directamente al negocio. Que sea la dirección los que tengan la responsabilidad de mantener un sistema obsoleto, siendo conscientes de lo que significa. Para los que estáis en sitios de dirección y estáis leyendo esta entrada, tener un sistema obsoleto no es broma. Mientras funciona, todo va bien, pero cuando lo deja de hacer, y lo hace en el momento más inesperado y inoportuno acostumbra a ser muy problemático. No son pocas las veces que lo he visto, la mayoría con parada de producción o todos de brazos cruzados, intentando salvar lo que es muy difícil de salvar con parches: haciendo un bypass, una venda por aquí, una operación por allá… algunos siguen unos días más, otros simplemente han callado para siempre. En definitiva todo sale muy caro por no haberlo planificado antes.

Fechas que debo tener en cuenta para planificar cuando cambio

Os dejo un cuadro con las fechas importantes de algunos sistemas críticos que podéis tener. Empezando por los Centros de Proceso de Datos (CPDs), vaya el núcleo y sobre todo los sistemas operativos de los servidores.

Subrayados en:

• rojo los que ya no debo tener.
• naranja los que debo estar migrando.

Microsoft

VMware

VMware

¿Te ha gustado el artículo? Lo puedes compartir en las redes sociales. También puedes dejar tu opinión, comentario o sugerencia. ¡Gracias!

Similar Posts by The Author:

• Microsoft SQL Server con SMB3
• Microsoft SQL Server amb SMB3
• Containers en Linux
• Containers amb Linux
• Migrar el servidor de archivos a Windows Server 2019
• Migrar el servidor de fitxers a Windows Server 2019
• Puerta enlace a Azure en el Windows Admin Center
• Porta enllaç a Azure en el Windows Admin Center
• Hola mundo! WordPress 5 y Gutenberg
• Hola món! WordPress 5 i Gutenberg