La doble deuda técnica: cuando el hardware viejo y el software sin soporte fallan juntos

Renovar los servidores resuelve la mitad del problema. La otra mitad vive en el software que corre encima: el hipervisor, los sistemas operativos, los drivers, los respaldos, la red y las aplicaciones que dependen de todo lo anterior. Cuando el hardware y el software llegan al fin de soporte al mismo tiempo, no fallan por separado: se amarran entre sí. Si tus hosts todavía corren VMware ESXi 7, llevan sin parches de seguridad desde el 2 de octubre de 2025, y actualizarlos casi nunca es tan simple como descargar una versión nueva.

¿Qué es la doble deuda técnica?

Es la combinación de dos deudas que normalmente se analizan por separado. La primera es de hardware: servidores, storage y equipos de red que el fabricante ya no soporta, sin refacciones garantizadas ni actualizaciones de firmware. La segunda es de software: hipervisores, sistemas operativos y aplicaciones que ya no reciben parches.

Cada una por su lado es manejable. Juntas se vuelven un nudo, porque cada mitad bloquea la solución de la otra. Ya hablamos de la deuda técnica como costo invisible y de cuándo reparar o reemplazar un servidor; aquí el foco es qué pasa cuando las dos coinciden.

¿Por qué no basta con cambiar los servidores?

Porque el camino natural para salir de ESXi 7 pasa por hardware nuevo, y el hardware nuevo no resuelve lo que corre encima. Broadcom documenta que vSphere 8 dejó de soportar los procesadores que sus fabricantes ya marcaron como fin de vida, y que VCF 9 directamente no se instala en servidores con esos procesadores. Es decir: el software no se puede actualizar sin cambiar el hardware, pero cambiar el hardware tampoco arregla, por sí solo, nada de lo siguiente:

• Sistemas operativos invitados sin soporte. Un Windows Server 2012 que sostiene el ERP no se vuelve más seguro por correr en un servidor nuevo.
• Identidades. Controladores de Active Directory, cuentas de servicio y credenciales heredadas que nadie ha rotado en años.
• Drivers y firmware. Un servidor nuevo con firmware sin actualizar arranca con la deuda ya instalada.
• Respaldos. Si el servidor de respaldos y el repositorio inmutable viven en el mismo hipervisor que protegen, un ataque a esa capa se los lleva a todos. Lo explicamos en ransomware a nivel hipervisor.
• Red. Un chasis de switch puede seguir vigente mientras sus módulos de primera generación ya perdieron soporte.
• Dependencias no documentadas. La aplicación que solo funciona con cierta versión de un driver, o el proceso nocturno que nadie recuerda quién configuró.

¿Qué fechas de fin de soporte ya pasaron o están por pasar?

Estas son fechas publicadas por los propios fabricantes para componentes que todavía encontramos en operación:

Ninguna de estas fechas significa que el equipo se apaga ese día. Significa que, a partir de ahí, cualquier falla o vulnerabilidad nueva la resuelves con tus propios medios.

¿Cómo se ve cuando fallan juntos?

El caso típico no es un apagón espectacular, sino una cadena. Decides migrar porque el hipervisor ya no recibe parches. Para migrar necesitas crear espacio nuevo en el storage, pero el arreglo ya no tiene bahías libres y tampoco soporte del fabricante. Durante la migración, los discos más viejos trabajan con una carga de lectura y escritura que no habían tenido en años, y uno con sectores dañados falla a mitad del proceso. Mientras tanto, el servidor del ERP no se puede actualizar porque la aplicación solo corre en su sistema operativo actual.

Ninguno de esos problemas es grave por sí solo. Juntos convierten un proyecto de fin de semana en un incidente. Por eso vale la pena revisar la capacidad real de tus hosts antes de fijar fechas.

¿Por dónde se empieza a salir de la doble deuda?

El orden importa más que la velocidad. Esta es la secuencia que usamos:

1. Descubrir. Inventario completo, incluidos los servidores físicos y no solo las máquinas virtuales; versiones de firmware, horas de encendido de los discos y el mapa de qué depende de qué.
2. Estabilizar. Antes de mover nada: sacar los respaldos del hipervisor que protegen, verificar que se pueden restaurar y proteger lo que no se puede parchear.
3. Construir el destino. El entorno nuevo, validado contra la lista de compatibilidad del fabricante, con capacidad de sobra para recibir las cargas.
4. Migrar por oleadas. Primero las cargas no críticas, para aprender en terreno seguro; después las críticas, con ventana acordada y plan de roll-back.
5. Validar. Pruebas funcionales con los usuarios de cada aplicación y una restauración real de respaldo en el entorno nuevo.
6. Retirar. Decomisionar el hardware viejo, borrar los discos de forma segura y eliminar las credenciales y accesos que ya no se usan.

Es la misma secuencia que seguimos cuando migramos nuestra propia operación de VMware a Proxmox. Si todavía estás decidiendo el destino, empieza por cómo salir de VMware.

¿Qué haces con lo que no se puede actualizar?

Casi todos los entornos tienen al menos una pieza así: una aplicación de negocio que solo corre en un sistema operativo viejo. La respuesta no es fingir que no existe, sino declararla como excepción: aislarla en su propio segmento de red, limitar quién y qué puede conectarse a ella, respaldarla por separado y ponerle fecha de salida. Si es un Windows Server 2012, toma en cuenta que el programa de actualizaciones de pago cierra el 13 de octubre de 2026; después de esa fecha no habrá parches oficiales ni pagando.

¿Tienes identificado cuál es esa pieza en tu operación y de qué depende?

¿Cómo sabes cuánta deuda tienes?

Con un diagnóstico que cruce ambas mitades: qué hardware y qué software llegan al fin de soporte, qué depende de qué y en qué orden conviene moverlo. En IT Experts lo hacemos con nuestro servicio de análisis y diagnóstico de infraestructura: mapa de dependencias, priorización de cargas por riesgo y un plan de migración reversible, para que decidas con datos y no con prisa.