Миграция с VMware на российские решения: гид для бизнеса

Согласно аналитическим данным iKS-Consulting, в 2018 году платформа VMware занимала доминирующее положение, будучи установленной у 78,8% российских компаний, внедряющих виртуализацию. Однако, по информации аналогичного исследования, проведенного весной 2025 года, ситуация изменилась: доля отечественных программных решений для виртуализации составила 60,2%, в то время как доля VMware снизилась примерно до 39%. Эти данные основаны на анализе предложений 19 крупнейших российских облачных провайдеров. Хотя решения VMware по-прежнему присутствуют на рынке, их былое доминирование уступило место новым тенденциям.

За прошедшие годы VMware в России сместилась с позиции «платформы по умолчанию» для виртуализации до одной из многих значимых, но уже не лидирующих опций. Рынок демонстрирует стремительное перераспределение долей в пользу российских аналогов. Основными причинами этого сдвига являются возросшая доступность технической поддержки и обновлений, улучшенная управляемость процессов и соответствие требованиям, предъявляемым к российским IT-инфраструктурам.

Почему VMWare теперь нельзя использовать как раньше

Четыре ключевые проблемы для российского рынка программного обеспечения

1. Усиление регуляторных требований: С начала 2025 года российское законодательство существенно ограничивает использование иностранного ПО в критической информационной инфраструктуре (КИИ) и госсекторе. Вступление в силу новых требований ФСТЭК (Приказ №117) с марта 2026 года также накладывает дополнительные обязательства на государственные информационные системы (ГИС). Использование VMware становится прямым нарушением данных предписаний для организаций, обрабатывающих персональные данные, работающих в КИИ или относящихся к госсектору.
2. Ограничения доступа к официальным поставкам и поддержке: Легальный канал продаж и технической поддержки VMware в России фактически заморожен. Приобретение новых лицензий, продление существующих контрактов поддержки и получение гарантированных обновлений стали крайне затруднительными. После интеграции с Broadcom, политика подписки и привязки к контрактам и порталам стала более жесткой, превращая доступ к патчам и техподдержке в ограниченную опцию. Использование неофициальных каналов сопряжено с высокими юридическими рисками и вероятностью потери доступа к критически важным обновлениям или поддержке в экстренных ситуациях.
3. Рост угроз безопасности из-за уязвимостей: В 2024-2025 годах были зафиксированы критические уязвимости в таких компонентах VMware, как vCenter, VCF и ESXi, некоторые из которых уже активно использовались злоумышленниками. Компрометация vCenter или гипервизора предоставляет атакующим контроль над множеством виртуальных машин, позволяя остановить или зашифровать целую инфраструктуру. Задержки с установкой патчей, связанные с проблемами доступа к обновлениям, превращают единичные инциденты в системные риски.
4. Изоляция от облачных сервисов: Российские облачные провайдеры лишены возможности эффективно создавать и развивать свои сервисы на базе VMware. Это вынуждает их клиентов искать альтернативные платформы для миграции своих облачных инфраструктур.

Как выглядит полноценная замена VMware

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

Что входит в платформу:

• собственный гипервизор на базе KVM с глубокой кастомизацией под реальные индустриальные нагрузки
• проприетарный протокол удалённого рабочего стола — сравним с VMware Blast по результатам тестов
• встроенный NGFW (межсетевой экран нового поколения)
• геораспределённый центр управления и отказоустойчивость до N-1
• готовые интеграции: LDAP, RADIUS, SSO, системы мониторинга

Развёртывание занимает один рабочий день — от bare metal до рабочей платформы. Автоматизированный установщик, минимум ручных конфигураций.

С чего начать миграцию: практический порядок действий

Миграция с VMware — это не разовое событие, а управляемый процесс. Он не требует полной остановки инфраструктуры и может выполняться поэтапно:

• Аудит текущей инфраструктуры: инвентаризация виртуальных машин, зависимостей, версий ПО
• Выбор пилотного сегмента: некритичные рабочие нагрузки для первого этапа
• Развёртывание новой платформы параллельно с существующей
• Постепенный перенос виртуальных машин с тестированием на каждом шаге
• Перевод критичных систем после подтверждения стабильности
• Вывод VMware из эксплуатации

Ключевой принцип: новая платформа должна работать параллельно с VMware до момента полной миграции. Это обеспечивает возможность отката и снижает риски для бизнес-процессов.

На что обратить внимание при выборе платформы для миграции

• Собственный гипервизор или надстройка над чужим — это определяет долгосрочную независимость
• Наличие в реестре российского ПО и статус сертификации ФСТЭК
• Скорость развёртывания — от этого зависит время простоя при миграции
• Поддержка существующих интеграций: Active Directory, системы мониторинга, резервного копирования
• Поддержка вендора: как быстро реагируют на инциденты и выпускают обновления

Архитектурная специфика Inscale

Платформа Inscale разрабатывается с 2019 года — ещё до того, как уход западных вендоров стал массовой темой. По архитектуре Inscale заметно отличается от большинства российских решений:

Стандартный путь — взять связку KVM + Libvirt и собирать поверх неё VDI-функционал. Это быстрее в разработке, но накладывает ограничения: control level, проброс устройств, работа с памятью, High Availability — всё это унаследовано из Libvirt и не контролируется командой полностью.

Inscale пошёл другим путём. От KVM оставлено только ядро — как драйвер обращения к ядру Linux. Всё остальное — control level, проброс устройств, работа с памятью, High Availability, балансировка — написано на собственном коде. Это даёт полный контроль над поведением системы и возможность глубокой оптимизации, недоступной решениям на стандартной связке.

Как устроена миграция с VMware на Inscale

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

Типовой сценарий перехода:

1. Аудит текущей инфраструктуры — сколько виртуальных машин, какие профили нагрузки, какие требования по безопасности.
2. Развёртывание тестового контура от одной ноды — для пилота не нужна СХД, достаточно сервера с локальными дисками.
3. Перенос 10–15% нагрузки в тестовый контур, проверка совместимости и производительности.
4. Поэтапная миграция остальных виртуальных машин — без остановки бизнес-процессов.
5. Вывод VMware из эксплуатации, переподписание лицензионных обязательств.

Основные риски — несовместимость специфического ПО и падение производительности после переноса. Оба снимаются на этапе тестового контура.

Реальный кейс: миграция на 1500 рабочих мест

В одном из действующих проектов по замещению VMware VDI на 1500 рабочих мест полная настройка системы заняла полтора дня — большую часть времени занял монтаж Debian-based дистрибутива на серверы. Кластер вырос от одной ноды до 11 серверов с подключением к нескольким Gateway, Radius-серверу, LDAP-директории и SSO.

Полтора дня — это не маркетинговая цифра, а следствие архитектурных решений: горизонтальное масштабирование, отказ от тяжёлой реляционной БД (используется Event Sourcing), готовая интеграция с типовыми системами авторизации.

7 вопросов, которые нужно задать до миграции

1. Сколько у нас виртуальных машин и на каких гипервизорах они сейчас работают?
2. Какое ПО критично для бизнеса и как оно поведёт себя на новой платформе?
3. Какие у нас требования по безопасности — ФСТЭК, КИИ, сертификаты, изолированные сегменты?
4. Какой бюджет на проект — включая лицензии, работы, обучение и возможные простои?
5. Кто в команде отвечает за миграцию и хватает ли компетенций или нужна помощь интегратора?
6. Какой срок допустим для всего проекта и какие окна простоя мы можем позволить?
7. Что мы делаем с текущими контрактами VMware — продление, заморозка, выход?

Заключение

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

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

Хотите получить оценку миграции под вашу инфраструктуру — напишите нам. Посчитаем объём работ, сроки и стоимость проекта на основе количества ваших виртуальных машин и требований по безопасности.