Hay una frase que suena razonable hasta que deja de serlo: «si funciona, no se toca». La escuchamos seguido cuando hablamos con gerentes y dueños de pyme sobre sus sistemas. Y tiene lógica, porque ese servidor que corre la base de datos de facturación lleva años trabajando sin quejarse. Nadie quiere despertar al que duerme tranquilo.
El problema es que el 14 de julio ese servidor cambia de estado sin que nadie lo toque. SQL Server 2016 llega a su fin de soporte extendido, y a partir de esa fecha Microsoft deja de publicar actualizaciones de seguridad para esa versión. La base de datos va a seguir encendida, va a seguir facturando y va a seguir viéndose exactamente igual. Por fuera, nada cambia. Por dentro, deja de recibir parches justo cuando más los necesita.
Aquí está el matiz que mucha gente pasa por alto: no decidir también es una decisión. Y en este caso, es la más cara de las opciones sobre la mesa. Este artículo no es para asustar, es para poner números y criterios donde normalmente hay corazonadas, y para que cuando tomes la decisión, la tomes con la información completa.
Qué significa realmente «fin de soporte»
«Fin de soporte» no es un mensaje de error que salta en pantalla. Es algo más silencioso y, por eso mismo, más peligroso.
Significa que Microsoft deja de emitir actualizaciones de seguridad para SQL Server 2016. Si mañana se descubre una vulnerabilidad que permita a un atacante entrar a esa base de datos, no habrá un parche oficial que la cierre. El software sigue funcionando; simplemente deja de defenderse solo.
Para una empresa esto se traduce en tres frentes concretos. El primero es ciberseguridad: cada vulnerabilidad nueva que aparezca queda abierta de forma indefinida. El segundo es cumplimiento: muchas normativas, contratos con clientes grandes y auditorías exigen que los sistemas que manejan datos estén dentro de soporte del fabricante. Un servidor sin soporte puede ser motivo de un hallazgo en auditoría. El tercero es respaldo del ecosistema: con el tiempo, versiones nuevas de otros programas, controladores y herramientas dejan de garantizar compatibilidad con una versión que ya nadie mantiene.
Nada de esto explota el día 15. Es una erosión lenta. Y esa lentitud es justo lo que hace que se posponga una y otra vez.
El costo invisible del statu quo
Cuando pedimos a un cliente que estime el costo de «no hacer nada», la respuesta casi siempre es cero. No hay factura, no hay proyecto, no hay línea en el presupuesto. Pero el costo existe; solo que está repartido en lugares donde no se mira.
El costo por hora cuando el sistema se cae
Imaginemos una empresa mediana cuyo sistema de facturación depende de esa base de datos. Si el servidor se cae un martes a media mañana, ¿cuánto cuesta cada hora sin facturar? No es solo la venta que no se emite. Es el personal administrativo detenido, los clientes esperando, los pedidos que no salen, la persona de TI apagando incendios en lugar de avanzar. Ese número por hora suele sorprender cuando por fin se calcula, y con un sistema sin parches de seguridad, la probabilidad de una caída no planificada deja de ser teórica.
(Cada empresa debe estimar su propio costo por hora de inactividad según su facturación y operación; es un ejercicio que vale la pena hacer antes de decidir.)
La prima de ciberseguro que sube o la póliza que no paga
Este punto pasa desapercibido y merece atención. Cada vez más aseguradoras que ofrecen cobertura de ciberseguridad preguntan, en el formulario o en el peritaje posterior a un incidente, si los sistemas afectados estaban dentro de soporte del fabricante. Operar software sin soporte puede traducirse en una prima más alta o, peor, en una póliza que no responde cuando ocurre el incidente, precisamente por haber usado un sistema fuera de mantenimiento. Conviene revisar las condiciones de tu póliza con tu corredor; es información que cada empresa debe validar en su contrato específico.
Migración de emergencia vs. migración planificada
Y aquí está el corazón del asunto. Toda empresa va a migrar de SQL Server 2016 tarde o temprano. La única pregunta es si lo hará en sus términos o en los del incidente.
Una migración planificada se hace de noche o en fin de semana, con pruebas previas, con un plan de reversión y sin presión. Una migración de emergencia se hace después de un ataque o una caída, con el negocio detenido, pagando horas extra, tomando atajos y sin margen para probar. Es exactamente el mismo destino, pero uno cuesta una fracción del otro. El inmovilismo no evita la migración: solo garantiza que se pague la versión más cara.
Las salidas ordenadas: tres rutas y un callejón sin salida
La buena noticia es que salir de SQL Server 2016 no es un salto al vacío. Hay caminos claros, y el correcto depende de tu operación, no de una moda. Estas son las tres rutas reales, más la que conviene descartar.
Ruta 1: Azure SQL (base de datos administrada en la nube)
Con Azure SQL dejas de preocuparte por la versión del motor, los parches y el mantenimiento del sistema operativo, porque Microsoft se encarga de eso por debajo. Es la opción más cómoda para quien quiere quitarse de encima la administración de infraestructura y pagar por lo que usa. Encaja bien cuando la aplicación es relativamente moderna y compatible, y cuando el equipo prefiere concentrarse en el negocio y no en cuidar un servidor.
Ruta 2: Máquina virtual en Azure con SQL Server actualizado
Si tu aplicación necesita un SQL Server «de toda la vida» pero fuera del hardware envejecido de la oficina, una máquina virtual en Azure te da lo mejor de dos mundos: sigues teniendo el control de un servidor completo, pero sobre una infraestructura moderna, elástica y respaldada. Es la ruta natural para migraciones donde la compatibilidad manda y no quieres reescribir nada. Si quieres entender cómo se comporta esa disponibilidad en la nube, este otro artículo sobre el SLA de las máquinas virtuales en Azure lo explica sin tecnicismos.
Ruta 3: SQL Server 2022 on-premises
No todo tiene que ir a la nube. Hay empresas con razones legítimas para mantener su base de datos dentro de sus instalaciones: requisitos de latencia, control físico del dato, inversiones recientes en hardware o exigencias particulares del sector. En esos casos, actualizar a SQL Server 2022 on-premises te devuelve al soporte del fabricante y a un ciclo de vida largo por delante, sin cambiar tu modelo de operación. Migrar no es sinónimo de mudarse; a veces es simplemente ponerse al día donde ya estás.
El callejón: quedarse en 2016
La cuarta opción es no hacer nada. Ya vimos por qué es la más cara: acumula riesgo de seguridad, complica el cumplimiento, encarece o invalida seguros y convierte una migración tranquila en una de emergencia. No es una ruta; es una cuenta que se paga después, con intereses.
Cómo saber cuál ruta te toca
No hace falta ser experto en bases de datos para empezar a orientarte. Estas preguntas ayudan a ubicarte:
- ¿Qué tan crítico es el sistema? Si detenerlo una mañana te cuesta caro, la conversación es urgente, no opcional.
- ¿Qué tan moderna es la aplicación que usa la base de datos? Cuanto más actual, más fácil aprovechar una opción administrada como Azure SQL.
- ¿Tienes requisitos de dónde vive el dato? Si hay exigencias de control físico o normativas específicas, on-premises o una VM entran con fuerza.
- ¿Cómo está tu equipo de TI? Si está saturado, quitarse el mantenimiento de encima con una opción administrada libera tiempo real.
La respuesta correcta casi nunca es obvia al primer vistazo, y ahí es donde vale acompañarse de alguien que ya ha recorrido este camino con otras empresas.
En conclusión:
SQL Server 2016 no va a apagarse el 14 de julio. Va a seguir encendido, funcionando y facturando como si nada. Ese es justo el problema: la ausencia de una alarma visible hace que sea fácil posponer una decisión que ya tiene fecha.
El fin de soporte no obliga a correr, pero sí a decidir con la cabeza fría mientras todavía hay margen. Migrar planificado cuesta una fracción de migrar bajo fuego, y las tres rutas ordenadas —Azure SQL, una máquina virtual en Azure o SQL Server 2022 on-premises— existen precisamente para que puedas elegir en calma. La única opción sin salida es la de no elegir. Y esa, como vimos, es la más cara de todas.
Siguiente paso?
Si quieres tener el mapa completo antes de decidir, preparamos una guía práctica Solicítala en este link: Salir de SQL Server 2016 sin detener la operación.