Импортозамещение VMware: куда и как переезжать в 2026 году

Неприятная правда: импортозамещение VMware — это полная пересборка всей операционной модели ИТ-инфраструктуры. В процессе предстоит решить ряд вопросов: как управлять хостами и ВМ, как строить сеть и хранение, на чём делать резервное копирование, как подтверждать соответствие регулятору и кто в итоге будет поддерживать систему 24/7.

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

• часть инфраструктуры переводить на zVirt;
• часть — на SpaceVM. 

Причина простая — в компании без предварительного тестирования закупили SpaceVM, которая не подошла под специфические задачи компании. 

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

В статье разбираем, какие платформы стоит рассматривать, на что обращать внимание и как спланировать переезд.

Что происходит на рынке

Доля российских разработчиков на рынке ПО виртуализации достигла 60,2%, но больше трети рынка виртуальных серверов — 39% — до сих пор работает на VMware. 

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

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

В реестре российского ПО более 90 решений по виртуализации, но реально жизнеспособных — не более 15. Для крупной компании список быстро сужается до нескольких платформ. Универсального лидера на все сценарии не существует, выбор определяется конкретной задачей — классический кластер, частное облако, сертифицированный контур, HCI или VDI.

На какие платформы смотреть

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

Basis Dynamix Enterprise стоит рассматривать для проектов, где нужен большой enterprise-стек, а не просто замена гипервизора: в банках, крупном госсекторе, телекоме. Система подходит для распределённых инфраструктур, сложного хранения и связки «виртуализация + VDI + SDN + управление облаком». 

Это крупнейший по выручке игрок в сегменте. Он последовательно усиливает зрелые enterprise-сценарии — глубокую интеграцию с СХД, развитие SDN, автоматическую балансировку нагрузки и поддержку современных протоколов работы с хранилищами.

zVirt остаётся одним из самых понятных путей для тех, кто долго жил на vSphere и хочет перейти без переворота эксплуатационной логики. Вендор позиционирует продукт как защищённую систему виртуализации в базовой, расширенной и сертифицированной ФСТЭК редакциях. 

В релизе 5.0:

• новая гипервизорная платформа zVirt Node 2.0
• живая миграция между ЦОД без общего хранилища
• управление задачами ВМ по расписанию
• аппаратная репликация NetApp
• L3/L4-балансировка
• BGP
• анонс редакции zVirt SDS для HCI до 64 хостов 

Заявление вендора о покрытии 95% возможностей VMware — гипотеза для каждой конкретной компании. Проверять нужно на своём контуре, сетях, образах ВМ и бэкапах.

SpaceVM разумно использовать, когда виртуализация — часть экосистемы приватного облака, VDI и сетевых сервисов. Space делает ставку на собственную разработку: в 2026 году вендор продвигал SpaceVM 7 с проприетарной сетевой подсистемой SDN Flow, встроенной в продукт без отдельной лицензии — по заявлению вендора, первая и единственная такая реализация на российском рынке. Это заявление нужно подтверждать на пилоте и в нагрузочных тестах. 

VMmanager закрывает сценарии отказоустойчивой среды виртуализации, VXLAN, управления адресным пространством и базы для VDI. Продукт получил сертификацию ФСТЭК, GPU-виртуализацию, многокаталожный LDAP и развивает enterprise-функции. В ряде случаевв — недооценённый и прагматичный вариант.

РЕД Виртуализация — важный продукт для компаний, которым нужен сертифицированный контур. В июне 2026 года сосуществуют стандартная редакция 8.0 и сертифицированная 7.3 для ГИС, значимых объектов КИИ и ИСПДн — проверять нужно конкретную редакцию, которая пойдёт в контур. 

Из плюсов — прямой импорт виртуальных машин из ESXi в 7.3.3: вендор заявляет рост скорости миграции в 3,5 раза и возможность переносить объёмные ВМ от 1 ТБ без внешнего хранилища. В roadmap на 2026 год — SDN, шаблоны вычислительных хостов и NVMe over FC/TCP/RDMA.

vStack HCP имеет смысл рассматривать, когда нужна гиперконвергентная система для производительных кластеров, геораспределённых площадок и облачного потребления ресурсов. У вендора ставка на производительность и собственный стек.

Это — наиболее универсальные платформы. Также есть решения, которые стоит рассматривать строго под конкретную задачу:

• Numa vServer — когда важна безопасность. Платформа соответствует требованиям ФСТЭК по 4 классу защиты и 4 уровню доверия, вендор называет её единственным сертифицированным гипервизором в реестре ФСТЭК.
• Кибер Инфраструктура — когда нужен HCI-стек с виртуализацией, сетью, хранилищем и встроенным резервным копированием, включая перенос ВМ из VMware и Hyper-V.
• Альт Виртуализация 11.0 — когда уместен прагматичный open-stack-подход и важна связка с платформой «Альт»: быстрый деплой, SDN, обновление через веб-интерфейс и упрощённая миграция из VMware.

Как выбрать сценарий под свой контур

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

• Классическая серверная виртуализация для core-сервисов — ERP, интеграционный слой, инфраструктурные сервисы, приложения с обычным жизненным циклом. Здесь стоит начинать с Basis и zVirt, а для регулируемых сред сразу проверять РЕД Виртуализацию. Важно тестировать функции на стенде, идентичном продуктивному: насколько стабильно работает HA, как ведёт себя живая миграция, насколько зрел DR, как платформа взаимодействует с СХД, как переживает обновления.
• Частное облако как внутренний сервис, когда ИТ-служба становится сервис-провайдером для внутренних команд. Логика выбора меняется: критичны квоты, каталог сервисов, интеграция с внешними каталогами и IAM. Здесь особенно интересны Basis в связке с облачным управлением, SpaceVM и VMmanager.
• Сертифицированный или доверенный контур требует понимания, какая именно редакция сертифицирована, на какой функциональной ветке она находится, насколько отстаёт от коммерческой ветки и какие функции реально доступны в контуре. Пример: у РЕД стандартная редакция 8.0, а сертифицированная — 7.3; у zVirt отдельная сертифицированная ветка zVirt Max; у VMmanager — отдельная ФСТЭК-редакция.
• И, наконец, смешанный сценарий, который на практике часто оказывается самым жизнеспособным: одна платформа — для строго регулируемого и чувствительного контура, вторая — для менее критичных сервисов, VDI или внутренних облачных сервисов. Такая архитектура рождается из здравого смысла: она гармонизирует разные требования по сертификации, разные команды эксплуатации, разные сроки миграции м разный жизненный цикл площадок.

Пошаговый план выбора и перехода

За последние два года наша команде выполняла очень разные задачи: от срочной миграции 10 физических серверов и десятков ВМ за 23 дня до многоплощадочных переходов, где перенос идёт волнами и требует разных платформ под разные контуры. На основе накопленного опыта составили дорожную карту.

1. Зафиксировать исходное состояние. Потребуется полный инвентарь: ВМ, роли, RPO/RTO, зависимости, сетевые схемы, бэкап, версии гостевых ОС, драйверы, агенты, интеграции с AD/LDAP, реальные пики нагрузки, требования ИБ и сертификации.
2. Разделить нагрузки на классы. Минимум четыре корзины: инфраструктурные сервисы, бизнес-критичные стандартные нагрузки, регулируемые/чувствительные контуры, отдельные спецсценарии (VDI, GPU, филиалы). Это почти всегда снимает соблазн «переехать всем сразу в один большой кластер».
3. Выбрать целевую архитектуру и платформу. Важно решить ключевое: одна платформа или две; классический кластер или HCI; нужен ли отдельный VDI-контур; где проходит граница между КИИ и не-КИИ; как строится DR; кто отвечает за железо, СХД, обновления и поддержку 24/7.
4. Провести тестовые испытания на своих сервисах. Испытать нужно всё, на конкретном железе, на протяжении минимум трёх недель. В том числе тестируем: 
   - импорт из VMware
   - сетевые сценарии
   - HA
   - DR
   - восстановление из резервной копии
   - интеграция с каталогами
   - поведение больших ВМ
   - обслуживание узла без остановки сервиса
   - обновление платформы
   - для отдельных контуров — GPU, сертифицированные настройки и работу в изоляции.
5. Собрать посадочную площадку. Нужны не только хосты и лицензии, но и мониторинг, бэкап, репозитории обновлений, регламенты эксплуатации, роли и доступы, шаблоны ВМ, регламент эскалаций, план откатки и понятный порядок внесения изменений. На этом этапе обычно выясняется, что у проекта будет новый стандарт эксплуатации.
6. Мигрировать постепенно. Сначала простые, затем типовые сервисы, затем критичные. Внутри каждого этапа — чёткие окна, критерии отката, подтверждение работоспособности приложением и сопутствующими сервисами.
7. Провести стабилизацию и только потом выводить VMware из контура. Старая среда остаётся подстраховкой, пока восстановление не отрепетировано, DR не проверен, а новая платформа не прошла несколько нормальных эксплуатационных циклов и не доказала, что выдерживает обновление, дефицит ресурсов и стандартные аварии.

Шесть ошибок импортозамещения виртуализации

1. Выбирать платформу по рейтингу. Рейтинги полезны для первого знакомства с рынком. Но когда в реестре больше 90 решений, а жизнеспособных — около 10, рейтинг становится только входом в обсуждение, а не готовым ответом. Кроме того, рейтинги строятся по различным критериям, и важно учитывать именно те, которые реально важны для вашей задачи. Решение принимается после тестирования на собственных нагрузках.

2. Искать «новый VMware». Желание перенести старую картину мира на новый софт понятно, но даже сами вендоры говорят лишь о покрытии ключевых сценариев. Проект, который начинается с требования «сделайте нам vSphere, только российский», почти гарантированно закончится разочарованием.

3. Мигрировать ВМ без сценариев эксплуатации. На многих проектах команда переносит виртуальные машины, а потом выясняется, что сеть, хранилище, бэкапы, роли, интеграции и DR остались в старой логике. Новая платформа требует новых регламентов.

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

5. Игнорировать требования регуляторов. Для значимых объектов КИИ переход к 100% доверенным ПАК должен завершиться до 1 января 2030 года. Строить миграцию без ИБ и юридического сопровождения — заранее готовить себе вторую волну переделок.

6. Переносить чужой опыт на свою инфраструктуру. Импортозамещение — это учет работы всей ИТ-инфраструктуры. То, что идеально сработало у другой компании из вашей отрасли, может не взлететь у вас из-за разницы в версиях гостевых ОС или требованиях к RPO/RTO.

Главный вывод

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

Не стоит искать новый VMware. Стоит искать архитектуру, надёжные решения и команду, которые переживут период 2026–2030. Выигрывают те, кто раньше перевёл разговор из плоскости иллюзий в плоскость управляемой дорожной карты.

Если вы хотите доверить экспертам весь процесс импортозамещения — от аудита инфраструктуры, выбора платформы и тестирования до ввода в эксплуатацию и администрирования — заполните форму. Мы свяжемся с вами.