Импортозамещение инфраструктурного ПО и СУБД: чем рискуют компании, оставаясь на зарубежных платформах

Когда речь заходит об импортозамещении, большинство компаний в первую очередь думают о прикладном софте — офисных пакетах, CRM, системах документооборота. Риски здесь понятны: в один день можно остаться без привычного инструмента. Но настоящая опасность кроется глубже — в инфраструктурном слое: операционных системах, системах управления базами данных. На этом уровне промедление может нанести еще более критичный урон.

Штрафы как новая реальность

В ноябре 2025 года глава Минцифры Максут Шадаев на форуме CNews озвучил то, чего рынок давно ожидал. Министерство готовит законопроект об оборотных штрафах для компаний, которые не переведут значимые объекты критической информационной инфраструктуры (КИИ) на российское программное обеспечение.

Ключевые параметры новой политики:

• Дедлайн — 1 января 2028 года для перехода на отечественное ПО на значимых объектах КИИ
• Санкции — ежегодные оборотные штрафы за несоблюдение сроков, размер обсуждается
• Охват — штрафы предусмотрены как за сам факт отказа от перехода, так и за отсутствие классификации объектов КИИ

Министр прямо сказал: компании могут остаться на зарубежном софте, но тогда придётся ежегодно платить оборотный штраф.

Предусмотрены механизмы отсрочки. Если до 1 сентября 2026 года компания заключит контракт на внедрение с датой завершения после 1 января 2028 года, срок перехода автоматически сдвигается — и даётся ещё 48 месяцев на завершение. Если компания инициирует особо значимый проект по разработке недостающего отечественного решения и заключит соглашение с правительством, горизонт может быть сдвинут, но не позднее 1 декабря 2030 года. Это исключения, требующие обоснования и согласования.

Почему потеря контроля над инфраструктурным ПО опаснее, чем кажется

С прикладным софтом ситуация относительно прозрачная. Переход с привычной CRM или офисного пакета болезненный, но локализованный. Инфраструктурное ПО — это совсем другой порядок сложности. Это фундамент, на котором стоит всё остальное: операционная система, СУБД, в которой хранятся данные всех бизнес-приложений, промежуточное ПО (от англ. Middleware), обеспечивающее интеграцию между системами.

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

Каскадный эффект. Сбой на уровне инфраструктуры останавливает не одно приложение, а все системы, которые от него зависят. Падение СУБД означает остановку биллинга, CRM, ERP, складского учёта — всего, что работает с данными. Это не инцидент уровня одного отдела: это остановка бизнеса.

Цена ошибки при миграции. Миграция прикладного ПО и миграция инфраструктурного — задачи принципиально разного масштаба и стоимости. Смена CRM — это, по своей природе, тоже миграция данных, нередко чрезвычайно сложная: зависимости, кастомизированная бизнес-логика, интеграции. Но миграция СУБД — это другой порядок: если что-то пошло не так при переносе базы данных, «откат» — это не нажатие кнопки. В лучшем случае это полное восстановление из резервной копии с потерей всех изменений за период миграции. В худшем — частичная потеря данных и недели работы по восстановлению целостности. Откат в таких проектах — всегда огромная операция, и на него идут крайне редко: обычно это признание катастрофы. Именно поэтому планирование сценария «что делать, если что-то пойдёт не так» — обязательная часть любого серьёзного проекта миграции инфраструктуры.

Зависимость от вендора в критических ситуациях. Когда что-то идёт не так на уровне инфраструктуры, нужна поддержка производителя. А в случае с западными вендорами — её больше нет. Нераскрытая уязвимость, проблема производительности под нагрузкой, нештатное поведение при обновлении окружения — всё это придётся разбирать без официальной поддержки и актуальных патчей.

Как уйти с СУБД Oracle

Среди всех задач импортозамещения инфраструктурного ПО миграция с Oracle Database занимает особое место — и дело не только в том, что это одна из самых распространённых корпоративных СУБД. Проблема в глубине интеграции.

Oracle десятилетиями была стандартом для крупных корпоративных систем. Банки, телеком, промышленность, ритейл — везде, где требовалась надёжная работа с большими объёмами данных и высокими нагрузками. За это время накопился огромный массив бизнес-логики, реализованной непосредственно внутри СУБД.

Vendor lock на уровне кода. PL/SQL — процедурный язык Oracle — стал для многих компаний основным инструментом реализации бизнес-логики. Хранимые процедуры, триггеры, пакеты — тысячи и десятки тысяч строк кода, которые нельзя просто «скопировать» в другую СУБД. Специфические конструкции Oracle не имеют прямых аналогов в PostgreSQL: автономные транзакции, AQ-очереди, flashback-запросы, специфические варианты партиционирования — каждая такая особенность требует отдельной проработки при миграции.

Перенос данных — не самое простое. Типы данных Oracle и PostgreSQL различаются: VARCHAR2 против VARCHAR, разное поведение пустых строк и NULL, специфические типы для работы с большими объектами (LOB). Миграция данных из активно работающей системы — отдельный вызов: нужно либо останавливать бизнес-процессы на время переноса, либо организовывать сложную схему с репликацией изменений, чтобы не потерять данные, накопившиеся за время миграции.

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

Текущая ситуация на рынке

По оценкам АРПП «Отечественный софт», к концу 2025 года на отечественный софт перешли 40–45% субъектов КИИ. То есть больше половины компаний всё ещё работают на зарубежных решениях, включая СУБД. В банковском секторе уровень импортозамещения выше — 50–60% по СУБД. В госкомпаниях картина хуже — лишь 30–40%, несмотря на изначально более жёсткие требования. Первоначальный дедлайн — 1 января 2025 года — был продлен.

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

• Отсутствие поддержки и обновлений от западных вендоров создаёт нарастающие технические риски. Уязвимости не закрываются, совместимость с новым оборудованием не гарантируется.
• Оборотные штрафы — это уже не абстрактная угроза, а конкретный законопроект в разработке. Даже если сроки сдвинутся, регулятор явно намерен заставить бизнес двигаться.
• Российские СУБД за последние годы серьёзно повзрослели. По оценкам рынка, отечественные решения закрывают 65–75% ключевых потребностей крупных заказчиков.

Системная интеграция как ключ к успеху

Миграция СУБД — это не типовой IT-проект. Здесь нет готовых шаблонов и универсальных решений. Каждый случай уникален: разная архитектура приложений, разный объём бизнес-логики в базе, разные требования к производительности и доступности.

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

Типичные ошибки при самостоятельной миграции:

• Недооценка объёма работ. Кажется, что нужно просто «перенести данные». На деле основная работа — адаптация бизнес-логики и оптимизация производительности — начинается после переноса и занимает бОльшую часть проекта.
• Попытка перенести «как есть». Архитектурные решения, оптимальные для Oracle, могут быть неэффективны или вовсе невозможны в PostgreSQL. Иногда разумнее переосмыслить архитектуру, чем воспроизводить старую структуру один в один.
• Игнорирование тестирования. Функциональное тестирование после миграции обязательно. Нужно убедиться, что приложения работают корректно, а результаты расчётов совпадают с эталонными. Нагрузочное тестирование — тоже, и это часто выявляет проблемы, которых не ждали.
• Отсутствие продуманного плана на случай нештатного развития событий. Параллельная работа старой и новой СУБД, механизмы обратной синхронизации, чёткие критерии переключения — всё это нужно проработать заранее. Понимание «что мы делаем, если на шаге N что-то пошло не так» должно существовать до старта, а не возникать в процессе миграции.

Для успешной миграции инфраструктурного ПО нужен комплексный подход. Это не замена одного компонента, а перестройка системы с сохранением её функциональности и производительности.

Компания «айФлекс» более 20 лет занимается системной интеграцией и разработкой, накопив значительный опыт работы с крупными корпоративными заказчиками в телекоме, банковском секторе, ТЭК и других отраслях. Глубокое понимание архитектуры сложных систем, умение работать с унаследованным кодом и интегрировать разнородные компоненты — именно те компетенции, которые критически важны при миграции инфраструктурного ПО.

Как работают профессионалы

Подход «айФлекс» к системной интеграции строится на нескольких принципах:

• Глубокое погружение в процессы клиента — прежде чем предлагать решения, команда детально изучает существующую архитектуру и бизнес-требования
• Комплексный аудит — выявление «узких мест» и потенциальных рисков до начала активной фазы проекта
• Поэтапная миграция — минимизация рисков за счёт последовательного переноса компонентов с возможностью контроля на каждом этапе
• Полный цикл работ — от проектирования до внедрения и поддержки, без передачи ответственности между разными подрядчиками

Двадцатилетний опыт разработки сложных IT-решений означает, что команда знает не только «как должно работать», но и «что может пойти не так». Это критически важно в проектах миграции.

Что нужно делать уже сейчас

Даже если ваша компания пока не подпадает под требования по КИИ или рассчитывает на отсрочки, откладывать подготовку к миграции рискованно. Время работает против тех, кто медлит.

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

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

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