Buluta geçiş maliyeti, sağlayıcının aylık sunucu fiyatından çok daha fazlasıdır: taşıma işçiliği, geçiş süresince iki ortamın birlikte çalışması, lisans değişiklikleri, veri çıkış ücretleri, güvenlik yapılandırması ve geçişten sonra harcamayı yönetecek emek de bu hesaba girer. Doğru bütçe, her uygulama için ayrı bir taşıma stratejisi seçilerek ve bugünkü toplam sahip olma maliyetiyle yan yana konarak kurulur.
Şirketler buluta geçişi genellikle nasıl hesaplıyor?
Tipik senaryo şöyle başlar: sunucu odasındaki donanımın ömrü dolmak üzeredir, yenileme teklifi yüksek gelmiştir ve biri "buluta geçsek aylık şu kadar tutar" diye bir sağlayıcının fiyat hesaplayıcısından ekran görüntüsü paylaşır. Karar bu tek rakam üzerinden verilir.
Birkaç ay sonra tablo farklıdır. Yedekler ayrı ücretlendirilir, dışarıya aktarılan veri faturaya eklenir, eski ERP'nin lisansı bulutta farklı bir modele geçer, eski sunucular "ne olur ne olmaz" diye kapatılmaz ve iki ortam birlikte ödenir. Üstelik taşınan sanal makineler, şirket içindeki boyutlarıyla bire bir kopyalandığı için ihtiyaçtan büyüktür.
Sorun bulutun pahalı olması değil; karşılaştırmanın yanlış kurulmasıdır. Bugünkü sunucu odasının gerçek maliyeti (elektrik, soğutma, yedekleme, bakım, personel zamanı, donanım yenileme) çoğu zaman hesaplanmamıştır; bulut tarafında ise yalnızca en görünür kalem hesaba katılmıştır.
Yanlış hesabın maliyeti
Bulut harcamasını yönetmek büyük kurumlar için bile kolay değil:
Flexera'nın 750'den fazla bulut karar vericisiyle yaptığı araştırmaya göre boşa giden bulut harcaması oranı beş yıl sonra ilk kez artarak %29'a çıktı; bulut harcamasını yönetmek katılımcıların %85'i için başlıca zorluk. (Flexera 2026 State of the Cloud Report)
Aynı raporda kurumların %63'ünün harcamayı izlemek için ayrı bir FinOps ekibi kurduğu görülüyor. Çoğu KOBİ'nin böyle bir ekibi yok; bu yüzden disiplinin geçiş tasarımına baştan yerleştirilmesi gerekiyor. Boşa giden harcamanın kaynağı çoğu zaman teknik değil, idari bir boşluktur: kimsenin sahiplenmediği test sunucuları, projesi biten ama kapatılmayan ortamlar ve kimin açtığı bilinmeyen depolama alanları.
Türkiye'de bulut kullanımı hâlâ ölçeğe göre büyük farklılık gösteriyor. TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması, 2026 verisine göre girişimlerin %20,2'si ücretli bulut bilişim hizmeti kullanıyor; bu oran 250 ve üzeri çalışanı olanlarda %57,0, 10-49 çalışanı olanlarda ise %16,7. Yani küçük işletmelerin çoğu bu kararı ilk kez verecek ve deneyimi olmadan bütçe kuracak.
Maliyetin bir de güvenlik tarafı var. Verizon 2026 Data Breach Investigations Report verisine göre üçüncü taraf kurumların yalnızca %23'ü bulut hesaplarındaki eksik ya da zayıf çok faktörlü kimlik doğrulama sorununu tamamen gidermiş. Aceleyle yapılan bir taşımada yanlış yapılandırılmış bir erişim, tasarruf edilen tutarın çok üzerinde bir olay maliyeti doğurabilir. Taşınan sistemlere ofis ağındaymış gibi güvenmek yerine her erişimi yeniden doğrulayan zero trust yaklaşımı bu riski baştan daraltır.
Buluta geçiş maliyetinde faturada görünmeyen kalemler
| Kalem | Neden atlanır | Ne yapılmalı |
|---|---|---|
| Taşıma işçiliği | "Kopyala-yapıştır" sanılır | Uygulama bazında iş kırılımı çıkarın |
| Çift çalışma dönemi | Eski sistem hemen kapanacak varsayılır | Paralel çalışma süresini takvime ve bütçeye yazın |
| Lisans değişikliği | Mevcut lisansın bulutta geçerli olduğu varsayılır | Her yazılımın bulut lisans koşulunu kontrol edin |
| Veri çıkışı ve yedek | Fiyat hesaplayıcıda ayrı satırdır | Aylık veri trafiğini ve yedek saklama süresini ölçün |
| Aşırı boyutlandırma | Sunucular bire bir kopyalanır | Gerçek kullanım verisine göre boyutlandırın |
| Güvenlik ve izleme | "Sağlayıcı hallediyor" sanılır | Paylaşılan sorumluluk modelini yazılı hale getirin |
| Bağlantı ve ağ | İnternet hattı yeterli sanılır | Şube ve üretim tarafının hat ihtiyacını hesaplayın |
| Ekip eğitimi ve işletme | Geçişten sonra kimin yöneteceği belirsizdir | Aylık işletme emeğini bütçeye koyun |
Bütçeyi doğru kurmanın 6 adımı
- Bugünün gerçek maliyetini çıkarın. Donanım amortismanı, yenileme takvimi, elektrik ve soğutma, yedekleme ortamı, bakım sözleşmeleri, lisanslar ve BT personelinin bu sistemlere ayırdığı zaman. Karşılaştırmanın bir tarafı bu olmalı.
- Uygulama envanteri yapın ve her birine strateji seçin. Her uygulama için karar farklıdır: olduğu gibi taşı (rehost), küçük uyarlamayla taşı (replatform), yeniden tasarla (refactor), hazır bulut hizmetiyle değiştir (repurchase), yerinde bırak (retain) ya da kapat (retire). Hiç kullanılmayan uygulamaları taşımamak en hızlı tasarruftur.
- Gerçek kullanıma göre boyutlandırın. İşlemci, bellek ve disk kullanımını birkaç haftalık veriyle ölçün. Yoğun dönemler için otomatik ölçeklendirmeyi, sürekli çalışan iş yükleri için rezervasyon seçeneklerini değerlendirin.
- Veri konumu ve mevzuatı baştan netleştirin. Kişisel veri işliyorsanız verinin hangi ülkede tutulacağı KVKK uyum süreci açısından önemlidir: 2024'te değişen kanunun 9. maddesi yurt dışına aktarımı yeterlilik kararı, uygun güvenceler (örneğin standart sözleşme) ve sınırlı istisnalara bağlıyor. Bu, sağlayıcı ve bölge seçimini doğrudan etkiler. Standart sözleşme ve bildirim adımlarını KVKK yurt dışına veri aktarımı rehberinde anlattık.
- Güvenliği geçişin parçası yapın. Yönetici hesaplarında MFA ve güçlü parola politikası, en az yetki ilkesi, şifreleme, kayıt tutma ve yedeklerin ayrı hesapta saklanması taşıma planında yer almalı; sonradan eklenmemeli. Yedekleme tarafını fidye yazılımına karşı 3-2-1 yedekleme yazımızda anlattık.
- Geçişten sonrası için harcama disiplini kurun. Etiketleme, aylık bütçe uyarıları, kullanılmayan kaynakların düzenli temizliği ve her ay bir kez yapılan maliyet gözden geçirmesi. Ayrı bir FinOps ekibi olmayan KOBİ için bu, bir kişinin takvimindeki aylık bir toplantıdır.
Her şeyi buluta taşımak zorunda değilsiniz. Üretim hattına bağlı sistemler, düşük gecikme isteyen uygulamalar ya da lisansı buluta uygun olmayan yazılımlar için hibrit bir yapı çoğu zaman en dengeli sonuçtur.
Hangi iş yükünün buluta daha uygun olduğunu anlamak için kaba bir ayrım işe yarar. Kullanımı mevsime ya da kampanyaya göre dalgalanan sistemler, uzaktan çalışan ekiplerin eriştiği e-posta ve dosya hizmetleri, yedekleme ve felaket kurtarma ortamları bulutta genellikle avantajlıdır. Uygulama sayısı arttıkça erişimi tek kimlikle yönetmek önem kazanır; tek oturum açma (SSO) yazımız bu tarafı anlatıyor. Buna karşılık yıl boyunca sabit ve yüksek kapasiteyle çalışan, büyük hacimli veriyi sürekli dışarıya aktaran ya da fabrikadaki makinelerle milisaniye düzeyinde konuşması gereken sistemlerde hesap daha dikkatli yapılmalıdır. Bu ayrımı her uygulama için yazılı hale getirmek, tartışmayı "bulut mu, değil mi" sorusundan "hangi sistem, hangi gerekçeyle" sorusuna taşır.
Geçişin ilk adımı çoğu zaman e-postadır; kutu envanterinden MX değişikliğine kadar adımları e-posta taşıma rehberinde anlattık. Kullanıcı başı fiyatın dışında kalan kalemleri ise kurumsal e-posta fiyatları yazısında topladık.
Buluta taşınan ilk iş yükü çoğu zaman ofisteki dosya sunucusudur. Bu geçişin klasör, yetki ve kesim planını dosya sunucusu yerine bulut rehberinde adım adım anlattık.
Digital Bridge'de bu işi nasıl yapıyoruz?
Buluta geçişi bir "sunucu kiralama" işi olarak değil, maliyet, güvenlik ve süreklilik projesi olarak yönetiyoruz:
- Envanter ve maliyet karşılaştırması. Bulut geçiş ve altyapı danışmanlığı kapsamında sunucularınızı, uygulamalarınızı ve gerçek kullanım verilerini çıkarıyor, bugünkü toplam maliyetle bulut senaryolarını aynı tabloda karşılaştırıyoruz. Sağlayıcı seçiminde sertifika, veri konumu ve olay bildirimi sorularını tedarikçi bilgi güvenliği değerlendirmesi yöntemiyle soruyoruz.
- Uygulama bazlı strateji. Her uygulama için taşı, uyarla, değiştir, bırak ya da kapat kararını gerekçesiyle yazıyoruz. ERP gibi kritik sistemlerde ERP yazılımı ekibimizle lisans ve entegrasyon etkisini birlikte değerlendiriyoruz.
- Entegrasyonları koruyoruz. Taşınan sistemlerin muhasebe, e-Fatura, üretim ya da CRM ile API tabanlı bağlantılarını sistem entegrasyonları kapsamında planlıyor, paralel çalışma döneminde veri tutarlılığını izliyoruz.
- Güvenlik ve KVKK. Kimlik, yetki ve şifreleme yapılandırmasını siber güvenlik danışmanlığı ile, veri konumu ve yurt dışı aktarım değerlendirmesini KVKK uyum danışmanlığı ile ele alıyoruz. Bulut sağlayıcısıyla imzalanacak veri işleyen sözleşmesinin maddelerini de bu aşamada netleştiriyoruz.
- Aşamalı geçiş. Önce düşük riskli bir iş yüküyle başlıyor, ölçülen maliyeti tahminle karşılaştırıyor ve kalan planı bu gerçek veriye göre güncelliyoruz. İnternete açılacak sistemleri canlıya almadan önce kapsamı yazılı bir sızma testiyle sınamayı öneriyoruz.
Somut bir örnek: üç sunuculu bir KOBİ
Bir üretim firmasını düşünün: bir dosya sunucusu, bir ERP sunucusu ve bir de artık kimsenin kullanmadığı eski bir raporlama uygulaması. Envanter sonrası karar şöyle çıkabilir: eski raporlama uygulaması kapatılır ve verisi arşivlenir; dosya sunucusu kurulum gerektirmeyen hazır bir kurumsal dosya yönetimi hizmetine (örneğin Smart360 ailesindeki SmartFiles dosya yönetimi) taşınır; ERP ise lisans koşulları ve fabrikadaki barkod terminalleriyle bağlantısı nedeniyle bir süre yerinde kalır, yedekleri buluta alınır. Bu yaklaşım, "her şeyi taşı" kararına göre hem daha az risklidir hem de bütçeyi gerçekten kullanılan sistemlere odaklar.
Kararın ardındaki mantığı kendi durumunuzla sınamak için KOBİ siber güvenlik kontrol listemize de göz atabilirsiniz; bulut ya da şirket içi, temel kontroller aynıdır. Veri konumu, yedekleme ve erişim konularındaki diğer yazılarımız Siber Güvenlik ve KVKK rehberimizde bir arada.
Sonraki adım
İlk adım olarak bu ay şu listeyi çıkarın: sunucu odanızdaki her sistem, onu kimin kullandığı ve son bir yılda kaç kez erişildiği. Bu liste, taşınacak, değiştirilecek ve kapatılacak sistemleri büyük ölçüde kendiliğinden ayırır. Ardından iletişim sayfamızdan bize ulaşın; envanterinizi birlikte değerlendirelim ve bugünkü maliyetinizle bulut senaryolarını yan yana koyan yazılı bir karşılaştırma hazırlayalım.