- 01Broadcom sonrası yeni VMware modeli subscription merkezli; VCF ve VVF 9'da 25 karakterlik lisans anahtarları yerine subscription tabanlı lisans dosyaları kullanılıyor.
- 02VMware subscription hesabında fiziksel CPU başına minimum 16 core kuralı uygulanır; düşük core'lu çok socket'li donanımda lisanslanan kapasite gerçek fiziksel core sayısından yüksek olabilir.
- 03Mevcut perpetual lisans support sona erdiğinde ortam otomatik kapanmaz; ancak yeni patch, sürüm ve teknik destek erişimi aktif support durumuna bağlıdır.
- 04VMware'den çıkış kararı VM sayısına göre değil vSAN, NSX, backup, ağ, otomasyon ve uygulama bağımlılıklarıyla birlikte verilmelidir.
- 05Doğru karşılaştırma üç senaryoyu içerir: mevcut donanımla VMware yenileme, konsolide donanımla VMware ve alternatif platform + migration maliyeti.
Kısaca
Broadcom sonrası VMware'den çıkış kararı yalnızca lisans fiyatına bakılarak verilmemelidir. Önce mevcut perpetual veya subscription hakkınızı, fiziksel core sayısını, vSAN/NSX bağımlılıklarını, yedekleme zincirini ve vSphere 9'a geçiş gereksinimini çıkarın. Dynamis Teknoloji, VMware göçünü ürün değiştirme projesi değil; sanallaştırma, depolama, ağ, yedekleme ve operasyon modelinin birlikte yeniden tasarımı olarak ele alır.
Broadcom sonrası VMware'de gerçekten ne değişti
Broadcom'un VMware satın alımı sonrasında lisanslama ve ürün portföyü önemli ölçüde değişti. Yeni perpetual lisans satışları sona erdi ve yeni VMware Cloud Foundation (VCF) ile VMware vSphere Foundation (VVF) sürümleri subscription modeliyle lisanslanıyor.
VCF ve VVF 9.0'dan itibaren eski 25 karakterlik lisans anahtarları yerine subscription tabanlı lisans dosyaları ve VCF Business Services Console kullanılıyor. Broadcom ayrıca vSphere 9 için eski vSphere 8.x lisans anahtarlarının doğrudan yükseltilemediğini açıkça belirtiyor.
Mevcut perpetual lisansınızın support sözleşmesi bittiyse ortam otomatik olarak kapanmaz. Broadcom'un güncel bilgi bankasına göre mevcut ESXi host'ları ve sanal makineler çalışmaya devam eder; ancak yeni patch, security update, major/minor sürüm indirmeleri ve teknik destek erişimi aktif support durumuna bağlıdır.
Bu fark önemlidir: "perpetual lisansım var, VMware'i süresiz aynı şekilde kullanırım" ile "perpetual lisansım var, mevcut yetkim dahilindeki sürümü çalıştırmaya devam ederim" aynı şey değildir.
16 core minimumu donanım envanterini maliyet modelinin parçası yapar
Güncel VMware subscription lisanslama modelinde fiziksel CPU başına minimum 16 core lisanslama kuralı uygulanır.
Basitleştirilmiş hesap:
Gerekli core = host sayısı × CPU sayısı × max(16, fiziksel core/CPU)
Örnek:
- 3 host
- Her hostta 2 fiziksel CPU
- Her CPU 12 fiziksel core
Gerçek fiziksel core sayısı:
3 × 2 × 12 = 72 core
Lisans hesabı ise minimum 16 core nedeniyle:
3 × 2 × 16 = 96 core
Donanım 16 core'un altında CPU'lar kullanıyorsa fiziksel core sayısı ile lisanslanan core sayısı farklılaşabilir. Bu nedenle VMware alternatifi değerlendirmesinde ilk tablo sanal makine sayısı değil, host ve CPU envanteri olmalıdır.
vSphere 9 kararı eski lisans hakkından ayrı değerlendirilmelidir
Broadcom'un güncel belgelerinde vSphere 9 ve VCF/VVF 9 için subscription tabanlı lisanslama akışı kullanılıyor. Eski Essentials Plus perpetual lisansları vSphere 9 ile uyumlu değil.
Bu durum her müşterinin hemen VMware'den çıkması gerektiği anlamına gelmez. Üç ayrı seçenek vardır:
- Mevcut lisanslı vSphere sürümünde kalmak
- Güncel VCF/VVF subscription modeline geçmek
- VMware dışı bir sanallaştırma veya özel bulut platformuna taşınmak
Doğru seçenek mevcut support süresi, güvenlik güncellemesi ihtiyacı, donanım yenileme tarihi ve üç yıllık toplam maliyete göre değişir.
Çıkış kararından önce VMware bağımlılık haritasını çıkarın
VMware ortamı yalnızca ESXi host'lardan oluşmaz. Migration projesi başlamadan önce hangi VMware özelliklerinin gerçekten kullanıldığını görün.
| Alan | Sorulacak soru | Göç riskine etkisi |
|---|---|---|
| Compute | Kaç host, socket ve fiziksel core var? | Hedef kapasite ve lisans hesabı |
| vCenter | Kaç cluster ve resource pool var? | Yönetim modelinin yeniden kurulması |
| vMotion | Canlı taşıma operasyonun parçası mı? | Hedef platformda eşdeğer davranış gerekir |
| HA/DRS | Otomatik yeniden başlatma ve yerleştirme kullanılıyor mu? | Kesinti ve kapasite tasarımı |
| vSAN | Depolama VMware'e gömülü mü? | Compute ve storage birlikte taşınabilir |
| NSX | Overlay network, microsegmentation veya firewall kullanılıyor mu? | Ağ dönüşümü ayrı proje olabilir |
| Backup | VADP/VDDK tabanlı yedekleme var mı? | Yeni platformda backup zinciri yeniden doğrulanmalı |
| GPU/passthrough | Donanıma doğrudan bağımlılık var mı? | Hedef hypervisor uyumluluğu |
| Automation | PowerCLI, API veya Terraform entegrasyonu var mı? | Otomasyon yeniden yazılabilir |
Sadece VM export listesi çıkarıp bu bağımlılıkları atlamak, migration'ın son haftasında sürpriz yaratır.
VMware'de kalmanın mantıklı olduğu durumlar
Broadcom sonrası lisanslama değişiklikleri VMware'in teknik kabiliyetlerini ortadan kaldırmadı. Aşağıdaki durumlarda mevcut veya yeni VMware modeliyle devam etmek rasyonel olabilir:
- Ekip vSphere operasyonunda güçlü deneyime sahipse
- vSAN ve NSX yoğun kullanılıyorsa
- Uygulamalar vMotion, DRS veya VMware'e özgü otomasyona bağlıysa
- VCF subscription teklifi üç yıllık toplam maliyet hedefini karşılıyorsa
- Migration riskinin lisans farkından daha yüksek olduğu kritik sistemler varsa
- Donanım yenileme tarihi yakın değilse ve mevcut sürüm güvenlik/support gereksinimini karşılıyorsa
Burada çıkış kararı ideolojik olmamalıdır. VMware ortamını iyi işleten bir ekip sırf vendor değişikliği oldu diye çalışan sistemi dönüştürmek zorunda değildir.
VMware'den çıkmanın mantıklı olduğu durumlar
Çıkış daha çok şu durumlarda incelenmelidir:
- Subscription yenileme toplam maliyeti bütçe modelini bozuyorsa
- Kullanılan VMware özelliklerinin küçük bir kısmı gerçekten gerekliyse
- Donanım yenileme ile lisans yenileme aynı döneme denk geliyorsa
- Küçük cluster'larda 16 core minimumu nedeniyle lisanslanan kapasite gerçek kullanımdan belirgin yüksekse
- vSAN/NSX gibi ürün bağımlılıkları zaten yoksa
- Operasyon ekibi farklı bir platformu destekleyebilecek yetkinliğe sahipse
- Türkiye'de özel bulut veya farklı veri konumu gereksinimi oluştuysa
Göçün maliyeti yalnızca yeni hypervisor değildir. Eğitim, yeniden otomasyon, backup entegrasyonu, monitoring, ağ ve cutover maliyetini de ekleyin.
VMware alternatifi seçerken ürün isminden önce işletim modelini seçin
Alternatifleri tek tabloda "hangisi en iyi?" diye sıralamak yanıltıcıdır. Önce hangi işletim modelini istediğinizi belirleyin.
| Model | Uygun olduğu durum | Dikkat edilmesi gereken |
|---|---|---|
| Mevcut VMware'de kalmak | VMware özellikleri yoğun kullanılıyor | Subscription ve upgrade yolu |
| Yeni VMware subscription | VCF/VVF kabiliyetleri gerekiyor | Core lisans hesabı ve dönem maliyeti |
| Kendi özel bulutunuz | Veri ve altyapı kontrolü önemli | Operasyon ekibi ve donanım yönetimi |
| Yönetilen özel bulut | Kontrol isteniyor, operasyon dışarıda kalacak | Sağlayıcı bağımlılığı ve devir planı |
| Alternatif hypervisor | VM ağırlıklı sade ortam | Backup, HA ve automation eşdeğerliği |
| Public/hibrit bulut | Donanım işletmek istenmiyor | Egress, servis bağımlılığı ve veri konumu |
Dynamis'in /vmware-alternatifi sayfası bu kararı hedef altyapı ve migration hizmeti açısından ele alır. Bu rehber ise karar vermeden önce teknik ve lisans bağımlılıklarını çıkarmak içindir.
Çıkış planı 6 aşamada ilerler
1. Lisans ve support hakkını belgeleyin
Şunları tek tabloda toplayın:
- VMware ürün ve edition
- Lisans tipi: perpetual veya subscription
- Lisanslanan core/CPU kapasitesi
- Support başlangıç ve bitiş tarihi
- Kullanılan major/minor sürüm
- vSphere 9 veya VCF 9 ihtiyacı
- Yenileme teklifi ve sözleşme süresi
Perpetual lisansın support'u bittiğinde mevcut çalışma hakkıyla yeni sürüm/patch erişimini karıştırmayın.
2. Donanım ve özellik envanterini çıkarın
Her host için CPU, core, RAM, NIC ve storage bağlantısını kaydedin. Sonra kullanılan VMware özelliklerini eşleştirin.
Dynamis'te migration değerlendirmesinde "kaç VM var?" sorusundan önce "hangi feature set gerçekten kullanılıyor?" sorusunu soruyoruz. 100 VM'lik sade bir vSphere ortamı, 20 VM'lik NSX ve vSAN bağımlı ortamdan daha kolay taşınabilir.
3. Hedef platformu küçük pilotla doğrulayın
İlk migration wave için düşük riskli 3-5 VM seçin. Pilot grubunda mümkünse şu çeşitleri bulundurun:
- Windows Server
- Linux uygulama sunucusu
- Küçük veritabanı olmayan stateless servis
- Farklı disk boyutları
- Farklı network/VLAN ihtiyacı
Pilotun amacı yalnızca VM'i boot etmek değildir. Backup, monitoring, IP/DNS, performans ve rollback birlikte test edilir.
4. Yedek ve rollback yolunu migration'dan önce test edin
VMware'den çıkış projesi backup projesiyle aynı anda öğrenilmemelidir. Migration wave başlamadan önce kaynak VM'in geri döndürülebilir bir yedeği bulunmalı ve en az bir test restore yapılmalıdır.
Ayrıntılı düzen için 3-2-1 yedekleme ve felaket kurtarma rehberini kullanın.
Özellikle vSAN kullanan ortamda "VM dosyası var" ile "VM farklı platformda kurtarılabilir" aynı şey değildir. Disk formatı, boot mode, driver ve network ayarları pilotta doğrulanmalıdır.
5. Wave planını uygulama bağımlılığına göre kurun
VM'leri yalnızca klasör veya host'a göre gruplayarak taşımayın. Aynı uygulamanın web, API ve database bileşenlerini bağımlılık haritasıyla birlikte planlayın.
Wave sırası genellikle şu mantığı izler:
- Düşük riskli bağımsız VM'ler
- İç uygulamalar
- Uygulama grupları
- Kritik stateful sistemler
- Yönetim ve altyapı servisleri
Ancak DNS, Active Directory, monitoring veya backup sunucuları gibi altyapı servislerinin hedef ortamda ne zaman gerekli olacağı ayrıca planlanmalıdır.
6. Eski VMware ortamını kontrollü kapatın
Migration sonrası eski cluster'ı aynı gün silmeyin. Önce:
- Uygulama sahibi doğrulaması
- Backup doğrulaması
- Monitoring ve alarm kontrolü
- Performans karşılaştırması
- Lisans ve support kayıtlarının arşivlenmesi
- Rollback süresinin kapanması
tamamlanmalıdır.
Rollback penceresi sona erdiğinde eski VM, datastore, snapshot ve network kaynaklarını kontrollü olarak kaldırın. Böylece iki ortamı gereksiz yere uzun süre işletmezsiniz.
Migration süresini VM sayısı tek başına belirlemez
"50 VM iki haftada taşınır" gibi sabit bir kural güvenilir değildir. Süreyi şu değişkenler belirler:
- Toplam veri hacmi
- Değişim oranı
- Network throughput
- Uygulama bağımlılıkları
- Bakım penceresi
- Windows/Linux driver dönüşümü
- vSAN veya NSX bağımlılığı
- Backup ve restore yöntemi
- Hedef platform otomasyonu
Bu yüzden migration teklifinde yalnızca VM sayısı değil, workload sınıflandırması kullanılmalıdır.
Broadcom lisans değişikliği bir kapasite optimizasyonu fırsatı da olabilir
VMware yenilemesi öncesinde host sayısını ve CPU topolojisini yeniden değerlendirin. Core bazlı subscription modelinde eski donanım yerleşimi lisans hesabını etkileyebilir.
Örneğin düşük core'lu çok sayıda CPU socket, minimum 16 core kuralı nedeniyle lisans kapasitesini artırabilir. Yeni donanım veya cluster konsolidasyonu bazı ortamlarda migration yapmadan da toplam lisanslanan core'u düşürebilir.
Bu nedenle üç senaryoyu aynı tabloda fiyatlayın:
- Mevcut donanım + yeni VMware subscription
- Konsolide donanım + VMware subscription
- Yeni platform + migration maliyeti
Sadece mevcut yenileme teklifini alternatif platform teklifiyle karşılaştırmak eksik TCO üretir.
KVKK veya Türkiye lokasyonu tek başına VMware'den çıkış sebebi değildir
VMware bir sanallaştırma katmanıdır; veri konumu altyapının fiziksel lokasyonuna göre belirlenir. Türkiye'deki donanım üzerinde VMware kullanarak da veriyi Türkiye'de tutabilirsiniz.
KVKK gereksiniminiz varsa konu VMware markası değil, verinin konumu, yurt dışı aktarım mekanizması, erişim, log ve yedek mimarisidir. Ayrıntısı KVKK uyumlu bulut altyapısı rehberinde yer alıyor.
Dynamis'in özel bulut yaklaşımında VMware'den çıkış, KVKK gereksinimi varsa Türkiye'de konumlanan hedef altyapıyla birleştirilebilir; ancak bu iki karar teknik olarak ayrı değerlendirilir.
Dynamis'te VMware çıkış değerlendirmesi
Dynamis'in VMware alternatifi hizmeti, mevcut sanallaştırma ortamını koruma, kısmi taşıma veya tamamen farklı bir özel bulut modeline geçme seçeneklerini aynı envanter üzerinden değerlendirir.
İlk değerlendirmede şu çıktıları oluştururuz:
- Host/core lisans envanteri
- VM ve dependency haritası
- vSAN/NSX/backup bağımlılıkları
- Yenileme ve üç yıllık TCO tablosu
- Hedef kapasite modeli
- Pilot migration wave
- Backup ve rollback planı
- Kesim ve decommission sırası
Amaç her VMware müşterisini platformdan çıkarmak değildir. Amaç, mevcut ortamda kalmanın ve çıkmanın maliyetini aynı veriyle karşılaştırabilmektir.
Sık yapılan hatalar
Broadcom değişikliğini yalnızca fiyat artışı olarak görmek: Lisans modeli, upgrade yolu ve ürün paketleri de değişti. Sadece birim fiyat karşılaştırmayın.
Perpetual lisansın her yeni sürüme hak verdiğini varsaymak: Mevcut lisans çalışma hakkı ile yeni sürüm entitlement'ı farklıdır.
16 core minimumunu donanım hesabına katmamak: Özellikle düşük core'lu çok socket'li hostlarda lisanslanan kapasite fiziksel core sayısından yüksek olabilir.
vSAN ve NSX'i VM migration detayına indirgemek: Depolama ve ağ katmanı ayrı migration planı gerektirebilir.
Backup entegrasyonunu sona bırakmak: Hedef platformda restore doğrulanmadan kritik wave taşımayın.
Tüm VM'leri tek wave'e koymak: Düşük riskli pilot ile dönüşüm yöntemini ve operasyon prosedürünü doğrulayın.
Alternatif platformu yalnızca lisans fiyatına göre seçmek: HA, canlı taşıma, backup, network, otomasyon ve destek maliyetini aynı TCO tablosuna ekleyin.
Sırada ne var
-
Cloud Migration hizmeti: VMware çıkış planını migration, cutover ve rollback süreciyle birlikte değerlendirin.
-
VMware alternatifi: mevcut cluster'ınız için hedef altyapı ve migration seçeneğini değerlendirin.
-
Bulut göçü sırası: bağımlılıklara göre migration wave planı: VMware workload'larını VM listesine değil dependency map ve risk seviyesine göre wave'lere ayırın.
-
AWS'den çıkış: maliyeti düşüren bulut göçü planı: farklı bir sağlayıcıdan çıkışta kullanılan wave ve rollback metodunu inceleyin.
-
3-2-1 yedekleme kuralı: migration öncesi geri dönüş yolunu doğrulayın.
-
KVKK uyumlu bulut altyapısı: Türkiye lokasyonu ve yurt dışı aktarım gereksinimlerini planlayın.
-
Cloud migration strategy: rehost, replatform ve refactor: VMware workload'ları için relocate, rehost, replatform ve replace seçeneklerini aynı karar çerçevesinde karşılaştırın.
Kaynaklar
- Broadcom: VMware perpetual licensing end of availability
- Broadcom: VCF ve VVF 9 licensing
- Broadcom: vSphere 8.x perpetual keys to vSphere 9 subscriptions
- Broadcom: perpetual license functionality after support expiry
- Broadcom: vSphere Essentials Plus compatibility with vSphere 9
- Broadcom: counting cores for VCF and VVF
Kaynaklar
- 1.VMware End Of Availability of Perpetual Licensing and SaaS ServicesBroadcom · 2026-09-19
- 2.Getting started with VCF or VVF V9 LicensingBroadcom · 2026-09-19
- 3.Licensing Migration Path from vSphere 8.x Perpetual Keys to vSphere 9 SubscriptionsBroadcom · 2026-09-19
- 4.Perpetual license functionality after support expirationBroadcom · 2026-09-19
- 5.vSphere Essentials Plus compatibility with vSphere 9.0Broadcom · 2026-09-19
- 6.Counting cores for VMware Cloud Foundation and vSphere FoundationBroadcom · 2026-09-19
Sık sorulan sorular
Broadcom sonrası VMware lisanslama nasıl değişti?
Broadcom, yeni VMware perpetual lisans satışını sonlandırıp subscription modeline geçti. VCF ve VVF çekirdek bazlı term subscription olarak lisanslanıyor; mevcut perpetual lisansların kullanım hakkı ise sahip olunan sürüm ve sözleşme koşullarına göre ayrıca değerlendirilmelidir.
VMware'den çıkmak zorunlu mu?
Hayır. Mevcut VMware özellikleri, operasyon yetkinliği ve VCF subscription maliyeti iş hedeflerinizi karşılıyorsa kalmak geçerli bir seçenektir. Çıkış kararı lisans, donanım, vSAN/NSX bağımlılığı, yedekleme ve üç yıllık toplam maliyet birlikte değerlendirilerek verilmelidir.
VMware lisansında 16 core minimumu ne anlama gelir?
Broadcom'un güncel VCF ve VVF lisanslama örneklerinde her fiziksel CPU için minimum 16 core subscription kapasitesi hesaplanır. İşlemci 16'dan az fiziksel core içeriyorsa da lisans hesabında 16 core dikkate alınır.
VMware'den başka platforma geçişte kesinti olur mu?
Kesinti süresi iş yüküne ve migration yöntemine bağlıdır. Pilot wave, doğrulanmış yedek, paralel hedef ortam ve uygulamaya uygun replikasyon veya dönüşüm yöntemiyle kesinti azaltılabilir; bazı stateful sistemlerde planlı bakım penceresi gerekebilir.
VMware alternatifi seçerken hangi özellikler karşılaştırılmalı?
vMotion benzeri canlı taşıma, yüksek erişilebilirlik, ağ ve VLAN modeli, paylaşımlı depolama, yedekleme entegrasyonu, GPU ve passthrough ihtiyacı, API/otomasyon, destek modeli ve üç yıllık toplam maliyet birlikte karşılaştırılmalıdır.