Buluta Geçiş: Adım Adım Planlama, Taşıma ve Riskler

Buluta geçiş kararı çoğu zaman bir tetikleyiciyle gelir: garantisi biten sunucular, dolmak üzere olan depolama, uzaktan çalışmanın doğurduğu erişim ihtiyacı ya da tek bir BT çalışanına bağımlı kalmış bir altyapı. Doğru planlandığında bulut; esneklik, erişilebilirlik ve yönetim kolaylığı sağlar. Plansız yapıldığında ise yerel sorunları olduğu gibi buluta taşır ve üstüne beklenmedik faturalar ekler. Bu rehberde KOBİ ve orta ölçekli işletmelerde uyguladığımız geçiş yaklaşımını, karar noktaları ve sık yapılan hatalarla birlikte adım adım aktarıyoruz.

Bulut Bilişimin İşletmeye Faydaları ve Sınırları

Bulutun işletmeye sağladığı gerçek faydalar şunlardır:

• Esneklik ve ölçeklenebilirlik: Kaynaklar ihtiyaca göre artırılıp azaltılabilir; yeni bir proje için haftalarca donanım beklemek gerekmez.
• Yatırımdan işletme giderine geçiş: Sunucu, depolama ve lisans için baştan büyük yatırım yerine kullanım bazlı ödeme yapılır.
• Erişilebilirlik: Doğru güvenlik kontrolleriyle uygulamalara ve verilere farklı lokasyonlardan erişim kolaylaşır.
• Donanım yükünden kurtulma: Donanım arızası, garanti takibi, sunucu odası enerjisi ve soğutması sağlayıcıya devredilir.
• Yerleşik yedeklilik seçenekleri: Farklı bölgeler ve erişilebilirlik alanları sayesinde yüksek erişilebilirlik tasarlamak kolaylaşır.

Ancak bulutun sınırlarını da bilmek gerekir. Sürekli ve sabit yük altında çalışan bazı iş yükleri bulutta şirket içinden daha pahalıya gelebilir. Büyük dosyaları yerel ağda yoğun biçimde işleyen uygulamalar internet bağlantısına bağımlı hale gelir. Bazı eski lisans modelleri buluta taşınamayabilir. Güvenlik ise kendiliğinden gelmez: sağlayıcı altyapıyı korur, yapılandırma ve erişim yönetimi sizin sorumluluğunuzdadır. Bu paylaşılan sorumluluk modelini bulut güvenliği rehberimizde ayrıntılı ele aldık.

IaaS, PaaS, SaaS: Hangi Model Neye Uygun?

• IaaS (Altyapı Olarak Hizmet): Sanal sunucu, depolama ve ağ kiralarsınız; işletim sistemi, uygulama ve güncellemeler sizin sorumluluğunuzdadır. Mevcut sunucuları değiştirmeden taşımak için uygundur.
• PaaS (Platform Olarak Hizmet): Yönetilen veritabanı, uygulama çalıştırma ortamı veya konteyner platformu gibi hizmetler kullanırsınız; işletim sistemi ve altyapı sağlayıcının sorumluluğundadır. Kendi yazılımını geliştiren veya veritabanı yönetim yükünü azaltmak isteyen işletmeler için uygundur.
• SaaS (Yazılım Olarak Hizmet): Uygulamayı hazır bir hizmet olarak kullanırsınız: Microsoft 365, bulut tabanlı ERP ve CRM, muhasebe yazılımları. Yönetim yükü en düşük modeldir.

Pratikte çoğu işletmenin buluta geçişi SaaS ile başlar: e-posta ve dosya paylaşımı Microsoft 365'e, muhasebe bulut tabanlı bir yazılıma taşınır. Geriye kalan özel uygulamalar ve veritabanları için IaaS veya PaaS değerlendirilir. Genel kural, yönetebileceğiniz en üst seviyedeki modeli seçmektir: kendiniz yönetmek zorunda olmadığınız her katman, işletme yükünüzü ve hata olasılığını azaltır.

Geçiş Öncesi Envanter ve Hazırlık Analizi

Geçişin başarısı, taşımadan önce yapılan analizin kalitesiyle doğru orantılıdır. Hazırlık aşamasında şu bilgileri toplayın:

1. Sunucu ve uygulama envanteri: Her sunucuda hangi uygulama çalışıyor, kimin sorumluluğunda, hangi işletim sistemi ve sürümde?
2. Kaynak kullanımı: Birkaç haftalık işlemci, bellek, disk ve ağ kullanım verisi. Bulutta doğru boyutlandırma yapmanın tek güvenilir yolu budur; mevcut donanımı birebir kopyalamak genellikle gereğinden büyük ve pahalı kaynaklarla sonuçlanır.
3. Bağımlılıklar: Uygulamalar birbirleriyle, veritabanlarıyla, Active Directory ile ve dış sistemlerle nasıl haberleşiyor? Sık haberleşen sistemlerin ayrı ortamlarda kalması gecikme sorunları doğurur.
4. Lisanslar: Mevcut lisanslarınız bulutta kullanılabilir mi, yoksa yeni bir lisans modeli mi gerekir?
5. Uyum gereksinimleri: Kişisel veriler, sektörel düzenlemeler ve müşteri sözleşmeleri verinin nerede tutulacağı konusunda kısıt getiriyor mu?
6. Ağ ve bağlantı: Ofis internet bağlantınız, kullanıcıların buluttaki uygulamalara erişimini kaldırabilecek kapasitede ve yedekli mi?

Hangi iş yükleriyle başlamalı?

İlk dalgada taşınacak iş yüklerini seçerken iki ölçüte bakın: iş açısından ne kadar kritik oldukları ve teknik olarak ne kadar karmaşık oldukları. Kritikliği ve karmaşıklığı düşük olan iş yükleri, örneğin test ortamları, iç raporlama araçları veya arşiv dosya paylaşımları, hem ekibin deneyim kazanması hem de yönetimin güven duyması için ideal başlangıç noktalarıdır. Kritik ve karmaşık sistemler, örneğin ERP veritabanı, süreç ve araçlar olgunlaştıktan sonra, ayrıntılı bir test ve geri dönüş planıyla taşınmalıdır. Kritik ama basit iş yükleri ise çoğu zaman SaaS ile değiştirmeye en uygun adaylardır.

Bu analizin sonunda her iş yükü için bir karar çıkar: taşı, dönüştür, yerinde bırak veya kapat. Hangi iş yüklerinin yerelde kalmasının daha mantıklı olduğu sorusunu hibrit bulut rehberimizde ele aldık.

Geçiş Stratejileri: Rehost, Replatform, Refactor

Sektörde yaygın olarak kullanılan geçiş stratejileri şunlardır:

• Rehost (olduğu gibi taşıma): Sanal makine buluta birebir taşınır. En hızlı yoldur ve uygulamada değişiklik gerektirmez; ancak bulutun avantajlarından sınırlı ölçüde yararlanır.
• Replatform (küçük uyarlamalarla taşıma): Uygulamanın çekirdeği değişmeden bazı bileşenler yönetilen hizmetlere geçirilir; örneğin veritabanının yönetilen bir veritabanı hizmetine taşınması. Makul bir çabayla önemli bir işletme kolaylığı sağlar.
• Refactor (yeniden tasarlama): Uygulama bulut yerel mimariye göre yeniden yazılır veya parçalara ayrılır. En büyük faydayı sağlar ama en fazla zaman ve yatırımı gerektirir.
• Repurchase (SaaS ile değiştirme): Kendi barındırdığınız uygulama yerine hazır bir SaaS ürününe geçilir; örneğin şirket içi e-posta sunucusundan Microsoft 365'e.
• Retain ve Retire: Bazı sistemler bilinçli olarak yerinde bırakılır, kullanılmayanlar ise kapatılır. Envanter çalışması, kimsenin kullanmadığı sunucuları ortaya çıkarmak için de iyi bir fırsattır.

Tek bir strateji tüm iş yüklerine uymaz. Çoğu projede ilk aşamada rehost ile hızlı ilerlenir, ardından en çok maliyet veya yönetim yükü yaratan iş yükleri replatform ya da refactor ile iyileştirilir. Stratejiyi seçerken şu sorular yol gösterir: Uygulamanın ömrü ne kadar kaldı? Üreticisi bulut sürümü sunuyor mu? Değişiklik yapacak yazılım ekibiniz var mı? Taşımanın aciliyeti ne?

Örnek vermek gerekirse, şirket içi e-posta sunucusu, dosya sunucusu, bir ERP uygulaması ve birkaç yardımcı sunucusu olan bir işletmede tipik bir yol şöyle olabilir: e-posta Microsoft 365'e taşınır (repurchase), dosya paylaşımı SharePoint ve OneDrive'a aktarılır, ERP sunucusu olduğu gibi buluttaki bir sanal makineye taşınır (rehost), ilerleyen aşamada ERP veritabanı yönetilen veritabanı hizmetine geçirilir (replatform) ve kullanılmadığı anlaşılan eski sunucular kapatılır (retire).

Adım Adım Taşıma ve Kesintisiz Geçiş Planı

1. Temel bulut ortamını kurun (landing zone): Kimlik yönetimi, ağ yapısı, güvenlik politikaları, adlandırma standartları, bütçe uyarıları ve yedekleme en baştan tanımlanmalıdır. Sonradan düzeltmek, baştan doğru kurmaktan çok daha zordur.
2. Bağlantıyı kurun: Ofis ile bulut arasında siteden siteye VPN veya özel bağlantı kurun; kimlik doğrulamanın buluttaki sunucular için de sorunsuz çalıştığını doğrulayın.
3. Pilot taşıma yapın: Kritik olmayan ve bağımlılığı az bir iş yüküyle başlayın. Süreç, araçlar ve ekip bu pilotta olgunlaşır.
4. Dalgalar halinde taşıyın: Birbirine bağımlı sistemleri aynı dalgada gruplayın. Her dalga için tarih, sorumlu, geri dönüş planı ve kullanıcı bilgilendirmesi hazırlayın.
5. Veriyi önceden senkronize edin: Büyük veri setlerini önceden kopyalayıp geçiş gününe yalnızca son değişikliklerin aktarımını bırakın; böylece kesinti süresi kısalır.
6. Test edin: Kesinti penceresinden önce buluttaki kopyada uygulama testleri yapın; iş birimleri kendi süreçlerini doğrulasın.
7. Geçişi yapın ve geri dönüş yolunu açık tutun: DNS ve bağlantı ayarlarını değiştirin; sorun çıkarsa kaynak sisteme dönülebilmesi için eski sistemleri bir süre kapatmayın.
8. İzleyin ve optimize edin: Performans, erişilebilirlik ve maliyet izlemesini kalıcı hale getirin; geçişten sonraki haftalarda gerçek kullanım verisine göre kaynakları küçültün ve uzun vadeli kullanım taahhüdü seçeneklerini değerlendirin.

Kullanıcı iletişimi planın ayrılmaz bir parçasıdır. Geçiş tarihini, olası kesinti süresini, değişecek erişim adreslerini ve sorun yaşandığında kime ulaşılacağını önceden duyurmak, geçiş sabahındaki destek taleplerini belirgin biçimde azaltır. Aynı hazırlık BT ekibi için de geçerlidir: yeni yönetim portallarını, izleme araçlarını, bulut ortamındaki yetkilendirme ve yedekleme süreçlerini geçişten önce öğrenmiş bir ekip, ilk sorunlara çok daha hızlı yanıt verir.

Sık Yapılan Hatalar ve Gizli Maliyetler

• Mevcut sunucuları birebir boyutlandırmak: Şirket içinde zamanında büyük alınmış bir sunucuyu bulutta aynı boyutta çalıştırmak, gereksiz maliyetin en yaygın nedenidir.
• Kapatılmayan kaynaklar: Test için açılıp unutulan sanal makineler, bağlı olmayan diskler ve eski anlık görüntüler faturada birikir.
• Veri çıkış ücretleri: Buluttan dışarıya giden trafik çoğu sağlayıcıda ücretlidir; yoğun veri alışverişi yapan hibrit yapılarda bu kalem büyüyebilir.
• Yedekleme ve izlemeyi unutmak: Buluttaki sanal makine kendiliğinden yedeklenmez; yedekleme, güvenlik ve izleme hizmetleri ayrı maliyet kalemleridir.
• Bağlantıyı küçümsemek: Tek internet hattına bağlı bir ofis için bulut, o hat kesildiğinde tamamen erişilemez hale gelir.
• Kullanıcıları hazırlamamak: Yeni erişim yöntemleri ve oturum açma adımları anlatılmadığında destek talepleri artar, verimlilik düşer.
• Güvenliği sonraya bırakmak: Yönetim portallarına MFA olmadan erişim, internete açık bırakılmış uzak masaüstü bağlantıları ve geniş yetkili ortak hesaplar bulutta en sık karşılaşılan risklerdir.

Maliyetleri geçiş sonrasında da kontrol altında tutmanın yöntemlerini bulut maliyet optimizasyonu rehberimizde derledik.

Bulut Geçiş Ortağı Seçerken Dikkat Edilecekler

• Analizle başlıyor mu? Envanter ve kullanım verisi toplamadan fiyat veren bir teklif, boyutlandırmanın tahmine dayandığını gösterir.
• Gerekçeli bir strateji sunuyor mu? Her iş yükü için tek bir ürün değil, neden seçildiği açıklanmış bir yol önermelidir.
• Geri dönüş planı var mı? Her taşıma dalgası için sorun anında ne yapılacağı yazılı olmalıdır.
• Güvenlik ve yedekleme kapsamda mı? Kimlik yönetimi, ağ güvenliği, yedekleme ve izleme projenin parçası olmalıdır.
• Geçiş sonrası destek: Optimizasyon, izleme ve sorun giderme için sürekli bir destek modeli sunuyor mu?
• Dokümantasyon ve bilgi aktarımı: Kurulan yapı belgelenmeli, ekibiniz ortamı anlayıp yönetebilmelidir.
• Sağlayıcı bağımsızlığı: Ortağın tek bir bulut platformunu her koşulda önermesi yerine, ihtiyacınıza göre farklı seçenekleri tarafsız biçimde karşılaştırabilmesi önemlidir.

Son olarak, bulut hesaplarının ve abonelik sahipliğinin işletmenizde kalmasına dikkat edin. Yönetici erişimi ortağınıza verilebilir; ancak hesabın sahibi ve fatura muhatabı siz olmalısınız.

Sonuç

Buluta geçiş tek seferlik bir taşıma değil; doğru analiz, aşamalı uygulama ve geçiş sonrası optimizasyonla yürütülen bir dönüşüm projesidir. Bulut çözümleri hizmetimiz kapsamında envanter analizinden taşıma dalgalarına ve maliyet optimizasyonuna kadar süreci sizinle birlikte planlayabiliriz. Altyapınız için doğru yol haritasını belirlemek üzere ücretsiz bir ön görüşme ayarlayın.