SQL Server 2016 se quedó sin soporte: ¿pagar ESU, actualizar o migrar?

El 14 de julio de 2026 terminó el soporte extendido de SQL Server 2016, y desde entonces no recibe parches de seguridad. Microsoft marcó la fecha en su blog de SQL Server tras diez años de soporte, y la ficha de ciclo de vida no deja margen de interpretación. Sin una suscripción a Extended Security Updates (ESU), la próxima vulnerabilidad crítica del motor no tendrá corrección para esa versión.

En empresas medianas y grandes de la región, SQL Server 2016 suele estar debajo del ERP, la nómina o la cartera, amarrado a integraciones que nadie quiere tocar. Quedarse quieto dejó de ser opción. Hay tres salidas —pagar ESU, actualizar el motor o pasar a un servicio gestionado— y cada una tiene una trampa que conviene ver antes de firmar.

¿Qué dejó de recibir exactamente SQL Server 2016?

Todo parche. La política de ciclo de vida fijo de Microsoft da cinco años de soporte principal y cinco de extendido; al terminar el extendido, no hay parches ni actualizaciones de seguridad. Tampoco hay soporte técnico: no se puede abrir un caso aunque exista un plan de soporte vigente; con ESU, solo para problemas de esas actualizaciones.

Para un auditor de ISO 27001 o de una superintendencia financiera, eso se traduce en un hallazgo concreto: un activo que procesa datos sensibles corre sobre software sin corrección de vulnerabilidades. Una herramienta de control de aplicaciones de terceros tampoco lo tapa; el mismo FAQ de Microsoft aclara que no reemplaza las correcciones del producto.

¿Qué cubren los ESU y cuánto duran?

Los ESU son un puente de pago de hasta tres años, en periodos anuales que Microsoft publica en la ficha del producto: el año 1 va del 15 de julio de 2026 al 13 de julio de 2027, y el último termina el 17 de julio de 2029. Lo que incluyen es más estrecho de lo que suele suponerse:

• Solo actualizaciones de seguridad calificadas como críticas por el MSRC de Microsoft, y solo si aparecen. No hay cadencia mensual.
• Nada de funciones nuevas, mejoras ni correcciones pedidas por clientes.
• Solo ediciones Enterprise y Standard. Express, Web y Developer no pueden suscribirse.
• Exige el último service pack (SP3 en 2016): Microsoft solo produce actualizaciones que se aplican sobre él.

Ese último punto es el que se descubre tarde. Si durante años solo se aplicaron actualizaciones GDR, Microsoft recomienda instalar y validar la última actualización acumulativa al suscribirse, no el día en que llega el primer parche crítico. Validar una actualización acumulativa con prisa, sobre el servidor del ERP, es justo la situación que el ESU debía evitar.

¿Cómo se contratan los ESU y por qué esperar no ahorra dinero?

Con Software Assurance bajo un Enterprise Agreement, EAS, SCE o EES, se contratan por licenciamiento por volumen. Sin Software Assurance, las vías son migrar a Azure o conectar la instancia a Azure Arc —conectar es gratis— y activar la facturación por uso. Los servidores alojados en otro proveedor también pasan por Arc.

Tres detalles de facturación cambian el cálculo:

• Se cobra por núcleo virtual, con un mínimo de cuatro núcleos por máquina virtual. En un parque de muchas VM pequeñas, ese mínimo pesa más que el tamaño real.
• La facturación empezó el 15 de julio de 2026 a medianoche UTC. Quien se suscribe después paga un cargo retroactivo único hasta el primer día del periodo. Retrasar la decisión no reduce la factura; solo deja meses sin parches.
• Un cambio de identificador de la VM —reconstruirla, clonarla, moverla de hardware— hace que Arc la trate como una máquina nueva y puede generar doble cobro. Antes de tocar la VM hay que cancelar la suscripción en la máquina original y activarla en la nueva después.

Y una diferencia con SQL Server 2014 que muchos presupuestos arrastran por error: con 2014, llevar la instancia tal cual a una VM de Azure daba ESU gratis. Con 2016 eso ya no aplica: en Azure también se pagan.

¿Puedo actualizar SQL Server en el mismo servidor?

Depende del sistema operativo, y ahí se rompe la mayoría de los planes. SQL Server 2025 acepta actualización directa desde 2016 con SP3, pero exige Windows Server 2019 o superior. Una instancia de SQL Server 2016 montada en 2017 o 2018 corre con frecuencia sobre Windows Server 2016, y en ese servidor la actualización in situ no es posible.

Además, Windows Server 2016 pierde su propio soporte extendido el 12 de enero de 2027. Actualizar solo el motor, si se pudiera, dejaría el servidor fuera de soporte cuatro meses después.

Desde la operación, esto es una ventaja. La ruta que usamos es una migración lado a lado: servidor nuevo con Windows Server 2022 o 2025 y la versión nueva de SQL Server, con las bases restauradas desde backup o sincronizadas con log shipping hasta la ventana de corte. El servidor viejo queda intacto, así que mientras no se abran escrituras en el nuevo, revertir es apuntar las conexiones de vuelta. Dos vencimientos se resuelven en un solo proyecto.

¿A qué versión conviene saltar?

A la que dé más años por el mismo esfuerzo. Migrar cuesta casi lo mismo hacia cualquier versión; lo que cambia es cuándo toca repetirlo:

• SQL Server 2017: soporte extendido hasta octubre de 2027. Trece meses de aire.
• SQL Server 2019: hasta enero de 2030, y su soporte principal ya terminó en 2025.
• SQL Server 2022: hasta enero de 2033.
• SQL Server 2025: hasta enero de 2036.

Quien corre en Amazon RDS tiene la decisión a medio tomar. AWS dejó de permitir instancias nuevas de SQL Server 2016 el 15 de enero de 2026 y programa las instancias restantes para migrar a SQL Server 2019. Esa migración automática resuelve el vencimiento de hoy y deja otro para 2030, en una fecha que elige el proveedor y no tu equipo. Conviene ejecutarla por cuenta propia, hacia 2022, con pruebas previas.

En SQL Server 2025 hay además un cambio de licenciamiento que merece una hoja de cálculo: la edición Standard sube a 32 núcleos y 256 GB de buffer pool por instancia e incorpora Resource Governor. Hay empresas que pagan Enterprise solo por memoria; con esos límites, parte de ese gasto puede dejar de tener justificación. La edición Web desaparece.

¿Qué se rompe al actualizar a SQL Server 2025?

Microsoft publica una lista de cambios que rompen compatibilidad, y casi todos tienen el mismo origen: el driver OLE DB 19 trae valores por defecto de cifrado más estrictos y exige un certificado de confianza. Lo que falla:

1. Servidores vinculados. Las configuraciones existentes pueden dejar de conectar si no hay un certificado válido.
2. Replicación con distribuidor remoto. Los datos siguen replicando, pero fallan los cambios a la publicación, el monitor de replicación y el estado de los agentes.
3. Monitoreo remoto de log shipping, cuando el monitor es 2025 y el resto de la topología es de una versión anterior.
4. Búsqueda de texto completo. Tras actualizar in situ, las consultas sobre índices creados antes fallan, porque 2025 elimina los separadores de palabras y filtros heredados. Hay que reconstruir o recrear esos índices.

El arreglo correcto para los tres primeros es emitir certificados desde una CA interna o pública antes de la ventana, no activar TrustServerCertificate para salir del paso. El certificado se prepara en una semana. El servidor vinculado que nadie documentó aparece el lunes después del corte, con la conciliación de la nómina detenida.

También salen componentes enteros. Data Quality Services y Master Data Services se descontinúan, y con DQS instalado la actualización falla. Reporting Services deja de publicarse: los reportes locales pasan a Power BI Report Server, que acepta los mismos archivos RDL y se instala con la clave de SQL Server 2025 Standard o Enterprise. Si tu SSRS 2016 vive en el mismo servidor que la base, esa migración también entra en el plan.

¿Cómo evito que cambie el rendimiento después del corte?

Separando dos riesgos que suelen mezclarse: cambiar el motor y cambiar el optimizador. Una base restaurada en una versión nueva conserva su nivel de compatibilidad, y SQL Server 2025 admite del nivel 100 al 170. La base puede llegar con el 130 de SQL Server 2016 y mantener el comportamiento del optimizador que ya conocía.

El orden que seguimos: migrar con nivel 130, activar Query Store, dejar correr un ciclo completo de negocio —un cierre de mes, no un fin de semana— y solo entonces subir el nivel de compatibilidad, comparando planes con los datos capturados. Microsoft documenta ese flujo y ofrece el Query Tuning Assistant para acompañarlo. Si una consulta empeora, se vuelve al nivel anterior con una sentencia ALTER DATABASE, sin tocar la migración.

¿Y si mejor lo llevo a un servicio gestionado?

Para muchas cargas es la salida que evita repetir este ejercicio en 2033. Azure SQL Managed Instance ofrece, según el FAQ de ESU de Microsoft, compatibilidad cercana al 100% con SQL Server local, alta disponibilidad incluida y un modelo sin versión: los parches y las actualizaciones dejan de ser un proyecto. Para clientes sin Software Assurance es la opción que Microsoft recomienda. Admite los niveles de compatibilidad desde el 100, así que la estrategia de migrar con 130 y subir después funciona igual.

El límite está en lo que no es base de datos: trabajos del Agente que llaman a ejecutables locales, paquetes de SSIS con rutas de red, integraciones por carpetas compartidas. Eso es lo primero que hay que inventariar, porque decide si la carga cabe en un servicio gestionado o necesita una VM.

Por dónde empezaríamos esta semana

1. Inventario por instancia: versión, edición, service pack, sistema operativo, servidores vinculados, replicación, texto completo, SSRS, DQS y MDS. SERVERPROPERTY y las vistas de sistema lo resuelven en una tarde.
2. Un destino por instancia, no uno para todo el parque: servicio gestionado, VM nueva con 2022 o 2025, o ESU como puente.
3. Si hay ESU, con fecha de salida escrita. Un puente sin fecha se convierte en un costo recurrente hasta 2029.
4. Certificados antes de la ventana para todo lo que se conecte por OLE DB 19.
5. Un ensayo de restauración en el servidor nuevo, con datos reales y tiempos medidos. Ese número define la ventana de corte.

Cómo te ayudamos en Athrun Data Intelligence

Llamada de 30 minutos para revisar tu inventario de SQL Server y decirte qué instancias conviene migrar ya, cuáles pueden esperar con ESU y cuáles encajan en un servicio gestionado. Si encaja, ejecutamos la migración lado a lado con la reversión preparada, y subimos el nivel de compatibilidad solo cuando los datos de Query Store lo respaldan.