Azure platformunda sıkça karşılaşılan en tehlikeli yanlışlardan biri şudur:
“PAYG (Pay-As-You-Go) aboneliğini CSP’ye taşırız, faturayı partnere geçiririz.”
Azure portalında “Transfer” veya “Move” gibi düğmeleri gördüğümüzde çoğu kişi bunun mümkün olduğunu varsayar. Oysa Microsoft, PAYG → CSP geçişini resmî olarak desteklemez.
Bu farkı bilmemek bir abonelik değişikliğini kısa sürede karmaşık bir migration projesine dönüştürür.
Bu makalemde bu konunun perde arkasını, teknik detaylarını ve en doğru ilerleme yöntemlerini ele alacağız.
1. PAYG ve CSP Arasındaki Fark: İki Farklı Dünya
Azure’da her abonelik tipi farklı sözleşme, faturalandırma ve sahiplik modeline sahiptir.
PAYG (Pay-As-You-Go) : bireysel kullanıcıların kredi kartı ile doğrudan Microsoft üzerinden fatura ödediği en basit abonelik modelidir.
CSP (Cloud Solution Provider) ise iş ortakları üzerinden sağlanan destek ve faturalandırması partner tarafından yönetilen kurumsal bir modeldir.
| Özellik | PAYG | CSP |
|---|---|---|
| Faturalandırma | Microsoft doğrudan kullanıcıya | CSP Partner üzerinden |
| Sözleşme tipi | Bireysel (Online sözleşme) | Microsoft Partner sözleşmesi |
| Destek modeli | Microsoft Support | Partner Support |
| Abonelik sahipliği | Müşteri | CSP Partner (delegated ownership) |
| Transfer hakkı | Yok | Kısıtlı (sadece EA/MCA özel durumlar) |
Bu farklılıklar nedeniyle PAYG aboneliğinin CSP’ye “taşınması” teknik olarak mümkün değildir.
Microsoft bu işlemi yalnızca Enterprise Agreement (EA) veya Microsoft Customer Agreement (MCA) gibi özel sözleşmelerde belirli koşullar altında destekler. PAYG kullanıcıları için geçişin tek yolu kaynak bazlı migration yapmaktır.
2. Gerçekte Ne Olur? “Abonelik Taşımak” Değil, “Kaynakları Yeniden Kurmak”
Birçok kişi CSP’ye geçişin basit bir fatura aktarımı olduğunu düşünür. Ancak durum tam tersidir:
“PAYG aboneliği taşımak” aslında “tüm kaynakları yeniden kurmak” anlamına gelir.
Çünkü Azure abonelikleri sadece bir fatura kabı değildir. Her abonelik kaynak grupları, kimlik yönetimi, ağ yapısı, güvenlik politikaları ve yedekleme planlarıyla birlikte bağımsız bir altyapı alanıdır.
PAYG → CSP geçişinde mevcut aboneliği taşıyamazsınız bunun yerine yeni bir CSP aboneliği oluşturur ve kaynakları bu yeni ortama tek tek migrate edersiniz.
Bu noktada karşımıza çıkan tablo aşağıdaki gibidir
3. Azure Kaynaklarının Taşınabilirlik Durumu
Aşağıdaki tabloda Azure kaynaklarının PAYG → CSP geçişinde nasıl davrandığını özetler.
Gerçek bir migration projesinde bu tabloyu rehber olarak kullanmak büyük fark yaratır.
Doğrudan Taşınabilen Kaynaklar (Move Supported)
Azure Resource Manager (ARM) üzerinde “Move” işlemiyle doğrudan CSP aboneliğine aktarılabilirler.
| Kaynak Türü | Açıklama |
|---|---|
| VM, Disk, NIC, Public IP | Sanal makineler ve ilişkili ağ bileşenleri |
| VNet, Subnet, NSG, UDR | Ağ yapılandırmaları (routing dahil) |
| Azure Storage (Blob/File/Queue/Table) | Veri depolama bileşenleri |
| Azure SQL Database | Tekil SQL veritabanı örnekleri |
| App Service (Consumption plan hariç) | Web uygulamaları ve API servisleri |
| Key Vault | Anahtar ve sertifika kasaları |
| Load Balancer, Application Gateway, Firewall | Trafik yönlendirme bileşenleri |
Bu kaynaklar “Move-AzResource” komutu veya portal üzerinden “Move to another subscription” seçeneği ile taşınabilir.
Kısmen Taşınabilen Kaynaklar (Export/Import veya Redeploy Gerektirir)
Bu tür servisler taşınmaz ancak yapılandırma veya veri dışa aktarılıp yeni ortamda yeniden kurulabilir.
| Kaynak Türü | Yöntem |
|---|---|
| Azure Database (MySQL/PostgreSQL) | Backup/Export + Restore |
| Logic App / Function App (Consumption plan) | Yeniden deploy (ARM template / ZIP deploy) |
| Cosmos DB | Data Migration Tool veya azcopy |
| Redis Cache | Yeni instance + bağlantı güncellemesi |
| AKS (Kubernetes Service) | ARM/Script ile yeniden oluşturma |
| Automation, Event Hub, Service Bus | Export / import yapılandırma |
| Backup/ASR | Disable + yeniden yapılandırma |
Bu kaynaklarda connection string’lerin managed identity’lerin ve network bağlantılarının yeniden yapılandırılması gerekir.
Asla Taşınamayan Kaynaklar (Move Unsupported)
Bu kaynaklar hiçbir şekilde başka bir aboneliğe taşınamaz sıfırdan oluşturulmaları gerekir.
| Kaynak Türü | Not |
|---|---|
| Recovery Services Vault (Backup + ASR) | Taşınamaz, tamamen yeniden kurulmalıdır |
| Log Analytics Workspace | Taşınamaz, veri kaybı kaçınılmaz |
| Azure Sentinel | Workspace’e bağımlı olduğundan yeni kurulum gerekir |
| Azure AD / Managed Identity | Global düzeyde tekil, taşınamaz |
| Marketplace Ürünleri | CSP ile uyumsuz olabilir |
| Classic Resources (ASM) | ARM dışı kaynaklar desteklenmez |
| Azure Policy / Blueprints | Manuel yeniden oluşturulmalı |
| Reserved Instances / Savings Plan | Abonelik bazlı, devredilemez |
Birçok geçiş projesinde teknik olarak kaynaklar taşınsa bile bağımlılıklar ve yapılandırma zincirleri gözden kaçar.
Bu da “her şey taşındı ama sistem çalışmıyor” gibi senaryolara yol açar.
İşte en sık atlanan noktalar:
- DNS Bağlantıları: Domain veya private endpoint adresleri değişir, uygulama trafiği kesilir.
- RBAC Rolleri: Eski abonelikteki izinler taşınmaz, kullanıcılar erişimini kaybeder.
- Backup/ASR: Vault taşınamadığı için yedekler sıfırdan yapılandırılmalıdır.
- Managed Identity: Yeniden oluşturulmadığı sürece uygulamalar kimlik doğrulaması yapamaz.
- Azure Policy / Blueprint: Güvenlik standartları ve uyumluluk kontrolleri devre dışı kalabilir.
- App Insights, Monitor, Sentinel: Bağlı workspace değişince veri akışı kopar.
Birçok ekip bu hataları migration sonrası fark eder, ama o noktada veri kaybı veya servis kesintisi çoktan yaşanmıştır.
Doğru Yaklaşım: Geçiş Öncesi Planlama ve Adım Adım Migration
PAYG → CSP geçişine başlamadan önce mutlaka şu adımlar planlanmalıdır:
Envanter Analizi
az resource list veya Azure Resource Graph ile tüm kaynakların envanteri çıkarılır.
Hangi servisler move destekli, hangileri export-import gerektiriyor belirlenir.
Taşınabilirlik Değerlendirmesi
Yukarıdaki tabloya göre “Move Supported / Redeploy Required / Unsupported” ayrımı yapılır.
Migration planı buna göre tasarlanır.
Bağımlılık Haritalama
DNS, RBAC, Key Vault, App Insights, Managed Identity ilişkileri çıkarılır.
Bu, taşınma sırasında “görünmeyen” hataları önler.
CSP Aboneliği Tasarımı
Yeni ortamda:
- Resource Group’lar
- Naming Convention
- Tag yapısı
- Azure Policy & RBAC planı
önceden tanımlanmalıdır.
Pilot Geçiş
Önce test veya dev ortamlarından başlanarak taşınabilirlik doğrulanır.
Uygulama bağlantıları ve script’ler test edilir.
Gerçek Geçiş
Üretim (production) ortamı için planlı kesinti penceresi belirlenir.
DNS TTL düşürülür, snapshot alınır, move işlemleri yapılır.
Doğrulama ve Temizlik
Taşınan kaynaklar çalışır durumda mı?
Monitoring, alert, backup ve policy’ler yeniden etkinleştirildi mi?
Bu aşamada validation kritik önemdedir.
