Azure SQL Data Sync больше не принимает новых пользователей: с 9 сентября Microsoft заблокировала первые развертывания сервиса в подписках, где он раньше не использовался. Для команд, которые синхронизируют SQL-базы между Azure и локальной инфраструктурой, это не просто галочка в календаре, а дедлайн на пересборку архитектуры до 30 сентября 2027 года.
О новом этапе вывода сервиса из эксплуатации сообщает The Register. Действующие клиенты пока могут продолжать работу: создавать, менять и администрировать sync groups и подключенные базы. Но если подписка раньше не использовала сервис, начать уже нельзя. Microsoft оставила старым пользователям чуть больше года на миграцию, а новым фактически сказала: выбирайте другой путь.
Azure SQL Data Sync работал по модели hub-and-spoke. В центре стояла база Azure SQL, которая играла роль хаба, а к ней подключались участники синхронизации: другие базы Azure SQL или локальные SQL Server. Для on-premises SQL Server требовался sync agent. При конфликте изменений администратор задавал политику: приоритет у хаба или у подключенной базы.
Такая схема закрывала довольно приземленные, но живучие сценарии. Например, когда часть приложения уже уехала в Azure, а часть базы по организационным, юридическим или техническим причинам остается в дата-центре. Или когда приложение работает в нескольких регионах и ему нужна синхронизация данных между распределенными площадками. Это не самая модная тема на фоне генеративного ИИ, зато именно такие сервисы годами держат корпоративные системы в рабочем состоянии.
Microsoft объявила о выводе сервиса из эксплуатации еще два года назад, но теперь процесс перешел из разряда «когда-нибудь потом» в режим практических ограничений. Компания объясняет решение изменившимися операционными требованиями, а также требованиями безопасности и комплаенса. Подробной технической причины в опубликованном описании нет. И это, пожалуй, самая неприятная часть новости для архитекторов: сервис убирают, а прямой замены с тем же поведением не дают.
В списке альтернатив Microsoft называет Azure Data Factory, Azure Functions, read replicas, linked servers, database mirroring, availability groups и transactional replication. Проблема в том, что это не взаимозаменяемые детали конструктора. Одни варианты больше про пакетную интеграцию и пайплайны данных, другие — про отказоустойчивость, репликацию или кастомную бизнес-логику. Перенести конфигурацию по принципу «экспортировал здесь, импортировал там» не получится.
Для разработчиков это означает ревизию зависимостей, которые часто лежат где-то под слоем ORM, интеграционных джоб и старых админских инструкций. Нужно понять, какие sync groups реально используются, какие таблицы синхронизируются, где возможны конфликты записи, кто владеет схемой данных и какие RPO/RTO бизнес считает приемлемыми. Без этой инвентаризации миграция рискует превратиться в серию ночных сюрпризов, а сюрпризы в базах данных обычно плохо сочетаются с SLA.
Для бизнеса риск еще проще: если сервис участвует в критичной цепочке, дата 30 сентября 2027 года превращается в жесткий срок проекта. Особенно для компаний с гибридной инфраструктурой, где локальные SQL Server живут не из любви к ретро, а из-за регуляторики, лицензий, интеграций с производственными системами или старых приложений, которые никто не хочет трогать без крайней необходимости. Теперь необходимость появилась.
Новым проектам сигнал тоже понятен: не стоит строить архитектуру на сервисах, которые уже находятся в режиме заката, даже если они еще доступны у соседней команды или в старой подписке. Для существующих клиентов Azure SQL Data Sync ближайшие месяцы лучше потратить не на ожидание «похожего преемника», а на выбор конкретной схемы миграции, тест конфликтов и проверку производительности. Microsoft оставила набор инструментов, но финальную сборку придется делать самим.