Импортозамещение прикладного ПО перестало быть формальной отчётностью. Постановление Правительства № 1236 и требования к госкомпаниям закрепили переход на софт из реестра Минцифры, а сроки по объектам КИИ сместили задачу из плоскости «когда-нибудь» в текущий бюджетный цикл. Прикладной слой – ERP, CRM, BI, документооборот, почта – мигрировать сложнее инфраструктуры: здесь живут бизнес-логика, интеграции и данные за десять лет. Ниже – как мы подходим к такому переносу на практике.

С чего начинается миграция

Сначала – инвентаризация, а не выбор вендора. Нужен реестр приложений с владельцами, версиями, лицензиями и картой интеграций. Без этой карты любой план переноса разваливается на первом же скрытом обмене данными между системами.

Дальше каждое приложение проходит через четыре сценария: заменить на отечественный аналог из реестра, переписать на open-source стек, оставить как есть (если санкционных и лицензионных рисков нет) или вывести из эксплуатации. Решение принимаем по матрице «критичность для бизнеса × сложность замены × стоимость владения». Почтовый сервер и портал мигрируют быстро, ядро ERP – годами, и это нормально планировать поэтапно.

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

Как снизить риск переключения

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

Чтобы развёртывание было предсказуемым и повторяемым, среды описываем кодом. Подход инфраструктуры как кода даёт идентичные тест, препрод и прод, а значит – миграционные прогоны, которые не «работают только на одной машине». Монолитные системы при переносе удобно резать на сервисы по доменам: мы уже описывали такую декомпозицию на примере перевода e-commerce на микросервисы. Это позволяет замещать импортные компоненты по частям, не останавливая весь контур.

Что важно для госсектора

Для госкомпаний и владельцев КИИ важна не только функция, но и доказуемость. Выбранное ПО должно числиться в реестре отечественного, СУБД и ОС – иметь сертификаты ФСТЭК там, где это требуется по классу защищённости. Поэтому реестр совместимости и протоколы испытаний мы готовим параллельно с техническими работами, а не после.

Второй акцент – независимость от одного поставщика. Открытые форматы, документированные API и отказ от закрытых расширений снижают вероятность, что через год придётся мигрировать повторно. Замещение ради галочки в отчёте создаёт новую зависимость вместо старой.

Вывод

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