El soporte extendido de Windows Server 2016 termina el 12 de enero de 2027. Para un responsable de sistemas, el reto no consiste únicamente en sustituir una versión: hay que identificar qué servicios dependen de cada servidor, comprobar la compatibilidad de las aplicaciones y elegir una ruta que no comprometa la operación.
Una actualización in-place puede ser adecuada para ciertas cargas; otras requieren migración a nuevos servidores, renovación de hardware o replanteamiento de su arquitectura. Las actualizaciones de seguridad extendidas pueden dar margen en casos concretos, pero no sustituyen un plan de modernización. La prioridad debe fijarse por impacto en negocio y riesgo operativo, no por el número de máquinas pendientes.
Introducción: el servidor que «no da problemas»
En muchas reuniones de infraestructura aparece la misma frase: «Ese servidor lleva años funcionando; mejor no tocarlo». Suele referirse a una máquina virtual de la que nadie habla hasta que falla. Quizá aloja una aplicación de negocio, comparte ficheros o participa en la autenticación. Su nombre figura en el inventario, pero no siempre está claro quién valida el servicio ni qué ocurriría si dejase de estar disponible.
El fin de soporte de Windows Server 2016 obliga a hacer esa pregunta antes de que la respuesta llegue en forma de incidencia. Microsoft fija el final del soporte extendido el 12 de enero de 2027. A partir de ahí, mantener la versión sin una cobertura específica de actualizaciones de seguridad deja de ser una decisión que pueda tomarse por inercia.
Mi recomendación es no empezar por «¿a qué versión actualizamos?», sino por otra cuestión: ¿qué servicio presta cada servidor y cuál es la forma menos arriesgada de mantenerlo?
Contexto actual: la infraestructura ya no se renueva por capas aisladas
Hace años era más habitual tratar la actualización del sistema operativo como una tarea separada del resto. Hoy, en un mismo entorno conviven máquinas virtuales, hardware con distintas fechas de renovación, aplicaciones de terceros, identidades híbridas y servicios que se consumen desde varias sedes. Cambiar una pieza puede afectar a otras.
Por eso, el fin de soporte llega en un momento en el que muchos equipos IT tienen que decidir también qué hacer con sus plataformas de virtualización, sus costes de operación y sus cargas en cloud. La respuesta no tiene por qué ser «todo a Azure» ni «todo se queda en el CPD». Lo razonable es evaluar cada carga según sus dependencias, requisitos de disponibilidad, compatibilidad y coste total.
Microsoft contempla distintas rutas para avanzar desde Windows Server 2016, incluida la actualización directa in-place a Windows Server 2025 en servidores no agrupados. Eso no significa que sea la mejor ruta para cualquier rol o aplicación. En los clústeres, por ejemplo, la actualización gradual tiene restricciones diferentes y avanza una versión cada vez.
Actualización in-place: válida, pero no por defecto
La ruta corta solo lo es si el servicio vuelve a funcionar
Una actualización in-place conserva configuración, roles y datos en el mismo servidor. Puede tener sentido para una máquina bien documentada, con un rol compatible, una aplicación validada por su proveedor y una ventana de intervención asumible. Su ventaja real es evitar la construcción y el traspaso completos a otro servidor.
No la elegiría por defecto para resolver años de configuraciones acumuladas, para una aplicación cuyo fabricante no certifica la versión de destino o para un servicio cuya recuperación no se ha ensayado. Tampoco debe confundirse una ruta de actualización del sistema operativo admitida con la compatibilidad de todo el software que corre sobre él. Microsoft advierte de que no todos los roles admiten actualización in-place.
Pensemos en un servidor de aplicación con pocas integraciones conocidas. Ahí puede ser razonable probar la actualización en un entorno representativo, verificar el funcionamiento y preparar el retorno. Si, en cambio, la aplicación depende de componentes antiguos que nadie sabe reinstalar, la aparente rapidez de la ruta puede convertirse en su mayor riesgo.
Mi recomendación es aprobar la actualización solo después de comprobar compatibilidad, copia recuperable, pruebas funcionales y criterio de vuelta atrás. El éxito no es que Windows arranque; es que el servicio opere correctamente al día siguiente.
Migrar a un servidor nuevo: más trabajo, más oportunidad de ordenar
Especialmente relevante para identidad y servicios compartidos
La migración a un servidor nuevo permite construir una plataforma limpia y trasladar roles o datos de forma controlada. Tiene sentido cuando se renueva hardware, se quiere separar funciones que hoy comparten máquina o el rol no admite actualización in-place. Su ventaja es que obliga a revisar configuraciones y dependencias que, de otro modo, se heredarían sin cuestionarlas. Su coste es un proyecto más amplio: coexistencia, pruebas, cambio de servicio y retirada del sistema anterior.
En identidad, esa distinción es importante. Microsoft no recomienda la actualización in-place de controladores de dominio y señala la migración como ruta admitida. Para ADFS, la matriz de roles tampoco contempla actualización in-place. En ambos casos, la decisión debe tomarse sobre el servicio completo, no sobre la máquina aislada.
Una propuesta de modernización de una plataforma ADFS sobre Windows Server 2016 contemplaba, además del cambio de versión, federaciones, publicaciones y dependencias de terceros. Es un buen ejemplo de alcance que sería fácil infravalorar si se presupuestara únicamente «actualizar el servidor». Se trataba de una propuesta de proyecto, no de un resultado de implantación que debamos dar por hecho.
Cuando el servicio es compartido o intervienen terceros, diseñar primero la coexistencia y las pruebas con sus responsables. Después, elegir la técnica de migración.
Hardware y clústeres: no mezclar dos decisiones distintas
El sistema operativo puede ser solo una parte del problema
Si un Windows Server 2016 se ejecuta sobre hardware próximo a su retirada, actualizar el sistema operativo y conservar la plataforma física puede resolver una fecha de soporte sin resolver la continuidad del servicio. En ese escenario tiene sentido estudiar conjuntamente capacidad, almacenamiento, garantías, virtualización y licencias.
Cuando la renovación física ya es necesaria o cuando el entorno puede simplificarse consolidando cargas la recomendación es renovar también los componentes físicos. La ventaja es evitar dos proyectos sucesivos sobre la misma infraestructura.
Cuando se propone comprar hardware nuevo sin haber comprobado qué cargas seguirán existiendo. La limitación no es solo presupuestaria: dimensionar sobre un inventario antiguo puede perpetuar capacidad innecesaria, en este caso es preferible revisar el hardware actual antes.
En clústeres Hyper-V hay otra cautela. Microsoft documenta la actualización gradual nodo a nodo, pero no un salto gradual directo de un clúster Windows Server 2016 a Windows Server 2025: para cruzar varias versiones hay que recorrerlas secuencialmente o migrar a un clúster nuevo. Antes de elegir, conviene comprobar capacidad con un nodo fuera de servicio, compatibilidad de red y almacenamiento y versiones de configuración de las máquinas virtuales.
Azure y gobierno híbrido: una alternativa, no una respuesta automática
Mover una carga exige revisar también su operación
Azure puede ser un destino adecuado si una carga necesita flexibilidad, si la infraestructura local debe renovarse o si la organización ya dispone de conectividad y operación cloud maduras. Su ventaja potencial es evitar la reposición de determinados componentes físicos y gestionar las cargas dentro de una estrategia más amplia.
No tiene sentido trasladar una máquina tal cual solo porque se acerca el fin de soporte, sin analizar latencia, dependencias locales, recuperación, licencias y coste recurrente. En ese caso se cambia el lugar donde reside el problema, no necesariamente el problema.
También cabe una estrategia híbrida: mantener determinadas cargas en local y utilizar Azure Arc para disponer de visibilidad y gestión sobre servidores fuera de Azure. Microsoft documenta la inscripción de máquinas Windows Server 2016 habilitadas para Azure Arc en actualizaciones de seguridad extendidas. Es una opción que conviene evaluar para cargas que no puedan migrarse a tiempo, comprobando condiciones y costes aplicables; no debe confundirse con una modernización del servicio.
ESU: ganar tiempo con una fecha de salida
Las Extended Security Updates (ESU) pueden servir como medida transitoria cuando una aplicación no está preparada para migrar antes del fin de soporte. Cubren determinadas actualizaciones de seguridad críticas e importantes, pero no añaden nuevas funcionalidades ni sustituyen la evolución de la plataforma. Microsoft documenta opciones de ESU para Windows Server 2016, entre ellas la inscripción mediante Azure Arc para servidores que no están alojados en Azure.
Ante una dependencia acreditada, con responsable, presupuesto y plan de retirada o migración sí tiene sentido aplicar ESU. Como excusa para posponer indefinidamente una decisión que ya se puede tomar, es preferible acometer la actualización.
Mi criterio sería sencillo: si se solicita ESU, la misma aprobación debería incluir qué impide migrar, quién desbloqueará esa dependencia y cuál es el siguiente hito de decisión. Sin eso, se compra tiempo sin decidir cómo utilizarlo.
Errores frecuentes que conviene evitar
- Priorizar por cantidad de servidores. Se empieza por los más fáciles para mejorar el porcentaje de avance y se deja para el final el servicio más crítico. Hay que ordenar por impacto y complejidad, no solo por volumen.
- Confundir compatibilidad del sistema operativo con compatibilidad de la aplicación. La actualización termina, pero el proveedor no da soporte al software instalado. Hay que validar ambas cosas por separado.
- Tratar un controlador de dominio como una máquina virtual cualquiera. Se planifica el cambio de Windows sin diseñar la transición del servicio de identidad. Conviene aplicar la ruta adecuada al rol y verificar el estado del entorno antes y después.
- Olvidar las dependencias indirectas. Se migra el servidor principal, pero una tarea programada, una integración o una publicación sigue apuntando al anterior. El mapa de dependencias debe revisarse con operación y con los responsables de aplicación.
- Dar por buena una copia de seguridad no probada. Tener una copia no demuestra que el servicio pueda recuperarse dentro del tiempo que necesita el negocio. La recuperación debe formar parte del plan de cambio.
- Mezclar renovación de hardware y migración de cargas sin separar alcances. El proyecto pierde visibilidad sobre qué se sustituye, qué se actualiza y qué se retira. Separar decisiones facilita presupuestar y secuenciar.
- Dejar las pruebas para el equipo de sistemas. Infraestructura confirma que el servidor responde, pero nadie comprueba el proceso de negocio. Cada carga necesita criterios de aceptación funcional.
- Usar ESU sin un plan posterior. Se reduce temporalmente una parte del riesgo, pero la aplicación y la arquitectura siguen donde estaban. La excepción debe tener propietario y fecha de revisión.
Lo que vemos habitualmente en los proyectos
La conversación suele empezar con una cifra: «Tenemos varios Windows Server 2016». Cuando se revisa el entorno, la cifra pierde protagonismo. Aparecen servicios de identidad, bases de datos, ficheros, aplicaciones de negocio y sistemas de copia que comparten dependencias. En propuestas de renovación que hemos trabajado, el alcance ha tenido que contemplar tanto servidores físicos y virtuales como SQL Server, controladores de dominio y servicios publicados.
La lección es que no todos los servidores merecen el mismo proyecto. Una máquina puede retirarse; otra puede actualizarse tras validar su aplicación; una tercera necesita una migración por fases porque presta un servicio compartido. En trabajos de planificación de clústeres, identidad y SQL, separar análisis, diseño, ejecución, pruebas y soporte posterior ayuda a que cada decisión tenga un responsable y un criterio de aceptación.
También vemos un riesgo menos visible: cerrar el proyecto cuando se apaga el servidor antiguo, sin actualizar documentación, monitorización y procedimientos de recuperación. Desde sistemas, la migración no termina con el cambio técnico. Termina cuando el nuevo servicio puede operarse con normalidad.
Recomendaciones prácticas para empezar
- Identifica todos los Windows Server 2016, incluidos los que están apagados, aislados o fuera del inventario habitual.
- Asocia cada servidor a un servicio, un responsable funcional y una criticidad de negocio.
- Clasifica las cargas en cuatro destinos: retirar, actualizar in-place, migrar a nueva plataforma o mantener temporalmente con una excepción justificada.
- Valida roles, aplicaciones, agentes, hardware y licencias antes de aprobar la ruta técnica.
- Define pruebas funcionales, recuperación y vuelta atrás para cada oleada.
- Separa el presupuesto de renovación física del esfuerzo de migración y del coste operativo posterior.
- Revisa cualquier necesidad de ESU como una medida temporal con responsable y plan de salida.
El 12 de enero de 2027 es una fecha importante, pero no debería ser el único argumento del proyecto. La decisión acertada no consiste en llevar todos los Windows Server 2016 a la misma versión por el mismo camino. Consiste en saber qué sostiene cada uno, cuánto riesgo admite el negocio y qué arquitectura podrá mantener el equipo de IT después.
Mi opinión es que una migración bien planteada debe dejar menos servidores innecesarios, menos dependencias desconocidas y una operación más clara. Si únicamente cambia el número de versión, habremos cumplido un hito técnico. Si además mejoramos la capacidad de mantener y recuperar los servicios, habremos aprovechado la oportunidad.
¿No tienes claro por dónde empezar? En Raona podemos ayudarte a revisar el inventario y las dependencias, comparar las rutas posibles y construir un plan de modernización ajustado a la realidad de tu infraestructura, sin dar por hecho que todas las cargas deban seguir el mismo camino.
