У нефтесервисной компании выгрузка пилотной базы объёмом около 300 ГБ в DT занимала 22 часа. После переноса два списка документов открывались в PostgreSQL несколько часов, хотя в MS SQL Server хватало нескольких секунд. Службы работали, пользователи входили в базу — но переключать рабочую систему было рано. Эти результаты описаны в кейсе RG-Soft о миграции 1С на PostgreSQL.
Перед вами стоит другая задача: сменить СУБД, сервер или редакцию 1С и сохранить рабочий день. Для этого мало перенести данные. До переключения нужно проверить операции пользователей, обмены, резервную копию и возврат на прежний контур.
Сначала отделите миграцию от обновления
Словом «миграция» часто называют три разных проекта. У них разные риски, сроки и критерии приёмки.
| Что меняется | Где искать риск | Что подтвердить на пилоте |
|---|---|---|
| Физический сервер или виртуальная среда | Ресурсы ВМ, сеть, диски, доступ к общим папкам | База запускается после переноса ВМ, пользователи и внешние системы видят нужные адреса |
| СУБД, например MS SQL Server на PostgreSQL | Запросы, типы данных, планы выполнения, поведение доработок | Тяжёлые списки, отчёты и проведение документов укладываются в рабочее время |
| Редакция конфигурации или версия платформы | Расширения, обмены, обработки, клиентские приложения | Критичные сценарии проходят на новой версии, возврат проверен до смены режима совместимости |
Вывод из таблицы: один успешный вход в базу подтверждает только запуск. Он ничего не говорит о проведении документов, обменах и длительности отчётов.
Производственное предприятие из кейса Copycon сохранило текущий программный стек. Подрядчик подготовил виртуальную машину, ночью перенёс базы 1С и общие папки, затем запустил систему на новом физическом сервере. Основные риски лежали в инфраструктуре, а не в запросах прикладного решения.
У компании «ОкаТрансНефть» проект выглядел иначе. Две круглосуточные АЗС перешли с «1С:Розницы» 2.3 на редакцию 3.0. Оперативный и бухгалтерский учёт объединили в «1С:Фреш». Здесь требовалось сохранить продажи и наладить обмен между старой и новой системами. Проект команды «Форус» описан в публикации фирмы «1С».
Если текущая СУБД пока работает, это ещё не довод откладывать проект. Сначала проверьте сроки поддержки и совместимость версий по порядку оценки работающей СУБД. Так вы отделите плановый переход от замены системы после отказа или прекращения поддержки.
Пилот должен повторять слабые места рабочей базы
Чистая демонстрационная база не отвечает на вопрос о готовности к миграции. В ней нет ваших расширений, старых данных, обменов и запросов, которые выросли за годы эксплуатации.
В проекте нефтесервисной компании переносили 17 систем. Для пилота выбрали доработанную 1С:УПП с базой около 300 ГБ и нагрузкой до 300 активных пользователей. Именно такая база могла показать ошибки, которые не видны на типовой конфигурации.
Проверка нашла семь текстовых значений размером от нескольких сотен мегабайт до объёма свыше 1 ГБ. Поля больше 512 МБ вызывали ошибки при загрузке в PostgreSQL. Этот дефект нельзя было обнаружить по скриншоту запущенного клиента.
После загрузки проявился второй класс проблем. Два списка со сложными запросами открывались несколько часов вместо нескольких секунд. Разработчики вынесли часть расчётов в кеширующие регистры. По итогам испытаний также изменили четыре отчёта и алгоритмы проведения шести документов.
Эти цифры относятся только к проекту RG-Soft. Переносить их на другую базу нельзя. Для вашей системы ценность кейса в методе: пилот строят вокруг самых тяжёлых данных и операций, а не вокруг удачного запуска службы.
Полный пилот проводят на копии рабочих данных. В него входят лицензии, печать, сетевой доступ, обмены, резервное копирование и откат. Пошаговый состав такой проверки есть в руководстве по переносу рабочего контура 1С.
Соберите проверку из действий пользователей
Фраза «провести нагрузочное тестирование» не задаёт критерий приёмки. Вместо неё перечислите операции, без которых остановится рабочий день.
Бухгалтер входит в базу, открывает тяжёлый список, проводит документ и формирует отчёт. Кассир оформляет продажу. Регламентное задание отправляет данные во внешнюю систему. Администратор восстанавливает копию в отдельный контур.
| Проверка | Как выполнять | Что считать результатом |
|---|---|---|
| Вход и начало работы | Запустить толстый, тонкий и веб-клиент теми способами, которыми пользуются сотрудники | Работают нужные способы входа, права и лицензии |
| Тяжёлые операции | Открыть проблемные списки, провести документы, сформировать отчёты за рабочий период | Операция заканчивается за время, которое принимает владелец процесса |
| Обмены и внешние связи | Запустить обмен с сайтом, кассами, ЭДО, бухгалтерией или другой базой | Данные уходят и возвращаются без ручного исправления |
| Резервная копия | Создать копию целевого контура и развернуть её отдельно | В восстановленную базу можно войти и выполнить контрольную операцию |
| Возврат | Пройти записанный сценарий переключения на старую систему | Ответственный знает порядок действий, адреса и границу допустимой потери данных |
Вывод из таблицы: готовность подтверждает пройденный рабочий маршрут, а не состояние служб в консоли.
Для каждой операции назначьте владельца. Администратор проверяет запуск и восстановление, но не решает, верно ли рассчиталась себестоимость. Это подтверждает бухгалтер или другой сотрудник, отвечающий за процесс.
Порог времени тоже задаёт владелец процесса. Если список открывается четыре минуты, сравнивать результат нужно не с абстрактной «нормой», а с рабочим сценарием. Один сотрудник может подождать, а очередь у кассы — нет.
Окно переключения определяет способ переноса
Сценарий выбирают после замера полного цикла на пилоте. В него входят остановка записи, перенос последних изменений, запуск целевой системы и контрольные операции.
Ночной перенос подходит, если вся последовательность помещается в согласованное окно. В кейсе Copycon базы 1С и общие папки перенесли ночью, когда магазины и бухгалтерия не работали. Утром сотрудники вошли уже в систему на новом сервере.
Полная выгрузка не подходит, если база выгружается дольше окна. В нефтесервисном проекте один DT для базы около 300 ГБ создавался примерно 22 часа. Даже без учёта загрузки, проверки и резерва такой способ не помещался бы в короткую ночную остановку.
Для больших систем окно бывает ещё жёстче. В техническом разборе DBReplication на Infostart описан режим, при котором на переключение дают один час раз в две недели или месяц. Основной объём заранее переносят в PostgreSQL, а последующие транзакционные изменения сохраняют отдельно и применяют позже.
Такой подход требует собственной проверки целостности и порядка применения изменений. Его нельзя выбирать только потому, что полная выгрузка идёт долго. Сначала подтвердите, что используемый инструмент поддерживает вашу платформу, конфигурацию и набор типов данных.
При круглосуточной работе старый и новый контуры держат параллельно до контрольной даты. «ОкаТрансНефть» применила такую схему на двух АЗС и переключилась 6 апреля 2026 года без остановки продаж. До переноса в системе ежедневно оформляли свыше 200 чеков по номенклатуре более чем из 3000 позиций, поэтому жёсткая остановка затрагивала бы кассовую работу.
| Условия проекта | Сценарий | Что проверить заранее |
|---|---|---|
| Бизнес останавливается ночью, весь цикл помещается в окно | Перенос готовой ВМ или базы в технологическое окно | Длительность копирования, запуск служб, сетевые адреса, время контрольной операции |
| Окно длится около часа, основной перенос идёт дольше | Предварительная загрузка и отдельная фиксация изменений | Полноту переноса изменений, повторный запуск процедуры, точку остановки записи |
| Продажи или производство нельзя остановить | Параллельная работа старого и нового контуров | Правила синхронизации, границу ответственности систем, способ сверки данных |
| Время переноса пока неизвестно | Ещё один пилот с замером полного цикла | Выгрузку, загрузку, проверку, резерв времени и возврат |
Вывод из таблицы: дата перехода появляется после проверки сценария, а не задаёт его.
Проверьте окружение базы
Миграция ломается не только внутри СУБД. Пользователь может открыть базу и потерять печать, общий каталог или связь с кассой.
Составьте перечень внешних зависимостей до пилота. Включите сетевые папки, лицензирование, фоновые задания, почту, ЭДО, кассовое оборудование, веб-сервисы и задания операционной системы. Для каждой зависимости запишите адрес, владельца и контрольное действие.
В кейсе Copycon вместе с базами переносили общие папки. На новом сервере настроили RAID 1, резервное копирование виртуальной машины, антивирусную защиту и защиту от подбора паролей. Если бы приёмка охватывала только клиент 1С, часть контура осталась бы вне проверки.
Отдельный стенд упрощает повторные испытания. На нём можно развернуть копию, поменять параметры и снова пройти сценарий без работы на боевой системе. Если свободного оборудования нет, оцените подготовку выведенного сервера для контрольных восстановлений.
План возврата проверяют до перехода
Фраза «при проблеме вернёмся назад» не описывает действие. Нужны ответственный, последовательность команд, адрес старой системы и правило обращения с данными, созданными после переключения.
Возврат без потерь возможен не всегда. Если пользователи уже начали вводить документы в новом контуре, простое включение старой базы отбросит эти изменения. До перехода решите, переносите ли новые документы назад, повторяете их вручную или признаёте целевой контур точкой без возврата.
Проверьте процедуру на пилоте. Остановите целевую систему, верните прежние адреса, подключите клиента и выполните контрольную операцию. Запишите фактическое время. Не проверенный возврат остаётся предположением.
Экономику считайте после выбора целевого контура
Сравнивать расходы до проектирования рано. В расчёт входят не только лицензии СУБД, но и сервер, виртуализация, резервный контур, сопровождение и доработки.
Фирма «1С» приводит данные «ОкаТрансНефти»: прежние ежегодные расходы составляли 135 000 рублей, после перехода ожидаются 40 400 рублей. Расчёт по опубликованным исходным данным выглядит так:
135 000 − 40 400 = 94 600 рублей в год.
Доля экономии:
94 600 / 135 000 × 100% ≈ 70%.
Это расчёт для компании с двумя АЗС и облачной инфраструктурой «1С:Фреш». Для своей системы подставьте текущие ежегодные расходы и стоимость выбранного контура. Разовые доработки держите отдельной строкой.
Срок окупаемости получают делением разовых затрат на годовую экономию. Например, если обозначить доработки и перенос буквой M, а ежегодную экономию — E, срок составит M / E лет. Численный результат появится только после коммерческих предложений и оценки доработок вашей базы.
Если выбор зависит от неизвестных доработок, объёма окна и схемы возврата, закажите техническую оценку плана перехода вашей 1С после внутреннего пилота. К этому моменту у исполнителя будут данные для решения, а не только название текущей СУБД.
Когда назначать рабочее переключение
Назначайте дату после четырёх подтверждений:
- копия целевой базы восстановилась в отдельном контуре;
- критичные операции прошли на целевой СУБД или инфраструктуре;
- обмены, печать и внешние зависимости дали ожидаемый результат;
- команда проверила возврат на старый контур по записанным шагам.
При ночной остановке переносите заранее подготовленную ВМ или базу в технологическое окно. При окне около часа заранее переносите основной объём и отдельно обрабатывайте накопленные изменения. При непрерывной работе держите оба контура параллельно до сверки и контрольного переключения.
Хотя бы одно неподтверждённое условие означает продолжение пилота. Не переносите этот риск на утро, когда в систему одновременно войдут кассиры, бухгалтерия и склад.