Базовый срок перехода значимых объектов КИИ на российское ПО это 1 января 2028 года. Отсрочки до 2031 и 2036 годов существуют, но касаются не всех и требуют выполненных условий.
Отсрочка на восемь лет не означает восемь лет спокойствия. Она означает, что часть компаний получит право переносить сроки, а вторая часть узнает об этом уже после проверки, когда переносить будет нечего.
Разрыв между новостным заголовком и содержанием документа здесь особенно велик. Публикации про перенос на 2036 год расходятся широко, условия получения этой отсрочки не расходятся никак. Разберём по датам: какой срок базовый, кому положены исключения, что делать с системами, для которых российского аналога нет, и с чего начинать инвентаризацию, если в ней ещё никто не разбирался.
Базовый срок: 1 января 2028 года, к этой дате доля российского ПО на значимых объектах КИИ должна составить 100%. Срок содержится в проекте постановления и окончательно не утверждён, что само по себе важно для планирования: опираться на него нужно, считать высеченным в камне нельзя.
Федеральный закон 58-ФЗ от 7 апреля 2025 года дал Правительству право устанавливать типовые отраслевые объекты КИИ, отраслевые особенности категорирования, а также порядок и сроки перехода на российское ПО и программно-аппаратные комплексы. Отсюда и появилась отраслевая логика в последующих документах.
В мае 2026 года Минцифры предложило два смягчающих сценария. Первый: срок до 1 января 2031 года для организаций, заключивших контракт на разработку российского ПО до 1 сентября 2027 года. Второй: срок до 1 января 2036 года для субъектов КИИ, привлечённых в 2026–2027 годах к реализации особо значимых проектов, перечень которых определяет Правительство.
Общая логика читается так: государство переносит сроки для тех, кто уже начал двигаться, и не переносит для тех, кто ждёт. Контракт на разработку это как раз доказательство движения.
Требования распространяются на субъектов КИИ и, в части сроков перехода, на значимые объекты КИИ. Это не синоним «любой компании с серверами».
Практическая проблема в другом: многие организации не проводили категорирование или проводили его формально несколько лет назад. За это время в контуре появились новые системы, часть процессов переехала в облако, где-то изменился состав интеграций. Формально объект может оказаться значимым, а в документах компании об этом ни строки.
С этого и стоит начинать. Актуальное категорирование даёт ответ на вопрос, сколько у вас времени: до 2028 года, до 2031-го при наличии контракта, или требования не касаются вас вовсе. Без этого ответа любой план миграции строится наугад.
Отдельный класс ситуаций: система работает, замены на рынке нет, а срок идёт.
Вариантов здесь три, и все три встречаются в реальных проектах. Первый: дождаться появления промышленного аналога и мигрировать на него. Риск в том, что зрелость продукта проверяется только в эксплуатации, и первым внедрившим достаётся роль испытателя. Второй: заказать собственную разработку под конкретный процесс. Дороже на старте, но именно этот вариант даёт контракт, на который опирается отсрочка. Третий: разложить систему на части и заменять их по очереди, начиная с интеграционного слоя.
Универсального ответа нет, и любой, кто называет его не глядя на ваш контур, продаёт шаблон. Выбор зависит от того, насколько система связана с остальными, есть ли на неё документация и сколько людей умеют с ней работать.
Замена работающей системы редко выглядит как одномоментный переезд. Обычно это параллельная разработка внутреннего решения, которое постепенно забирает функции.
В проекте Fortech (fortech.dev), аккредитованной IT-компании из Ростова-на-Дону, для заказчика из нефтегазовой отрасли команда делала систему мониторинга бурения с аналитикой и отчётностью. Цели работ были сформулированы прямо: замена текущего устаревшего решения, переход на импортонезависимый стек и разработка внутреннего продукта, покрывающего потребности пользователей. Система работает с метриками и отчётами по бурению в реальном времени. Состав команды: fullstack-разработчик, backend-разработчик, архитектор ПО, два QA-инженера, scrum-мастер и аналитик, проект занял четыре месяца.
Задачи внутри выглядели совсем не так, как их представляют на уровне презентаций про импортозамещение: интерфейс формирования отчётов, фильтрация и пагинация на стороне бэкенда, группировка данных на фронтенде, переработка механики построения дерева объектов и поиска по нему, запуск генерации отчётов через планировщик. Именно из таких задач состоит переход на отечественный стек, а не из выбора вендора на совещании.
Когда речь идёт о замене работающей системы, техническая поддержка проектов старого решения обычно нужна параллельно с разработкой нового: выключить легаси в день запуска замены не получается почти никогда. Это двойная нагрузка на бюджет, и закладывать её нужно сразу, а не обнаруживать в середине года.
Порядок действий, который работает независимо от отрасли.
Срок 2028 года выглядит далёким ровно до момента, когда выясняется, что миграция одной системы занимает год, а систем в контуре двадцать. Отсрочки работают только для тех, у кого к нужной дате есть подписанный контракт.
Начните с инвентаризации и категорирования, это две недели работы и единственный способ понять, в каком вы сценарии из трёх. Всё остальное планируется после.
Базовый срок это 1 января 2028 года, к нему доля отечественного ПО на значимых объектах КИИ должна составить 100%. Срок содержится в проекте постановления и окончательно не утверждён, поэтому планировать по нему нужно, а считать окончательным пока нельзя.
По предложению Минцифры от мая 2026 года, до 1 января 2031 года могут переходить организации, заключившие контракт на разработку российского ПО до 1 сентября 2027 года. Срок до 1 января 2036 года предусмотрен для субъектов КИИ, привлечённых в 2026–2027 годах к особо значимым проектам по перечню Правительства.
Есть три рабочих сценария: дождаться промышленного аналога и мигрировать, заказать собственную разработку под конкретный процесс, либо разложить систему на части и заменять их по очереди. Второй вариант дополнительно даёт контракт, на котором строится отсрочка до 2031 года.
С актуального категорирования объектов и реестра систем с указанием происхождения ПО. Без этих двух документов невозможно определить, какой срок относится к вашей организации, и любой план миграции строится наугад. Инвентаризация занимает около двух недель.
