После ухода западных вендоров реестр отечественного ПО Минцифры стал первым местом, куда идут ИТ-директора за заменой. Записей там тысячи, и формальное наличие продукта в реестре ничего не говорит о том, потянет ли он вашу нагрузку. Часть позиций – зрелые продукты с собственным кодом и поддержкой. Часть – «обёртки»: тонкая оболочка вокруг чужого открытого или зарубежного движка, оформленная как российская разработка. Разберём, как отличить одно от другого до того, как вы подпишете контракт.

Что реально подтверждает запись в реестре

Реестр (формируется по постановлению Правительства № 1236) подтверждает один юридический факт: правообладатель – российское лицо, и исключительные права принадлежат ему. Это важно для госзакупок и для запрета на покупку иностранного софта. Но реестр не проверяет архитектуру, не гарантирует производительность и не страхует от технологической зависимости.

Открывайте карточку и смотрите на четыре поля. Класс ПО – продукт должен закрывать нужный вам класс, а не «соседний». Дата регистрации и история обновлений – свежая запись марта-апреля 2022 года часто означает, что вендор только что переоформил права под спрос. Правообладатель – проверьте его по ЕГРЮЛ: реальная команда разработки или пустое юрлицо. Ссылка на сайт и документацию – если нет ни внятного описания архитектуры, ни требований к окружению, это сигнал.

Как вскрыть «обёртку»

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

  • Состав сборки. Запросите перечень используемых компонентов и open source. Если ядро – это PostgreSQL, Nginx, Keycloak или Elastic с тонким слоем сверху, вы платите за интеграцию, а не за продукт. Это не всегда плохо, но цена и поддержка должны соответствовать.
  • Происхождение лицензий. Уточните лицензии open source-компонентов (GPL, Apache, MIT). От них зависит, сможет ли вендор закрывать уязвимости и не получите ли вы юридических проблем при доработке.
  • Реакция на инциденты. Спросите, как вендор закрывал последние критические CVE в своих зависимостях. История с уязвимостью Log4Shell хорошо показывает, кто отслеживает свой состав ПО, а кто узнаёт о дырах из новостей.
  • Стенд и пилот. Зрелый вендор даёт развернуть продукт на вашем железе и прогнать реальную нагрузку. Обёртка обычно «показывает демо» и тянет с доступом к дистрибутиву.

Как встроить проверку в миграцию

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

Отдельно про сроки. Если уход вендора уже остановил процессы, не хватайте первую попавшуюся запись из реестра – это путь к двойной миграции. Логику быстрых, но управляемых решений мы разбирали в материале про экстренное замещение при уходе вендора, а специфику тяжёлых учётных систем – в разборе замены SAP и ERP.

Вывод

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