Bulut Geçişinde 6R Stratejisi: Her Sunucu Buluta Gitmemeli

Rehost, replatform, refactor, repurchase, retire ve retain; 120 sunuculu örnek dağılım ve 5 yıllık TCO karşılaştırması.

Bulut geçişi projelerinin en yaygın hatası, tüm sunucuları olduğu gibi buluta taşımaktır. Bu yaklaşım ("lift and shift") bazen hızlı çözümdür ama çoğu zaman bulut faturasının yerinde işletmeden pahalı çıkmasına yol açar. 6R çerçevesi, her uygulama için doğru stratejiyi seçmenizi sağlar.

6R nedir?

Rehost (taşı): Uygulama aynen buluta taşınır. Hızlıdır, en az değişiklik gerektirir.
Replatform (platform değiştir): Küçük iyileştirmelerle taşınır; örneğin veritabanı yönetilen servise geçer.
Refactor (yeniden tasarla): Uygulama bulut yerel mimariye göre yeniden yazılır. Pahalıdır ama en büyük uzun vadeli kazancı sağlar.
Repurchase (yeniden satın al): Uygulama yerine hazır bir SaaS çözümü kullanılır (ör. e-posta, CRM).
Retire (emekli et): Kullanılmayan veya tekrar eden uygulamalar kapatılır.
Retain (yerinde tut): Gecikmeye duyarlı, düzenlemeye bağlı veya eski donanıma bağımlı uygulamalar yerinde kalır.

Örnek dağılım: 120 sunuculu bir şirket

Strateji	Sunucu sayısı	Not
Rehost	55	Hızlı dalga, 3 ayda
Replatform	25	Veritabanları yönetilen servise
Refactor	6	Müşteriye dönük kritik uygulamalar
Repurchase	10	E-posta, dosya paylaşımı, İK
Retire	14	Kullanılmayan test ve eski sistemler
Retain	10	Üretim hattı ve gümrük sistemleri

Yalnızca envanter aşamasında 14 sunucunun gereksiz olduğu görüldü; bu bile yıllık yaklaşık %11 maliyet tasarrufu demektir.

Maliyet karşılaştırması

Beş yıllık toplam sahip olma maliyetinde (TCO): Yerinde işletim 18 milyon ₺; her şeyi olduğu gibi taşıma 17,2 milyon ₺ (kazanç sınırlı); 6R stratejisi ve FinOps uygulaması 13 milyon ₺. Fark, kaynakların doğru boyutlandırılması, rezerve kapasite ve emekli edilen sistemlerden gelir. Rakamlar örnektir.

Başarı için ipuçları

Geçişten önce bulut yönetişimi (etiketleme, bütçe uyarıları, kimlik) kurulmalıdır.
Geçiş dalgalar halinde yapılmalı, her dalga sonunda maliyet ve performans ölçülmelidir.
KVKK ve sektörel düzenlemeler nedeniyle veri yerleşimi konusu en başta ele alınmalıdır.

Omurga, hazırlık analiziyle başlar ve sonuçta yönetim kuruluna sunulabilecek bir iş senaryosu raporu hazırlar.

Güvenlik ve uyum notu

Geçişte kimlik, şifreleme ve loglama kararları mimarinin en başında verilmelidir. Bulut sağlayıcısı ile müşteri arasındaki sorumluluk paylaşımı (shared responsibility) yazılı olarak netleştirilmeli; KVKK kapsamında kişisel veri içeren iş yüklerinin konumu ve yedekleri belgelenmelidir.