Исход с VMware в 2025: миграция без простоя 🔁

1. Введение: почему «исход» с VMware стал фактом

Ещё недавно казалось, что VMware — это навсегда. Компания десятилетиями была синонимом виртуализации, устанавливая стандарты для дата-центров по всему миру. А потом начался 2024 год, за ним 2025-й, и всё изменилось. Сотни клиентов начали уходить, доказывая, что в бизнесе нет ничего вечного. И для бизнеса сегодня вопрос звучит уже не «нужно ли мигрировать?», а «как именно и куда?».

Broadcom + VMware: эффект слияния

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

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

Европейский рынок под давлением

В Европе ситуация обострилась до предела. Отмена vSphere Essentials, продукта, который был невероятно популярен у малого и среднего бизнеса, фактически оставила тысячи компаний без доступа к привычной экосистеме VMware. Его место заняли куда более дорогие тарифы, ориентированные на крупных клиентов.

Broadcom даже не скрывает, что теперь они работают только с крупными клиентами. Это ставит небольшой бизнес в безвыходное положение: либо платить «как большие» корпорации, либо срочно искать замену. Неудивительно, что после такого поворота событий резко вырос интерес к OpenStack, KVM, Proxmox и, конечно, к облачным провайдерам.

Регуляторы тоже в деле

Такой агрессивный подход Broadcom не остался незамеченным. В ЕС уже идут антимонопольные расследования, которые должны выяснить, не нарушает ли компания правила конкуренции. Но бизнесу нет смысла ждать, пока бюрократы разберутся. Инфраструктура нужна здесь и сейчас, а не через год или два, когда решение будет принято.

2. Европейский контекст: на что смотреть в первую очередь

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

Законы и правила: куда же без них?

Европейский бизнес не может просто так взять и игнорировать законодательство. Уже есть GDPR, который жёстко регулирует работу с данными. Эти новые правила, как NIS2, Data Act и DORA, добавляют бизнесу головной боли.

Data Act диктует, как должны работать совместимость и обмен данными между разными платформами. А DORA ориентирован на финансовый сектор, где миграция с VMware — это не просто апгрейд, а условие для соблюдения закона.

Дефицит VMware-инженеров и рост open-source

К тому же, есть ещё и проблема с кадрами. К тому же, есть ещё и проблема с кадрами. В Европе уже ощущается острый дефицит сертифицированных VMware-инженеров. Часть из них ушла в консалтинг, а кто-то решил осваивать Kubernetes и другие облачные технологии.

Из-за этого рынок труда меняется, и теперь нужны специалисты по open-source решениям вроде OpenStack, KVM и Proxmox. И хотя рынок ещё не насыщен такими кадрами, здесь есть явный плюс: молодые специалисты охотнее их изучают, так как эти навыки пригодятся не только в дата-центрах, но и в больших облачных сервисах.

Доступность сервисов и сертификаций

И не забывайте, что соответствие стандартам — это ещё один ключевой критерий. Европейские провайдеры на OpenStack активно предлагают клиентам свои услуги с сертификатами ISO 27001 (информационная безопасность) и ISO 27701 (управление конфиденциальностью).

К тому же, скоро появится EUCS (Европейская схема сертификации кибербезопасности), который станет единым стандартом для всех облачных сервисов в ЕС. Это значит, что, выбирая платформу, стоит смотреть не только на «железо» и гипервизор, но и на наличие этих сертификатов у провайдера. По сути, они становятся пропуском на рынок для компаний из финансовой, медицинской и государственной сферы.

Суверенность данных: скрытый драйвер

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

Из-за этого многие компании больше не могут работать с такими гигантами, как AWS или Azure, если те не обеспечивают нужный уровень локализации и прозрачности. По сути, бизнесу приходится искать новые пути. Это подталкивает их к локальным облачным провайдерам на OpenStack или к использованию гибридных моделей, где часть данных остаётся в собственном дата-центре, а часть — у проверенного партнёра в ЕС.

3. Подготовка к миграции: то, о чём часто забывают

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

Инвентаризация: видеть больше, чем «виртуалки»

Первая ошибка — ограничиваться списком виртуальных машин. Да, список VM с CPU, RAM и дисками нужен. Но на VMware-стеке обычно работает гораздо больше «невидимых» сервисов:

сетевые политики (vDS, NSX), без которых мигрированные VM внезапно оказываются в изоляции;
vSAN или другие SDS-решения, где данные не привязаны к конкретному диску, а распределены по кластерам;
vRealize-автоматизации и оркестраторы, которые управляют созданием и удалением VM;
кастомные шаблоны, снапшоты и скрипты, которые жили «под капотом» годами.

Инвентаризация должна охватывать все уровни: compute, storage, network, automation. Иначе на новом стеке бизнес рискует потерять часть автоматизаций или, что хуже, нарушить критичные процессы.

Лицензированные приложения и compliance

Вторая зона риска — коммерческие приложения, такие как Oracle Database или SAP. Их лицензии зачастую завязаны на конкретный гипервизор, ядра CPU или даже конкретные модели серверов.

Например, перенос Oracle с VMware на KVM может потребовать пересмотра лицензий и пересчёта метрик «per core». А в случае SAP придётся согласовывать поддержку платформы у вендора. Плюс есть вопросы compliance: в финансовых и фармацевтических компаниях миграция без официального подтверждения от вендора может привести к штрафам и проблемам на аудитах.

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

Hidden dependency: то, что всегда забывают

Ещё одна ловушка — это «невидимые» агенты и интеграции. Классические примеры:

агенты резервного копирования (Veeam, Commvault), которые завязаны на VMware API;
системы мониторинга, собирающие метрики через vCenter;
CI/CD-пайплайны, где деплой «в прод» автоматизирован именно под VMware.

Все эти интеграции нужно выявить и заранее проверить: есть ли у новых платформ аналогичные API и SDK, как перенастроить пайплайны, какие агенты обновить. Иначе после миграции инфраструктура может оказаться «голой» — без мониторинга и бэкапов.

Оптимизация перед миграцией

Миграция — отличный повод навести порядок. В среднем в корпоративных средах 20–30% VM оказываются «зомби»: их никто не использует, но они всё ещё крутятся и потребляют ресурсы.

Перед миграцией стоит провести rightsizing: пересчитать реальные потребности приложений и уменьшить «жирные» VM, которые исторически раздулись. Это позволит снизить нагрузку на новую платформу и ускорить сам процесс миграции. Переезд «как есть» — почти всегда дороже и дольше.

Практический инструмент: CMDB и IaC

Наконец, главный вопрос — как снизить количество «ручных» операций. Здесь помогают два подхода:

CMDB (Configuration Management Database): актуальная база конфигураций позволяет понять, какие сервисы от чего зависят, и не забыть ни один критичный компонент.
Infrastructure as Code (IaC): хранение описаний инфраструктуры в виде кода (Terraform, Ansible, Helm charts) превращает миграцию из «копипаста VM» в воспроизводимый процесс. Если IaC уже есть — супер, если нет — миграция отличный повод начать.

4. Сценарии миграции: от lift-and-shift до полной перестройки

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

Lift-and-shift: быстро, но не всегда умно

Классический сценарий — lift-and-shift. Суть проста: виртуальные машины «как есть» переносятся в OpenStack или KVM, меняется только гипервизор.

Плюсы:

быстрое время миграции,
минимальные изменения в архитектуре,
пользователи часто даже не замечают «переезда».

Минусы:

сохраняются все «старые грехи»: избыточные ресурсы, устаревшие образы, неочевидные зависимости;
лицензированные приложения могут работать некорректно без сертифицированной поддержки;
сетевые и storage-политики нужно фактически строить заново.

Короче говоря, «lift-and-shift» — это способ быстро сбежать от VMware, но не лучшее решение на перспективу.

А вот для малого и среднего бизнеса и филиалов всё изменил Proxmox. Это относительно простой в управлении гипервизор, который без проблем работает на обычном «железе» и даёт хороший функционал.

Но важно понимать ограничения:

Proxmox слабее в масштабируемости по сравнению с OpenStack,
ограниченные возможности интеграции с enterprise-инструментами,
меньше доступных сертификаций и вендорской поддержки.

Поэтому Proxmox — отличное решение для локальных площадок, пилотов или edge-узлов, но для корпоративного уровня и особенно в высокорегулируемых отраслях он часто используется как «ступенька», а не как конечная цель.

Контейнеризация на лету: KubeVirt и Harvester

Для тех, кто уже перешёл на контейнеры, существует очень умный способ работать с ВМ. Технологии вроде KubeVirt или Harvester позволяют запускать виртуальные машины прямо внутри кластера Kubernetes, что даёт возможность «упаковать» ВМ в контейнер.

Что это даёт:

единая платформа для VM и контейнеров,
возможность постепенно «распаковывать» монолиты в микросервисы,
гибкая автоматизация через Kubernetes API.

Минусы тоже есть:

высокая сложность настройки,
повышенные требования к квалификации команды,
не все приложения хорошо себя ведут в таком окружении.

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

Экспертный момент: унификация через cloud-init и Ansible

Независимо от выбранного сценария, миграция почти всегда — шанс навести порядок в конфигурациях. Здесь на помощь приходят инструменты вроде cloud-init и Ansible.

Например, после переноса VM можно автоматизированно:

прописать сетевые настройки,
добавить пользователей и ключи,
настроить агенты мониторинга и бэкапа.

Единая Ansible-роль или playbook позволяет гарантировать, что инфраструктура после миграции будет выглядеть одинаково, а не как набор «сюрпризов» от каждого администратора.

Двухоблачный период: временный, но затратный

Практически в каждом проекте миграции есть «двухоблачный» период, когда часть нагрузок остаётся на VMware, а часть уже работает на OpenStack или в другом облаке.

Это самый рискованный этап, потому что:

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

5. Инструменты миграции: что реально работает в Европе

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

Open-source инструменты: дешево, гибко, но с оговорками

Для компаний, которые хотят минимизировать затраты на миграцию, есть набор проверенных open-source решений:

Virt-v2v — инструмент для конвертации виртуальных машин с VMware в KVM/OpenStack. Помимо работы с дисками, он умеет переносить параметры виртуальной машины и подстраивать конфигурацию. Ограничение: не все драйверы и агенты «переживают» процесс без ручной доработки.
Qemu-img — настоящая классика — утилита, которая позволяет конвертировать диски из одного формата в другой (например, из VMDK → RAW или qcow2). По сути, главное в виртуальной машине — это её диск, а значит, достаточно перегнать его в нужный формат и создать новую VM с этим образом. Метод простой, но требует ручных настроек окружения.
Cloudbase-qemu-tools — полезен при миграции Windows-гостевых систем, так как автоматически устанавливает VirtIO-драйверы и оптимизирует работу сети/дисков.
Velero (бывший Heptio Ark) — инструмент для бэкапа и восстановления Kubernetes-кластеров, но его можно использовать в связке, если часть приложений уже контейнеризирована.
Heptio (ныне часть VMware Tanzu) всё ещё применяется для отдельных сценариев, но чаще — в проектах, где гибрид Kubernetes + VM.
StarWind V2V Converter — хотя это не чистый open-source, а бесплатный проприетарный инструмент, его часто ставят в один ряд с OSS-решениями из-за простоты и удобства. Позволяет в пару кликов конвертировать образы между форматами (VMDK, VHDX, QCOW2 и др.), и особенно популярен для «быстрых» миграций.

Главное достоинство open-source решений — доступность и прозрачность. Но минус очевиден: они требуют высокой квалификации команды и больше ручной работы.

Коммерческие решения: «коробка» за деньги

На рынке Европы популярны и коммерческие инструменты миграции:

Zerto — один из лидеров в DR и миграциях. Позволяет делать «почти безостановочный» перенос VM за счёт репликации на уровне гипервизора.
PlateSpin (Micro Focus) — старый, но всё ещё используемый продукт для «массовых» миграций серверов, включая физику → виртуалку и обратно.
Carbonite Migrate — ориентирован на минимизацию простоя, работает с разными ОС и гипервизорами.

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

Hyperscaler-решения: хорошо, но не всегда легально

Крупные облака предлагают свои сервисы миграции:

AWS Application Migration Service,
Azure Migrate,
Google Migrate for Compute Engine.

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

Локальные облачные провайдеры

Европа активно развивает собственные облака, и многие из них уже предлагают нативные сценарии миграции с VMware:

OVHcloud (Франция) — один из лидеров OpenStack-провайдеров, поддерживает инструменты миграции на уровне сервисов.
IONOS Cloud (Германия) — делает ставку на compliance и сертификации, включая ISO и BSI C5.
Scaleway (Франция) — популярен у стартапов и SMB за счёт простоты и прозрачных цен.
Deutsche Telekom Open Telekom Cloud — крупный игрок, работает на базе Huawei OpenStack, сертифицирован под строгие немецкие стандарты.

Для компаний, которым важно остаться в ЕС-юрисдикции и соответствовать требованиям Gaia-X, SecNumCloud или NIS2, именно эти провайдеры становятся приоритетным выбором.

Неочевидное: сетевые миграции

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

Разница между overlay и underlay-сетями может приводить к непредсказуемым задержкам.
Проблемы с MTU (особенно если новый стек использует VXLAN/GENEVE) могут вызвать «странные» отказы приложений.
Multicast не всегда поддерживается в облачных провайдерах или требует особых настроек.

Чтобы избежать сюрпризов, важно заранее протестировать сетевые сегменты: прогнать пакеты, проверить MTU, убедиться, что multicast и broadcast-трафик работает так же, как в VMware-среде.

6. Минимизация простоя: подходы и архитектуры

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

Live-migration и репликация

Самый очевидный вариант — live-migration. Здесь данные синхронизируются в реальном времени, а переключение выполняется почти без простоя.

Zerto делает это через двунаправленную репликацию VM: пока сервис крутится в VMware, его копия уже синхронизируется в OpenStack или другом облаке.
В open-source мире похожую роль играет DRBD Proxy, который реплицирует блочные устройства между кластерами.

Минус — стоимость (в случае Zerto) и сложность настройки. Но для банковских и e-commerce систем такой подход практически незаменим.

Dual-write и временные шлюзы

Для баз данных и потоковых систем часто применяют dual-write или временные шлюзы синхронизации.

PostgreSQL умеет работать через logical replication, когда данные пишутся одновременно в старую и новую базу.
Kafka можно «размножить» с помощью mirror-механизмов, синхронизируя топики между кластерами.

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

Canary и staged-cutover

Опыт показывает: переносить всё «за ночь» — почти всегда плохая идея. Ошибка на одном сервисе может парализовать весь процесс.

Намного надёжнее работать по бизнес-сервисам, а не по кластерам. Такой staged-подход напоминает canary-развёртывания в DevOps: сначала уводим часть пользователей или транзакций в новую среду, проверяем стабильность, потом расширяем.

Infrastructure as code — ускоритель

Чтобы ускорить повторное развёртывание VM и сервисов в новой среде, помогает Infrastructure as Code. Например:

Terraform + OpenStack provider позволяют описать профили VM, сети и хранилища как код.
Это превращает создание новых окружений из «ручной магии» в быстрый и воспроизводимый процесс.

Благодаря IaC можно параллельно вести миграцию и тестировать «чистые» окружения, снижая риски неожиданностей.

7. Экономика и TCO: что важно учитывать в 2025–2026

При обсуждении миграции с VMware почти всегда звучит аргумент «будет дешевле». Но цифры не всегда очевидны. Чтобы понять реальную экономику, важно считать TCO (total cost of ownership) на горизонте 3–5 лет.

VMware vs. OpenStack/Proxmox

После изменений Broadcom подписки VMware выросли на десятки процентов, особенно для SMB и mid-market. За три года лицензии + поддержка VMware обходятся дороже, чем миграция на OpenStack или Proxmox с поддержкой локального интегратора.

OpenStack даёт лучшие перспективы масштабирования, но требует команды. Proxmox дешевле и проще, но подходит в основном для филиалов и малого бизнеса.

Hidden cost

Open-source — не «бесплатно». Компании платят временем и зарплатами: обучение персонала, сертификация инженеров, поддержка сообщества или подписка на enterprise-дистрибутив (Red Hat OpenStack, Canonical). Эти расходы стоит учитывать, иначе TCO может неожиданно вырасти.

Экономия на масштабе

Миграция — шанс обновить «железо». Новые процессоры AMD EPYC и появляющиеся в 2025 году технологии CXL (Compute Express Link) позволяют консолидировать нагрузку и эффективнее делить память/PCIe-ресурсы. Это снижает CapEx и делает open-source стек конкурентным даже с hyperscaler-облаками.

Европейские программы поддержки

В 2025–2026 годах в Европе действуют EU Innovation Fund, Horizon Europe и локальные налоговые льготы для «зелёных» дата-центров. Компании, которые при миграции вкладываются в энергоэффективность и локальные облака, могут компенсировать до 20–30% расходов через гранты и кредиты.

8. Кейсы из Европы: практические примеры

Чтобы не оставаться в теории, посмотрим, как европейские компании реально уходят с VMware и что выбирают взамен.

Немецкий банк: OpenStack ради compliance

Один из крупных банков в Германии в 2024–2025 годах начал миграцию с VMware на OpenStack. Причина — новые требования NIS2 и DORA, которые ужесточают правила для финансовых организаций.

Банк выбрал OpenStack-дистрибутив с коммерческой поддержкой, чтобы гарантировать долгосрочную стабильность и доступность сертификаций. Дополнительно внедрили IaC (Terraform) и Ansible, чтобы инфраструктура проходила аудиты быстрее. Итог — не только снижение зависимости от VMware, но и улучшение прозрачности процессов для регуляторов.

Франция: гос-сектор и SecNumCloud

Во Франции госсектор пошёл ещё дальше: несколько ведомств отказались от VMware в пользу провайдера, сертифицированного по SecNumCloud. Здесь ключевым драйвером стала суверенность данных — критично, чтобы персональные и государственные данные обрабатывались в пределах Франции и под французской юрисдикцией.

В результате часть систем была перенесена на локальный OpenStack-провайдер, часть осталась в частных дата-центрах. Такой гибрид позволил выполнить все требования ANSSI (национального регулятора по безопасности) и при этом сохранить гибкость в масштабировании.

SMB в Бенилюксе: Proxmox + IONOS Cloud

Средний бизнес в Бенилюксе часто выбирает более лёгкий сценарий. Пример — сеть медицинских лабораторий, которая перевела филиальные офисы на Proxmox, а для аварийного восстановления использовала IONOS Cloud в Германии.

Такой подход позволил сэкономить на лицензиях и одновременно соответствовать GDPR: данные остаются в ЕС, DR-сценарии сертифицированы по ISO 27001. Для SMB это оказалось золотой серединой — без vendor lock-in и без переплаты за hyperscaler.

9. Заключение: стратегия «жизни после VMware»

VMware никуда не исчезнет завтра — продукты останутся, крупные клиенты будут пользоваться ими ещё годы. Но доверие подорвано: изменения Broadcom в лицензировании и поддержке показали, насколько рискованно опираться только на одного вендора.

Европейский рынок уже отвечает на этот вызов. Всё больше компаний переходят на open-source стек — OpenStack, KVM, Proxmox — и выбирают локальных облачных провайдеров, соответствующих требованиям GDPR, NIS2, DORA или SecNumCloud. Это не просто «экономия», а стратегический шаг к суверенности и гибкости.

Что делать сегодня? Готовить roadmap миграции на горизонте 12–24 месяцев. Даже если вы не планируете немедленный переезд, нужно понимать: какие сервисы завязаны на VMware, какие альтернативы реальны, где риски и сколько это будет стоить.

Лучший первый шаг — тестовые песочницы. Разверните OpenStack или Proxmox, попробуйте миграцию пары сервисов, сравните TCO и SLA разных провайдеров. Параллельно стройте multi-cloud-архитектуру, где ключевое — не «сидеть на одном вендоре», а иметь свободу выбора.

Жизнь после VMware есть. И чем раньше вы начнёте её планировать, тем меньше будете зависеть от чужих решений завтра.