Скільки насправді коштує VMware? Як розрахувати ТСО міграції

Майстер-клас: секрети випікання найсмачніших млинців!

24.07.2026

VMware роками була стандартом корпоративної віртуалізації — платформою, на якій працює серверна інфраструктура більшості середніх і великих компаній. Але в листопаді 2023 року її придбала корпорація Broadcom, і правила гри кардинально змінилися.
Новий власник переглянув модель ліцензування, зробивши ставку на флагманський пакет VMware Cloud Foundation (VCF) — повний стек для програмно-визначеного центру обробки даних, орієнтований на великих замовників. У результаті для більшості компаній рахунки зросли у 2–5 разів, а в окремих випадках — у понад 10. 

Показовий приклад — британська мережа супермаркетів, яка судиться з Broadcom на понад £100 млн і паралельно переносить близько 40 тисяч серверних навантажень на інші платформи.

Проте міграція з VMware коштує більше, ніж здається на перший погляд. Окрім ліцензій, є приховані витрати: заміна мережевого обладнання, перенавчання команди, місяці паралельної роботи двох середовищ і ризики, пов’язані з новою платформою. 

Ми не агітуємо за жодну з платформ й не закликаємо до переходу з VMware. Наша мета — надати чітке розуміння структури витрат для кожного сценарію.

Нові правила Broadcom: за що тепер платять клієнти VMware?

Щоб зрозуміти, чому рахунки зросли, варто розглянути 3 ключові зміни, які Broadcom запровадила майже одразу після угоди:
● Зникли безстрокові ліцензії — софт більше не можна купити раз і назавжди, лише підписку на 1–5 років.● Понад 160 окремих продуктів об'єднали в кілька пакетів — якщо раніше компанія купувала тільки потрібний їй vSphere, то зараз змушена платити за VMware Cloud Foundation разом із vSAN, NSX та іншими компонентами, якими може взагалі не користуватися.● Оплата тепер розраховується за кожне ядро процесора з мінімумом 16 ядер на CPU — і що сучасніші сервери, то вищий рахунок.
Що змінилося для бізнесу?
У 2025 році курс на укрупнення став остаточним. З виходом vSphere 9 гіпервізор (базовий програмний шар, на якому працюють віртуальні машини) перестали продавати окремо. Нові версії доступні лише в складі підписок VCF або полегшеного пакета vSphere Foundation (VVF), а продажі й продовження vSphere Standard та Enterprise Plus припинено. 
Для компаній, які використовували VMware лише як гіпервізор, це означає не просто збільшення вартості, а архітектурний перегляд серверів і мережі під логіку гіперконвергентної платформи. Наприкінці 2025-го Broadcom навіть зняла VVF з продажу в частині країн EMEA. Один із замовників визначив, що перехід на VCF обійшовся б йому в $1,3 млн на рік замість $130 тис.
Утім, повністю відмовитися від середнього сегмента вендор не наважився: у травні 2026 року разом із VCF 9.1 вийшла оновлена VVF 9.1. Для замовників, не готових до переходу на VCF, це єдиний шлях на vSphere 9 (це особливо актуально напередодні завершення підтримки vSphere 8 у жовтні 2027 року).
Найвідчутніше зміни вдарили по малому та середньому бізнесу — через мінімальні пороги ядер невеликі інсталяції здорожчали неспівмірно. За даними Європейської асоціації хмарних провайдерів CISPE, тарифи для її учасників зросли на 800–1500%.
Чому так відбувається?
Варто відзначити: перехід на підписки — не примха одного вендора, а відповідь індустрії на багаторічну практику економії з боку клієнтів. Безстрокова ліцензія дозволяла купити софт один раз і роками не платити ні за підтримку, ні за оновлення. 
Аналогічним шляхом уже пройшли виробники мережевого обладнання: сучасний комутатор чи фаєрвол без активної підписки втрачає значну частину функцій. Аналогія проста: автомобіль ви купили, але без пального він не поїде. 
Тож малому бізнесу не стільки підвищили ціни, скільки позбавили звичного способу економити — працювати без підтримки й оновлень. Для критичної інфраструктури така економія завжди була прихованим ризиком; тепер його конвертували в обов’язковий рахунок.
Посилюють тиск і часові обмеження: підтримка vSphere 7 завершилася у жовтні 2025 року, а восени 2026-го спливає термін перших трирічних підписок, укладених одразу після поглинання. Відкладати вибір далі немає сенсу — питання полягає лише у тому, чи буде майбутній крок фінансово обґрунтованим.

Як порахувати реальну вартість інфраструктури? Методика TCO

TCO (Total Cost of Ownership) — це сукупна вартість володіння: усі витрати на технологічне рішення протягом його життєвого циклу, а не лише ціна купівлі. Для інфраструктури оптимальний горизонт — 3–5 років: коротший не відображає накопичених операційних витрат, довший — створює невизначеність.
Коректний розрахунок містить 6 блоків витрат:

● ліцензії та підписки — гіпервізор, система управління, резервне копіювання, моніторинг;● обладнання — сервери, системи зберігання даних, амортизація наявного апаратного забезпечення;● мережа — комутатори, кабельна інфраструктура, резервування живлення;● операційні витрати — персонал, сервісна підтримка вендора, електроенергія, перенавчання команди;● міграція — одноразові витрати на перенесення навантажень, включно з паралельною роботою двох середовищ під час переходу;● ризики — можливі простої, несумісність конфігурацій, залежність від вендора.

Open Source не економить бюджет: справжня вартість «безкоштовних» ліцензій

Відкриті платформи на кшталт Proxmox VE чи KVM не вимагають плати за ліцензію і, на перший погляд, здаються однозначно дешевшими, ніж VMware. Проте в корпоративному сегменті повністю безкоштовного ПЗ не існує — змінюється лише стаття витрат.
Перше — технічна підтримка. Безкоштовна версія Proxmox не гарантує часу реакції на збої, що критично для бізнес-систем. Комерційна підписка коштує від €120 до €1100 на рік за кожен фізичний процесор, і її потрібно оформити на одному рівні для всіх серверів у кластері.

Друге — персонал. Перехід на відкриті платформи потребує перенавчання команди, а налаштування обладнання та інтеграцій часто покладається на власних інженерів, бо екосистема готових рішень тут менша, ніж у VMware.

Третє — безпека та зрілість. Proxmox побудований на Debian: без комерційної підписки немає гарантованих строків виправлення вразливостей, а корпоративні сертифікації та вбудовані механізми безпеки суттєво обмежені порівняно з VMware чи OpenShift. Для регульованих галузей це означає, що відповідність вимогам комплаєнсу потребуватиме додаткових засобів — а отже, додаткових витрат.

Зрештою, витрати не зникають, а лише перерозподіляються: з купівлі ліцензій — на технічну підтримку, інтеграцію та оплату праці. Це універсальне правило: у будь-якому продуктивному сценарії (від Proxmox до OpenShift) комерційна підтримка є не опцією, а обов’язковою статтею бюджету.

Куди мігрувати? Вибір платформи визначає домінуюча ОС

Вибір нової платформи має починатися з аналізу наявних навантажень. Саме домінуюча ОС визначає, яке рішення буде технічно й фінансово виправданим.
Windows-середовища оптимально переводити на Microsoft Hyper-V. Якщо компанія має ліцензії Windows Server Datacenter, гіпервізор уже входить до їхнього складу, а завдяки механізму автоматичної активації віртуальних машин (AVMA) гостьові Windows-системи отримують ліцензію від хоста без окремих ключів. 
За оцінками галузевих кейсів, така міграція скорочує витрати на ліцензування платформи на 30–50%, а звичні інструменти адміністрування спрощують перехід. Для організацій із домінуванням Microsoft логічним горизонтом стає Azure Local із сервісними угодами вендора, однак це рішення передбачає додаткові витрати (розглянемо далі).
Linux-навантаження та DevOps-середовища логічно переводити на KVM або Proxmox VE. Це той самий Linux-стек, з яким інженери вже працюють, тож команда не потребує глибокого перенавчання.
Для змішаних інфраструктур (Windows + Linux) підходять універсальні платформи на кшталт Nutanix AHV. Саме тут TCO варто прорахувати особливо ретельно, щоб зрозуміти, чи не вигідніше залишитися на VMware.
Контейнерні та ШІ-навантаження змінюють логіку вибору: якщо стратегія компанії — Kubernetes і власні ML-сервіси, кандидатом №1 стає Red Hat OpenShift. Але це вже не заміна гіпервізора, а зміна операційної моделі — з відповідними витратами на перенавчання.
Гіпервізор, який не відповідає домінуючому стеку, — це зниження продуктивності, ускладнене адміністрування та зайві витрати на ліцензії. А для користувачів екосистеми Windows є ще один стратегічний фактор: Microsoft поступово перетворює локальну інфраструктуру на частину своєї хмари.

Залежність від вендора: скільки коштує втрата контролю над інфраструктурою?

Для компаній на Windows Microsoft підготувала власне рішення — Azure Local (колишній Azure Stack HCI): фізичні сервери стають частиною глобальної розподіленої хмари. Усередині працює Hyper-V, але керування кластерами, віртуальними машинами та політиками безпеки здійснюється через хмарний портал Azure.
Оплата нараховується за кожне фізичне ядро за підпискою. Власники ліцензій Windows Server Datacenter можуть скасувати щомісячну плату за сервери, але пільга діє лише для базової гіперконвергентної конфігурації. Щойно компанія додає зовнішнє сховище даних (SAN), пільга втрачається і плата за ядра відновлюється.

Ціна такої екосистеми — поступова втрата автономності. Сервери стоять у вашій серверній, але платформа вимагає регулярного зв’язку з хмарою, а контрольна панель належить вендору. 

Той самий вектор простежується в архітектурі Windows Server 2025. Частина можливостей прив’язана до агента Azure Arc (наприклад, встановлення оновлень безпеки без перезавантаження доступне локальним серверам лише через Arc), а нова модель pay-as-you-go виставляє рахунки за локальний Windows Server через Azure. Кожен крок є зручним окремо, але разом вони переносять центр керування (і центр виставлення рахунків) у хмару Microsoft.

Якщо Broadcom обмежує вибір клієнтів пакетними пропозиціями, то Microsoft — глибиною інтеграції зі своїми сервісами. У результаті компанія втрачає свободу розвитку систем і переговорну позицію під час оновлення контрактів. У TCO-моделі цю залежність варто закладати окремою статтею — «вартість виходу». Це конкретна сума витрат через 3–5 років на нову міграцію, перенавчання та ліцензії.

Неочевидна економія: оновлення серверного парку замість «втечі» від ліцензій

Є спосіб скоротити витрати на ліцензування, який рідко розглядають першим, хоча він найпростіший: оновити самі сервери. Модель оплати за ядро робить утримання старого обладнання вкрай невигідним: застарілі процесори мають у рази меншу продуктивність на ядро, ніж сучасні. Консолідація навантажень на менше число нових серверів зменшує кількість ліцензованих ядер — часто у співвідношенні 3:1 або краще. 
Ефект каскадний, адже за ядра платять не лише Broadcom. За ядрами тарифікуються Windows Server і SQL Server (одна з найдорожчих ліцензій у корпоративному ІТ), частина систем резервного копіювання та контрактів підтримки. Додайте до цього нижчі витрати на електроенергію та обслуговування меншої кількості серверів. Сумарна економія здатна перекрити значну частину вартості нового обладнання протягом TCO-горизонту.

Швидкість як прихований бонус для користувачів

І це той рідкісний випадок, коли оптимізація витрат працює на користь бізнесу, а не всупереч йому. Нове обладнання дає змогу не лише скоротити кількість ліцензованих ядер, а й суттєво пришвидшити роботу. Сучасні процесори, швидша пам'ять і NVMe-накопичувачі скорочують час виконання операцій, на які користувачі скаржаться найчастіше.

Звіт, який створювали годину, формується за лічені хвилини; нічні розрахунки й резервне копіювання вкладаються у коротші технологічні вікна; облікові системи відповідають швидше — і це відчує кожен співробітник, який із ними працює. У TCO-моделі цей ефект прямо не монетизується, але для бізнесу він часто виявляється не менш цінним, ніж сама економія. Рідкісна інвестиція одночасно зменшує рахунки за ліцензії та підвищує продуктивність людей. 

Фактор DRAM та необхідність точної оцінки ресурсів

Щоправда, є обставина, яка робить планування закупівлі ще вимогливішим, ніж будь-коли: оперативна пам’ять. Через бум ШІ виробники перерозподілили потужності на пам’ять для прискорювачів, і ціни на серверну DRAM за рік зросли майже вдвічі. У типових конфігураціях віртуалізації саме пам’ять тепер становить левову частку вартості сервера. 

Це змінює підхід до закупівлі. Просто скопіювати специфікації старого парку «із запасом» — означає переплатити десятки відсотків бюджету за гігабайти, які не використовуються. Тому обов’язковою є частина асесменту — актуалізація реально необхідних ресурсів: аудит фактичної утилізації, вивільнення надлишків пам’яті та процесорів, накопичених за роки, виведення з експлуатації сервісів і застарілих систем, які давно не використовуються, але досі споживають ресурси.

Окремий резерв економії — надлишкова відмовостійкість застарілих систем. Архітектуру з дубльованими вузлами й кластерами високої доступності проєктували роки тому, коли ці системи були критичними для бізнесу. Сьогодні частина з них уже втратила цей статус, а резервні вузли досі споживають ядра, пам’ять і ліцензії.

Для таких систем варто переглянути вимоги до доступності разом із бізнесом. Якщо погоджений час відновлення це дозволяє, дубльовану інфраструктуру можна замінити на продуману стратегію резервного копіювання зі швидким відновленням. Це вивільнить ресурси, які сьогодні вкрай вартісні. Кожен заощаджений гігабайт — це економія коштів на нове обладнання. 

Важливі застереження TCO-розрахунку

Аби розрахунок TCO був об'єктивним, зважте на три важливі нюанси:

● Враховуйте CapEx (капітальні витрати). Витрати на нові сервери мають увійти в ту саму TCO-модель. Інакше це не економія, а лише перерозподіл коштів між бюджетними статтями. ● Пам'ятайте про мінімум ядер. Консолідувати обладнання «нижче порога» немає сенсу, оскільки вимога щодо мінімум 16 ліцензованих ядер на процесор залишається чинною.● Перераховуйте ризики. Чим менше серверів у системі, тим вищою є ціна відмови кожного вузла. Резервування та регламенти обслуговування доведеться адаптувати під щільніший кластер.
Гібридна стратегія: кілька гіпервізорів під різні задачі

Логічне продовження цього підходу — гібридні схеми з кількома гіпервізорами. Критичні системи та ШІ лишаються на VMware, Windows-навантаження переходять на Hyper-V, тестові середовища й Linux-сервіси — на відкриті платформи. Дорогих ядер VCF меншає, переговорна позиція з Broadcom посилюється. Ціна питання — експлуатація кількох платформ одночасно: подвійний моніторинг, окремі контури резервного копіювання, ширші компетенції команди — і все це теж рядки TCO-моделі. 

Головний висновок може здатися парадоксальним. Коректний TCO-асесмент з оцінкою реальної утилізації ресурсів іноді доводить, що обґрунтоване рішення — не мігрувати від Broadcom, а ущільнити інфраструктуру на сучасному обладнанні, скоротити кількість ліцензованих ядер і переукласти контракт із сильнішої позиції. Міграція — лише один зі сценаріїв, а не самоціль.

TCO-асесмент з IT Specialist — точні розрахунки замість готових відповідей

Ретельний аналіз усіх витрат часто призводить до несподіваних результатів. Сукупна вартість володіння зрілими платформами є приблизно однаковою. Економія на ліцензіях нівелюється витратами на підтримку — у жодному продуктивному сценарії її не уникнути. 
Перехід на інше обладнання вимагає оновлення мережі, а зручність єдиної екосистеми означає залежність. Broadcom обмежує вибір пакетними пропозиціями, Microsoft — хмарною інтеграцією, Red Hat — операційною моделлю Kubernetes. Універсальної правильної відповіді не існує. Є відповідь, яка є правильною для конкретної інфраструктури, команди та стратегії компанії на найближчі 3–5 років. 
Знайти її можна лише через розрахунок, і саме в цьому полягає суть TCO-асесменту від IT Specialist. Ми не залежимо від жодного вендора, тому не пропонуємо готових рішень. 
Ми аналізуємо інфраструктуру та реальне використання ресурсів, моделюємо кілька сценаріїв (від повної міграції до консолідації парку й перегляду контракту з Broadcom) і переводимо в цифри всі приховані витрати та ризики: від технічної несумісності до вартості майбутнього виходу з платформи. Якщо чесна математика покаже, що вам вигідніше залишитися там, де ви є, — ви побачите це у висновках.
Залишайте заявку на консультацію та розрахунок TCO з IT Specialist і ухвалюйте рішення щодо віртуалізації на підставі цифр, а не під тиском обставин.

Автор статті — Олексій Бутич, провідний фахівець з підтримки та впровадження інфраструктури кіберзахисту.