Mi instancia de Cloud SQL con SQL Server 2017 sigue funcionando. ¿Tengo que hacer algo hoy?

Nada se rompe esta semana. Lo que te da el aviso del 14 de septiembre de 2026 es una fecha: a partir del 12 de abril de 2027 no vas a poder crear instancias nuevas de Cloud SQL para SQL Server 2017, y el aviso menciona un paso adicional a partir de octubre de 2027. Trátalo como trabajo planeado para los próximos dos trimestres. La primera tarea no es la actualización, es preguntarle por escrito a tu proveedor de software qué versiones soporta, porque esa respuesta es la que más tarda.

¿Google va a actualizar mi instancia automáticamente si no hago nada?

La política de versiones de Cloud SQL dice que una instancia que corre en una versión principal obsoleta se actualiza a la versión principal y secundaria predeterminada del motor, y que los propietarios del proyecto reciben el aviso de obsolescencia al menos 12 meses antes de la fecha. Así que la actualización pasa de cualquier forma. La diferencia es si cae en una ventana que tú elegiste, con un plan de regreso probado y el proveedor disponible, o en una fecha que eligió alguien más.

¿Tengo que migrar a una instancia nueva o puedo actualizar la que tengo?

Cloud SQL permite una actualización de versión principal en el lugar para SQL Server. La documentación de Google la describe como la ruta más simple, porque no migras datos ni cambias cadenas de conexión y la instancia conserva su nombre, su dirección IP y el resto de su configuración. Necesitas el rol de propietario o administrador de Cloud SQL. Revisa primero los destinos de actualización disponibles para tu instancia con el método instances.get de la API de administración, y ensaya en un clon antes de tocar producción.

Cloud SQL retira SQL Server 2017: planea la migración

Imagina una distribuidora de 30 personas. Despacho, facturación y los reportes que el dueño abre cada lunes corren contra una sola instancia de Cloud SQL. Se creó en 2019 con SQL Server 2017, porque esa era la versión del momento, y nadie la ha vuelto a ver desde entonces. Funciona bien. Ese es justamente el problema, porque el reloj de esa versión ya es público y trae fechas.

Qué cambió y cuándo

El 14 de septiembre de 2026, Google publicó un aviso de obsolescencia en las notas de versión de Google Cloud: Cloud SQL para SQL Server 2017 queda marcado como obsoleto. La consecuencia concreta que indica ese aviso es que a partir del 12 de abril de 2027 ya no vas a poder crear instancias nuevas de Cloud SQL para SQL Server 2017. El aviso sigue con un paso adicional a partir de octubre de 2027, así que léelo completo antes de fijar fechas en el calendario.

Octubre no es un mes al azar. La página de ciclo de vida de Microsoft para SQL Server 2017 indica fin de soporte principal el 11 de octubre de 2022 y fin de soporte extendido el 12 de octubre de 2027. La política de versiones de Cloud SQL sigue el ciclo de vida del motor: cuando termina el soporte extendido de una versión principal, Cloud SQL la marca como obsoleta, y una instancia que siga corriendo en una versión principal obsoleta se actualiza automáticamente a la versión principal y secundaria predeterminada del motor. La misma política dice que Cloud SQL envía el aviso de obsolescencia a los propietarios del proyecto al menos 12 meses antes de la fecha de obsolescencia. El aviso de septiembre es exactamente eso.

De ahí salen dos conclusiones. Tienes tiempo, más de un año. Y la actualización va a ocurrir la planifiques o no, que es lo que define cómo te va el año. Una actualización que tú agendas es una ventana de mantenimiento un sábado en la noche, con el proveedor disponible y un plan de regreso probado. Una actualización que llega sola es un lunes con el teléfono sonando y nadie seguro de qué cambió.

A quién le pega en una empresa pequeña o mediana

Por lo que vemos, las empresas que caen en un aviso como este casi nunca tienen un equipo de bases de datos. Son las que corren una aplicación de línea de negocio en Windows: un ERP, un punto de venta, el sistema de una clínica o un taller comprado a un proveedor local, un paquete contable que algún contratista subió a Google Cloud hace años y entregó con una cadena de conexión y buenos deseos.

Hay tres grupos que deberían revisar esto en las próximas semanas.

Quien tenga una instancia de Cloud SQL todavía en SQL Server 2017. Un comando te lo dice, y lo vemos más abajo.
Quien dependa de un proveedor que certifica una versión específica de SQL Server. Si el contrato de soporte menciona 2017 y nada más nuevo, la conversación con el proveedor es lo que se va a tardar, no la actualización. Empiézala ahora, mientras todavía es un correo de planeación y no una escalación.
Quien reconstruya infraestructura desde código. Esta es la trampa que casi nadie ve. Si un módulo de Terraform, un script de despliegue o un runbook de recuperación tiene fijada la versión 2017, va a seguir funcionando hasta el día en que de verdad lo necesites. Después del 12 de abril de 2027 esa llamada de creación falla. Un plan de recuperación que no puede recrear la instancia no es un plan, y el peor momento para enterarte es cuando lo estás usando.

La buena noticia es que esto es trabajo normal y agendable. La mala es solo que sigue siendo normal mientras quede tiempo en el reloj.

Qué revisamos primero en un proyecto

Antes de tocar nada, armamos el panorama. En un proyecto típico eso es medio día, y es el medio día que evita el sábado malo.

Inventario en todos los proyectos. Las empresas acumulan proyectos: uno del contratista original, uno de una prueba de concepto, uno que alguien creó para un test y terminó en producción. Listamos instancias en todos:

gcloud sql instances list --project=TU_PROJECT_ID

La columna de versión de base de datos es la que importa. Toda instancia que reporte una edición de SQL Server 2017 entra a la lista.

Qué se conecta. Para cada instancia anotamos las aplicaciones, las herramientas de reportes, los trabajos programados y la hoja de cálculo que alguien actualiza con una consulta directa. En esa última categoría es donde viven las sorpresas.

La matriz de soporte del proveedor. Para cada aplicación, qué versiones de SQL Server soporta hoy el proveedor, por escrito. Si la respuesta tarda dos semanas, mejor haber preguntado en el primer mes.

Nivel de compatibilidad de cada base. Una base puede quedarse en un nivel de compatibilidad viejo dentro de un motor nuevo. Saber el nivel actual nos dice si el comportamiento del optimizador va a cambiar después de la migración, y nos deja separar la actualización del motor del cambio de compatibilidad para que cualquier regresión tenga una causa obvia.

Respaldos y restauraciones. Confirmamos que los respaldos automáticos estén activos, que la recuperación a un punto en el tiempo esté configurada, y luego que alguien de verdad haya restaurado al menos una vez. Un respaldo que nadie ha probado es una esperanza, no un plan de regreso.

Infraestructura como código y runbooks. Buscamos en los repositorios las cadenas de versión 2017 fijadas, porque esas son las que se rompen al crear instancias en abril.

La migración, paso a paso

Cloud SQL permite una actualización de versión principal en el lugar para SQL Server. La documentación la describe como el camino más simple: no migras datos ni cambias cadenas de conexión, y la instancia conserva su nombre, su dirección IP y el resto de su configuración. Por dentro usa la utilidad de actualización en el lugar de SQL Server. Necesitas el rol de propietario o administrador de Cloud SQL para ejecutarla.

Este es el orden en que trabajamos.

Elige la versión destino con el proveedor, no por tu cuenta. La tentación es saltar a la versión más nueva. La correcta es la más nueva que tu proveedor soporte por escrito, que muchas veces está un paso atrás de la más nueva que ofrece Google.
Confirma a qué destinos puede llegar tu instancia. Los destinos de actualización disponibles para una instancia salen de la API de administración de Cloud SQL, con el método instances.get. Verifica que el valor que piensas usar aparezca ahí antes de agendar nada.
Ensaya en un clon. Este es el paso que la gente se salta y el que se paga solo. Clona la instancia, actualiza el clon, apunta una copia de la aplicación ahí y pásale un día real de trabajo: el reporte lento, el cierre de mes, la integración que registra facturas. Aprovecha y cronometra la actualización, porque ese número es tu ventana de mantenimiento.
Toma un respaldo fresco justo antes de la corrida real. Nuestro plan de regreso para una actualización de versión principal es una restauración, así que esa ruta tiene que estar vigente y probada, no supuesta.
Ejecuta la actualización en la ventana. El comando cambia la versión de base de datos de la instancia:

gcloud sql instances patch NOMBRE_INSTANCIA \
  --database-version=VERSION_DESTINO \
  --project=TU_PROJECT_ID

Verifica antes de irte a dormir. Inicio de sesión de la aplicación, una escritura, una lectura, el trabajo nocturno, los reportes. Mantenemos una lista corta por cliente y la recorremos en el mismo orden siempre, porque una lista le gana a la memoria a las dos de la mañana.
Sube el nivel de compatibilidad después, como cambio aparte. Separarlo de la actualización del motor significa que si un plan de consulta se pone raro la semana siguiente, sabes cuál cambio revisar. Una semana de diferencia suele bastar.
Arregla el código y los runbooks esa misma semana. Actualiza la versión fijada en Terraform, en los scripts y en el documento de recuperación, y que alguien que no lo escribió intente seguirlo.

Notas de costo y riesgo

Vale la pena saberlo antes de que alguien se asuste con la factura: Cloud SQL no cobra por soporte extendido en Microsoft SQL Server, a diferencia de cómo maneja MySQL y PostgreSQL. La presión aquí no es una línea sorpresa en la factura. La presión es la actualización automática al final de la política, que va a escoger su momento si tú no escoges el tuyo.

El costo sí puede moverse por otra razón. Si aprovechas la actualización para cambiar también de edición o de tamaño de máquina, eso cambia lo que cuesta la instancia. Decide esas cosas como preguntas separadas y revisa las cifras vigentes en la página de precios de Cloud SQL de Google, en lugar de confiar en un número de un artículo, incluido este.

Sobre el riesgo, el resumen honesto es corto. Una actualización de versión principal cambia el comportamiento del optimizador contra el que tu aplicación viene corriendo desde hace años. La mayoría de aplicaciones ni se entera. Algunas tienen un reporte que dependía en silencio de un plan viejo, y se pone lento. Eso es trabajo de afinación, no un desastre, y se atiende mucho mejor un martes después de una actualización planeada que en medio de una que no lo fue. Ensayar en un clon es lo que convierte el primer caso en el caso normal.

Hay un riesgo más que no tiene que ver con la base de datos: el proveedor que ya no existe. Si la aplicación encima de esa instancia vino de una empresa que cerró, la pregunta de la actualización se vuelve una pregunta de aplicación, y eso necesita más pista de la que te da el aviso. Averígualo ya.

Cómo ayuda Guanacos Tech

Hacemos este trabajo para empresas pequeñas y medianas en Norteamérica y Latinoamérica, en inglés y en español. En un proyecto así inventariamos las instancias en todos los proyectos, conseguimos por escrito las respuestas del proveedor, ensayamos la actualización en un clon, corremos la real en la ventana que tú elijas, y te dejamos runbooks que alguien más de tu equipo pueda seguir la próxima vez. Si la respuesta del proveedor resulta ser un muro, te lo decimos claro y planeamos alrededor en lugar de fingir que está bien.

Puedes ver lo que hacemos en Google Cloud, o leer cómo trabajamos antes de hablar con nadie. Si quieres ponerle fecha a esto mientras todavía es un ejercicio de planeación, agenda una llamada y trae tu lista de proyectos.

Cloud SQL deja atrás SQL Server 2017: cómo planeamos la migración