Миграция с зарубежного ПО на российский стек для большинства компаний и ведомств позади. Серверы переехали, базы данных работают на отечественных СУБД, офисный пакет сменился, домен и почта – на российских решениях. Акт приёмки подписан. Но именно здесь начинается работа, которую часто откладывают: проект переезжал в спешке, под давлением сроков и регуляторных требований, и архитектура несёт на себе следы этой спешки. Совокупная стоимость владения (TCO) после миграции почти всегда выше, чем должна быть. Разберём, где именно и что с этим делать.

Где прячется лишний TCO после переезда

Первый источник – избыточная инфраструктура. Чтобы гарантированно уложиться в окно миграции, команды закладывали запас по ресурсам: брали виртуальные машины с двукратным резервом CPU и памяти, дублировали узлы «на всякий случай», оставляли старые системы в горячем резерве на месяцы. Когда пыль осела, этот запас продолжает потреблять лицензии, электроэнергию и место в стойке. Аудит реальной утилизации за квартал обычно высвобождает 20–35% мощностей.

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

Третий – лицензии, купленные по принципу «как было раньше». Российские вендоры считают подписку иначе, чем западные: по ядрам, по пользователям, по узлам кластера. Лицензионная модель, скопированная с прежнего поставщика, почти всегда переплачена.

Безопасность и данные: считать вместе, а не отдельно

Оптимизировать инфраструктуру в отрыве от ИБ – ошибка. С 1 марта 2026 года требования приказа ФСТЭК № 117 к защите информации в ГИС и на значимых объектах КИИ обязательны, и любое сокращение узлов или переразметка сетей должны проходить через модель угроз. Сэкономленные на «лишних» серверах деньги легко потерять на внеплановой аттестации, если менять контур бездумно.

Отдельная статья расходов – данные. После миграции аналитика часто остаётся на временных выгрузках и ручных отчётах. Перенос BI внутрь рабочих систем по принципу встроенной аналитики убирает дублирующие витрины и лишний ETL-слой. Там же стоит пересмотреть, какие ML- и LLM-сценарии действительно нужны в продакшене: внедрение GigaChat Enterprise в контуре имеет смысл там, где оно заменяет ручной труд, а не добавляет ещё один сервис в реестр расходов.

С чего начать оптимизацию

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

Главное правило – менять по одному параметру за раз и фиксировать метрики до и после. Тогда экономия будет доказуемой, а не оценочной.

Оптимизация TCO – не разовая акция, а постоянная дисциплина: инфраструктура, ИБ и данные считаются в одной модели. Выстроить этот процесс позволяет миграция и сопровождение инфраструктуры с аудитом после переезда и целевой архитектурой с прозрачной стоимостью владения.