Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı · MS-100 / MS-102 / AZ-104 sertifikalı danışmanlar · 25+ yıl saha deneyimi
Özet (TL;DR): Microsoft, Broadcom'un VMware lisanslama değişikliğine uyum sağlamak için Azure VMware Solution'da (AVS) lisans modelini kökten değiştiriyor: 31 Ekim 2026'dan itibaren lisans-dahil (license-included) yeni AVS ortamı satışı duruyor; mevcut kullandıkça-öde (PayGo) düğümler bu tarihe kadar değişiklik olmadan çalışmaya devam edebiliyor. Yalnızca 15 Ekim 2025'e kadar önceden ödemeli rezervasyon (Reserved Instance) satın almış kurumlar 30 Ağustos 2027'ye kadar ek bir geçiş süresi kazanıyor. Bu tarihlerden sonra AVS'de kalmak isteyen her kurum, Broadcom'dan kendi VMware Cloud Foundation (VCF) lisansını satın almak (kendi lisansını getir — BYOL) zorunda kalıyor. Sonuç: çoğu kurum için "AVS'de kal, Broadcom'a ayrıca lisans öde" ile "VMware'den tamamen çık, iş yüklerini doğrudan Azure sanal makinesine taşı" arasında net bir karar anı doğdu. Bu rehber tarihleri, karar ağacını, Azure Migrate ile adım adım göç sürecini, sık yapılan hataları ve Türkiye'ye özel (KVKK, kur riski) noktaları tek yerde topluyor.
Azure VMware Solution'da tam olarak ne değişiyor?
Broadcom, VMware'i devraldıktan sonra lisanslamayı köklü biçimde değiştirdi: kalıcı (perpetual) lisans satışını durdurup her şeyi VMware Cloud Foundation (VCF) adlı paket bir abonelik ürününe yönlendirdi. Bu paket, çoğu kurumun kullanmadığı bileşenleri de (NSX ağ sanallaştırması, vSAN depolama gibi) içine alıyor ve minimum çekirdek şartı getiriyor. Microsoft, kendi Azure VMware Solution (AVS) hizmetini de bu yeni modele uydurmak zorunda kaldı; sonuç, AVS müşterilerini doğrudan etkileyen bir dizi tarih oldu. Microsoft'un resmi Azure Migration Blog duyurusuna göre (2026-08 itibarıyla):
| Tarih | Ne oluyor |
|---|---|
| 31 Ekim 2026 | Microsoft, lisans-dahil (VMware lisansı pakete gömülü) yeni AVS ortamı satışını durduruyor. Mevcut kullandıkça-öde (PayGo) düğümler bu tarihe kadar değişiklik olmadan çalışmaya devam edebiliyor. |
| 15 Ekim 2025 (geçmiş eşik) | Bu tarihe kadar önceden ödemeli rezervasyon (Reserved Instance) satın almış müşteriler ek bir geçiş süresi kazanıyor. |
| 30 Ağustos 2027 | Yukarıdaki rezervasyon şartını karşılayan müşteriler için lisans-dahil AVS düğümlerinin kullanılabileceği son tarih. Bu tarihten sonra AVS'de kalmak, Broadcom'dan taşınabilir bir VCF lisansı (BYOL) satın almayı gerektiriyor. |
Kritik bir ayrıntı çoğu kurumun kaçırdığı noktadır: AVS, Broadcom'un VMware'i satın almasından kaçış gibi görünse de, artık kendisi de Broadcom lisanslamasına bağımlı. Microsoft'un resmi AVS fiyatlandırma sayfası 2025'in sonundan itibaren "tüm AVS boyutlarının artık müşteriden taşınabilir bir VMware VCF Aboneliği sağlamasını gerektirdiğini" açıkça belirtiyor — yani AVS'de kalmak, Broadcom faturasından tamamen kurtulmak anlamına gelmiyor. Gerçek "kaçış", VMware'in kendisinden (ESXi, vCenter, NSX, vSAN) çıkıp iş yükünü doğrudan Azure sanal makinesine (native Azure VM) taşımaktır — bu durumda Broadcom lisans denklemi tamamen devre dışı kalır.
Broadcom lisans şoku: piyasa neden bu kadar hareketlendi?
Bu değişikliğin arka planında sektör genelinde yaşanan bir fiyat şoku var. Piyasa araştırmalarına göre (çapraz doğrulama amaçlı, Microsoft dışı kaynak — kesin rakam için kendi VMware/Broadcom teklifinize bakın) vSphere lisans maliyetleri devralma sonrası bazı kurumlarda %150-400 arasında arttı; yeni paket, mid-market ortamları zorlayan bir 72 çekirdek minimum şartı da getirdi. Bu, dünya genelinde birçok kurumun VMware'den Azure, Hyper-V veya alternatif platformlara göç değerlendirmesini hızlandırdı. Yani AVS'deki bu lisans değişikliği izole bir olay değil, daha büyük bir "VMware'den çıkış" dalgasının Microsoft tarafındaki yansıması.
AVS'de kaç düğümünüz (node) var, hangi lisans modelindesiniz, rezervasyon tarihiniz ne zaman biliyor musunuz? Ücretsiz VMware/AVS envanteri ve göç yol haritası çıkaralım — 31 Ekim'e kaç günle girdiğinizi bir sayfada görün.
Karar ağacı: BYOL ile AVS'de kalmak mı, Azure'a tam geçiş mi?
Doğru karar; düğüm sayınıza, rezervasyon durumunuza, NSX/vSAN gibi VMware'e özgü özellikleri ne kadar kullandığınıza ve bütçenize göre değişir. Üç ana yol var:
| Seçenek | Ne zaman mantıklı | Broadcom bağımlılığı |
|---|---|---|
| AVS'de kal + Broadcom VCF (BYOL) | NSX/vSAN'a derin bağımlı, kısa vadede uygulama mimarisini değiştiremeyen kurumlar | Devam eder — kendi VCF lisansınızı satın almanız gerekir |
| Azure sanal makinesine (IaaS) tam göç | VMware'e özgü özellik kullanmayan, "kaldır-taşı" (lift-and-shift) ile buluta geçebilecek çoğu iş yükü | Sıfırlanır — Broadcom lisans denklemi dışına çıkılır |
| Modernizasyon (PaaS'a geçiş) | Veritabanı/uygulama katmanını Azure SQL, App Service gibi yönetilen hizmetlere taşıyabilecek kurumlar | Sıfırlanır + işletim yükü de azalır |
Küçük ve orta ölçekli çoğu Türk kurumu için (NSX/vSAN gibi ileri VMware özelliklerini kullanmayan, standart sanal sunucu ortamı çalıştıran) en ekonomik ve en sürdürülebilir yol genellikle Azure sanal makinesine doğrudan göçtür — hem Broadcom'a hem AVS'nin ek maliyetine ihtiyaç kalmaz. Azure altyapı çözümlerimiz bu değerlendirmeyi mimariniz üzerinden ücretsiz yapıyor.
Göçe başlamadan önce: envanter ve ön koşullar
Microsoft'un resmi Azure Migrate — VMware göç haritası belgesine göre süreç şu sırayla ilerler:
- Keşif (discovery): Ortamınızdaki tüm sunucuların listesini çıkarın. İki yol var: sürekli keşif yapan bir Azure Migrate appliance'ı (keşif ve replikasyon için kurulan yazılım bileşeni) dağıtmak, veya RVTools ile üretilen bir Excel dosyasını içe aktarmak.
- Bağımlılık analizi: Sunucular arasındaki bağımlılıkları çıkarıp birlikte taşınması gereken grupları belirleyin — örneğin ERP uygulama sunucusu ile veritabanı sunucusu genelde birlikte taşınmalıdır.
- İş gerekçesi (business case): Azure Migrate'in değerlendirme aracıyla, Azure'a geçişin mevcut altyapıya kıyasla maliyet/performans etkisini hesaplayın.
- Değerlendirme (assessment): Ortamınızı hem doğrudan Azure sanal makinelerine hem yönetilen Azure VMware Solution seçeneğine göre ayrı ayrı değerlendirin — boyutlandırma ve maliyet farkını görün.
- İzin ve rol kontrolü: Göçü yürütecek hesabın Azure Migrate projesinin ve hedef kaynak grubunun üzerinde Azure Migrate Owner veya Azure Migrate Execute Expert rolüne sahip olması gerekir.
Bölge seçimi de ön koşulların bir parçası: Türkiye'de yerel bir Azure bölgesi bulunmuyor; çoğu kurum West Europe veya North Europe'u tercih ediyor. Göçten önce mutlaka uygulamalarınızın bu bölgelere olan gecikme (latency) toleransını test edin — özellikle Logo/Netsis gibi masaüstü istemcili yerli ERP'lerde kritik. Fiziksel sunuculardan buluta göçün genel adımlarını daha önce fiziksel sunucudan Azure'a geçiş rehberimizde de ele almıştık; VMware kümesi de teknik olarak benzer bir keşif-değerlendirme-göç akışı izler.
Adım adım: Azure Migrate ile VMware'den Azure sanal makinesine taşıma
Ön koşullar tamamlandıktan sonra agentless (aracısız) veya agent-based (aracılı) replikasyon arasında seçim yaparsınız. Çoğu standart VMware ortamı için agentless yeterlidir ve sunucuya ek yazılım kurmaz. Adımlar:
- Replikasyonu yapılandır: Taşınacak VM'leri seçip hedef abonelik, bölge ve ağ ayarlarını belirleyin.
- İlk replikasyon: Azure Migrate, VM'in bir anlık görüntüsünü (snapshot) alır ve disklerin tam bir kopyasını hedef abonelikteki yönetilen disklere (managed disks) aktarır.
- Delta (artımlı) replikasyon: İlk kopyalama bittikten sonra, VMware'in değişen blok izleme (Changed Block Tracking — CBT) teknolojisiyle yalnızca değişen veri periyodik olarak senkronize edilir. Sonraki döngü
min[maks(1 saat, önceki döngü süresi/2), 12 saat]formülüyle otomatik zamanlanır. - Test göçü (önerilir, zorunlu değil): İzole bir test sanal ağında VM'i gerçekten başlatıp uygulamanın çalıştığını doğrulayın; testten sonra test kaynaklarını mutlaka temizleyin.
- Kesme (cutover): Kaynak VM'i kapatın (veri kaybını önlemek için şart), son bir "istek üzerine" (on-demand) delta döngüsü çalışır, ardından Azure Migrate VM'i replika disklerle Azure'da oluşturur.
- Replikasyonu durdur: Göç başarıyla tamamlandıktan sonra mutlaka replikasyonu durdurun — aksi halde ara (seed) diskler silinmez ve gereksiz depolama ücreti ödemeye devam edersiniz.
Ölçek notu: her Azure Migrate appliance aynı anda en fazla 52 diski paralel replike edebilir; her ESXi host'u (VMware'in sunucu sanallaştırma katmanı) en fazla 8 disk, her veri deposu (datastore) en fazla 15 anlık görüntü destekler. 300'den fazla VM'i eşzamanlı taşıyacaksanız bir scale-out appliance eklemeniz gerekir. Gece/mesai saatleri gibi replikasyonun durması gereken pencereler için blackout window (karartma penceresi) yapılandırılabilir; büyük ölçekli göçlerde Azure PowerShell ile otomasyon önerilir.
Doğrulama ve sık yapılan hatalar
- "AVS = Broadcom'dan tam kaçış" yanılgısı: Yukarıda belirtildiği gibi AVS artık kendisi de Broadcom VCF aboneliği gerektiriyor. Gerçek kaçış, iş yükünü doğrudan Azure VM'e taşımaktır.
- Mevcut yedekleme anlık görüntüleriyle çakışma: Microsoft'un resmi uyarısına göre VM üzerinde Veeam gibi araçlardan kalan eski anlık görüntüler agentless replikasyon kurulumunu engeller — göçten önce temizleyin.
- Replikasyonu durdurmayı unutmak: Göç tamamlandıktan sonra "Complete Migration" adımını atlarsanız ara diskler silinmez, gereksiz depolama işlem ücreti birikir.
- Veri deposu doldurma riski: Yoğun veri değişimi (churn) olan disklerde anlık görüntü boyutu veri deposu kapasitesini aşarsa üretim VM'leri yanıt vermez hale gelebilir; kritik disklerde veri deposu boyutunu önden büyütün.
- Bölge gecikmesini test etmeden karar vermek: Türkiye'de Azure bölgesi olmadığından West Europe/North Europe gecikmesi, özellikle masaüstü istemcili ERP'lerde kullanıcı deneyimini etkileyebilir.
- Azure Hybrid Benefit'i gözden kaçırmak: Mevcut Windows Server/SQL Server lisanslarınızda Software Assurance varsa, Azure'a taşındığınızda Azure Hybrid Benefit (yerinde lisansı bulutta yeniden kullanma hakkı) ve Windows Server/SQL Server için 3 yıl ücretsiz Genişletilmiş Güvenlik Güncelleştirmeleri (ESU) maliyeti belirgin şekilde düşürebilir — ESU mantığını ve geri-faturalama tuzağını SQL Server 2016 destek sonu rehberimizde detaylı işledik.
Saha vakası: 90 kişilik üretim firması, VMware'den Azure'a göç
Aşağıdaki vaka anonimleştirilmiştir; sektör ve yapı gerçektir.
Durum: 90 çalışanlı bir üretim firması, ERP (Netsis Fusion) veritabanı, dosya sunucusu ve 14 uygulama sunucusunu tek bir on-prem VMware kümesinde (3 ESXi host, tek veri deposu) çalıştırıyordu. Broadcom'un lisans yenileme teklifi geldiğinde, önceki yıla göre lisans kalemi üç katına yakın çıkmıştı; yönetim önce Azure VMware Solution'a geçmeyi düşündü.
Karar noktaları:
- AVS teklifini aldığımızda, düğün başı fiyata ayrıca bir Broadcom VCF aboneliği eklenmesi gerektiğini gördük — bu da "Broadcom'dan kaçış" beklentisini geçersiz kıldı.
- Ortamda NSX veya vSAN gibi VMware'e özgü ileri özellik kullanılmadığını doğruladık — standart sanal sunucular, standart ağ.
- Netsis Fusion veritabanı sunucusunun collation (Türkçe karakter sıralaması) ve bağımlı raporlama araçlarının Azure VM'de sorunsuz çalıştığını bir test ortamında doğruladık.
Sonuç: Firma, AVS'yi hiç devreye almadan doğrudan Azure sanal makinelerine agentless göç yolunu seçti. 14 uygulama sunucusu üç dalga halinde taşındı; ERP veritabanı sunucusu son dalgada, hafta sonu kesme penceresinde sıfır veri kaybıyla taşındı. Broadcom'un yıllık lisans faturası tamamen ortadan kalktı, yerine öngörülebilir aylık Azure tüketimi geldi. Xen ekibinin rolü: envanter ve bağımlılık analizi, test göçü, kesme planı ve geri dönüş senaryosuydu. Ders: "AVS'ye geç" refleksi yerine önce "Broadcom denklemi gerçekten sıfırlanıyor mu?" sorusunu sormak gerekiyor.
Benzer bir VMware kümesi/Broadcom lisans yenilemesiyle mi karşı karşıyasınız? Uzmanımızla 15 dakikalık ücretsiz teknik görüşme ayarlayın ya da WhatsApp'tan yazın — kümenizin envanterini birlikte çıkaralım.
Türkiye'ye özel: KVKK, kur riski ve yerel gerçekler
KVKK Madde 12 ve veri konumu: 6698 sayılı Kanun'un 12. maddesi, veri sorumlusuna kişisel verinin güvenliği için "gerekli her türlü teknik ve idari tedbiri" alma yükümlülüğü getirir. VMware'den Azure'a göç sırasında iki ayrı konu var: (1) desteklenmeyen/yamasız bir sanallaştırma katmanında kalmak başlı başına bir teknik tedbir eksikliğidir; (2) Türkiye'de yerel Azure bölgesi olmadığından veriniz fiilen yurt dışında (West Europe/North Europe) işlenir — bu durumda KVKK'nın yurt dışına veri aktarımı rejimi (Kurul'un onayladığı Standart Sözleşme mekanizması) kapsamında sözleşme ve bilgilendirme yükümlülüklerinizi gözden geçirin. Microsoft güvenlik ve uyumluluk danışmanlığımız bu değerlendirmeyi göç planına dahil ediyor.
Kur riski: Hem Broadcom VCF aboneliği hem Azure faturaları döviz (USD/EUR) bazlıdır. Özellikle 1-3 yıllık önceden ödemeli rezervasyon (Reserved Instance) taahhüdüne girmeden önce, Türk Lirası'ndaki dalgalanmanın bütçenizi nasıl etkileyeceğini hesaba katın. Xen Bilişim olarak CSP paketlerimizde kur farkı riskini biz üstleniyoruz — sabit TL faturayla planlama yaparsınız. TL faturayla CSP paketimizi görün.
Yerli ERP bağımlılığı: Logo Tiger, Netsis Fusion veya Mikro gibi ERP'lerin veritabanı sunucusu genellikle VMware kümesinde çalışır. Göç öncesi ERP üreticinizin hedef ortamı (Azure VM işletim sistemi/SQL Server sürümü) resmi olarak desteklediğini teyit edin; aksi halde bir sorunda üretici desteği alamazsınız.
Sıkça Sorulan Sorular (SSS)
Azure VMware Solution kapanıyor mu?
Hizmetin kendisi kapanmıyor, ama lisans modeli değişiyor. 31 Ekim 2026'dan itibaren Microsoft, VMware lisansı dahil yeni AVS ortamı satmıyor; devam etmek isteyen kurumların kendi Broadcom VCF lisansını (BYOL) sağlaması gerekiyor.
Mevcut AVS ortamım 31 Ekim 2026'da aniden durur mu?
Hayır. Mevcut kullandıkça-öde (PayGo) düğümleriniz bu tarihe kadar değişiklik olmadan çalışmaya devam eder; 15 Ekim 2025'e kadar rezervasyon (Reserved Instance) satın aldıysanız 30 Ağustos 2027'ye kadar ek süreniz var. Bu tarihlerden sonra devam etmek için kendi VCF lisansınızı sağlamanız gerekiyor.
AVS'ye geçersem Broadcom'dan tamamen kurtulur muyum?
Hayır. Microsoft'un resmi fiyatlandırma sayfasına göre tüm AVS boyutları artık müşteriden taşınabilir bir Broadcom VCF Aboneliği talep ediyor. Broadcom lisans denkleminden tamamen çıkmak için iş yükünü doğrudan Azure sanal makinesine (veya Azure SQL gibi PaaS hizmetlerine) taşımanız gerekir.
VMware'den Azure'a göç için Azure Migrate ücretli mi?
Hayır. Microsoft'un resmi fiyatlandırma sayfasına göre Azure Migrate hub'ı (keşif, değerlendirme, bağımlılık haritalama) ek ücret olmadan sunulur. Ücret yalnızca replikasyon sırasında kullanılan depolama/ağ kaynaklarından ve hedefte oluşturulan Azure VM'lerin işletim maliyetinden doğar.
Agentless mi agent-based mi seçmeliyim?
Çoğu standart VMware ortamı için agentless yeterlidir; sunucuya ek yazılım kurmadan, VMware anlık görüntü ve değişen blok izleme (CBT) teknolojisiyle çalışır. Agent-based, agentless'in desteklemediği özel senaryolarda (ör. bazı üçüncü taraf disk yapılandırmaları) tercih edilir.
Göç sırasında veri kaybı riski var mı?
Doğru sırayla ilerlerse (ilk replikasyon → delta senkronizasyon → test göçü → kaynak VM'i kapatıp son delta döngüsünü tamamlama) risk minimumdur. Kaynak VM'i kapatmadan kesme yapmak veri kaybına yol açabilir; bu adım asla atlanmamalı.
300'den fazla sunucum var, tek appliance yeterli mi?
Hayır. Azure Migrate tek appliance ile aynı anda 500 VM'e kadar eşzamanlı replikasyonu destekler, ancak 300 VM eşiğini aştığınızda bir "scale-out appliance" eklemeniz gerekir; aksi halde replikasyon devam edemez.
Sonuç: AVS'de kalmak bir varsayım değil, hesaplanmış bir karar olmalı
Broadcom'un VCF lisans değişikliği, Azure VMware Solution'ı da içine alan geniş bir dalga yarattı. 31 Ekim 2026 ve 30 Ağustos 2027 tarihleri, "sonra bakarız" için fazla yakın; ama panikle acele bir karar vermek de gerekmiyor. Kritik nokta şu: AVS artık otomatik bir "Broadcom'dan kaçış" değil — kendisi de bir VCF aboneliği istiyor. Bu yüzden karar, salt "AVS'ye geçelim mi" değil, "iş yükümüz gerçekten VMware'e özgü özelliklere (NSX, vSAN) bağımlı mı, yoksa doğrudan Azure sanal makinesine taşınabilir mi" sorusuyla başlamalı.
Envanterinizi çıkarıp NSX/vSAN bağımlılığınızı, rezervasyon durumunuzu ve uygulama mimarinizi netleştirdiğinizde, çoğu kurum için en ekonomik ve en az bağımlılık yaratan yolun doğrudan Azure Migrate ile native Azure VM'e göç olduğunu göreceksiniz.
Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun VMware'den Azure'a göç yolculuğunda envanter çıkarma, karar analizi, Azure Migrate ile agentless göç ve kesme planından geri dönüş senaryosuna kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın; 31 Ekim 2026 öncesi takviminizi birlikte çıkaralım.
