Реестр отечественного ПО заработал с 1 января, и госзаказчики теперь обязаны обосновывать каждую закупку зарубежного софта. Для многих это означает один вопрос: что делать с базами на Oracle и Microsoft SQL Server, на которых годами держится учёт, документооборот и отраслевые системы. Лицензии дорожают вместе с курсом, а поддержка вендора больше не выглядит надёжной опорой. Миграция на PostgreSQL или другую СУБД из реестра – задача решаемая, но проваливается она ровно там, где её начинают без плана.

Начните с аудита, а не с переноса данных

Перенести таблицы и строки – самая простая часть. Проблемы прячутся в логике. Соберите полную карту зависимостей: хранимые процедуры, триггеры, представления, пакеты PL/SQL и T-SQL, права доступа, задания планировщика. Отдельно выпишите всё, что приложение делает в обход стандартного SQL – иерархические запросы CONNECT BY, аналитические функции, специфичные типы данных, последовательности.

Каждый такой элемент классифицируйте: переносится автоматически, требует ручной переработки или подлежит выносу в код приложения. По нашему опыту, 60–70% объектов конвертируются инструментами вроде ora2pg, а оставшаяся треть – это и есть основной бюджет проекта. Именно недооценка этой трети срывает сроки.

Перенесите схему и логику поэтапно

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

PL/SQL и T-SQL придётся адаптировать под PL/pgSQL вручную: различаются обработка транзакций, поведение пустых строк и NULL, упаковка в пакеты. Сложную логику лучше выносить из базы в сервисный слой приложения – это упрощает не только текущую миграцию, но и будущее сопровождение. Если архитектура движется к контейнерам, держите СУБД и сервисы как отдельные управляемые компоненты; здесь полезен опыт перехода на оркестрацию рабочих нагрузок, где состояние и логика тоже разносятся по слоям.

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

Тестируйте под реальной нагрузкой

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

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

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

Вывод

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