SQL Server 2016 llegó a su fin de soporte el 14 de julio de 2026. Sin actualizaciones de seguridad, cada vulnerabilidad nueva que aparezca queda abierta para siempre. Aquí repasamos qué riesgos concretos implica seguir con esta versión, cuánto cuesta el soporte extendido de Microsoft y cuáles son las rutas de migración reales, con sus ventajas y sus pegas.
El 14 de julio de 2026, Microsoft retiró el soporte para SQL Server 2016. Esto significa que la versión que ha gestionado las bases de datos de miles de empresas durante una década ya no recibirá actualizaciones de seguridad ni parches de corrección. Si tu infraestructura todavía depende de este motor, a partir de ahora estás operando sin cobertura.
Mucha gente piensa que mientras el servidor arranque y responda a las consultas, el problema no corre prisa. Eso es un error (aunque sea comprensible). El software desactualizado no deja de funcionar de golpe, pero sí acumula superficie de ataque con cada nueva vulnerabilidad que se descubre sin parchear. Y tarde o temprano también empieza a dar problemas de compatibilidad con las herramientas del ecosistema actual.
En este punto tienes dos opciones: pagar a Microsoft por unos años extra de parches de seguridad a un precio nada razonable, o planificar una migración antes de que una brecha te fuerce a hacerlo con prisa.
Qué implica el End of Support de SQL Server 2016
El término End of Support (EOS) suena a burocracia de licencias, pero sus consecuencias son técnicas y concretas. Cuando un gestor de base de datos llega a esta fase, Microsoft cierra el desarrollo activo para esa versión: sin correcciones de bugs, sin parches de estabilidad y sin respuesta a las nuevas vulnerabilidades de seguridad que se descubran.
Si mañana aparece un exploit de ejecución remota de código que afecte a la arquitectura de SQL Server 2016, tu servidor se quedará expuesto, sin fecha de solución. Además, el EOS tiene un efecto en cadena sobre el resto del stack: los drivers de .NET, Node.js o Python dejan de probarse contra versiones sin soporte, y herramientas de monitorización u observabilidad pueden empezar a reportar fallos de integración.
Cuando Microsoft publica un parche para versiones soportadas (ahora mismo las versiones 2019 o 2022), los atacantes aplican ingeniería inversa para identificar qué vulnerabilidad corregía. Luego lanzan esos mismos ataques contra instancias de 2016, sabiendo que nadie las va a parchear.
Además, si manejas datos personales o financieros, operar con un sistema sin soporte oficial puede ponerte en incumplimiento del RGPD por no ser diligentes con la seguridad, con las sanciones que eso conlleva, independientemente de que hayas sufrido una brecha o no.
ESU: cuánto cuesta el soporte extendido y qué cubre exactamente
Para empresas que no llegan a migrar a tiempo, Microsoft ofrece las Extended Security Updates (ESU). El programa permite comprar parches de seguridad críticos durante un máximo de tres años. El problema está en el precio: el primer año cuesta aproximadamente el 75 % del precio de una licencia completa de SQL Server, el segundo sube al 100 % y el tercero al 125 %. Solo por parches. Sin funcionalidades nuevas, sin mejoras de rendimiento, sin corrección de errores que no estén catalogados como críticos de seguridad.
No tienen mucho sentido.
Las licencias ESU son gratuitas únicamente si mueves tus máquinas virtuales de SQL Server 2016 a infraestructura Azure IaaS. El descuento no es casual: es el incentivo directo de Microsoft para llevar esas cargas de trabajo a su nube.
Las opciones reales para migrar
La migración no exige rehacer las bases de datos desde cero. La opción más directa para quien quiere quedarse on-premise es actualizar a SQL Server 2022. Mantienes el control de la infraestructura, aprovechas el hardware existente y solo actualizas las licencias. El salto entre versiones suele ser manejable si usas las herramientas adecuadas.
Si prefieres eliminar la gestión de servidores, la alternativa es pasarte a un entorno PaaS como Azure SQL Database o Azure SQL Managed Instance. Con esto te olvidas de parchear el sistema operativo, de gestionar copias de seguridad a bajo nivel y de los ciclos de fin de soporte, porque el motor se actualiza en segundo plano.
Para cargas de trabajo donde el coste de las licencias corporativas no es asumible, este cambio forzado también es una buena excusa para evaluar alternativas como PostgreSQL. El cambio de motor implica reescribir consultas y procedimientos almacenados, así que no es una decisión que se pueda tomar a la ligera. A medio plazo elimina el pago de licencias recurrentes, pero hay que medir bien el coste real de la transición. Eso sí, ahí la IA puede resultaros de gran ayuda.
Cómo planificar la migración de versión de SQL Server, paso a paso
Una migración sin sorpresas empieza con una fase de análisis antes de tocar nada en producción. La herramienta que probablemente conoces para esto, el Data Migration Assistant (DMA), fue retirada por Microsoft en julio de 2025. Su reemplazo depende de hacia dónde vayas.
Si te quedas on-premise y actualizas a SQL Server 2022, el análisis de la migración ahora está integrado directamente en SQL Server Management Studio (SSMS). Con la versión actual, basta con hacer clic derecho sobre la instancia en el Object Explorer y seleccionar Migrate SQL Server: el asistente analiza compatibilidad, detecta características en desuso y señala cambios de comportamiento que pueden romper consultas al cambiar de versión. Nada que instalar aparte.
Si el destino es Azure SQL, el flujo es distinto. Microsoft recomienda usar SQL Server habilitado con Azure Arc: desde el portal de Azure obtienes un inventario continuo de tus instancias, recomendaciones de destino y proyecciones de coste. Para la migración propiamente dicha, Azure Database Migration Service sigue siendo la opción principal, ya sea desde el portal o automatizado con Azure CLI o PowerShell.
En cualquier caso, una vez resueltos los avisos de la evaluación, monta un entorno de pruebas con una copia restaurada en la versión de destino. Y no basta con comprobar que la aplicación conecta: hay que ejecutar pruebas de carga reales. Uno de los problemas más comunes al saltar desde SQL Server 2016 son los cambios en el estimador de cardinalidad (Cardinality Estimator), que puede alterar los planes de ejecución de consultas complejas y ralentizar procesos que antes funcionaban bien. No es un caso raro.
Por último, define una estrategia de corte con ventanas de mantenimiento claras. Si no puedes asumir horas de parada, usa replicación transaccional (on-premise) o Azure Database Migration Service en modo online (hacia Azure) para sincronizar los cambios en tiempo real hasta el momento del cambio definitivo. Una vez validado el nuevo entorno, apagas el servidor antiguo y rediriges las cadenas de conexión.