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

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

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

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

Шаг 1. Проверьте совместимость конфигурации и платформы

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

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

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

Шаг 2. Сделайте полную резервную копию

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

Для клиент-серверной базы используйте штатные средства СУБД: для MS SQL Server — полный backup базы, для PostgreSQL — pg_dump. Выгрузка .dt через конфигуратор для больших клиент-серверных баз может занимать часы и не всегда применима как основной метод, но как дополнительная страховка полезна.

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

Шаг 3. Установите новую платформу и подготовьте тестовую среду

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

Создайте тестовую копию базы: скопируйте каталог файловой базы в отдельный каталог или восстановите backup СУБД под другим именем базы. Подключите тестовую базу в списке информационных баз с явным указанием новой версии платформы.

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

1. 1
   Зафиксируйте текущие версии платформы и конфигурации
2. 2
   Проверьте совместимость целевого релиза конфигурации с новой платформой
3. 3
   Сделайте полную резервную копию и проверьте её восстановление
4. 4
   Установите новую платформу, не удаляя старую
5. 5
   Создайте тестовую копию базы и выполните конвертацию на ней
6. 6
   Обновите конфигурацию тестовой базы до нужного релиза
7. 7
   Проведите тестирование ключевых операций
8. 8
   Запланируйте окно простоя и повторите процедуру на рабочей базе
9. 9
   Проверьте работу пользователей и оставьте старую платформу как запасной вариант

Шаг 4. Обновите конфигурацию на тестовой копии

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

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

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

Шаг 5. Протестируйте работу на копии

Тестирование должно покрывать реальные сценарии работы, а не только факт открытия базы. Минимальный набор: вход под типичными ролями пользователей, проведение ключевых документов, формирование регламентированной отчётности, обмены с другими системами, печать, работа оборудования (сканеры, ККТ, эквайринг).

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

Замерьте скорость выполнения типовых операций на тестовой базе и сравните с рабочей. Заметная деградация производительности — повод разобраться с настройками СУБД и индексами до перехода, а не после жалоб пользователей.

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

Как проверить готовность к переходу

Открытие базы на новой платформе

Норма

База открывается без ошибок конвертации

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

Ошибки структуры, аварийное завершение

Проведение документов

Норма

Ключевые документы проводятся, движения корректны

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

Ошибки проведения, неверные итоги

Отчёты и печать

Норма

Отчёты формируются, печатные формы выводятся

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

Пустые отчёты, ошибки макетов

Обмены и интеграции

Норма

Данные уходят и приходят без ошибок

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

Обрывы обмена, ошибки форматов

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

Норма

Выполняются по расписанию

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

Задания не стартуют или падают с ошибкой

Шаг 6. Выполните переход рабочей базы и план отката

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

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

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

Особые случаи: клиент-серверный вариант и сильно доработанные конфигурации

Для клиент-серверных баз дополнительно проверьте совместимость новой платформы с версией СУБД и обновите при необходимости саму СУБД — но отдельным этапом, не одновременно с платформой. После перехода обновите статистику и пересоздайте индексы средствами СУБД, это влияет на производительность.

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

Если база работает через веб-сервер или тонкие клиенты, не забудьте обновить публикацию на веб-сервере и дистрибутивы клиентов — несовпадение версий клиента и сервера приводит к отказу в подключении.

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

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

Напрямую — нет: после конвертации база не открывается на старой версии платформы. Откат выполняется восстановлением резервной копии, сделанной до конвертации. Именно поэтому копия должна быть свежей и проверенной.

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

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

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

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

Что делать, если после обновления не работают внешние печатные формы?

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

Можно ли выполнить переход своими силами без привлечения специалистов?

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

Как узнать, что обновление данных завершилось полностью?

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