Срок до 1 января 2028: что реально успеть

Дедлайн миграции сдвинут, объём работ не уменьшился.

Что произошло

Срок обязательного перехода значимых объектов критической информационной инфраструктуры на отечественные решения установлен на 1 января 2028 года. Для части рынка это прозвучало как отсрочка: первоначальные ориентиры были более ранними, и компании, не успевавшие к ним, получили дополнительное время. Реакция многих была предсказуемой: проекты, которые планировалось начать, отложены на год, бюджеты перераспределены, а тема миграции ушла из повестки правления в повестку ИТ-департамента.

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

По нашему опыту миграций, типовая длительность перехода учётной системы или СУБД в крупной компании — от 12 до 18 месяцев, если считать честно: с инвентаризацией, проектированием, переносом логики, параллельной эксплуатацией и переобучением людей. Это означает, что окно для старта закрывается не 1 января 2028 года, а на год с лишним раньше, и оно сужается. Отсчёт от дедлайна назад показывает, что сейчас не запас времени, а его последние резервы.

Как устроена миграция: откуда берутся 12–18 месяцев

Инвентаризация: то, чего никто не знает

Первый и самый недооценённый этап. Компания, которая эксплуатировала систему десять лет, не знает, что в ней есть. Доработки делались разными подрядчиками, интеграции строились под конкретные задачи, отчёты создавались пользователями, хранимые процедуры писались под текущую СУБД и опираются на её особенности. Всё это существует, но не описано.

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

Перенос логики, а не данных

Главное заблуждение при миграции СУБД — что это перенос данных. Данные переносятся инструментами за дни. Переносится логика: хранимые процедуры, триггеры, представления, специфичные типы и функции, особенности транзакционного поведения, планы выполнения запросов. Логика, написанная под одну СУБД, не работает в другой без переписывания, а переписывание требует не только знания обеих систем, но и понимания того, что именно эта логика делает для бизнеса.

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

Параллельная эксплуатация и переобучение

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

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

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

Календарь обратного отсчёта

Если сложить этапы и отсчитать от 1 января 2028 года назад, получается следующая картина.

Этап	Длительность по нашему опыту	Крайний срок начала для завершения к дедлайну
Инвентаризация и решение о целевом стеке	Недели, при готовой команде	Первая половина 2026 года
Проектирование, пилот, нагрузочные испытания	Кварталы	Вторая половина 2026 года
Перенос логики и данных, интеграции	Кварталы	Конец 2026 — начало 2027 года
Параллельная эксплуатация	Не менее одного отчётного цикла	Не позднее середины 2027 года
Переобучение, отключение старой системы, резерв на инциденты	Кварталы	Вторая половина 2027 года

Календарь показывает: старт в 2027 году оставляет менее года на весь цикл. Это возможно только при отказе от параллельной эксплуатации или переобучения, то есть при переносе рисков на промышленную эксплуатацию. Для значимого объекта КИИ такой перенос неприемлем.

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

Конкуренция за одних и тех же людей

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

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

Как это выглядит на практике

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

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

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

Что это значит для российской компании

Регуляторика. Требования к значимым объектам КИИ по 187-ФЗ и связанным актам не ограничиваются заменой ПО: они затрагивают средства защиты, аппаратные комплексы, процессы категорирования. Миграция — часть более широкой программы соответствия, и планировать её нужно вместе с ней, а не отдельно.

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

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

Отечественный стек. Целевой стек на открытом ядре — PostgreSQL, Kubernetes, Kafka с российским слоем поддержки — даёт заменяемость подрядчика и доступность специалистов на рынке. Закрытые продукты из реестра могут быть обязательны для отдельных компонентов, но ядро архитектуры стоит строить так, чтобы следующая миграция не повторила эту.

Что делать: пошагово

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

Типичные ошибки

Отложить старт, потому что срок перенесли. Почему: объём работ не изменился, а конкуренция за людей в 2027 году сделает старт дороже и медленнее. Что вместо: использовать перенос как запас на параллельную эксплуатацию, а не как отсрочку начала.
Пропустить инвентаризацию. Почему: объём доработок и логики в СУБД неизвестен до её проведения, и договор без неё — договор с неизвестной стоимостью. Что вместо: инвентаризация до выбора подрядчика, её результат — основание для сметы.
Считать миграцию СУБД переносом данных. Почему: данные переносятся за дни, логика переписывается месяцами. Что вместо: оценка объёма логики как основа плана.
Сжать параллельную эксплуатацию. Почему: расхождения обнаружатся после отключения старой системы, когда сверять будет не с чем. Что вместо: полный отчётный цикл параллельной работы как неснижаемое требование.
Договор без фиксации команды. Почему: подрядчик перебросит опытных людей на новый проект, а вам достанутся те, кто учится на вашей системе. Что вместо: поимённый состав, порядок замены, ответственность.
Единственный носитель знаний. Почему: его уход в середине проекта останавливает миграцию. Что вместо: дублирование ролей, документирование по ходу, внутренний специалист рядом с внешним.

Как понять, что вы на верном пути

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

Вопросы, которые нам задают

Если начать в начале 2027 года, разве нельзя успеть за год?

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

Что делать, если инвентаризация показала объём, который не укладывается в срок?

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

Можно ли переложить риск сроков на подрядчика?

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

Стоит ли начинать с самой критичной системы или с самой простой?

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