Bulut migrasyonunda projeyi batıran şey teknik göç değil, hangi uygulamanın taşınmayacağına karar verememek. AWS'nin kendi rehberi stratejiyi yedi başlık altında topluyor ve bunların ikisi "taşımamak": Retire ve Retain. Türkiye bağlamında üçüncü bir kısıt daha var ve o teknik değil hukuki: bankacılık ve sermaye piyasası mevzuatı birincil ve ikincil sistemlerin yurt içinde bulundurulmasını zorunlu kılıyor. Bu yazı, yedi stratejinin hangi durumda seçileceğini, envanter çıkarmanın ölçülebilir eşiklerini ve yurt dışına veri aktarım rejimini anlatıyor.
Yedi strateji: AWS'nin resmî listesi ve ne zaman hangisi
Yaygın olarak "6 Rs" diye anılıyor ama AWS'nin prescriptive guidance dokümanı yedi tane sayıyor. Sıralama, sıklıkla sanıldığının aksine taşımamakla başlıyor:
| Strateji | Ne yapar | Ne zaman seçilir |
|---|---|---|
| Retire | Kullanımdan kaldırma veya arşivleme | Ölçülen kullanım eşiğin altında (aşağıdaki tanıma bakın) |
| Retain | Kaynak ortamda bırakma | Veri ikamet zorunluluğu, yüksek risk, çözülemeyen bağımlılık, mainframe |
| Rehost | "Lift and shift", değişiklik yapmadan taşıma | Veri merkezi çıkış tarihi baskısı var, uygulamaya dokunulamıyor |
| Relocate | Platformun bulut sürümüne toplu taşıma | En hızlı yol; AWS'nin ifadesiyle genel mimariyi etkilemiyor |
| Repurchase | "Drop and shop", farklı ürüne/SaaS'a geçiş | Uygulama ayırt edici değil; hazır ürün işi görüyor |
| Replatform | "Lift, tinker and shift", küçük optimizasyonlar | Veritabanını yönetilen hizmete almak gibi sınırlı kazanç |
| Refactor | Bulut-doğal yeniden tasarım | AWS'nin kendi ifadesiyle en karmaşık ve en maliyetli strateji |
Dikkat çekici bir ayrıntı: AWS, büyük migrasyonlar için rehost, replatform, relocate ve retire öneriyor; refactor'ı büyük migrasyon kapsamında önermiyor (bkz. AWS Prescriptive Guidance, Migration strategies). Yani "madem taşıyoruz, bir de mikroservise geçelim" fikri, en yetkili kaynağın açıkça uzak durduğu yaklaşım. İki büyük değişikliği aynı anda yapmak, sorun çıktığında hangisinin sebep olduğunu bilememek demek.
Retire kararını hisle değil, ölçüyle verin
AWS'nin dokümanı iki tanım veriyor ve bunlar doğrudan bir sorguya çevrilebilir:
- Zombie uygulamalar: 90 gün boyunca ortalama CPU ve bellek kullanımı %5'in altında olanlar (bkz. AWS Prescriptive Guidance, Migration strategies).
- Idle uygulamalar: aynı dönemde %5 ile %20 arasında kalanlar.
Bu eşikler envanter çalışmasının en değerli çıktısı. Tipik bir kurumsal veri merkezinde sunucuların azımsanmayacak bir bölümü bu iki kategoriye giriyor ve hiç kimse onları kapatmaya cesaret edemiyor, çünkü ne işe yaradığı bilinmiyor.
Yaklaşım şu: kapatmak yerine önce ağ erişimini kısıtlayın. Otuz gün boyunca kimse şikâyet etmiyorsa kapatın. Kapatma kararını göç projesinin içine gömmek, kimsenin itiraz etmeyeceği tek zaman penceresi.
Keşif araçları: adları ve 2026'daki durumları
Envanter çıkarmadan planlama yapılamıyor ve her bulut sağlayıcının kendi aracı var. Bir de güncel bir değişiklik:
- AWS: Migration Acceleration Program (MAP) üç fazlı çerçeve sunuyor — Assess, Mobilize, Migrate & Modernize. Keşif tarafında uzun süredir kullanılan AWS Application Discovery Service için dokümanın başında açık bir uyarı var: servis yeni müşterilere kapalı ve alternatif olarak AWS Transform gösteriliyor. Rehost otomasyonu için AWS'nin bugün listelediği araçlar AWS Transform MGN, Cloud Migration Factory Solution ve VM Import/Export.
- Azure: Azure Migrate; kendi tanımıyla Azure'a göçe karar vermenize, planlamanıza ve yürütmenize yardım eden ücretsiz bir servis. Fazlar Decide, Plan, Execute. Bileşenler: Azure Migrate appliance, Azure Migrate Collector (hava boşluklu ve kısıtlı ağlarda snapshot keşfi için) ve Azure Copilot migration agent (önizleme). Klasik deneyim "Azure Migrate Classic" olarak ayrılmış durumda.
- Google Cloud: Migration Center; varlık keşfi (sunucular ve SQL Server, MySQL, PostgreSQL veritabanları), altyapı değerlendirmesi, TCO raporlaması, ağ bağımlılık analizi ve göç planlaması (bkz. Google Cloud, Migration Center).
Üç aracın da ortak zayıf noktası aynı: ağ bağımlılıklarını bulmakta iyiler, iş bağımlılıklarını bulmakta değiller. "Bu sunucu ayın son günü finans ekibinin elle çalıştırdığı bir rapor üretiyor" bilgisi hiçbir keşif aracında görünmüyor. Envanterin yanına insan mülakatı koyun.
Türkiye kısıtı: birincil ve ikincil sistem yurt içinde olmak zorunda
Bu, bulut migrasyon planını en çok değiştiren madde ve çoğu proje bunu geç fark ediyor.
Bankacılık. 15 Mart 2020 tarihli 31069 sayılı Resmî Gazete'de yayımlanan "Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik"in 25. maddesi net: bankaların birincil ve ikincil sistemlerini yurt içinde bulundurmaları zorunlu. Aynı maddenin ikinci fıkrası kapsamı genişletiyor: birincil sistemlerin kaçıncı yedeği olduğuna bakılmaksızın her türlü yedeği ikincil sistem sayılıyor ve aynı zorunluluğa tabi.
Beşinci fıkra bulut için doğrudan yazılmış: birincil veya ikincil sistemler kapsamındaki bir faaliyet için dış hizmet ya da bulut bilişim hizmeti alınması hâlinde, dış hizmet sağlayıcının kullandığı bilgi sistemleri ve bunların yedekleri de birincil ve ikincil sistemler kapsamında ele alınıyor ve yurt içinde bulunduruluyor. Yani "bulut sağlayıcının sorumluluğu" argümanı burada işlemiyor.
Sermaye piyasası. Burada 2025'te bir değişiklik oldu ve eski dokümanlarla çalışan ekipler yanlış tebliğe bakıyor. Bilgi Sistemleri Yönetimi Tebliği (VII-128.9) yürürlükten kalktı; yerine 13 Mart 2025 tarihli 32840 sayılı Resmî Gazete'de yayımlanan Bilgi Sistemleri Yönetimine İlişkin Usul ve Esaslar Tebliği (VII-128.10) geldi ve 30 Haziran 2025'te yürürlüğe girdi.
Yeni tebliğin 27. maddesi aynı zorunluluğu taşıyor ve bir şart ekliyor: ikincil sistemin yeri, doğal ve çevresel felaketlere karşı birincil sistemle aynı risklere maruz kalmayacak şekilde seçilecek. Aynı madde her süreç için kabul edilebilir kesinti süresi (RTO) ve kabul edilebilir azami veri kaybı (RPO) değerlerinin belirlenmesini istiyor.
Bu iki düzenleme, "her şeyi buluta taşıyalım" planını baştan ikiye bölüyor. Düzenlemeye tabi iş yüklerini yurt içi bölgeye ya da yurt içi veri merkezine yerleştirin; geri kalanı için bölge kısıtı yok. Mimariyi bu ayrımı taşıyacak şekilde kurun, çünkü sonradan bölge değiştirmek veri taşıma ve kesinti demek.
Yurt dışına veri aktarımı: 2024'te değişen rejim
Yurt içi bölge kullanmıyorsanız KVKK'nın 9. maddesi devreye giriyor ve bu madde 12 Mart 2024 tarihli 32487 sayılı Resmî Gazete'de yayımlanan 7499 sayılı Kanun'la değişti; 1 Haziran 2024'te yürürlüğe girdi. Rejim üç kademeli:
- Yeterlilik kararı. Kurul'un yeterli koruma bulunduğunu ilan ettiği ülke, sektör veya uluslararası kuruluşa aktarım. Kararlar en geç dört yılda bir gözden geçiriliyor.
- Uygun güvenceler. Yeterlilik kararı yoksa dört yoldan biri: kamu kurumları arası anlaşma (Kurul izniyle), bağlayıcı şirket kuralları (Kurul onaylı, ek izin gerektirmiyor), Kurul'un yayımladığı standart sözleşme (ek izin gerektirmiyor ama bildirim zorunlu), veya yazılı taahhütname (Kurul izniyle).
- Arızi haller. Açık rıza, sözleşmenin ifası, üstün kamu yararı gibi; düzenli olmayan ve süreklilik göstermeyen aktarımlar için.
Operasyonel olarak en kritik ayrıntı 9/5'te: standart sözleşme, imzalanmasından itibaren beş iş günü içinde Kurul'a bildirilmek zorunda (bkz. KVKK, Yurt Dışına Aktarım). Bildirim fiziki olarak, KEP üzerinden veya Standart Sözleşme Bildirim Modülü ile yapılabiliyor. Ayrıca Kurul, standart sözleşme metinlerinde isteğe bağlı veya alternatif içerik dışında ekleme, çıkarma veya değişiklik yapılamayacağını belirtiyor.
Sık yapılan hata: bulut sağlayıcısıyla imzalanan AB Standart Sözleşme Maddeleri'nin (SCC) KVKK için de yeterli olduğunu varsaymak. KVKK'nın standart sözleşmesi ayrı bir metin ve ayrıca imzalanıp bildirilmesi gerekiyor.
Maliyet: göç sonrası faturanın neden beklenenden yüksek geldiği
Üç kalem tahminlerde eksik kalıyor:
- Veri çıkış (egress) ücreti. Buluta veri koymak ucuz, çıkarmak pahalı. Yurt içinde kalan bir sistemle sürekli veri alışverişi yapan bir uygulamayı taşıdığınızda bu kalem sürpriz üretiyor. Göçü uygulama grubu bazında planlayın; birbiriyle çok konuşan sistemleri aynı tarafta tutun.
- Boyutlandırmanın bire bir kopyalanması. Fiziksel sunucular en yüksek yüke göre alınmıştı; bulutta aynı boyutu kiralamak, ödemeniz gereken en pahalı seçenek. Rehost sonrası ilk otuz gün ölçün ve küçültün.
- İkincil sistem. Düzenlemeye tabiyseniz felaket kurtarma ortamı isteğe bağlı değil; maliyeti baştan hesaba katın.
Göç projesinin efor tarafı için bir bant çıkarmak isterseniz proje fiyat hesaplama aracı işinizi görür.
Sırada ne var
Envanterinizi açın ve iki sütun ekleyin: "son 90 günün ortalama CPU kullanımı" ve "düzenlemeye tabi mi". Birinci sütun %5'in altındaki satırlar taşınmayacak, kapatılacak. İkinci sütunda evet yazan satırlar yurt içi bölgeye gidecek. Geriye kalan liste, gerçek göç kapsamınız; genellikle başlangıçta sanılanın epey altında.
Konteyner ve dağıtım tarafındaki pratik için Docker ile üretime dağıtım yazısına, mimari kararı için mikroservis mi monolit mi yazısına bakabilirsiniz. Bulut ve altyapı tarafındaki çalışma biçimimiz DevOps ve altyapı ile AWS danışmanlığı sayfalarında; görüşme için iletişim sayfası uygun yer.
Atıflar 25 Eylül 2026 tarihinde birincil kaynaklardan doğrulanmıştır: AWS Prescriptive Guidance migration strategies sayfası (7 Rs, zombie/idle tanımları), AWS Application Discovery Service dokümanındaki kapanış uyarısı, AWS Migration Acceleration Program sayfası, Microsoft Azure Migrate genel bakış, Google Cloud Migration Center genel bakış, KVKK Yurt Dışına Aktarım sayfası ve 6698 sayılı Kanun md. 9'un 7499 sayılı Kanun ile değişik hâli, BDDK "Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik" (RG 15.03.2020, sayı 31069) md. 25 ve SPK Bilgi Sistemleri Yönetimine İlişkin Usul ve Esaslar Tebliği VII-128.10 (RG 13.03.2025, sayı 32840) md. 27. Mevzuat değişebilir; plan yapmadan önce güncel metni teyit edin. Bu yazı hukuki görüş yerine geçmez.
