Bursa’daki bir otomotiv yan sanayi üreticisi VMware vSphere ortamında 180 sunucu çalıştırıyordu. Donanım yenileme zamanı geldiğinde “yeniden host alalım mı, yoksa Azure’a mı geçelim” sorusu masaya geldi. Hesaplar Azure’ı işaret etti, ama 180 sunucu küçük bir proje değildi. Azure Migrate aracını kullanarak 4 ay süren bir migration projesi yaptık. Discovery, assessment, replication, test failover, cutover. Bu yazı o projeden öğrendiklerim; özellikle “broşürde yazmıyor ama sahada başına geliyor” kısımları.

Azure Migrate’in Üç Ayrı Aracı

“Azure Migrate” tek bir araç değil, hub:

1. Server Assessment: VMware/Hyper-V/fiziksel sunucuları keşfet, sizing önerisi al, maliyet hesabı çıkar.
2. Server Migration: Sunucuyu replicate edip Azure’a taşı (lift-and-shift).
3. Database Migration Service (DMS): SQL Server, Oracle, MySQL, PostgreSQL’i Azure SQL’e veya Azure DB’ye taşı.

Bu yazıda ağırlıklı Server Assessment + Server Migration. DMS’i database tarafı için ayrı yazıda toplamak gerekir.

Discovery: Appliance Kurulumu

VMware ortamında discovery için bir Linux veya Windows appliance kurulmalı. Bu appliance vCenter’a bağlanıp inventory’yi çekiyor, ek olarak guest OS içinde script çalıştırıp dependency map oluşturuyor.

Sahada uyguladığım kurulum:

1. Bursa veri merkezinde Hyper-V veya VMware’de yeni bir Windows Server 2022 VM (8 vCPU / 16 GB RAM / 80 GB disk).
2. Azure Migrate Server Assessment paketini indir, kur.
3. vCenter credentials gir (read-only kullanıcı yeter).
4. Optional: Linux/Windows VM credentials ile guest OS inspection (bu olmadan dependency map sınırlı kalır).
5. Discovery başlasın, ilk run ~~30 dakika.

180 sunucu 30 dakikada keşfedildi. Her sunucu için: hostname, IP, OS version, vCPU, RAM, disk, ağ adaptör bilgisi. Ek olarak VM düzeyinde performance metrikleri (CPU/RAM/IOPS/network) son 24 saat boyunca toplanıyor (sürekli).

Performance-Based Sizing: 30 Günlük Veri Şart

Assessment yaparken iki sizing stratejisi var:

• As-on-premise: Mevcut VM boyutunu Azure’a en yakın SKU’ya eşle. Hızlı ama overprovision.
• Performance-based: Son N gün CPU/RAM/IOPS metriklerine göre rightsize. Doğru ama veri toplaması gerekir.

Bursa projesinde 30 gün veri topladık (Microsoft önerisi de bu). Performance-based sizing’in sonucu: as-on-premise ile karşılaştırınca aylık tahmini Azure faturası %38 daha düşük çıktı. Çünkü VMware’de “ihtiyatla” 8 vCPU verilen sunuculardan birçoğu gerçekte ortalama 1.2 vCPU kullanıyordu.

Confidence rating’i de kontrol et: Discovery aracı her sunucu için 1-5 yıldız confidence veriyor (5 yıldız = 30 gün tam veri var, sizing güvenilir). 1-2 yıldızlı sunucular için sizing tahmini güvenilmez, manuel review gerekir.

Dependency Mapping: Hangi Sunucu Hangisine Bağımlı

Lift-and-shift’in en büyük tuzağı: Bir sunucuyu taşıyorsun, dependency’sini taşımıyorsun, uygulama bozuluyor. Azure Migrate’in dependency analysis özelliği bu sorunu çözüyor. İki tip:

• Agentless: vCenter üzerinden VMware Tools ile network connection bilgisini çekiyor.
• Agent-based: Microsoft Monitoring Agent + Dependency Agent her VM’e kuruluyor, daha detaylı veri.

Bursa’da agentless ile başladık (180 VM’e agent kurmak büyük efor). Sonra critical 30 sunucuya agent kurduk (production database, application server, integration servisleri). Çıkan dependency map ile “bunlar bir grup olarak migrate edilmeli, ayrı ayrı taşıma riskli” denildi.

Migration wave’leri (dalgaları) bu map’e göre tasarlandı:

• Wave 1: Standalone development/test sunucuları (35 adet). Risk düşük, ekibin Azure’a alışması.
• Wave 2: Internal tools, file servers (45 adet). Orta risk.
• Wave 3: Application servers + database (60 adet). Yüksek risk, dependency grupları halinde.
• Wave 4: ERP (SAP B1) + integration (40 adet). En yüksek risk, en son.

Business Case: ROI Hesabı

Azure Migrate, 1 saatte business case raporu üretebiliyor. Yıllık on-premise maliyet (donanım amortismanı + bakım + enerji + datacenter alan + lisans + personel) vs yıllık Azure maliyet karşılaştırması.

Bursa’da rapor:

Kalem	On-prem yıllık (USD)	Azure yıllık (USD)
Donanım amortismanı (5 yıl)	140.000	0
VMware lisansı	45.000	0
Datacenter (rack, cooling, güç)	72.000	0
Backup yazılım + storage	28.000	(Azure Backup içinde)
Compute + storage + network	0	185.000
Backup + DR	0	32.000
Operasyon personeli (2 FTE)	120.000	60.000 (1 FTE)
Toplam yıllık	405.000	277.000

Yıllık tasarruf ~~128.000 USD. Migration projesi tek seferlik ~~85.000 USD (consulting + license + training). 8 ayda break-even. Bu hesap üst yönetimi ikna eden tablo oldu.

Azure Hybrid Benefit (mevcut Windows Server / SQL Server lisanslarını Azure’da kullan) hesabı kritik, Azure tarafının %35’ini buradan kaydediyorsun.

Replication Phase: Network Bandwidth Planlama

Migration başladığında her VM’in disk’leri Azure’a replike edilir. Initial replication tüm disk’i kopyalar (büyük olabilir; bizde 24 TB toplam veri), delta replication sadece değişiklikleri.

Bursa’da datacenter’ın Azure’a olan internet bağlantısı 200 Mbps’ti. 24 TB initial replication için kabaca:

24 TB × 8 bit = 192.000 Gbit. 200 Mbps = 0.2 Gbps. 192.000 / 0.2 = 960.000 saniye = ~~11 gün.

Eğer paralel 5 VM replicate edersen 11 gün toplam (bandwidth bottleneck). Production trafik aynı internet bağlantısını paylaşıyorsa rate limit koymak şart, aksi halde gündüz internet yavaşlar.

Bizim çözüm: ExpressRoute geçici 1 Gbps tahsis ettik (3 ay), initial replication 2 günde bitti. Delta replication düşük bandwidth ile sürdü.

Test Failover: Cutover’dan Önce Mutlaka

Replicate edilen VM’leri Azure’da bir izole VNet’e açıp test edebiliyorsun. Production’ı etkilemiyor. Bursa’da her wave için 2 hafta önce test failover yaptık.

Tipik bulgular:

• Static IP’li uygulamalar: On-prem’de hardcoded IP olan integration adresleri Azure VNet aralığıyla farklı. Configuration update gerekti.
• Hostname resolution: On-prem DNS server kullanan uygulamalar Azure’da farklı DNS server kullanıyor. Hosts file veya Azure Private DNS Zone gerekti.
• License binding: Bazı uygulamalar MAC address’e bağlı lisans kullanıyordu. Azure’da MAC değişince lisans error. Vendor’la önceden bilgi almak şart.

Test failover’dan sonra “test VM”i temizleyip orijinal replication’a devam ediliyor, herhangi bir veri kaybı olmuyor.

Cutover: Bakım Penceresi Planlama

Cutover sırasında uygulama down olur. Süre: VM boyutuna ve son delta replication süresine bağlı, tipik 15-45 dakika.

Bursa’da en kritik wave (ERP + integration) cutover’ı için:

1. Cuma 22:00 – kullanıcılara önceden duyuru, son uyarı.
2. Cuma 22:30 – on-prem ERP read-only moda alındı.
3. Cuma 23:00 – son delta replication tetiklendi.
4. Cuma 23:30 – cutover komutu, on-prem VM kapandı.
5. Cuma 23:45 – Azure’da VM açıldı, smoke test başladı.
6. Cumartesi 02:00 – Smoke test temiz, DNS değişikliği (ERP hostname Azure VM’e işaret etti).
7. Cumartesi 06:00 – Pilot kullanıcılar (5 kişi) prod’da test, sorun yok.
8. Pazartesi 08:00 – Tüm kullanıcılar Azure ERP’ye geçti.

Pazartesi sabahı ekipte “çalıştı mı, çalışmadı mı” gerginliği vardı. Ortalama login süresi 3 saniyeden 8 saniyeye çıkmıştı (Bursa – Azure West Europe latency). 1 hafta sonra Türkiye West region’a geçirdik, latency 1 saniyenin altına indi.

Sahada Düşülen Beş Tuzak

1. Discovery sonrası “hemen migrate edelim” baskısı: 30 günlük performance veri olmadan sizing yanlış olur. Sabırlı ol.
2. Dependency map’i atlamak: “Standalone sandığım sunucu aslında üç başka sunucuya bağımlıymış” sürprizi cutover gecesi yaşanır. Wave planlamasında dependency’yi her zaman önce.
3. Network bandwidth’i unutmak: Initial replication için ExpressRoute geçici tahsis veya off-hours throttling şart.
4. Lisans tarafını lifecycle’ın sonunda düşünmek: Windows Server, SQL Server, Oracle lisanslarının cloud’a taşıma kuralları farklı. Azure Hybrid Benefit hesabını başta yap.
5. Cutover sonrası eski VM’i hemen silmek: 30 gün on-prem VM’i kapalı tut, sorun çıkarsa rollback. Replication kontrolü kapatınca eski VM yine çalışır halde.

Migrate Sonrası: FinOps ve Optimizasyon Aşaması

Migration bitti diyorsun, fatura geliyor, tahminin üstünde. Tipik. Sebepler:

• Performance-based sizing 7/24 çalışacak gibi hesaplandı, dev/test 7/24 lazım değil. Auto-shutdown.
• Azure Backup retention default’lar pahalı (180 gün). 30 güne düşür.
• Reserved Instance veya Savings Plan satın al (1 yıl reserved %30, 3 yıl %50 tasarruf).
• Idle disk’leri tespit et (unattached managed disks). Aylık fatura içinde “size düşük” görünür ama 50 disk birikince ciddi rakam.

Bursa’da migration’dan 3 ay sonra FinOps assessment yaptık, aylık faturayı %22 daha düşürdük. Toplam ROI hesabımız doğrulandı.

Sonuç: Migration Bir İT Projesi Değil, Bir İş Dönüşüm Projesidir

180 sunucu taşımak teknik olarak çözülebilir; daha zoru kullanıcı etkisini, eğitim ihtiyacını, yeni operasyon modelini yönetmek. Bursa projesinde ekibe 2 ay önceden Azure Administrator (AZ-104) eğitimi başlattık, herkes sertifikalı oldu. Cutover sonrası ekibin “ne yapmamız gerek bilmiyoruz” durumu olmadı.

Azure Migrate aracı discovery + assessment + replication kısmını sıkıca çözüyor. Geri kalan iş kısmı (wave planlaması, kullanıcı iletişimi, lisans, operasyon modeli) hâlâ insan + süreç yönetimi.

CloudSpark olarak VMware/Hyper-V → Azure veya VMware/Hyper-V → CloudSpark Cloud (VHI) migration projelerinde end-to-end danışmanlık + implementasyon hizmeti veriyoruz. Discovery raporu için ücretsiz pilot yapıyoruz.