Bulut Geçişi: KOBİ’ler İçin Adım Adım Planlama Rehberi

Kısaca: Bulut geçişi, şirket içindeki sunucularda çalışan uygulama, veri ve hizmetlerin planlı bir sırayla bulut altyapısına taşınmasıdır. KOBİ’ler için başarılı bir bulut geçişi; önce envanter ve bağımlılık haritası çıkarmak, iş yüklerini az kritik olandan çok kritik olana doğru dalgalar halinde taşımak ve her iş yükü için kesinti penceresini ve geri dönüş planını önceden yazmak demektir.

Birçok işletmede bulut kararı bir donanım yenileme dönemi, sunucu odasında yaşanan bir arıza veya uzaktan çalışma ihtiyacıyla gündeme gelir. Karar hızlı alınır, ama geçiş çoğu zaman “her şeyi bir hafta sonunda taşırız” varsayımıyla planlanır. Sonuç tanıdıktır: unutulan bir bağımlılık yüzünden pazartesi sabahı açılmayan ERP, beklenenden uzun süren veri aktarımı ve geri dönüş yolu tanımlanmadığı için gece yarısı yapılan düzeltmeler.

Bu yazıda bulut geçişini bir “sunucu taşıma” işi olarak değil, yönetilen bir proje olarak ele alıyoruz: hazırlık, sıralama, kesinti ve geri dönüş kararlarını adım adım anlatıyoruz.

Bulut geçişi nedir, ne değildir?

Bulut geçişi; dosya sunucusu, e-posta, ERP, veritabanı veya özel yazılım gibi iş yüklerinin şirket içi (on-premise) ortamdan bir bulut sağlayıcısına taşınmasıdır. Her iş yükü için aynı yöntemi seçmek gerekmez. Sık kullanılan yaklaşımlar şunlardır:

• Olduğu gibi taşıma (rehost): Sanal makineyi değiştirmeden buluta taşımak. En hızlı yoldur, ancak maliyet ve performans iyileştirmesini sonraya bırakır.
• Platform değiştirme (replatform): Uygulamayı büyük ölçüde korurken veritabanı gibi bir bileşeni yönetilen bir bulut hizmetine geçirmek.
• Yeniden düzenleme (refactor): Uygulamayı buluta özgü hizmetlerden yararlanacak şekilde değiştirmek. Daha fazla emek ister, uzun vadede esneklik kazandırır.
• Değiştirme veya emekliye ayırma: Bazı sistemler hiç taşınmaz; yerine hazır bir SaaS ürünü alınır ya da artık kullanılmıyorsa kapatılır.

Bulut geçişi tek başına bir maliyet düşürme garantisi değildir. Doğru boyutlandırılmadan taşınan sunucular bulutta da gereğinden pahalı çalışabilir. Bu yüzden karar iş yükü bazında verilmelidir. ERP’nizi bulutta mı yoksa kendi sunucunuzda mı çalıştıracağınızı tartıyorsanız bulut ERP ile on-premise ERP karşılaştırmamız iyi bir başlangıç noktasıdır.

Geçiş öncesi hazırlık: envanter, hedef ve ekip

1. Envanteri çıkarın

Hangi sunucuların, uygulamaların, veritabanlarının ve zamanlanmış görevlerin çalıştığını, her birinin sahibini ve iş için ne kadar kritik olduğunu listeleyin. Lisans koşullarını da not edin; bazı yazılımların lisansı bulutta farklı kurallara tabi olabilir. Güncel bir altyapı resminiz yoksa önce bir BT altyapı denetimi yapmak, geçiş sırasında sürpriz çıkma ihtimalini azaltır.

2. Her iş yükü için hedefi yazın

“Buluta taşıyalım” tek başına bir hedef değildir. Her iş yükü için beklentiyi somutlaştırın: güvenli uzaktan erişim, donanım yenileme maliyetinden kaçınma, yedekleme ve felaket kurtarmayı kolaylaştırma veya dönemsel yükte ölçeklenebilmek. Hedef netleşince yöntem seçimi ve başarı ölçütü de netleşir.

3. Ekip yetkinliğini değerlendirin

Bulut ortamını kim yönetecek? Kimlik yönetimi, ağ, yedekleme ve maliyet takibi konusunda ekipte deneyim yoksa bu boşluğu eğitimle veya dış destekle kapatın. Microsoft’un Cloud Adoption Framework geçiş planlama rehberi de geçişe başlamadan önce ekip becerilerinin değerlendirilmesini ve deneyim eksikse dış uzmanlık alınmasını öneriyor.

Bulut geçişi planı: bağımlılıklar, dalgalar ve geri dönüş

4. Bağımlılık haritasını çizin

Uygulamalar birbirine bağlıdır: ERP bir veritabanına, raporlama aracı ERP’ye, depo etiket yazıcısı yerel bir sunucuya bağlı olabilir. Doğrudan ve düşük gecikmeyle haberleşen bileşenleri aynı grupta taşıyın. Bir bağımlılığın ne kadar kritik olduğundan emin değilseniz bileşenleri birlikte gruplayın; grubu sonradan ayırmak her zaman mümkündür, ama yanlışlıkla bölünmüş bir sistem geçiş günü durur.

5. İş yüklerini dalgalara bölün

İlk dalgaya daha az kritik ve bağımsız iş yüklerini koyun: test ortamları, iç araçlar, arşiv dosyaları. Ekip süreci bu işlerde denedikten sonra kritik sistemleri sonraki dalgalara alın. Üretim ortamından önce test ortamını taşımak, yapılandırmayı ve performansı kullanıcıları etkilemeden doğrulamanın en güvenli yoludur.

6. Kesinti penceresini seçin

Her iş yükü için kabul edilebilir kesinti süresini iş birimiyle birlikte yazın. Planlı bir kesintiye dayanabilen sistemlerde kesintili geçiş daha basit ve hızlıdır. Müşteriye dönük ya da sürekli işlem gören sistemlerde ise verinin önceden eşitlendiği ve yalnızca kısa bir geçiş anı gerektiren yöntem tercih edilmelidir. Ay sonu kapanışı, kampanya dönemi veya sayım günü gibi kritik tarihleri geçiş takviminden çıkarın.

7. Geri dönüş planını önceden yazın

Geçişe başlamadan “başarısız” sayılacak durumu tanımlayın: açılmayan uygulama, kabul edilemez yanıt süresi, eksik veri veya bir güvenlik bulgusu. Bu durumda eski ortama nasıl ve kimin kararıyla dönüleceğini adım adım yazın ve test ortamında deneyin. Şirket içi sunucuları, geçiş doğrulanıp kullanıcılar onay verene kadar kapatmayın.

Geçiş günü ve sonrası

• Son yedeği alın ve geri yüklemeyi deneyin: Önemli olan yedeğin varlığı değil, ondan gerçekten geri dönebilmektir. Felaket kurtarma planı rehberimiz RPO ve RTO hedeflerini nasıl belirleyeceğinizi anlatıyor.
• Kabul testlerini kullanıcılarla yapın: Muhasebe, satış ve depo ekipleri kendi günlük işlemlerini yeni ortamda denemeden geçişi tamamlanmış saymayın.
• Erişim güvenliğini sıkılaştırın: Bulut yönetim paneline ve uzaktan erişime çok faktörlü kimlik doğrulama (MFA) zorunlu olmalıdır.
• Maliyeti ilk günden izleyin: Kullanılmayan kaynakları kapatın, sunucu boyutlarını gerçek kullanıma göre düzeltin ve bütçe uyarıları tanımlayın.
• Dokümantasyonu güncelleyin: Yeni IP adresleri, erişim yolları ve sorumlular yazılı olmazsa ilk arızada zaman kaybedilir.

Sık yapılan hatalar

• Her şeyi tek seferde taşımak: Tek bir büyük geçiş, bir hatanın tüm şirketi durdurmasına yol açar.
• Bağımlılıkları varsaymak: Belgelenmemiş bir entegrasyon veya zamanlanmış görev, geçişten sonra sessizce çalışmayı bırakır.
• Veri aktarım süresini hafife almak: Büyük veritabanları ve dosya arşivleri için hat kapasitesi önceden test edilmelidir.
• Geri dönüşü planlamamak: “Sorun çıkarsa bakarız” yaklaşımı, sorun çıktığında karar verecek kimseyi bırakmaz.
• Geçişi bitti saymak: Boyutlandırma, maliyet ve güvenlik ayarları geçişten sonraki haftalarda gözden geçirilmezse bulutun faydası azalır.

Bulut geçişi kontrol listesi

• Sunucu, uygulama, veritabanı ve görev envanteri sahipleriyle birlikte hazır mı?
• Her iş yükü için hedef ve geçiş yöntemi yazıldı mı?
• Bağımlılık grupları ve geçiş dalgaları belirlendi mi?
• Kesinti pencereleri iş birimleriyle onaylandı mı, kritik tarihler takvimden çıkarıldı mı?
• Başarısızlık ölçütleri ve geri dönüş adımları yazılı ve test edildi mi?
• Geçiş sonrası güvenlik, maliyet ve dokümantasyon sorumluları belli mi?

Bulut geçişi, doğru sırayla ve geri dönüş yolu açık tutularak yapıldığında işletmeye esneklik kazandıran, kontrollü bir dönüşümdür. ÇAP Teknoloji olarak KOBİ’lerin bulut geçişini envanter ve bağımlılık analizinden geçiş dalgalarının planlanmasına, geri dönüş senaryolarından geçiş sonrası maliyet takibine kadar birlikte planlıyoruz. Danışmanlık hizmetlerimizi inceleyebilir veya mevcut altyapınızı birlikte değerlendirmek için bizimle iletişime geçebilirsiniz.

Sıkça Sorulan Sorular