İş yükü envanteri, güvenli geçiş, ölçülebilir kabul
Bulut Sunucu ve Cloud Migration Hizmetleri
Buluta geçişi yalnızca sunucu kopyalama işi olarak ele almıyoruz. Uygulama, veri, kimlik, ağ, lisans, güvenlik ve operasyon bağımlılıklarını birlikte değerlendiriyor; uygun iş yüklerini bulut veya hibrit mimariye kontrollü biçimde taşıyoruz. Antalya'da yerinde keşif, Türkiye genelinde uzaktan ve hibrit proje desteği sunuyoruz.
İlk adımda hangi sunucunun nereye taşınacağını değil, neden taşınacağını netleştirelim
Mevcut sunucu ve uygulama listenizi, veri hacmini, kullanıcı sayısını, bağlantı kapasitesini ve kesinti beklentinizi paylaşın. Uygun geçiş yaklaşımını, temel riskleri ve teklif için gereken çalışma kapsamını birlikte belirleyelim.
Cloud migration nedir?
Başarılı bulut geçişi, çalışan bir sistemi yeni adreste açmaktan daha fazlasıdır
Cloud migration; kurumun uygulama ve verilerini yerel veri merkezinden, başka bir sağlayıcıdan veya eski bir barındırma ortamından hedef bulut altyapısına taşıma sürecidir. Proje; keşif, bağımlılık analizi, hedef mimari, güvenlik sınırları, veri aktarımı, test, üretim geçişi ve işletim modelini kapsar. Uygulama açılıyor olsa bile kimlik doğrulama, entegrasyon, yedekleme, izleme, performans ve iş sahibi kabulü doğrulanmadan geçiş tamamlanmış sayılmaz.
Doğru hedefi seçmek
Bulut, hibrit ve yerel altyapı farklı ihtiyaçlara cevap verir
Her iş yükünü buluta taşımak yerine, iş hedefi ve teknik kısıtlar üzerinden karar veriyoruz. NIST'in bulut rehberi de kurumların faydalarla birlikte güvenlik, taşınabilirlik, erişilebilirlik ve yönetişim risklerini değerlendirmesi gerektiğini belirtir.
Buluta taşıma
Değişken kaynak ihtiyacı, hızlı devreye alma, farklı lokasyonlardan erişim veya yönetilen hizmet kullanımı beklenen iş yüklerinde uygun olabilir. Sürekli maliyet ve veri trafiği ayrıca hesaplanır.
Hibrit mimari
Yerel sistem bağımlılığı sürerken yedek, felaket kurtarma, arşiv, test ortamı veya belirli uygulamaların bulutta çalışması gereken kurumlarda iki ortam kontrollü biçimde bağlanır.
Yerinde tutma veya sonlandırma
Donanım bağımlılığı, mevzuat, çok düşük gecikme, desteklenmeyen sürüm veya ekonomik gerekçe nedeniyle bazı iş yükleri yerinde kalabilir. İş değeri kalmayan sistemler ise taşınmadan kapatılabilir.
Karar ilkesi: Bulut otomatik olarak daha ucuz, daha güvenli veya kesintisiz değildir. Doğru hizmet modeli, güvenlik yapılandırması, yedekleme, maliyet kontrolü ve işletim sorumluluğu tasarlanmadığında risk yalnızca başka bir ortama taşınmış olur.
Geçiş stratejisi
Aynı geçiş yöntemi her uygulamaya uygulanmaz
Strateji; iş değerine, teknik borca, uyumluluğa, proje süresine ve beklenen bulut kazanımına göre iş yükü bazında seçilir.
Rehost
Sanal makine veya sunucu sınırlı değişiklikle hedef ortama taşınır. Hızlı olabilir; fakat eski mimarinin maliyet ve yönetim sorunlarını da beraberinde taşıyabilir.
Replatform
Uygulamanın temel yapısı korunurken yönetilen veri tabanı, depolama veya yedekleme gibi seçili platform hizmetleri kullanılır. Değişiklik ve kazanım dengelenir.
Refactor veya yeniden geliştirme
Uygulama ölçeklenme, dayanıklılık ve otomasyon için yeniden tasarlanır. En yüksek dönüşüm potansiyeline karşılık daha fazla analiz, test ve yazılım çalışması gerektirir.
Repurchase
Mevcut uygulama yerine uygun bir SaaS veya yeni ürün seçilir. Veri aktarımı, entegrasyonlar, kullanıcı eğitimi ve sözleşme çıkış koşulları ayrıca yönetilir.
Retain
Taşınması uygun olmayan sistem belirli süre yerinde tutulur. Hibrit bağlantı, güvenlik, yedekleme ve ne zaman yeniden değerlendirileceği açıkça kaydedilir.
Retire
Kullanılmayan, tekrarlanan veya iş değeri kalmayan sistem kontrollü biçimde kapatılır. Veri saklama ve denetim gereksinimleri tamamlanmadan kaynak silinmez.
Keşif ve ölçüm
Tekliften önce hangi bilgileri topluyoruz?
Microsoft'un Cloud Adoption Framework rehberi, kapsamlı iş yükü envanterini geçiş planının temeli olarak tanımlar. Bu nedenle yalnızca sunucu adedi değil, uygulamanın iş ve teknik ilişkileri de kaydedilir.
- İş yükü ve sahiplik
- Uygulamanın iş sahibi, kullanıcıları, kritikliği, çalışma saatleri, destek sorumlusu ve kabul kriterleri belirlenir.
- Teknik bağımlılıklar
- DNS, Active Directory, servis hesapları, sertifikalar, veri tabanları, API'ler, dosya yolları, portlar ve zamanlanmış görevler çıkarılır.
- Kapasite ve performans
- CPU, RAM, disk IOPS ve gecikme, depolama büyümesi, ağ trafiği ve tepe kullanım değerleri ölçülerek hedef kaynaklar boyutlandırılır.
- Veri ve aktarım penceresi
- Aktif veri hacmi, günlük değişim, bağlantı kapasitesi, şifreleme, son senkronizasyon ve doğrulama süresi birlikte hesaplanır.
- RPO ve RTO
- Kabul edilebilir veri kaybı ile hizmetin geri dönüş süresi belirlenir; yedekleme, replikasyon, bölge ve rollback tasarımı bu hedeflere bağlanır.
- Maliyet ve lisans
- Mevcut sözleşmeler, işletim sistemi ve veri tabanı lisansları, bulut kaynakları, trafik, log, güvenlik, destek ve yönetim maliyeti birlikte değerlendirilir.
Uygulama süreci
Keşiften üretim geçişine nasıl ilerliyoruz?
- 01
İş hedefi ve kapsam
Maliyet, yenileme, ölçeklenme, uzaktan erişim, felaket kurtarma veya veri merkezi çıkışı gibi projenin gerçek nedeni ve başarı ölçütü belirlenir.
- 02
Envanter ve bağımlılık haritası
Sunucular, uygulamalar, veri, kullanıcılar, entegrasyonlar, ağ akışları, lisanslar, iş sahipleri ve destek sınırları tek kayıt altında toplanır.
- 03
Hedef mimari ve landing zone
Hesap veya abonelik yapısı, kimlik, yetki, ağ, DNS, güvenlik politikaları, loglama, bütçe ve kaynak etiketleri iş yükü gelmeden hazırlanır.
- 04
Pilot ve prova
Düşük riskli veya temsil gücü yüksek bir iş yüküyle aktarım, performans, kimlik, entegrasyon, yedekleme ve işletim adımları test edilir.
- 05
Veri senkronizasyonu ve cutover
Son veri aktarımı, yazma işlemlerinin durdurulması, DNS veya trafik değişikliği, sorumlular ve iletişim akışı onaylı bakım penceresinde yürütülür.
- 06
Doğrulama ve iş sahibi kabulü
Veri bütünlüğü, kimlik doğrulama, kritik işlemler, entegrasyonlar, performans, loglar, alarmlar, yedekleme ve geri yükleme kontrol edilir.
- 07
İzleme, optimizasyon ve kontrollü kapatma
İlk kullanım eğilimi izlenir, gereksiz kaynaklar düzeltilir ve kaynak ortam ancak kabul ile geri dönüş süresi tamamlandıktan sonra kapatılır.
Güvenli temel
İş yükünden önce kimlik, ağ, log ve maliyet sınırlarını kuruyoruz
Hazırlıksız açılan bulut hesabı; dağınık yetki, izlenemeyen maliyet ve yanlış ağ kuralları üretir. Hedef ortamın temel güvenlik ve yönetişim yapısı taşıma başlamadan önce test edilir.
- Kurumsal kimlik, çok faktörlü doğrulama ve en az yetki rolleri
- Üretim, test ve yönetim ortamlarının hesap, abonelik veya proje ayrımı
- VPC veya VNet, subnet, route, firewall, VPN ve özel bağlantı tasarımı
- Merkezi log, zaman senkronizasyonu, alarm ve olay sorumluları
- Şifreleme anahtarları, secrets yönetimi ve veri sınıflandırması
- Kaynak etiketleri, bütçe eşikleri, maliyet uyarıları ve yaşam döngüsü
- Yedeklerin ayrı hesap veya hedefte tutulması ve geri yükleme testi
- Yönetim erişiminin kayıtlı, sınırlı ve gerektiğinde onaylı olması
Paylaşılan sorumluluk: Sağlayıcının veri merkezini ve platformu koruması; müşteri kimliklerinin, verisinin, ağ kurallarının, uygulamasının ve yapılandırmasının otomatik olarak güvenli olduğu anlamına gelmez.
Cutover ve rollback
Üretim geçişinden önce geri dönüş kararını yazılı hale getiriyoruz
Microsoft'un migration planlama rehberi, başarısız geçişin ne olduğunun ve rollback prosedürünün üretim adımından önce tanımlanmasını önerir. Karar yalnızca teknik ekibe bırakılmaz; uygulama sahibi ve operasyon sorumluları da kabul ölçütlerini onaylar.
Geçiş öncesi kontrol
Kaynak ortamın sağlığı, son yedek, replikasyon, bakım penceresi, sorumlular ve kullanıcı iletişimi doğrulanır.
- Pilot veya prova sonucu
- Son senkronizasyon süresi
- Başarı ve başarısızlık eşikleri
- Rollback için son karar saati
Geçiş sonrası kabul
Servisin açılmasıyla yetinilmez. Veri bütünlüğü, iş akışları, performans, güvenlik, yedek ve izleme sonuçları kayıt altına alınır.
- Uygulama sahibi onayı
- Dosya, kayıt veya checksum doğrulaması
- Alarm ve yedekleme kontrolü
- Kaynak ortamın kontrollü kapatılması
Kaynak ortam ve veri hazırlığı
Geçiş planı, mevcut altyapının gerçek durumuyla başlar
Sunucu adı ve disk kapasitesi tek başına yeterli değildir. Uygulamanın hangi veriye, kimliğe, porta, servise ve kullanıcı grubuna bağlı olduğu; verinin ne hızla değiştiği ve hangi sürede doğrulanabileceği birlikte incelenir.
Toplam maliyet
Bulut bütçesi, yalnızca sanal makine fiyatından oluşmaz
Kaynak tüketimi
CPU ve RAM çalışma süresi, disk türü, IOPS, snapshot, yedek, veri tabanı, yük dengeleme ve yüksek erişilebilirlik seçimi aylık maliyeti belirler.
Ağ ve veri trafiği
İnternet çıkışı, bölgeler arası trafik, VPN veya özel bağlantı ile büyük veri aktarımları ayrıca hesaplanır. Uygulamanın trafik yönü bilinmeden sağlıklı tahmin yapılamaz.
İşletim ve güvenlik
Log saklama, güvenlik araçları, lisans, destek paketi, izleme, yama, yedekleme ve teknik yönetim işçiliği toplam sahip olma maliyetine eklenir.
Geçişten sonra kaynak boyutları ve kullanım saatleri gerçek veriye göre gözden geçirilir. Bütçe alarmı, etiketleme ve sorumlu ekip tanımlanmadan açılan kaynaklar zaman içinde görünmeyen maliyet oluşturabilir.
Teslim ve kabul
Proje sonunda hangi kayıtlar teslim edilir?
Teslimat listesi seçilen sağlayıcıya, iş yüküne ve hizmet kapsamına göre uyarlanır. Kapsam dışında kalan lisans, uygulama değişikliği veya yönetilen hizmetler teklifte açıkça belirtilir.
Envanterİş yükleri, sahipler, bağımlılıklar ve kritik sınıflar
Hedef mimariHesap, kimlik, ağ, kaynak, güvenlik ve yedek yapısı
Geçiş planıDalga, bakım penceresi, sorumlular, cutover ve rollback
Kabul kayıtlarıVeri, işlev, performans, entegrasyon ve iş sahibi onayı
İşletim planıİzleme, alarm, yedekleme, maliyet ve değişiklik sorumluları
Kaynak listesiHizmetler, sürümler, lisanslar, etiketler ve yenilemeler
Kurum tipine göre öncelik
Cloud migration planı işletmenin çalışma biçimine göre değişir
- Küçük ve orta ölçekli işletme
- Basit yönetim, öngörülebilir maliyet, güvenli uzaktan erişim, yedekleme ve gerektiğinde hibrit çalışma önceliklidir. Gereksiz platform karmaşıklığından kaçınılır.
- Kurumsal ve çok şubeli yapı
- Merkezi kimlik, ağ bağlantıları, rol ayrımı, politika, log, maliyet merkezi, değişiklik yönetimi ve geçiş dalgaları daha ayrıntılı planlanır.
- Otel ve turizm tesisi
- PMS, POS, rezervasyon, muhasebe ve saha uygulamalarında sezon yoğunluğu, 7/24 çalışma, internet yedekliliği ve bakım penceresi dikkate alınır.
- Üretim ve lojistik
- ERP, depo, üretim terminali ve uzak saha bağlantılarında düşük gecikme, yerel devamlılık ve BT/OT sınırları nedeniyle hibrit mimari gerekebilir.
- Yazılım ve e-ticaret ekibi
- Test ve üretim ayrımı, otomasyon, ölçeklenme, veri tabanı, CDN, gizli bilgi yönetimi ve sürüm geri alma süreçleri hedef mimariyi belirler.
- Veri merkezi yenileyen kurum
- Donanım garanti bitişi veya lokasyon değişikliği; iş yüklerini kapatma, taşıma, modernleştirme ve yerinde tutma kararlarını birlikte değerlendirmek için fırsat oluşturur.
Sık sorulan sorular
Bulut sunucu ve cloud migration hakkında merak edilenler
Cloud migration hizmeti hangi çalışmaları kapsar?
Kapsam; mevcut iş yüklerinin ve bağımlılıkların çıkarılması, uygun geçiş stratejisinin seçilmesi, hedef bulut veya hibrit mimarinin hazırlanması, kimlik ve ağ tasarımı, veri aktarımı, pilot test, üretim geçişi, geri dönüş planı, iş sahibi kabulü, izleme ve dokümantasyonu içerir. Uygulama modernizasyonu, lisans ve yönetilen hizmet kapsamı projeye göre ayrıca tanımlanır.
Her sunucu ve uygulama buluta taşınmalı mıdır?
Hayır. Donanım anahtarına, çok düşük gecikmeye, yerel üretim sistemine, desteklenmeyen işletim sistemine veya özel lisans modeline bağlı iş yükleri yerinde kalabilir. İş değeri düşük sistemler kapatılabilir; bazı uygulamalar hizmet olarak yazılımla değiştirilebilir. Her iş yükü için taşıma, modernleştirme, değiştirme, yerinde tutma veya sonlandırma kararı ayrı verilmelidir.
Rehost, replatform ve refactor arasındaki fark nedir?
Rehost, iş yükünü sınırlı değişiklikle yeni ortama taşır. Replatform, yönetilen veri tabanı veya depolama gibi bazı platform hizmetlerinden yararlanmak için kontrollü değişiklik yapar. Refactor ise uygulamayı bulutun ölçeklenme ve dayanıklılık özelliklerinden daha fazla yararlanacak şekilde yeniden tasarlar. Maliyet, süre, risk ve beklenen kazanım birlikte değerlendirilir.
Bulut geçişinde hizmet kesintisi olur mu?
Kesinti; uygulama mimarisi, veri değişim hızı, replikasyon yöntemi, DNS, kimlik ve entegrasyon bağımlılıklarına göre değişir. Yakın sıfır kesinti bazı iş yüklerinde mümkündür; ancak her sistem için gerçekçi değildir. Pilot, prova, son senkronizasyon, bakım penceresi ve yazılı rollback kriterleriyle kesinti ve risk azaltılır.
Veri kaybı riski nasıl azaltılır?
Geçişten önce doğrulanmış yedek alınır, aktarım yöntemi veri değişim hızına göre seçilir ve son senkronizasyon zamanı kayıt altına alınır. Hedefte dosya sayısı, boyut, zaman damgası, veri tabanı tutarlılığı ve mümkün olduğunda checksum karşılaştırmaları yapılır. Kaynak sistem, iş sahibi kabulü ve rollback süresi tamamlanmadan kapatılmaz.
Bulut maliyeti nasıl öngörülür?
Sadece sanal makine fiyatına bakılmaz. İşlemci ve RAM çalışma süresi, disk türü ve kapasitesi, yedekler, snapshot, dışarı veri çıkışı, internet ve özel bağlantı, güvenlik, log saklama, lisans, destek ve yönetim işçiliği birlikte hesaplanır. Mevcut kullanım ölçülmeden yapılan tahminler gereğinden büyük veya yetersiz kaynak seçimine yol açabilir.
Buluta geçince güvenlik tamamen sağlayıcının sorumluluğunda mıdır?
Hayır. Sağlayıcı fiziksel altyapı ve seçilen hizmet katmanının belirli bölümlerini korur; müşteri tarafında kimlik, yetki, veri sınıflandırması, ağ kuralları, işletim sistemi veya uygulama güvenliği, loglama, yedekleme ve yanlış yapılandırmalar için sorumluluk devam eder. Sorumluluk sınırı kullanılan IaaS, PaaS veya SaaS hizmetine göre değişir.
Bulut yedekleme ve felaket kurtarma migration kapsamına dahil midir?
Hedef mimarinin parçası olarak yedekleme ve felaket kurtarma gereksinimleri değerlendirilir; ancak saklama süresi, ikinci bölge veya hesap, geri yükleme testi, replikasyon ve felaket anı operasyonu teklifte ayrı kalemler olarak tanımlanır. Buluta taşınmış olmak tek başına yedek veya felaket kurtarma planı oluşturmaz.
Türkiye genelinde cloud migration desteği veriyor musunuz?
Evet. Envanter, mimari değerlendirme, bulut hesabı hazırlığı, uzaktan kurulum, veri aktarımı, test, dokümantasyon ve yönetim çalışmaları Türkiye genelinde uzaktan veya hibrit yürütülebilir. Fiziksel kaynak sistem, kabin veya bağlantı müdahalesi gerekiyorsa lokasyona göre saha planı ayrıca hazırlanır.
Cloud migration teklifi için hangi bilgiler gerekir?
Sunucu ve sanal makine listesi, uygulamalar ve iş sahipleri, işletim sistemi ve veri tabanı sürümleri, CPU/RAM/disk kullanımı, aktif veri hacmi, bağlantı kapasitesi, kullanıcı ve lokasyon sayısı, lisanslar, entegrasyonlar, RPO/RTO hedefleri, güvenlik veya mevzuat gereksinimleri ve planlanan geçiş tarihi ilk değerlendirme için yeterlidir.
Teknik referanslar: Microsoft iş yükü envanteri rehberi · Microsoft migration planlama rehberi · Microsoft üretim geçişi rehberi · Google Cloud migration başlangıç rehberi · NIST SP 800-146
Teknik içerik son gözden geçirme: 21 Temmuz 2026. Nihai mimari, güvenlik ve lisans uygunluğu; seçilen sağlayıcının güncel dokümanı, sözleşme koşulları ve iş yükü keşfiyle doğrulanır.
Bulut geçişinizi birlikte planlayalım
Veri merkezi yenileyecek, mevcut sunucularınızı taşıyacak, hibrit mimari kuracak veya bulut maliyetinizi düzenleyecekseniz; iş yüklerini, geçiş riskini, rollback planını ve kabul kriterlerini birlikte netleştirelim.