Импортозамещение ПО: как заменить ушедшие системы без остановки бизнеса

Одинаковой обязанности для всех нет, и это первое, что стоит развести.

Юридическая рамка проще, чем кажется, если убрать из неё панику.

Указ №166 от 30 марта 2022 года. Госзаказчикам и владельцам значимых объектов КИИ запрещено закупать иностранное ПО без согласования, а с 1 января 2025 года использование иностранного ПО на значимых объектах КИИ запрещено.

Указ №250. Зарубежные средства защиты информации в критической информационной инфраструктуре применять нельзя.

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

Категорирование. Ответ на вопрос «касается ли это вас» даёт не отрасль, а перечень объектов КИИ и присвоенные категории значимости. Устаревшее категорирование — частая причина, по которой компания либо тратит лишнее, либо неожиданно оказывается нарушителем.

Что делать в 2026 году владельцам объектов КИИ: провести ревизию объектов и уточнить категорирование, собрать полный состав иностранного ПО и средств защиты, проверить наличие российских аналогов и подготовить согласованный план перехода. Без этого следующий шаг — сама миграция — превращается в неуправляемый проект, а до конца переходных сроков остаётся всё меньше времени.

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

Инвентаризация — скучный этап, который определяет стоимость всей программы. В список входит не только софт.

• Системы и версии: что стоит, какой редакции, где именно, кто владелец.
• Поддержка и обновления: есть ли патчи безопасности, до какого срока, кто их устанавливает.
• Данные: какие персональные и коммерческие данные обрабатывает система, где они хранятся.
• Интеграции: с чем система обменивается данными и в какую сторону. Это самая недооценённая часть списка.
• Кастомизация: какие доработки сделаны сверху, кем и зачем; какие из них реально используются.
• Люди: сколько сотрудников работает в системе и насколько их процессы к ней привязаны.
• Лицензии и договоры: что оплачено, до какого срока, что произойдёт при неоплате.

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

Решение принимается не по системе целиком, а по каждому блоку функций.

Ситуация по классам софта разная: где-то выбор из нескольких зрелых продуктов, где-то замены нет вообще. Ориентир по основным категориям:

Соблазн — начать с простого, чтобы показать прогресс. Правильнее — с рискованного. Приоритет считается по четырём признакам:

• 1. Нет обновлений безопасности. Система с известными уязвимостями и без патчей — первый кандидат независимо от удобства замены.
• 2. Критичные данные. Персональные данные, платежи, коммерческая тайна: чем чувствительнее, тем выше приоритет.
• 3. Цена простоя. Что произойдёт, если система встанет на день: остановится склад, отгрузки, производство или пострадает только отчётность.
• 4. Зависимость от вендора. Облачный сервис, который можно отключить дистанционно, опаснее локальной установки, которая продолжит работать.

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

Итог этого этапа — не список систем, а очередь с обоснованием. Она защищает бюджет и объясняет, почему в первый год меняется три системы, а не тридцать.

Это та часть программы, о которой не пишут вендоры, потому что продать здесь нечего. Аналог отсутствует в четырёх случаях.

Отраслевой софт. Узкие системы под конкретное производство, логистику или лабораторию: западный продукт был единственным, российского аналога нет, а процесс на нём держится.

Самописные интеграции и обвязка. Скрипты, обмены и надстройки, которые никто не документировал. Формально это не «система», но именно они склеивают контур, и при замене любого элемента переписывать придётся их — а это уже задача автоматизации процесса, а не переноса файлов.

Ушедший SaaS. Сервисы для маркетинга, поддержки, аналитики, управления проектами и дизайна. Часть заменяется российскими продуктами, часть — только своей разработкой, если процесс уникален.

Десктопные приложения. Западные клиентские программы, которые больше не обновляются. Здесь мы предлагаем не переписывать десктоп, а собирать PWA — веб-приложение, которое устанавливается на компьютер и работает офлайн; поддерживать его дешевле, а обновления доставляются мгновенно.

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

Отдельная категория — мобильные приложения, которые пропали из зарубежных сторов. Замена собирается на Flutter и выкладывается в RuStore; для внутренних приложений годится и распространение внутри компании.

Самая тяжёлая часть импортозамещения — учётное ядро. Порядок величин по практике интеграторов: замена SAP ECC и Oracle DB на 1С:ERP для промышленного предприятия на 2000 сотрудников — это примерно 80–120 млн ₽ и 18–24 месяца работы. Такие цифры полезно знать до того, как программа получит срок «до конца года».

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

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

Замена системы выглядит как установка нового продукта, а на деле это проект по данным.

Перенос данных. Что переносим: только остатки и открытые документы или всю историю. История тянет за собой качество данных прошлых лет, и это отдельный бюджет; часто разумнее оставить её в архивной копии старой системы с доступом на чтение.

Справочники. Номенклатура, контрагенты, подразделения в двух системах названы по-разному. Пока нет единого источника истины, обмен переносит расхождения.

Интеграции. Каждый обмен нужно переписать под новую систему: форматы, гарантии доставки, защита от повторов, окна выгрузок. Техника разобрана в материале про интеграционную шину, а организационный вывод такой: срок проекта задаёт готовность владельцев соседних систем.

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

Из нашей практики: у B2B-дистрибьютора обмен с хранилищем данных держит отклик меньше полусекунды на RabbitMQ и Go, а статусы всех обменов видны на мониторинге с алертами. В переходный период такой мониторинг — не роскошь: он показывает, какие данные разошлись между контурами, пока это ещё можно исправить.

Разработка в программе импортозамещения появляется в трёх ролях, и все три обычно недооценены в первой смете.

Замена тому, чего нет. Отраслевая система, ушедший SaaS, внутренний портал. Здесь пишется продукт, и это самостоятельный проект со своим объёмом.

Обвязка нового ядра. Модули поверх 1С, кабинеты для клиентов и партнёров, рабочие места сотрудников, мобильные приложения. Формально ядро уже стоит, но пользователи работают именно с этой обвязкой.

Переходный слой. Обмен между старым и новым контуром на время миграции: синхронизация справочников, дублирование операций, сверка расхождений. Живёт от нескольких месяцев до года, но без него параллельная работа невозможна. Все три роли можно заранее прикинуть по деньгам — в бесплатном калькуляторе оценки.

Ориентиры по нашим работам: модули и личные кабинеты поверх 1С начинаются от 3 млн ₽ (ERP под ключ мы не делаем), заказная разработка продукта под процесс — от 1,7 млн ₽, отдельная интеграция — от 150 тыс. до 1,5 млн ₽, аудит кода и архитектуры — от 200 до 600 тыс. ₽. Вашу цифру можно назвать только после инвентаризации: оценка проекта бесплатная — опишите задачу.

• 1. Инвентаризация и категорирование. Полный список систем, интеграций, данных и лицензий. В крупной компании занимает от трёх до шести месяцев — и это нормально.
• 2. Оценка риска и очередь. Приоритет по уязвимостям, данным, цене простоя и зависимости от вендора.
• 3. Решение по каждому блоку. Аналог, open source, разработка или изоляция; здесь же выбирается стек для нового контура.
• 4. План перехода. Что и в каком порядке, кто владелец каждого шага, как работают два контура параллельно, каковы критерии готовности.
• 5. Пилот на одной системе. Отработка переноса данных, обменов, обучения и приёмки на объекте, который не остановит бизнес.
• 6. Тиражирование. Остальные системы по очереди, с накопленными шаблонами переноса и интеграций.
• 7. Вывод старого контура. Архивная копия с доступом на чтение, отключение лицензий, закрытие доступов.

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

Начинать с закупки. Аналог выбран до инвентаризации, а потом выясняется, что он не закрывает половину процессов и не умеет обмениваться с оставшимся контуром.

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

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

Переключаться «большим взрывом». Одномоментный переход всей компании в выходные заканчивается откатом; параллельная работа контуров дороже, но она работает.

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

Оставить программу без владельца. Без руководителя с полномочиями каждая система найдёт причину остаться иностранной ещё на год.

Смешивать замену с улучшением процессов. Переделка процессов под видом миграции размывает объём и делает сроки недостижимыми.

Три шага, которые не требуют подрядчика. Первое — собрать список систем с ответом по каждой: есть ли обновления безопасности, какие данные внутри, что произойдёт при остановке, можно ли её отключить дистанционно. Второе — уточнить, попадаете ли вы под требования: перечень объектов КИИ, категории значимости, роль в госзакупках. Третье — отметить системы, для которых аналога нет: это будущая разработка, и планировать её нужно с самым большим запасом.

С этим списком дальше решается, что покупать, что разворачивать в своём контуре, что писать и что осознанно изолировать до появления замены.