Импортозамещение ПО в 2026: что мигрировать первым и как не сорвать бизнес

Содержание

• Почему «мигрировать всё и сразу» — провальная стратегия
• Карта рисков: что давит на бизнес прямо сейчас
• Приоритизация: что мигрировать первым
• Базы данных: Oracle/MS SQL → PostgreSQL
• Зарубежные SaaS: самое незаметное и самое опасное
• Как мигрировать без простоя: паттерн strangler
• Реестр Минцифры, 152-ФЗ и госзаказчики
• Чек-лист импортозамещения
• FAQ

Почему «мигрировать всё и сразу» — провальная стратегия

Импортозамещение ПО в 2026-м перестало быть темой презентаций и стало операционной задачей с дедлайнами. Но самая частая ошибка, которую мы видим, когда к нам приходят на аудит — попытка заместить весь стек одним проектом «под ключ за полгода». Это почти всегда заканчивается сорванными сроками, потому что мигрируют по принципу «что на слуху», а не «что реально создаёт риск».

Правильный подход обратный: сначала закрыть то, что уже горит (отвалившиеся обновления, недоступные платежи, санкционные блокировки), потом — то, что создаёт vendor lock-in, и только в конце — то, что «иностранное, но работает и никому не мешает». Ниже — как расставить приоритеты по данным, а не по панике.

Карта рисков

То, что обсуждают в ИТ-сообществах и с чем приходят клиенты, складывается в несколько типов боли — и они очень разные по срочности:

• Отвалившийся доступ и обновления. Обновления Windows для части пользователей в РФ стали платными и попросту недоступными к покупке. Зарубежные облака и лицензии отключаются без предупреждения. Это прямой риск безопасности — система без патчей.
• Платежи и подписки. Оплата иностранных SaaS превратилась в квест с картами третьих стран. Любая критичная подписка, завязанная на зарубежный биллинг, — это бомба замедленного действия.
• Санкционная недоступность. Вендор может уйти с рынка в любой момент, забрав с собой поддержку, а иногда и работоспособность облачного продукта.
• Регуляторное давление. Для госсектора и КИИ это уже не выбор: реестр отечественного ПО, требования к суверенным датасетам, 152-ФЗ по персональным данным.

Конкретики хватает: Microsoft ограничивает скачивание образов и обновлений Windows для российских IP, драйверы Intel недоступны без смены IP, зарубежные AI-сервисы отказывают со ссылкой на санкции. А весной 2026-го добавился парадокс: ужесточение блокировок VPN ударило рикошетом по самому импортозамещению — часть ИТ-компаний была вынуждена ставить проекты на паузу, потому что инструменты разработки и репозитории внезапно оказались за «забором». Урок простой: чем больше внешних зависимостей в контуре, тем выше шанс, что завтра что-то отвалится не по вашей вине.

Ключевой вывод: срочность определяется не «иностранностью», а тем, что сломается завтра. Сначала — доступ и платежи, потом — lock-in, в конце — комфортная замена.

Приоритизация: что мигрировать первым

Мы используем матрицу «риск отключения × стоимость переключения»:

P0 — это то, где «выключат — встанет бизнес», а переключиться относительно дёшево. Именно туда идут первые ресурсы.

Базы данных

Миграция СУБД — самая трудозатратная, но и самая стратегическая часть. Стандартный маршрут: Oracle / MS SQL → PostgreSQL (часто в варианте отечественной сборки из реестра — Postgres Pro и аналоги).

Что обычно недооценивают:

• Не сама схема, а логика в БД. Хранимые процедуры на PL/SQL, триггеры, специфичные типы и функции Oracle — это 70% трудозатрат. Перенос таблиц автоматизируется, перенос бизнес-логики — нет.
• Запросы приложения. Диалекты SQL различаются: иерархические запросы, аналитические функции, работа с датами. Нужен аудит всех запросов приложения, а не только дампа БД.
• Производительность после переезда. PostgreSQL ведёт себя иначе по планам запросов — без переиндексации и тюнинга легко получить деградацию. Нагрузочное тестирование обязательно.

Реалистичный срок миграции средней корпоративной БД с логикой — 4–8 месяцев при поэтапном подходе. Мы ведём такие проекты в рамках заказной разработки ПО: переписываем процедуры на стороне приложения (Java/Kotlin), а не тащим их в новую СУБД, — так система становится переносимой и на будущее.

Зарубежные SaaS

Самый коварный класс. Облачный CRM, система аналитики, сервис рассылок, биллинг — они незаметны, пока работают, и роняют процессы, когда отключаются. При этом данные клиентов часто лежат на зарубежных серверах, что отдельно конфликтует с 152-ФЗ.

Варианты замещения:

1. Отечественный аналог — быстро, но не всегда покрывает кастомные процессы.
2. Self-hosted open-source — контроль и данные у вас, но нужна команда на внедрение и поддержку.
3. Своя разработка — когда процессы уникальны и SaaS их не закрывает; здесь уместна заказная разработка на Java/Kotlin под ваш контур.

Принцип тот же, что и при выборе между локальными и облачными LLM: чем чувствительнее данные и критичнее процесс, тем сильнее аргумент за закрытый контур под вашим контролем.

Как мигрировать без простоя

Главный страх бизнеса — «всё встанет на время миграции». Поэтому мы не делаем big-bang замену, а используем паттерн strangler fig: новая система выращивается рядом со старой и постепенно перехватывает функции.

// Фасад маршрутизирует трафик между legacy и новой системой
@Service
class MigrationFacade(
    private val legacy: LegacyClient,
    private val modern: ModernService,
    private val flags: FeatureFlags,
) {
    fun handle(req: Request): Response =
        // по фиче-флагу переключаем модули по одному, без остановки
        if (flags.isMigrated(req.module)) modern.handle(req)
        else legacy.handle(req)
}

Этапы:

1. Адаптеры и двусторонняя синхронизация. Старая и новая системы работают параллельно, данные синхронизируются.
2. Перенос по модулям за фиче-флагами. Каждый модуль переключается отдельно; что-то пошло не так — мгновенный откат флагом.
3. Постепенное «удушение» legacy. Когда весь трафик ушёл на новую систему, старую гасят.

Бизнес не замечает миграции — пользователи продолжают работать. Это сложнее в реализации, чем «переписать с нуля», но именно так мигрируют системы, которые нельзя останавливать.

Реестр Минцифры

Для коммерческого сектора реестр отечественного ПО — рекомендация. Для госсектора, компаний с госучастием и объектов КИИ — обязанность: закупка ПО из реестра, а для ряда контуров — обучение и работа ИИ-систем на суверенных датасетах. Правила госзакупок (44-ФЗ, 223-ФЗ) в 2026-м перекраиваются именно под гарантированный спрос на отечественные решения.

Что это значит на практике:

• Если вы поставщик для госзаказчика — ваш продукт, скорее всего, должен быть в реестре. Это влияет на архитектуру (лицензирование, состав компонентов) с самого начала.
• Если вы заказчик из госсектора — выбор сужается регулятором, и закладывать импортозамещение нужно в техзадание, а не «потом».

Мы учитываем требования реестра и 152-ФЗ на этапе проектирования — переделывать готовую систему под регуляторику дороже, чем заложить её сразу.

Чек-лист импортозамещения

1. Инвентаризация. Полный список зарубежного ПО, SaaS, лицензий, облаков — с пометкой «что сломается, если отключат завтра».
2. Приоритизация по риску × стоимости. Сначала P0 (высокий риск отключения, дешёвая замена), потом lock-in, в конце — комфорт.
3. Данные и 152-ФЗ. Где лежат персональные данные? Что требует переноса в РФ-контур?
4. СУБД — отдельный трек. Аудит хранимых процедур и запросов приложения, а не только дампа.
5. Strangler вместо big-bang. Поэтапный перенос за фиче-флагами с возможностью отката.
6. Нагрузочное тестирование после каждого этапа — особенно для БД.
7. Реестр и регуляторика — закладывать в архитектуру с первого дня, если рядом госсектор.

Импортозамещение — это backend-проект полного цикла: миграция данных, переписывание логики, интеграции, инфраструктура. Если нужна команда, которая проведёт его поэтапно и без остановки бизнеса — это наша заказная разработка ПО на Java/Kotlin под ключ.

FAQ

С чего начать импортозамещение, чтобы не сорвать сроки?

С инвентаризации и приоритизации по риску отключения, а не по «иностранности». Первыми мигрируют зарубежные SaaS и подписки с высоким риском отключения и дешёвой заменой (P0). СУБД и инфраструктура — планово (P1). Десктопный софт — без спешки (P2).

Сколько занимает миграция с Oracle на PostgreSQL?

Для средней корпоративной БД с хранимой логикой — 4–8 месяцев при поэтапном подходе. Основная трудоёмкость не в переносе таблиц, а в переписывании процедур, триггеров и запросов приложения. Обязательно нагрузочное тестирование после переезда — планы запросов в PostgreSQL отличаются.

Можно ли мигрировать без остановки бизнеса?

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

Обязательно ли отечественное ПО должно быть в реестре Минцифры?

Для коммерческого сектора — нет, это рекомендация и налоговые льготы. Для госсектора, компаний с госучастием и объектов КИИ — да, закупка из реестра обязательна, а для ряда контуров требуется обучение ИИ на суверенных датасетах. Если вы работаете с госзаказом, закладывайте это в ТЗ заранее.

Что делать с зарубежным SaaS, у которого нет полного аналога?

Три пути: отечественный аналог (быстро, но не всегда покрывает кастом), self-hosted open-source (контроль данных, нужна поддержка) или своя разработка (когда процессы уникальны). Выбор — по чувствительности данных и критичности процесса.