SQL Server 2016 после окончания поддержки: как перенести базу 1С и не потерять задания, права и интеграции

Обычная поддержка закончилась. Что теперь делать с базой 1С на боевом сервере

Когда версия SQL Server выходит за рамки обычной поддержки Microsoft, база 1С не останавливается сама по себе. Но компании нужно выбрать путь обновления или временной защиты и проверить, можно ли восстановить работу на целевой платформе. Вместе с данными учитывайте логины, SQL Agent, связанные серверы, резервные копии и интеграции.

Кому и зачем нужна эта статья

Перенос не стоит сводить к командам backup и restore. Сначала проверьте поддержку целевой СУБД вашей версией платформы 1С, затем на тестовой копии выполните обычные рабочие операции и измерьте время. Дату жизненного цикла SQL Server и доступность расширенных обновлений сверяйте с официальной документацией Microsoft для вашей редакции и лицензии.

Что на самом деле означает конец поддержки SQL Server 2016

Жизненный цикл SQL Server состоит из пяти лет обычной (mainstream) поддержки и ещё пяти лет расширенной (extended) — итого десять [2]. Расширенная поддержка SQL Server 2016 закончилась 14 июля 2026 года [1]. Это не значит, что база данных перестаёт работать: сервер продолжает принимать подключения, задания продолжают выполняться. Меняется другое — Microsoft больше не выпускает для этой версии регулярные обновления безопасности, исправления ошибок и не оказывает техническую поддержку вне отдельной платной программы [1][3].

Microsoft описывает три официальных пути:

1. Переход на Azure SQL (Azure SQL Database, Azure SQL Managed Instance или SQL Server на виртуальных машинах Azure) — снимает с компании задачу обновлений и резервного копирования, но требует облачной инфраструктуры [1].
2. Обновление до SQL Server 2025 — сохраняет локальное или гибридное размещение, даёт актуальные возможности движка и встроенные функции работы с векторным поиском и ИИ-сценариями [1].
3. Extended Security Updates (ESU) — временный «мост» для тех, кому нужно больше времени на подготовку миграции [1][3].

Extended Security Updates: что это и сколько реально стоит

ESU покрывает только критические уязвимости — без новых функций, без исправления некритичных ошибок, без штатной техподдержки [3]. Программа рассчитана на три года, покрытие для SQL Server 2016 действует до 17 июля 2029 года [3]. По оценкам нескольких независимых источников, цена растёт скачкообразно: первый год — около 75% годовой стоимости лицензии, второй — около 150%, третий — около 300%, итого порядка 525% первоначальной стоимости лицензии за три года [5]. С апреля 2026 года Microsoft перешла на единую модель цен ESU — стоимость одинакова вне зависимости от того, работает сервер в Azure или локально [6][4]. Участие в ESU обычно требует действующей лицензии с Software Assurance или подписки — то есть это не разовая покупка «патча», а отдельный контракт [4].

Важная оговорка: наличие программы ESU у Microsoft не означает автоматической возможности ей воспользоваться для конкретной российской компании. С 2022 года доступ к покупке и продлению лицензий Microsoft через прежние каналы для многих организаций в России ограничен или требует нестандартных схем [7]. Это не повод считать вопрос закрытым в ту или иную сторону — доступность ESU (через какого партнёра, на каких условиях, для какого юрлица) нужно проверять индивидуально, до того как закладывать этот вариант в план миграции.

Инвентаризация: с чего начинается безопасная миграция

Прежде чем выбирать целевую платформу, нужно понять, что вообще есть в периметре. Практика показывает, что «забытые» экземпляры на виртуальных машинах, о которых никто не помнит, — типичная находка при инвентаризации перед миграцией [8]. Минимальный набор данных для инвентаризации:

• Экземпляры и редакции: сколько инстансов SQL Server 2016 в контуре, какая редакция (Standard/Enterprise), номер сборки — точный build можно свести с официальным списком обновлений Microsoft [2].
• Базы данных: какие базы принадлежат 1С, какие — другим системам (отчётность, BI, внешние интеграции), их текущий уровень совместимости.
• Драйверы клиентских приложений: какая версия ODBC- или OLE DB-драйвера установлена на серверах приложений и рабочих станциях, откуда именно идут подключения к базе.
• Зависимые приложения: отчётность, внешние сервисы, обмены с сайтом или другими системами, которые обращаются к базе напрямую или через связанные серверы.

Результат этого шага — не список серверов, а карта зависимостей: какая база от какого приложения зависит, и что сломается, если сервер станет недоступен на несколько часов.

Совместимость 1С, уровень совместимости и используемые функции

Какие версии SQL Server официально поддерживает 1С

По официальному списку системных требований «1С:Предприятия 8», платформа поддерживает Microsoft SQL Server версий 2016, 2017, 2019 и 2022 [9]. SQL Server 2025 в этом списке на момент подготовки статьи не указан. Это значит, что решение «раз Microsoft советует переходить на SQL Server 2025, значит и 1С туда же» нельзя принимать автоматически: нужно свериться с актуальным списком 1С непосредственно перед проектом, потому что список обновляется, а официальная поддержка новой версии СУБД конкретной платформой 1С может появиться позже релиза самой СУБД.

Показательно и то, куда фактически расширяется список поддерживаемых 1С СУБД: помимо MS SQL Server там сейчас перечислены несколько версий Postgres Pro, Tantor SE/Certified для 1С и Pangolin [9] — то есть 1С системно готовит клиентов к работе не только с продуктами Microsoft, и для части заказчиков это отдельный, самостоятельный вариант миграции, а не запасной.

Проверка фактически используемых функций СУБД

Совместимость версии — это не только номер релиза, но и то, какие конкретно возможности движка реально задействованы в вашей конфигурации и внешних компонентах. Для выявления таких проблем у Microsoft есть отдельный инструмент — Data Migration Assistant (DMA), который сканирует исходные базы на предмет проблем совместимости при переходе на новую версию SQL Server или в Azure и указывает на устаревшие (deprecated) функции, которые могут не работать на целевой платформе [10].

Отдельно стоит явно проверить состав используемых клиентских драйверов и провайдеров подключения: например, SQL Server Native Client (SNAC) — устаревший компонент для доступа к данным по ODBC и OLE DB, который был полностью удалён из SQL Server 2022 и SQL Server Management Studio 19; Microsoft прямо рекомендует переходить на новый драйвер Microsoft OLE DB (MSOLEDBSQL) или актуальный ODBC-драйвер для новых и существующих приложений [11]. Если внешние отчёты, интеграционные сервисы или сторонние компоненты подключаются к базе через SNAC, это нужно исправить до миграции, а не обнаружить постфактум, когда часть интеграций перестанет подключаться.

К списку функций, которые стоит явно проверить перед переносом, помимо драйверов относятся: используемые провайдеры для связанных серверов, наличие CLR-объектов, полнотекстового поиска, репликации, шифрования на уровне столбцов и любых расширений, установленных поверх штатной поставки СУБД — каждый из этих компонентов имеет собственные условия переноса и не гарантированно «переезжает» вместе с базой данных при простом backup/restore.

Уровень совместимости базы и риск деградации после переноса

Уровень совместимости базы данных (compatibility level) — это переключатель, который позволяет обновить движок СУБД, не меняя поведение оптимизатора запросов для существующей базы «сразу и полностью» [13]. После восстановления базы на новом сервере уровень совместимости обычно можно оставить прежним и поднимать его отдельно, контролируемо. Это важно, потому что смена уровня совместимости меняет модель стоимости запросов оптимизатора — известны задокументированные случаи, когда план выполнения переключался с параллельного на последовательный именно из-за повышения уровня совместимости, что резко замедляло тяжёлые запросы с большими результирующими наборами [12]. Рекомендованный Microsoft рабочий процесс — снять эталон производительности через Query Store на старом уровне совместимости, затем поднимать уровень поэтапно и сравнивать планы выполнения «до» и «после» [13].

Российская специфика

Доступность ESU и лицензий

Как уже сказано выше, ESU — легитимная программа Microsoft, но для конкретного российского юрлица нужно отдельно выяснять: через какого партнёра можно оформить или продлить лицензию, какие условия оплаты доступны и не изменились ли они с момента подготовки этого текста [7]. По данным профильных публикаций, после введения санкций Microsoft сократила число партнёров, через которых распространяются лицензии SQL Server, что напрямую влияет на доступность канала для продлений и новых покупок [14]. Не стоит ни исключать вариант ESU заранее, ни закладывать его в бюджет без проверки у партнёра по лицензированию.

Импортозамещение СУБД: отдельные сроки

Указ президента от 30.03.2022 № 166 и последующие методические рекомендации вводят поэтапный запрет на использование иностранного ПО для государственных компаний, компаний с госучастием и субъектов критической информационной инфраструктуры (КИИ) [15][16]. Особенность именно для СУБД в том, что срок перехода отличается от сроков по операционным системам, офисным пакетам и антивирусам: если по большинству категорий ПО ориентир — 1 января 2025 года, то для баз данных методические рекомендации называют более поздний срок — 1 января 2026 года [16][15]. Дальнейшее ужесточение требований к КИИ продолжается и в 2026 году, с отдельными подзаконными актами по срокам категорирования и перехода [17][18].

Практический вывод: если ваша компания — субъект КИИ, госорганизация или компания с госучастием, вопрос «обновлять SQL Server 2016 или переезжать на другую СУБД» для вас может быть не техническим, а нормативным, и обновление до SQL Server 2019/2022/2025 само по себе не решает требование по импортозамещению. Для остальных коммерческих компаний, не относящихся к этим категориям, обязательных сроков перехода на отечественную СУБД по этим актам может не быть — но это стоит подтвердить с юристом по ИТ-регулированию именно для вашей отрасли, а не считать по умолчанию.

1С и российские СУБД как реальная альтернатива

Учитывая, что 1С официально поддерживает несколько линеек Postgres Pro, Tantor и Pangolin [9], миграция с SQL Server 2016 не обязана заканчиваться другой версией SQL Server. Для части компаний — особенно тех, кто попадает под требования импортозамещения, — правильнее сравнивать не «SQL Server 2016 → SQL Server 2022», а «SQL Server 2016 → SQL Server 2022 (временное решение)» против «SQL Server 2016 → Postgres Pro / Tantor (стратегическое решение)». Это две разные по сложности задачи: смена редакции SQL Server — это преимущественно перенос объектов и проверка производительности; смена СУБД — это ещё и адаптация части кода на уровне 1С, которая иначе работает с диалектом SQL и хранимыми процедурами.

Что переносится вместе с базой, а не само по себе

Ключевая ошибка при миграции — считать, что резервное копирование и восстановление базы данных переносит всё окружение. На практике отдельно нужно переносить как минимум три вещи.

Логины и права

Резервная копия базы содержит пользователей базы данных (database users), но не логины уровня сервера (server logins) и их пароли — это два разных объекта SQL Server. У Microsoft есть штатная документированная процедура выгрузки логинов и паролей (включая SID) с одного экземпляра для последующего создания на другом [19]. Важный нюанс из той же документации: по умолчанию выполнить выгрузку логинов может только член роли sysadmin, а сама процедура не переносит информацию о базе данных по умолчанию для конкретного логина — на новом сервере эта база может просто не существовать [19]. Отдельно нужно свериться, что SID пользователей базы данных совпадают с SID серверных логинов после переноса — иначе пользователь физически не сможет подключиться под восстановленной учётной записью, хотя формально она существует.

Задания SQL Agent

Задания SQL Agent (резервное копирование, регламентные обработки 1С, интеграционные обмены по расписанию) хранятся в системной базе msdb и не переносятся вместе с пользовательской базой данных. Практикующие администраторы используют два основных подхода: скриптование каждого задания через SSMS («Script Job as… Create To») с последующим выполнением скрипта на целевом сервере, либо программный перенос через T-SQL-скрипты, которые читают системные таблицы msdb (sysjobs, sysjobsteps, sysjobschedules) на одном сервере и создают аналогичные записи на другом [20]. Второй подход быстрее при большом числе заданий, но требует аккуратности: задания стоит переносить в выключенном состоянии и включать по одному, чтобы не запустить одновременно несколько тяжёлых регламентных операций на непрогретом новом сервере.

Связанные серверы и настройки резервного копирования

Связанные серверы (linked servers) — это конфигурация конкретного экземпляра, а не базы данных: пароли для входа на связанный сервер (linked server login) физически не экспортируются штатными средствами и их придётся создавать заново на целевом сервере. То же самое касается заданий плана обслуживания и расписаний резервного копирования: если на старом сервере это настроено через Maintenance Plans или сторонний агент, конфигурацию нужно воссоздать на новом окружении, а не полагаться на то, что она «приедет» вместе с базой.

Практические этапы миграции

Ниже — последовательность, которая закрывает и техническую, и организационную часть переноса.

1. Инвентаризация окружения. Список экземпляров, редакций, версий сборок, драйверов клиентов, зависимых приложений и связанных серверов.
2. Проверка совместимости 1С и используемых функций. Сверка целевой версии СУБД с актуальным списком поддерживаемых 1С СУБД [9], сканирование базы инструментом вроде DMA на устаревшие функции [10], проверка используемых драйверов и провайдеров подключения [11].
3. Развёртывание тестового окружения. Целевая версия СУБД на отдельном сервере/ВМ, максимально близкая по конфигурации к боевой среде.
4. Перенос схемы и данных. Backup/restore или detach/attach для самих баз данных.
5. Перенос окружения экземпляра. Логины и права [19], задания SQL Agent [20], связанные серверы, настройки резервного копирования и alert-уведомлений.
6. Снятие эталона производительности. Query Store или расширенные события на старом сервере под реальной нагрузкой — это должно быть сделано до отключения старого сервера, а не постфактум.
7. Контролируемое повышение уровня совместимости. Поэтапно, со сравнением планов выполнения ключевых запросов [12][13].
8. Тестирование регламентных операций. Резервное копирование, обновление статистики, реиндексация, регламентные обработки 1С — на тестовом контуре, под нагрузкой, приближенной к боевой.
9. Репетиция восстановления и расчёт простоя. Отдельный этап, вынесенный ниже в собственный раздел.
10. Переключение и период повышенного наблюдения. Первые дни после перехода — усиленный мониторинг журналов ошибок, планов выполнения и длительности регламентных заданий.

Проверка производительности: до и после переноса

Сравнение «на глаз» — плохая методика: разница в 10–15% по времени выполнения тяжёлого регламентного задания (закрытие месяца, перепроведение документов, формирование отчётности) может быть незаметна в моменте, но накопиться к концу отчётного периода. Практический подход — зафиксировать через Query Store или расширенные события набор из 10–20 самых ресурсоёмких запросов и регламентных операций на старом сервере, затем прогнать тот же набор на новом окружении при сопоставимой нагрузке [13]. Отдельно стоит проверить именно те запросы, которые чувствительны к смене плана выполнения при повышении уровня совместимости — как правило, это запросы с большими результирующими наборами и сложными соединениями, где чаще всего фиксируется переключение с параллельного плана на последовательный [12].

Проверка восстановления и реальной длительности простоя

Резервная копия, которая никогда не восстанавливалась на другом сервере, — это гипотеза, а не готовность к аварии. Перед миграцией стоит явно измерить:

• Фактическое время восстановления полной резервной копии актуального размера на целевом оборудовании — это число редко совпадает с оценкой «по документации».
• Время до готовности базы к работе, включая проверку целостности, обновление статистики и прогрев кэша — иногда это занимает больше времени, чем само восстановление файла.
• План отката, если после переключения на новый сервер обнаружится критичная проблема — на какой стадии переключение ещё можно безопасно отменить.

Эти цифры и становятся основой реального окна простоя, которое можно согласовывать с бизнесом, а не абстрактным «перенесём ночью, должно уложиться».

Как разграничить обновление СУБД, ESU и смену платформы

Три задачи часто смешивают в один проект, хотя логически они разные:

• ESU — это способ купить время без изменения архитектуры. Он не решает задачу модернизации и не отменяет необходимость миграции — это отсрочка с растущей ценой [3][5].
• Обновление СУБД (SQL Server 2016 → 2019/2022/2025) — техническая задача переноса объектов, логинов, заданий и проверки совместимости 1С, описанная выше. Она не меняет архитектуру системы и не закрывает требования по импортозамещению, если они применимы к организации.
• Смена платформы (переход на другую СУБД или в облако) — отдельный проект с иным объёмом рисков: адаптация кода, обучение администраторов, пересмотр схемы резервного копирования и мониторинга. Его не стоит запускать «заодно» с задачей ухода от end-of-life версии — совмещение двух больших изменений в одном окне обычно увеличивает и риск, и продолжительность простоя.

Разделение этих трёх задач на бумаге — до начала проекта — помогает не выбрать ESU как «временное решение», которое незаметно становится постоянным, и не затянуть простую задачу обновления версии в полноценный проект смены платформы без явного решения об этом.

Типичные ошибки и риски

• Забыть про логины уровня сервера и их SID — база данных «восстановилась», но пользователи не могут подключиться.
• Не перенести или не проверить задания SQL Agent, отвечающие за регламентные обмены — обмен «просто перестаёт работать», хотя ошибки в приложении нет.
• Поднять уровень совместимости базы сразу и полностью, без промежуточного сравнения планов выполнения — регламентные операции внезапно замедляются в разы.
• Не проверить фактически используемые функции и клиентские драйверы — часть интеграций перестаёт подключаться после удаления устаревшего компонента вроде SNAC на новой версии.
• Выбрать целевую версию SQL Server без проверки актуального списка поддерживаемых 1С СУБД [9] — конфигурация технически работает, но остаётся вне зоны официальной поддержки со стороны 1С.
• Считать ESU автоматически доступным вариантом для российской компании без проверки у партнёра по лицензированию [7][14].
• Не различать сроки импортозамещения для КИИ/госсектора и требования для обычной коммерческой компании — и то принять на себя лишние обязательства, то пропустить реально применимый срок [15][16][17].
• Не репетировать восстановление резервной копии на целевом оборудовании — реальное время простоя оказывается сюрпризом в ночь переключения.

Как выбрать решение под свою ситуацию

Если база некритична к срокам и относится к обычной коммерческой компании без требований КИИ — разумный путь: обновление до поддерживаемой версии SQL Server (2019/2022, с проверкой поддержки 2025 версией 1С на момент проекта) с полноценным переносом окружения экземпляра. Если нужен запас времени на подготовку — ESU, но с чётким пониманием растущей стоимости и обязательным параллельным планированием миграции, а не вместо неё. Если организация подпадает под требования по импортозамещению СУБД или стратегически хочет снизить зависимость от одного вендора — стоит рассматривать переход на Postgres Pro/Tantor как отдельный проект, сравнивая его не только по лицензионной стоимости, но и по объёму адаптации конфигураций 1С и обучения команды администрирования.

Вывод

Конец обычной поддержки SQL Server 2016 — это не техническая авария, а управленческое решение, которое нужно принять осознанно: купить время через ESU, обновить СУБД в рамках прежней архитектуры или пересмотреть платформу целиком с учётом требований импортозамещения. В любом из этих сценариев перенос самой базы данных — только часть работы: логины, задания SQL Agent, связанные серверы и настройки резервного копирования нужно переносить отдельно и проверять так же тщательно, как и саму базу, а решение о повышении уровня совместимости — принимать на основании измеренной, а не предполагаемой производительности.

Источники

[1] microsoft.com — SQL Server 2016 end of support is here: Plan your next steps — https://www.microsoft.com/en-us/sql-server/blog/2026/07/14/sql-server-2016-end-of-support-is-here-plan-your-next-steps/

[2] learn.microsoft.com — KB3177312: SQL Server 2016 build versions — https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2016/build-versions

[3] techcommunity.microsoft.com — SQL Server 2016 Extended Security Updates: Stay Protected While You Modernize — https://techcommunity.microsoft.com/blog/sqlserver/sql-server-2016-extended-security-updates-stay-protected-while-you-modernize/4529478

[4] learn.microsoft.com — Варианты окончания поддержки SQL Server — https://learn.microsoft.com/ru-ru/sql/sql-server/end-of-support/sql-server-end-of-support-overview?view=sql-server-ver16

[5] brentozar.com — SQL Server 2016 Support Ends in 90 Days — https://www.brentozar.com/archive/2026/04/sql-server-2016-support-ends-in-90-days/

[6] learn.microsoft.com — Clarification on ESU cost for SQL Server 2016 (Q&A) — https://learn.microsoft.com/en-us/answers/questions/5882155/clarification-on-esu-cost-for-sql-server-2016-on-w

[7] zerobit.ru — Блокировка Microsoft в России: варианты перехода для бизнеса — https://zerobit.ru/blog/microsoft_stops_its_cloud_services_for_russian_companies_what_to_do_2024

[8] northdoor.co.uk — When Does SQL Server 2016 Support End? — https://www.northdoor.co.uk/insight/blog/sql-server-2016-support-end-july-2026/

[9] v8.1c.ru — СУБД | Системные требования «1С:Предприятия 8» — https://v8.1c.ru/tekhnologii/systemnye-trebovaniya-1s-predpriyatiya-8/subd/

[10] github.com/MicrosoftDocs — Overview of Data Migration Assistant — https://github.com/MicrosoftDocs/sql-docs/blob/live/docs/dma/dma-overview.md

[11] learn.microsoft.com — SQL Server Native Client (удаление SNAC из SQL Server 2022 и SSMS 19) — https://learn.microsoft.com/en-us/sql/relational-databases/native-client/sql-server-native-client?view=sql-server-ver15

[12] learn.microsoft.com — Уровень совместимости обновления снижает производительность — https://learn.microsoft.com/ru-ru/troubleshoot/sql/performance/upgrade-compatibility-level-degrades-performance

[13] learn.microsoft.com — Change the Database Compatibility Level and Use the Query Store — https://learn.microsoft.com/en-us/sql/database-engine/install-windows/change-the-database-compatibility-mode-and-use-the-query-store?view=sql-server-ver17

[14] infostart.ru — Вопросы и ответы по лицензированию Microsoft SQL Server — https://infostart.ru/1c/articles/1010055/

[15] kontur.ru — Указ президента об импортозамещении: что изменится с 1 января 2025 года — https://kontur.ru/talk/spravka/54411-ukaz_prezidenta_ob_importozameshchenii

[16] kontur.ru — Импортозамещение ПО в России — https://kontur.ru/talk/spravka/51205-importozameshchenie_po_v_rossii

[17] habr.com — КИИ-2026: нормы безопасности и импортозамещение СУБД — https://habr.com/ru/companies/mt-integration/articles/1003118/

[18] passwork.ru — Импортозамещение ИБ-решений: переход на российское ПО — https://passwork.ru/blog/importozamieshchieniie-ib-rieshienii/

[19] learn.microsoft.com — Передача имен входа и паролей SQL Server между экземплярами — https://learn.microsoft.com/ru-ru/troubleshoot/sql/database-engine/security/transfer-logins-passwords-between-instances

[20] habr.com — Перенос заданий и расписаний с одного экземпляра MS SQL Server на другой средствами T-SQL — https://habr.com/ru/articles/341196/