Миграция 1С на PostgreSQL

Что входит

Мигрируем базы 1С на отечественный стек PostgreSQL: аудит, тестовый перенос, оптимизация и контролируемый переход с минимальным простоем.

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

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

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

Этапы работы

1. 01Аудит баз и нагрузки
2. 02Тестовый перенос и проверка целостности
3. 03Оптимизация производительности
4. 04Финальный перенос и сопровождение

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

Как устроен процесс миграции?

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

Данные не потеряются при переходе?

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

Всё ли работает после смены СУБД?

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

Что нужно предоставить для старта?

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