Как перенести базу 1С на новую платформу

Перенос базы 1С на новую платформу — задача, с которой рано или поздно сталкивается любой администратор: старые версии платформы снимаются с поддержки, новые конфигурации требуют свежих релизов, а обновления безопасности выходят только для актуальных версий. Сам по себе переход несложен, если база типовая и обновления устанавливались регулярно, но при пропущенных релизах, доработках и больших объёмах данных процедура требует подготовки.

Главный риск при миграции — потеря или повреждение данных из-за прерванного обновления, несовместимости конфигурации с новой платформой или отсутствия рабочей резервной копии. Все эти риски устраняются последовательным планом: сначала копия и тестовый прогон, затем перенос рабочей базы в нерабочее время.

Ниже разобран полный цикл: от оценки текущего состояния базы до проверки результата после перехода. Инструкция подходит как для файловых, так и для клиент-серверных баз, различия отмечены отдельно.

Оцените текущее состояние базы перед переносом

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

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

Сделайте резервную копию правильно

Резервная копия — обязательное условие, без которого перенос начинать нельзя. Для файловой базы выполните выгрузку в dt через конфигуратор («Администрирование» → «Выгрузить информационную базу») и дополнительно скопируйте сам файл 1Cv8.1CD. Выгрузка dt проверяет целостность, а копия файла создаётся быстрее и служит второй линией защиты.

Для клиент-серверной базы сделайте полный бэкап средствами СУБД (MS SQL, PostgreSQL) — это надёжнее и быстрее dt на больших объёмах. Выгрузку dt при этом тоже полезно выполнить: она позволяет развернуть копию на другом сервере без привязки к конкретной СУБД.

Проверьте копию до начала работ: разверните её в отдельный каталог или на тестовый сервер и убедитесь, что база открывается, пользователи входят, документы читаются. Непроверенная копия — это отсутствие копии.

Установите новую платформу и проверьте совместимость

Установите новую версию платформы параллельно со старой — они сосуществуют на одном компьютере или сервере без конфликта, база привязывается к конкретной версии в свойствах подключения. Старую платформу не удаляйте до полного завершения миграции: она понадобится для отката.

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

Выполните обновление конфигурации на тестовой копии

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

После установки обновления платформа выполнит реструктуризацию — изменение структуры таблиц. На больших базах это занимает от десятков минут до нескольких часов, прерывать процесс нельзя. Засеките фактическое время на тесте: это даст реалистичное окно для обновления рабочей базы.

Если конфигурация доработана, сравнение и объединение с новым релизом потребует ручной разборки изменений. Проверьте работу расширений: часть из них может потребовать адаптации под новую версию.

1. 1
   Согласуйте окно простоя и предупредите пользователей
2. 2
   Завершите все сеансы и заблокируйте вход в базу
3. 3
   Сделайте финальную резервную копию (dt и бэкап СУБД)
4. 4
   Установите обновления конфигурации цепочкой до целевого релиза
5. 5
   Дождитесь завершения реструктуризации и обработчиков обновления
6. 6
   Переключите базу на новую платформу, проверьте вход и ключевые операции
7. 7
   Разблокируйте доступ и наблюдайте за работой первые дни

Перенесите рабочую базу и проверьте результат

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

После завершения обновления проверьте не только вход в базу, но и отложенные обработчики: в типовых конфигурациях часть данных обновляется в фоне после первого запуска. Откройте монитор обновления (в типовых — «Администрирование» → «Результаты обновления») и дождитесь статуса завершения, иначе пользователи увидят неполные данные.

Контрольные точки

Как проверить результат

Вход пользователей

Норма

Все роли входят без ошибок

Тревожный признак

Ошибки прав или отсутствие интерфейса

Обработчики обновления

Норма

Все отложенные обработчики завершены

Тревожный признак

Зависшие или аварийные задания

Ключевые операции

Норма

Проведение документов, отчёты, обмены работают

Тревожный признак

Ошибки при проведении, пустые отчёты

Регламентные задания

Норма

Выполняются по расписанию без ошибок

Тревожный признак

Задания падают или не запускаются

Типичные ошибки и откат при неудаче

Большинство проблем при переносе связано не с самой платформой, а с нарушением порядка действий: пропуск промежуточных релизов, обновление без теста, прерванная реструктуризация. Отдельный источник сбоев — нехватка места на диске: при реструктуризации большой базы временные файлы могут превышать её размер.

План отката должен быть готов до старта: если обновление рабочей базы провалилось, не пытайтесь «чинить на месте» — восстановите базу из копии, верните подключение к старой платформе и разбирайте причину на тестовой среде. Именно поэтому старую платформу и копии держат под рукой минимум до конца первой недели работы на новой версии.

Частые вопросы

Можно ли перенести базу, не обновляя конфигурацию?

Да, если текущий релиз конфигурации поддерживает новую платформу — это указано в системных требованиях релиза. Часто конфигурация запускается на новой платформе в режиме совместимости. Но на практике переход на новую платформу обычно совмещают с обновлением конфигурации, поскольку свежие релизы изначально рассчитаны на актуальные версии платформы.

Сколько времени занимает перенос?

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

Что делать, если обновление прервалось ошибкой?

Не перезапускайте обновление поверх повреждённой базы. Восстановите рабочую копию из резервной копии, зафиксируйте текст ошибки и воспроизведите ситуацию на тестовой базе. Частые причины — нехватка места на диске, разрыв соединения с СУБД, повреждения в исходной базе, которые выявляет тестирование и исправление.

Нужно ли обновлять платформу на всех компьютерах пользователей?

Да. После перевода базы на новую версию платформы тонкие и толстые клиенты старых версий не смогут подключиться. Обновите клиентские места заранее или сразу после миграции; при работе через веб-сервер или сервер 1С достаточно обновить серверную часть и публикацию.

Чем отличается перенос файловой базы от серверной?

Принцип тот же, различаются инструменты: для файловой базы копия — это выгрузка dt и копирование файла 1Cv8.1CD, для серверной — бэкап средствами СУБД. Серверная миграция дополнительно требует контроля сеансов через консоль кластера и достаточного места под временные файлы СУБД при реструктуризации.

Можно ли вернуться на старую платформу после перехода?

Только через восстановление базы из резервной копии, сделанной до обновления: база, сконвертированная новой платформой, в старой не открывается. Поэтому копию и старую версию платформы сохраняют как минимум до подтверждения стабильной работы на новой версии.