Microsoft inicia la fase final de SQL Data Sync: qué debes revisar antes de 2027

Hay servicios que pueden llevar años funcionando en una empresa sin que prácticamente nadie vuelva a tocarlos.

Configuras una sincronización, resuelve el problema y queda ahí. Hasta que un día el proveedor anuncia que se termina.

Eso está pasando con SQL Data Sync.

Microsoft inició la fase final de retirada del servicio y desde el 9 de septiembre de 2026 las suscripciones de Azure que nunca habían utilizado SQL Data Sync ya no pueden crear nuevas implementaciones.

Los clientes que actualmente lo utilizan pueden continuar operando, pero tienen una fecha que conviene apuntar desde ahora: 30 de septiembre de 2027.

Ese día SQL Data Sync será retirado definitivamente.

¿Qué era SQL Data Sync?

SQL Data Sync nació para resolver un problema bastante común: mantener determinada información sincronizada entre diferentes bases de datos.

Podías tener, por ejemplo, SQL Server dentro de tu empresa y Azure SQL Database en la nube.

Data Sync permitía seleccionar información y sincronizarla entre diferentes bases. Una característica especialmente interesante era que podía trabajar de forma bidireccional.

Eso permitió utilizarlo principalmente en tres escenarios:

• Sincronización híbrida entre infraestructura local y Azure.
• Aplicaciones distribuidas que separaban determinadas cargas entre bases.
• Sistemas distribuidos geográficamente que necesitaban compartir información entre regiones.

Microsoft explica que el servicio está construido sobre una generación anterior de tecnología de sincronización y recomienda migrar hacia soluciones modernas que se adapten mejor a los requisitos actuales de seguridad y cumplimiento.

Lo que cambió ahora

La retirada realmente no es una noticia nueva.

Microsoft anunció desde 2024 que SQL Data Sync desaparecería en septiembre de 2027. Lo importante de septiembre de 2026 es que entramos en otra etapa del proceso.

Los clientes nuevos ya quedaron fuera.

Una suscripción que nunca utilizó SQL Data Sync ya no puede comenzar a utilizarlo.

Los clientes existentes todavía pueden mantener sus implementaciones durante aproximadamente un año.

Esto convierte 2026 en un momento bastante más razonable para empezar una migración que septiembre de 2027.

No existe un sustituto directo

Aquí está para mí la parte realmente importante de la noticia.

Microsoft no está diciendo:

Cambia SQL Data Sync por este nuevo servicio.

La documentación oficial presenta varias alternativas porque depende completamente de lo que estés haciendo actualmente.

Microsoft mantiene una guía oficial de migración de SQL Data Sync donde separa las alternativas según origen, destino y escenario.

Y esa tabla debería revisarse antes de elegir tecnología.

Azure Data Factory no reemplaza automáticamente a Data Sync

Este punto puede provocar errores.

Ves que Microsoft recomienda Azure Data Factory y parece lógico pensar que esa será la migración natural.

Puede serlo. Pero depende.

Data Factory está diseñado para mover, transformar y orquestar datos. Funciona muy bien cuando necesitas copiar información periódicamente o realizar cargas incrementales.

Una sincronización bidireccional tiene otra complejidad.

Si dos sistemas pueden modificar el mismo registro, necesitas decidir qué ocurre cuando ambos lados cambian información antes de sincronizarse.

¿Quién gana?

¿Qué actualización es la correcta?

¿Qué haces con un registro eliminado?

Ese comportamiento forma parte de la arquitectura y no desaparece porque cambiemos de producto.

Por eso una migración de Data Sync puede terminar siendo un pequeño proyecto de reingeniería.

Lo primero que revisaría

Antes de escoger cualquier alternativa, haría inventario.

1. Qué Sync Groups siguen activos

Parece obvio, pero en sistemas con varios años encima pueden existir sincronizaciones que nadie recuerda.

Hay que identificar cuáles siguen siendo necesarias.

2. Qué bases participan

Documentaría claramente origen, destino y ubicación.

Especialmente si existe infraestructura SQL Server local conectada con Azure SQL Database.

3. Dirección de sincronización

Este dato cambia completamente las alternativas disponibles.

No es igual copiar información desde un servidor central hacia Azure que permitir modificaciones desde ambos lados.

4. Frecuencia

Una sincronización cada noche tiene necesidades muy diferentes de otra ejecutándose cada pocos minutos.

5. Volumen

No es lo mismo mover algunos miles de registros que mantener sincronizadas tablas con millones.

6. Conflictos

Este probablemente sea el punto que más revisaría en sistemas bidireccionales.

Hay que entender qué ocurre actualmente cuando dos bases modifican la misma información.

Si esa regla existe dentro de Data Sync y nadie la documentó, migrar puede cambiar silenciosamente el comportamiento del sistema.

No esperaría hasta 2027

Microsoft ha dado bastante tiempo.

El anuncio original ocurrió aproximadamente tres años antes de la retirada definitiva precisamente para permitir que las organizaciones planearan la transición.

Pero un año se consume muy rápido cuando hablamos de sistemas empresariales.

Hay que descubrir dependencias, seleccionar tecnología, configurar infraestructura, migrar, hacer pruebas de carga, validar datos, comprobar recuperación ante fallos y finalmente cambiar producción.

Y eso suponiendo que todo esté documentado.

En sistemas legacy esa última parte suele ser optimista.

Lo que me llevo

He trabajado suficientes años con SQL Server y sistemas empresariales para desconfiar de cualquier proceso automático que “lleva años funcionando sin problemas”.

Normalmente significa que nadie lo ha tenido que revisar.

Hasta que toca hacerlo.

La retirada de SQL Data Sync me parece un buen ejemplo de deuda técnica que no necesariamente está en el código.

También existe deuda en infraestructura, servicios administrados, versiones, integraciones y decisiones arquitectónicas que parecían permanentes cuando fueron implementadas.

Microsoft está avisando con tiempo.

Yo aprovecharía ese tiempo.

Conclusión

SQL Data Sync seguirá funcionando para clientes existentes hasta el 30 de septiembre de 2027. Microsoft no lo apagó hoy.

Pero la última etapa ya comenzó.

Las nuevas suscripciones que nunca utilizaron el servicio ya no pueden implementarlo y Microsoft está empujando a los clientes actuales hacia tecnologías más modernas.

El trabajo importante ahora no es simplemente escoger entre Azure Data Factory, Always On o replicación.

Es entender por qué existe cada sincronización actual.

Una vez que sabes qué problema estaba resolviendo, puedes escoger correctamente su reemplazo.

Esperar hasta septiembre de 2027 convierte una migración planificada en una emergencia perfectamente evitable.

La documentación oficial de Microsoft sobre SQL Data Sync ya muestra claramente la fecha de retirada. Si tienes este servicio en algún ambiente, ese sería mi punto de partida.