Azure Local projelerinde donanım seçimi, kapasite planlama, network ve storage tasarımını tamamladıktan sonra işin belki de en kritik bölümlerinden birisine geliyoruz; mevcut sanal makinelerin yeni platforma taşınması. Yeni kurulan bir ortam söz konusu olduğunda işimiz nispeten kolay, çünkü uygulamaları baştan Azure Local üzerinde konumlandırabiliyoruz. Ancak gerçek hayatta projelerin önemli bir bölümü böyle ilerlemiyor. Müşterinin yıllardır çalışan bir VMware veya Hyper-V altyapısı, yüzlerce sanal makinesi, bu makineler üzerinde çalışan kritik uygulamaları ve doğal olarak mevcut operasyon alışkanlıkları bulunuyor. Dolayısıyla Azure Local kurulduktan sonra asıl soru genellikle “Peki mevcut sistemleri buraya nasıl taşıyacağız?” oluyor.
Örneğin VMware üzerinde çalışan 300 sanal makineniz olduğunu düşünelim. Teknik olarak bunların her birisini kaynak ortamdan alıp Azure Local üzerine taşımak mümkün olabilir. Ancak burada önemli olan VM sayısı değil, bu sanal makinelerin hangi uygulamalara hizmet verdiği, birbirleriyle nasıl haberleştiği, hangi IP adreslerini kullandığı, hangi veritabanlarına bağlandığı ve hangi sırayla taşınması gerektiğidir. Çünkü bir web sunucusunu tek başına taşımak son derece kolay olabilir ancak aynı uygulamanın arkasında çalışan uygulama sunucusu ve SQL Server eski ortamda kalıyorsa beklediğiniz sonucu alamayabilirsiniz. Hatta uygulama içerisinde sabit IP adresleri, lisans sunucuları veya farklı sistemlere bağımlılıklar varsa teknik olarak başarılı bir VM migration sonrasında uygulamanız çalışmayabilir.
Bu nedenle özellikle büyük ortamlarda migration konusuna sadece sanal makine taşıma projesi olarak bakmamak gerekiyor. Ben burada “Migration Factory” yaklaşımını daha doğru buluyorum. Migration Factory Microsoft’un ayrıca satın aldığınız bir ürünü değil, aslında büyük ölçekli taşıma projelerini standart bir sürece oturtmak için kullandığımız operasyonel bir model. Önce mevcut ortamı keşfediyor, uygulama bağımlılıklarını çıkarıyor, hedef ortamın kapasitesini doğruluyor, taşıma gruplarını oluşturuyor, replication işlemlerini gerçekleştiriyor ve ardından kontrollü cutover yapıyoruz. Her migration dalgasında yaşadığımız sorunlardan da bir sonraki dalga için ders çıkarıyoruz. Böylece 300 sanal makine için 300 ayrı proje yürütmek yerine tekrar edilebilir ve ölçülebilir bir süreç oluşturuyoruz.
Bence burada en önemli nokta şu; VM migration ile application migration aynı şey değil. Sanal makinenin Azure Local üzerinde açılması bize hypervisor seviyesinde taşımanın başarılı olduğunu gösterir. Ancak uygulamanın kullanıcıya hizmet vermesi, verinin tutarlı olması, backup sisteminin yeni VM’yi koruması, monitoring agent’larının çalışması ve gerekiyorsa uygulama ekiplerinin testi tamamlaması ayrı bir süreçtir.
Azure Migrate bu yapının neresinde?
Microsoft, Azure Local’a VMware ve Hyper-V sanal makinelerinin taşınması için Azure Migrate hizmetini kullanıyor. Azure Migrate uzun zamandır mevcut olduğu için çoğumuz bu ürünü public Azure’a migration yapan bir servis olarak biliyoruz ancak Azure Local senaryosunda hedef Microsoft’un veri merkezi değil, müşterinin kendi veri merkezinde çalışan Azure Local altyapısı.
Burada mimariyi doğru anlamak önemli. Azure Migrate Project, migration işlemlerinin yönetildiği Azure tarafındaki merkezi kaynak. Kaynak ortamda çalışan appliance VMware veya Hyper-V altyapısını keşfediyor ve replication işlemlerinde görev alıyor. Azure Local tarafında çalışan target appliance ise kaynak ortamdan gelen verinin hedef altyapıya aktarılmasını sağlıyor. Azure Arc Resource Bridge de Azure Resource Manager ile Azure Local üzerindeki VM provisioning süreci arasında gerekli yönetim katmanını oluşturuyor.
Yani yönetim ve orkestrasyon Azure üzerinden gerçekleşirken, VM disk verisinin tamamını önce public Azure’a yükleyip ardından tekrar veri merkezinize indirmiyorsunuz. Disk verisi kaynak ortam ile hedef Azure Local arasında lokal network üzerinden aktarılıyor. Azure tarafı ise migration metadata’sı, orchestration ve ilgili state bilgilerinin yönetilmesinde görev alıyor.
Bu özellikle büyük VM’leri olan müşteriler için önemli bir detay. Örneğin toplam 100 TB disk veriniz varsa bunun tamamını internet üzerinden Azure’a taşıyıp sonra Azure Local’a geri indirmek gibi bir model söz konusu değil. Ancak burada “veri lokal gidiyor, dolayısıyla internet bağlantısına ihtiyacım yok” sonucuna da çıkmamak gerekiyor. Azure Migrate’in yönetim bileşenlerinin ihtiyaç duyduğu Azure erişimleri yine sağlanmalı.
VMware ve Hyper-V aynı durumda değil
Migration planına başlamadan önce kaynak platformun destek durumunu mutlaka kontrol etmek gerekiyor. 5 Kasım 2026 itibarıyla Azure Migrate üzerinden VMware’den Azure Local’a migration genel kullanıma açık durumda. Hyper-V tarafındaki Azure Migrate tabanlı Azure Local migration ise hala Public Preview seviyesinde.
Bu ayrımı özellikle kritik production sistemleri için göz ardı etmemek gerekiyor. Preview durumda olan bir özelliği kullanıp kullanmamak kurumun risk yaklaşımına, destek beklentisine ve taşınacak workload’un önemine göre değerlendirilmelidir.
Azure Local tarafında migration için desteklenen minimum platform sürümünün yanında kaynak hypervisor sürümü, guest işletim sistemi, storage tipi ve VM konfigürasyonu da önemli. Örneğin Hyper-V tarafında clustered ortam üzerinde çalışan fakat Highly Available olmayan VM’ler doğrudan aynı şekilde discovery ve migration kapsamına alınamıyor. Bu makinelerin öncelikle Highly Available hale getirilmesi gerekiyor. Yine clustered Hyper-V üzerinde VM disklerinin desteklenen Cluster Shared Volume yapısında bulunması bekleniyor. DAS veya SMB üzerinde farklı şekilde konumlandırılmış bazı senaryolar aynı migration yöntemine uygun olmayabilir.
Bunlar küçük detaylar gibi görünüyor ancak migration gecesi öğrenmek istemeyeceğiniz detaylar. Bu nedenle ben migration başlamadan önce teknik inventory içerisinde yalnızca VM adı, CPU ve memory bilgilerini değil, generation, boot tipi, disk yerleşimi, encryption durumu, network interface sayısı, static IP kullanımı ve varsa özel storage bağımlılıklarını da toplamak isterim.
VMware tarafında da benzer şekilde yalnızca vCenter’a bağlanabiliyor olmak yeterli değil. Azure Migrate replication işlemlerinde VMware Virtual Disk Development Kit yani VDDK kullanılıyor ve gerekli VDDK paketinin Broadcom tarafından sunulan uygun kaynaklardan temin edilmesi gerekiyor. Microsoft’un güncel dokümantasyonunda da özellikle bazı müşterilerin gerekli VDDK paketine erişim noktasında kısıt yaşayabileceği ve böyle durumlarda desteklenen üçüncü parti migration ürünlerinin alternatif olabileceği belirtiliyor. Bu nedenle VMware projesinde VDDK konusunu ilk haftada kontrol etmek, migration başlamasına birkaç gün kala öğrenmekten çok daha sağlıklı.
Discovery yaparken makinelere değil uygulamalara bakmak gerekiyor
Malum büyük ortamlarda CMDB veya sanallaştırma platformundan hızlı bir şekilde VM listesi çıkarmak mümkün. Ancak bu liste bize sadece kaç tane sanal makinemiz olduğunu söyler. Migration için asıl ihtiyacımız olan, bu makinelerin hangi sistemin parçası olduğunu anlamak.
Örneğin ERP-WEB01, ERP-APP01 ve ERP-SQL01 isimli üç sanal makinemiz olsun. Teknik olarak üç ayrı VM görüyoruz ama operasyon açısından bunlar tek bir uygulamanın üç katmanı. Bunlardan SQL Server’ı bu hafta, web sunucusunu gelecek hafta taşımak çoğu zaman doğru bir plan olmayacaktır. Aynı şekilde bir uygulama sunucusu Active Directory, DNS, lisans sunucusu, dosya sunucusu veya başka bir veritabanına bağımlı olabilir.
Bu nedenle discovery aşamasında Azure Migrate’in teknik olarak topladığı bilgilerin yanında uygulama sahiplerinin bilgisine de ihtiyacımız var. Hangi makineler beraber çalışıyor, hangi network bağlantıları gerekli, hangi servisler migration sırasında kapatılmalı, hangi sistemin ne kadar kesinti toleransı var, bunların tamamı migration dalgalarını belirler.
Ben bu nedenle Migration Factory içerisinde VM listesini tek başına ana plan olarak kullanmak yerine uygulama gruplarını oluşturmayı daha doğru buluyorum. Çünkü sonunda taşıdığımız şey bir VHDX veya VMDK dosyası değil, kuruma hizmet veren bir uygulama.
Assessment tarafında da benzer şekilde sadece mevcut sanal makinenin kaç CPU ve ne kadar memory kullandığına bakmak yeterli değil. Yıllardır çalışan ortamlarda ciddi overprovisioning görmek mümkün. VMware üzerinde 16 vCPU ve 64 GB memory verilmiş bir VM gerçekte 4 vCPU ve 16 GB ile son derece rahat çalışıyor olabilir. Tam tersi şekilde, kaynak ortam zaten kapasite problemi yaşıyorsa mevcut tahsis edilen kaynaklar hedef ortam için doğru sizing bilgisini vermeyebilir.
Bu nedenle CPU, memory, disk kapasitesi, IOPS, latency ve network throughput gibi performans verilerinin de değerlendirilmesi gerekiyor. Böylece migration aynı zamanda mevcut yanlış sizing kararlarını yeni ortama taşımak yerine bunları düzeltme fırsatı haline gelebilir.
Replication ve cutover iki farklı konu
Azure Migrate tarafında replication başladıktan sonra kaynak VM çalışmaya devam ederken disk değişiklikleri hedef Azure Local ortamına aktarılıyor. İlk replication doğal olarak daha uzun sürebilir, çünkü mevcut veri setinin aktarılması gerekiyor. Sonrasında değişen bloklar takip edilerek hedef ortam güncel tutuluyor.
Burada migration süresini sadece “10 TB VM var, 10 Gbps network var, şu kadar saatte biter” şeklinde hesaplamak doğru değil. Kaynak storage’ın performansı, appliance kapasitesi, kaynak ve hedef network arasındaki gerçek throughput, hedef Azure Local storage performansı ve en önemlisi VM üzerindeki değişen veri miktarı toplam süreyi etkiliyor.
Özellikle yoğun transaction üreten SQL Server gibi sistemlerde VM çalışmaya devam ederken disk değişiklik miktarı yüksek olabilir. Bu nedenle pilot migration’larda elde edilen replication değerleri sonraki dalgaların planlanmasında ciddi fayda sağlar.
Ancak replication ne kadar başarılı olursa olsun bana göre migration projesinin en kritik bölümü cutover.
Çünkü bu aşamada artık kaynak ve hedef sistem arasında gerçek geçiş yapıyoruz. Örneğin ERP sistemini taşıyorsak kullanıcı erişimini hangi saatte kapatacağımız, aktif transaction’ların nasıl sonlandırılacağı, son replication işleminin ne zaman tamamlanacağı, kaynak VM’nin ne zaman kapatılacağı, hedef VM’nin ne zaman açılacağı ve uygulama testini kimin yapacağı önceden belirlenmiş olmalı.
Bu kararları migration gecesi vermeye başladığınız anda risk ciddi şekilde artıyor.
Aynı durum rollback için de geçerli. Rollback sadece hedef VM’yi kapatıp eski VM’yi açmak değildir. Eğer hedef sistem üzerinde uygulama çalıştı ve yeni transaction’lar oluştuysa eski sisteme dönmek veri tutarsızlığı oluşturabilir. Bu nedenle özellikle database ağırlıklı sistemlerde geri dönüş planının uygulama ve veri tarafını da kapsaması gerekiyor.
Azure Arc kaynaklarını yeniden kullanabilmek önemli bir avantaj
2026 yılında Azure Local migration tarafında gelen önemli yeniliklerden birisi mevcut Azure Arc kaynaklarının yeniden kullanılabilmesi oldu.
Örneğin VMware üzerinde çalışan bir Windows Server zaten Azure Connected Machine Agent üzerinden Azure Arc-enabled Server olarak Azure’a kayıtlı olabilir. Üzerinde Azure Policy atamaları, RBAC yetkileri, tag’ler, monitoring ayarları ve extension’lar bulunabilir.
Eskiden migration sırasında bu VM’nin mevcut Arc bağlantısını kaldırıp hedef sistemde yeniden oluşturmak gerekebiliyordu. Güncel Arc resource reuse desteğiyle uygun VM’lerde mevcut Azure Arc resource korunabiliyor ve migration sonrasında Azure Local VM modeline taşınabiliyor.
Bence özellikle büyük ortamlarda bunun önemli bir operasyonel avantajı var. Çünkü yıllardır kullandığınız Azure resource kimliğini ve onun üzerinde oluşturduğunuz governance ayarlarını kaybetmek istemezsiniz.
Ancak bu özellik her Arc senaryosunda geçerli değil. Kaynak VM’nin doğrudan Azure Connected Machine Agent ile Azure Arc-enabled Server olarak kaydedilmiş olması gerekiyor. Azure Arc-enabled VMware vSphere veya SCVMM üzerinden farklı bir projection modeliyle yönetilen kaynaklar aynı kapsamda değil.
Yine reuse seçildiğinde hedef resource group veya VM adı gibi bazı bilgiler mevcut Arc resource’a bağlı olabildiği için migration öncesinde bu kararı vermek önemli. Replication başladıktan sonra fikrinizi değiştirmeniz gerektiğinde replication batch’ini yeniden oluşturmanız gerekebilir.
Dolayısıyla “Arc zaten var, nasılsa devam eder” diye düşünmek yerine migration inventory içerisinde mevcut Arc durumunu da ayrı bir kolon olarak tutmak bence faydalı.
Trusted Launch migration sırasında değerlendirilebilir
Ekim 2026 itibarıyla gelen önemli yeniliklerden birisi de uygun Generation 2, yani UEFI kullanan VMware ve Hyper-V sanal makinelerinin Azure Local’a Trusted Launch ile taşınabilmesi.
Bu sayede migration sırasında Secure Boot ve vTPM gibi güvenlik özelliklerinin kullanılması mümkün hale geliyor.
Özellikle yeni Azure Local altyapısına geçerken güvenlik standardını yükseltmek isteyen kurumlar için güzel bir fırsat. Ancak burada dikkatli davranmak gerekiyor. Migration gecesi ilk kez Secure Boot, vTPM ve benzeri güvenlik özelliklerini etkinleştirip eski bir işletim sistemi veya özel appliance üzerinde sürpriz yaşamak istemeyiz.
Bu nedenle Trusted Launch kullanmayı planlıyorsak öncelikle guest işletim sisteminin uyumluluğunu, VM generation bilgisini ve varsa BitLocker gibi disk encryption yapılarını kontrol etmek gerekiyor.
Microsoft’un VMware migration gereksinimlerinde encrypted disk ve volume’lar için sınırlamalar bulunuyor. Dolayısıyla BitLocker veya başka bir encryption mekanizması kullanan VM’leri standart migration dalgasına doğrudan eklemek yerine ayrı değerlendirmekte fayda var.
Ben genel olarak migration projesini aynı zamanda modernizasyon fırsatı olarak görüyorum ancak modernizasyonla migration riskini aynı geceye yüklememek gerektiğini düşünüyorum. VM’yi yeni platforma taşımak zaten önemli bir değişiklik. Buna aynı anda işletim sistemi upgrade’i, network değişikliği, security model değişikliği ve uygulama versiyon yükseltme işlemlerini de eklerseniz sorun çıktığında hangi değişikliğin probleme neden olduğunu anlamak zorlaşır.
Migration dalgalarını nasıl oluşturmak gerekir?
300 VM’lik örneğimize geri dönersek bu makinelerin tamamını tek bir hafta sonu taşımak teknik olarak mümkün olsa bile operasyonel açıdan çok doğru olmayabilir. Burada dalgaları oluştururken sadece VM sayısına bakmamak gerekiyor.
İlk dalgada düşük kritik seviyedeki sistemleri ve farklı teknik senaryoları temsil eden birkaç VM’yi tercih etmek bence en sağlıklısı. Örneğin Windows Server, Linux, static IP kullanan bir sistem, birden fazla diski bulunan VM ve uygulama bağımlılığı olan bir workload pilot için iyi örnekler olabilir.
Bu ilk migration’dan sonra sadece “VM açıldı mı?” diye bakmamak gerekiyor. Replication ne kadar sürdü, cutover ne kadar zaman aldı, network değişiklikleri problem oluşturdu mu, VMware Tools veya Hyper-V integration bileşenlerinde sorun yaşandı mı, application validation ne kadar sürdü, bunların tamamı kayıt altına alınmalı.
Sonrasında ikinci dalgada 20-25 VM’ye, daha sonra 40-50 VM’ye çıkabilirsiniz. Ancak wave büyüklüğünü belirleyen yalnızca teknik migration kapasitesi değildir.
Bazen asıl darboğaz uygulama ekipleri olabilir.
Örneğin bir gecede 50 VM taşıyabilirsiniz ancak üzerlerinde çalışan 20 farklı uygulamayı sabah olmadan doğrulayacak uygulama ekibiniz yoksa teknik olarak hızlı migration yapmanın size pek faydası olmaz.
Bu nedenle Migration Factory sadece infrastructure ekibinin yürüttüğü bir çalışma olmamalı. Uygulama sahipleri, network ekibi, güvenlik ekibi, backup ekibi ve gerekiyorsa iş birimleri de planın içinde yer almalı.
Bence iyi bir migration planında her dalganın sonunda küçük bir değerlendirme yapmak gerekiyor. İlk dalgada Linux VM’lerin network interface isimleri nedeniyle sorun yaşadıysanız, ikinci dalgada aynı problemi yeniden yaşamamanız lazım. Belirli bir VMware Tools sürümü problem çıkardıysa bu sürümü kullanan diğer makineleri önceden tespit etmek gerekiyor.
Migration Factory yaklaşımının gerçek faydası burada ortaya çıkıyor. Aynı işi yüzlerce kez yapmak değil, her dalgada süreci biraz daha iyileştirmek.
Migration bittikten sonra iş bitmiyor
Azure Migrate üzerinde migration status başarılı göründüğünde projenin tamamlandığını düşünmemek gerekiyor.
Hedef VM gerçekten açılıyor mu?
Diskler doğru görünüyor mu?
IP adresi ve gateway doğru mu?
DNS kayıtları güncel mi?
Domain bağlantısı sağlıklı mı?
Uygulama servisleri çalışıyor mu?
Backup sistemi yeni VM’yi koruyor mu?
Monitoring tarafında yeni kaynak doğru izleniyor mu?
Bunların tamamının kontrol edilmesi gerekiyor.
Özellikle backup konusu zaman zaman atlanabiliyor. VMware üzerinde kullandığınız backup ürünü yeni Azure Local VM’yi otomatik olarak korumaya başlamayabilir. VM’nin yeni resource kimliği, storage konumu veya yönetim modeli nedeniyle backup policy yeniden değerlendirilmek zorunda olabilir.
Monitoring ve güvenlik ürünleri için de aynı durum geçerli.
Ben bu nedenle migration sonrasında bir kapanış dokümanı hazırlanmasını önemli buluyorum. Kaynak VM’nin nereden taşındığı, hedef Azure Local resource bilgileri, kullanılan logical network, IP adresi, storage konumu, backup durumu, monitoring durumu, uygulama sahibi ve cutover tarihi bu dokümanda bulunmalı.
Çünkü proje ekibi migration sonrasında dağılacak ancak sistemi yıllarca yönetecek operasyon ekipleri bu bilgilere ihtiyaç duyacak.
Özellikle VMware’den Azure Local’a geçiş yapan kurumların bu projeyi sadece hypervisor değişikliği olarak değerlendirmemesini öneririm. Çünkü hedef platformun işletim modeli de değişiyor. Azure Arc kullanımı, Solution Update lifecycle, Network ATC, Azure Local VM management, RBAC ve automation gibi konular mevcut operasyon modelinden farklı olabilir.
Dolayısıyla VM’lerin Azure Local üzerinde açılması migration’ın teknik olarak bittiğini gösterir, ancak kurumun yeni platformu doğru şekilde işletmeye başlaması ayrı bir başarı kriteridir.
Ben büyük migration projelerinde başarılı bir geçişi üç temel noktada değerlendiriyorum; workload’ların veri bütünlüğü korunarak taşınması, uygulamaların kabul edilen performans ve erişilebilirlik seviyesinde çalışması ve yeni platformun operasyon ekiplerine eksiksiz şekilde devredilmesi.
Azure Migrate discovery, replication ve migration tarafında bize güçlü araçlar sunuyor. Azure Arc ise taşınan VM’lerin Azure Resource Manager üzerinden yönetilebilmesini sağlıyor. Ancak bütün bu teknolojilerin etrafında düzgün bir süreç yoksa yüzlerce sanal makineyi taşımak ciddi bir operasyonel riske dönüşebilir.
Özetle sanal makineyi taşımak teknik olarak çok zor değil. Asıl iş, yüzlerce sanal makineyi uygulama bağımlılıklarını, veri bütünlüğünü, kesinti toleransını ve operasyonel devamlılığı koruyarak yeni platforma geçirmek.
Bir sonraki makalede ise migration tamamlandıktan sonra önem kazanan diğer kritik konuya, Azure Local Backup, Disaster Recovery ve Azure Site Recovery tarafına geçeceğim. Çünkü sistemleri Azure Local’a taşımak kadar, bu sistemlerin bir disk, node, site veya daha büyük bir felaket durumunda nasıl geri döneceğini de daha proje aşamasında planlamak gerekiyor.
Kullanılan temel Microsoft kaynakları
Bu makale 5 Kasım 2026 itibarıyla erişilebilir resmi Microsoft dokümantasyonu esas alınarak hazırlanmıştır. Özellikle Eylül 2026 Azure Arc resource reuse ve Ekim 2026 Trusted Launch migration yenilikleri kontrol edilmiştir.
Options for migrating virtual machines to Azure Local
What’s new in Azure Migrate for Azure Local
Overview of Azure Migrate based migration for Azure Local
Review requirements for VMware VM migration to Azure Local
Review requirements for Hyper-V VM migration to Azure Local
Reuse Azure Arc-enabled server resources when you migrate VMs to Azure Local
Migrate VMs to Azure Local with Azure Migrate using PowerShell, Azure CLI or Terraform
