# Kesintiyi ve maliyet sürprizini önceden planlayan buluta geçiş. > Uygulamalarınızı AWS, Azure, GCP veya Türkiye’deki veri merkezlerine taşıyan bulut geçişi: envanter, maliyet modeli, test ve geri dönüş planı. Source: https://www.algofact.tech/tr/services/cloud/cloud-migration Language: tr-TR Updated: 2026-10-26 Languages: en-US, tr-TR ALGOFACT, şirket içi sunucularda veya başka bir sağlayıcıda çalışan uygulamaları AWS, Azure, GCP ya da veri yerelliği gerektiğinde Türkiye’de barındırılan veri merkezlerine taşır. Geçişten önce uygulama envanterini ve bağımlılıkları çıkarır, her sistem için taşıma yöntemini ve aylık maliyet modelini belirler, her dalgayı kabul testi ve geri dönüş planıyla yürütürüz. Çalışma, ISO 27001:2022 sertifikası ve Kamu Bilişim Yetki Belgesi bulunan mühendislik ekibimizce Adana ve Ankara TEKMER’den yürütülür. ## Key facts - **Hedef ortam:** AWS, Azure, GCP veya Türkiye’de barındırma - **Veri yerelliği:** KVKK ve sektör kurallarına göre yerleşim - **Planlama:** Dalgalar halinde taşıma, her dalgada geri dönüş - **Maliyet:** Geçiş öncesi aylık işletme maliyeti modeli - **Kamu projeleri:** Kamu Bilişim Yetki Belgesi - **Bilgi güvenliği:** ISO 27001:2022 sertifikalı ## Buluta geçiş ne zaman mantıklıdır? Donanım yenileme dönemi yaklaşıyorsa, sistem kapasitesi yoğun dönemlerde yetmiyorsa, yedekleme ve felaket kurtarma tek bir kişinin bilgisine bağlıysa veya yeni yapay zeka ve veri projeleri esnek hesaplama kaynağı gerektiriyorsa buluta geçiş ciddi bir seçenektir. Her iş yükü buluta taşınmamalıdır. Sabit ve yüksek kullanımlı bir iş yükü kendi donanımınızda daha ucuz kalabilir, lisans koşulları belirli bir ortama bağlı olabilir, bazı veriler mevzuat gereği yurt içinde kalmak zorundadır. Değerlendirmenin sonunda bazı sistemler için önerimiz yerinde bırakmak, bazıları için tamamen kapatmak olabilir. Bunu raporda gerekçesiyle açıkça yazarız. ## Neleri taşırız Bir geçiş kapsamı genellikle şu iş yüklerinin bir karışımıdır. ### Kurumsal uygulamalar ERP, CRM, muhasebe ve şirket içinde geliştirilmiş web uygulamaları; bunlara bağlı entegrasyonlar ve zamanlanmış işler. ### Veritabanları PostgreSQL, SQL Server, MySQL veya Oracle veritabanlarının yönetilen servislere ya da bulut sanal makinelerine taşınması; veri doğrulaması ve senkronizasyon dahil. ### Dosya ve doküman arşivleri Ağ paylaşımları ve doküman arşivlerinin nesne depolamaya veya yönetilen dosya servislerine, erişim yetkileri korunarak aktarılması. ### Veri ve yapay zeka iş yükleri Veri ambarları, raporlama ve model eğitimi için ölçeklenebilir hesaplama ve depolama; ihtiyaç olduğunda GPU kapasitesi. ### Sağlayıcı değişikliği ve geri taşıma Bir bulut sağlayıcısından diğerine geçiş veya genel buluttan yurt içindeki bir veri merkezine geri taşıma. ## Geçiş nasıl yürütülür ### Envanter ve bağımlılık haritası Sunucuları, uygulamaları, veritabanlarını ve aralarındaki bağlantıları çıkarırız. Sabit IP adresleri, paylaşılan dosya yolları ve gece çalışan işler gibi gizli bağımlılıklar, geçişlerin en sık takıldığı yerdir. ### Taşıma yönteminin seçimi Her sistem için olduğu gibi taşıma, platform değiştirme, yeniden yapılandırma, yerinde bırakma veya kapatma kararı verilir. Karar maliyet, risk ve ekibinizin kapasitesine göre yazılı gerekçeyle alınır. ### Hedef mimari ve landing zone Hesap yapısı, ağ, kimlik yönetimi, merkezi loglama ve yedekleme, taşınacak ilk sistemden önce kurulur. Bu temel sonraki her dalgada yeniden kullanılır. ### Pilot dalga Düşük riskli bir sistemle başlar; taşıma adımlarını, veri doğrulamasını ve geri dönüş prosedürünü gerçek koşullarda deneriz. ### Dalgalar halinde geçiş Kalan sistemler iş takviminize göre planlanan dalgalar halinde taşınır. Her dalganın bir kesinti penceresi, kabul testleri ve geri dönüş kararı için net bir kriteri vardır. ### Optimizasyon ve kapanış Geçişten sonraki dönemde kaynak boyutları gerçek kullanıma göre ayarlanır, eski sunucular kapatılır ve işletme devri tamamlanır. ## Teslim edilenler ### Geçiş değerlendirme raporu Envanter, bağımlılık haritası, her sistem için önerilen yöntem ve gerekçesi. ### Maliyet modeli Hedef ortamdaki tahmini aylık işletme maliyeti, bugünkü maliyetle karşılaştırma, rezervasyon ve tasarruf planı seçenekleri. ### Landing zone kodu Hesaplar, ağ, kimlik, loglama ve yedekleme tanımları; kod olarak ve sizin deponuzda. ### Dalga planı ve geri dönüş prosedürleri Her dalga için takvim, kabul kriterleri ve önceki ortama dönüş adımları. ### Yeni ortam için işletme kılavuzu Yedekten geri yükleme, ölçekleme ve olağan bakım işleri için adım adım talimatlar. ## Veri yerelliği, maliyet ve geri dönüş Geçişin teknik başarısı bu dört kararın baştan doğru verilmesine bağlıdır. - **Veri yerelliği:** Kişisel verilerin yurt dışına aktarımı KVKK kapsamında ek koşullara bağlıdır; bankacılık gibi bazı sektörlerde düzenleyiciler de verinin yurt içinde tutulmasını bekler. Bu durumda iş yükünü Türkiye’de barındırılan veri merkezlerine yerleştirir, hangi verinin nerede tutulduğunu belgeleriz. - **Maliyet kontrolü:** Bulut faturası kendiliğinden düşmez. Etiketleme standardı, bütçe alarmları, kullanılmayan kaynakların temizlenmesi ve sürekli çalışan iş yükleri için rezervasyon planı geçişin parçası olarak kurulur. - **Geri dönüş planı:** Eski ortam, yeni ortamda kabul testleri geçilip kararlaştırılan gözlem süresi dolana kadar kapatılmaz. Veri iki yönlü senkronize edilmiyorsa geri dönüşün nasıl yapılacağı geçişten önce prova edilir. - **Kesinti yönetimi:** Kesinti penceresi iş birimleriyle birlikte belirlenir. Uzun kesintinin kabul edilemediği sistemlerde veritabanı replikasyonu ile geçiş kısa bir anahtarlama anına indirilir. ## Bulut geçişi hakkında sorular ### Hangi bulut sağlayıcısını öneriyorsunuz? Belirli bir sağlayıcıya bağlı değiliz. Seçim; veri yerelliği gereksiniminize, kullandığınız lisanslara, ekibinizin deneyimine ve maliyet modeline göre yapılır. AWS, Azure ve GCP’nin yanında Türkiye’de barındırılan veri merkezleri de değerlendirmeye girer. ### Geçiş sırasında sistemlerimiz kapanır mı? Her dalga için bir kesinti penceresi planlanır ve iş birimlerinizle önceden kararlaştırılır. Kesintinin kabul edilemediği sistemlerde veri önceden senkronize edilir ve geçiş kısa bir anahtarlama işlemine indirilir. ### Fatura beklediğimizden yüksek çıkarsa ne olur? Maliyet modeli geçişten önce hazırlanır ve bütçe alarmları ilk günden kurulur. Geçiş sonrası optimizasyon döneminde kaynaklar gerçek kullanıma göre küçültülür; modelden sapma varsa nedeni raporlanır. ### Kamu kurumlarının geçiş projelerinde çalışıyor musunuz? Evet. ALGOFACT’in Kamu Bilişim Yetki Belgesi vardır. Kamu projelerinde barındırma yeri ve güvenlik gereksinimleri kurumun mevzuatına göre belirlenir ve bu gereksinimler sıklıkla yurt içinde barındırmayı gerektirir. ### Geçişten sonra yeni ortamı kim işletir? Sizin ekibiniz veya isterseniz biz. Erişimler ve işletme kılavuzu devredilir; sürekli işletme desteği isterseniz yönetilen destek modeliyle devam ederiz. ### Geçişin süresini ve maliyetini ne belirler? Taşınacak sistem ve veritabanı sayısı, veri hacmi, bağımlılıkların ne kadar belgelendiği, kabul edilebilir kesinti süresi, yeniden yapılandırılacak uygulamaların oranı ve uyum gereksinimleri. Değerlendirme sonunda dalga planını, tahmini süreyi ve hedef ortamın aylık maliyetini yazılı olarak sunarız. ## Related - [Bulut](https://www.algofact.tech/tr/services/cloud) - [DevOps ve CI/CD](https://www.algofact.tech/tr/services/cloud/devops) - [Yönetilen IT ve uygulama desteği](https://www.algofact.tech/tr/services/cloud/managed-it-support) - [Keşif görüşmesi](https://www.algofact.tech/tr/contact)