Bulut migrasyonları nadiren teknolojiden dolayı başarısız olur. Eksik keşiften, olmayan temellerden ve hiç prova edilmemiş geçişlerden başarısız olur. Bu yol haritası AWS, Azure veya Google Cloud'da başarıyı gerçekte neyin belirlediğini anlatıyor: 7R çerçevesinin dürüst uygulanması, ilk iş yükü taşınmadan önce kurulmuş bir landing zone, veri bütünlüğünü koruyan migrasyon mekaniği ve ilk faturayla temasta ayakta kalan bir maliyet modeli.

Değerlendirme ve Keşifle Başlayın

Her migrasyon planı ancak envanteri kadar iyidir. Strateji seçmeden önce uygulamaları, sunucuları, veritabanlarını, lisansları ve — en önemlisi — aralarındaki bağımlılıkları kataloglayın. Belgelenmemiş bağımlılıklar migrasyon günü sürprizlerinin bir numaralı nedenidir: sahibi olmayan batch işi, sabitlenmiş IP adresi, üç ekibin unuttuğu paylaşımlı dosya mount'u.

Üç büyük sağlayıcının da keşif araçları var: AWS Application Discovery Service ve Migration Evaluator, Azure Migrate, Google Cloud Migration Center. Gerçek kullanım ve ağ akışlarını yakalamak için agent'lı ya da agent'sız toplayıcıları en az iki-dört hafta çalıştırın; sonra her iş yükünü iş kritikliği, uyumluluk kısıtları ve veri çekimine (data gravity) göre sınıflandırın. Çıktı bir dalga planı olmalı: birbirleriyle konuştukları için birlikte taşınan uygulama grupları.

7R Çerçevesi, Doğru Tanımlarıyla

Sektör standardı çerçeve yedi strateji tanımlar; tanımları doğru oturtmak önemlidir çünkü her biri farklı maliyet, risk ve takvim profili taşır:

  • Rehost (taşı-geç): İş yükünü olduğu gibi bulut VM'lerine taşımak. En hızlı yol ama otomatik olarak ucuz değil — değiştirilmemiş bir sunucu filosu, rightsizing ve taahhüt yapılana kadar on-demand fiyatlarla çoğu zaman yerini aldığı donanımdan pahalıya gelir.
  • Replatform (taşırken elden geçir): Çekirdek mimariyi değiştirmeden taşınma sırasında hedefli iyileştirmeler — örneğin kendi yönettiğiniz PostgreSQL'i Amazon RDS, Azure Database for PostgreSQL veya Cloud SQL ile değiştirmek, ya da bir uygulamayı yönetilen Kubernetes üzerinde container'lara almak. Bulut platformu değiştirmek anlamına gelmez.
  • Refactor (yeniden mimarile): Uygulamayı bulut-yerlisi olacak şekilde yeniden tasarlamak — yönetilen servisler, yatay ölçekleme, olay-güdümlü desenler. En yüksek efor ve en yüksek uzun vadeli getiri; iş gerekçesi açık iş yüklerine saklayın.
  • Repurchase (satın al): Kendi barındırdığınız sistemi emekli edip SaaS ürünle değiştirmek — klasik CRM hamlesi.
  • Retire (emekli et): Kimsenin kullanmadığını kapatmak. Keşif tipik olarak envanterin %10–20'sinin düpedüz kapatılabileceğini bulur — var olan en ucuz migrasyon.
  • Retain (tut): Bazı iş yüklerini bilinçli olarak şimdilik yerinde bırakmak — gecikmeye bağlı sistemler, düzenleyici kısıtlar veya ömrünün sonuna yaklaşan uygulamalar.
  • Relocate (yerinden taşı): Yeniden mimarilemeden hypervisor seviyesinde taşınmak — VMware Cloud on AWS, Azure VMware Solution veya Google Cloud VMware Engine. Takvim baskısıyla veri merkezi boşaltırken işe yarar.

Gerçek programların çoğu stratejileri karıştırır: agresifçe emekli et ve satın al, uzun kuyruğu rehost/relocate et, veritabanlarını replatform et ve işi farklılaştıran bir avuç sistemi refactor et.

İlk İş Yükünden Önce Landing Zone'u Kurun

Landing zone, iş yüklerinizin ineceği çoklu hesap (veya subscription/proje) temelidir: federatif kimlik ve SSO, hub-and-spoke veya shared-VPC ağ topolojisi, merkezî loglama ve denetim izleri, politika olarak uygulanan korkuluklar — AWS Service Control Policies, Azure Policy veya GCP Organization Policies. AWS Control Tower, Azure Cloud Adoption Framework landing zone'ları ve Google'ın Fabric FAST şablonları görüşlü başlangıç noktaları sunar; hangisini seçerseniz seçin, ilk günden infrastructure-as-code olarak tanımlayın. Düz, elle kurulmuş bir hesaba taşınmak, ekiplerin on sekiz ay sonra bulut ortamını baştan kurmasının hikâyesidir.

Veri Migrasyonu Mekaniği

Migrasyon veride ciddileşir. Veritabanlarında desen her bulutta aynı: önce tam yükleme, ardından geçişe kadar hedefi senkron tutan change data capture (CDC). AWS Database Migration Service, Azure Database Migration Service ve GCP Database Migration Service bunu uygular ve kesintiyi bağlantı adreslerini değiştirmenin sürdüğü dakikalara indirir. Veritabanı motoru değiştiriyorsanız şema dönüşümünü ayrıca bütçeleyin — AWS Schema Conversion Tool gibi araçlar çoğunu otomatikleştirir ama stored procedure'lar ve üreticiye özel SQL her zaman insan incelemesi ister.

Dosya ve nesne verisinde çevrimiçi/çevrimdışı transfer kararını basit bant genişliği matematiği verir: 100 TB'ı adanmış 1 Gbps hatta tam kullanımla taşımak kabaca on gün sürer. Çevrimiçi seçenekler AWS DataSync, Azure Storage Mover ve AzCopy, Google Storage Transfer Service; hesap tutmuyorsa veriyi AWS Snowball, Azure Data Box veya Google Transfer Appliance ile gönderin. Yol ne olursa olsun checksum'lar ve satır sayımlarıyla doğrulayın — kaynak silindikten sonra keşfedilen bozulma geri getirilemez.

Geçiş (Cutover) Stratejileri

Geçişi program başına değil, dalga başına planlayın. İşleyen üç desen: big bang (her şey bir anda — yalnızca küçük, düşük riskli sistemler için), kademeli geçiş (bileşenleri veya kullanıcı segmentlerini adım adım taşı) ve paralel çalıştırma (eski ve yeni yan yana çalışır, anahtar çevrilmeden sonuçlar karşılaştırılır). Her durumda: DNS TTL'lerini günler önce düşürün, pencere etrafında değişiklik dondurun ve — pazarlıksız — rollback prosedürünü yazıp prova edin. Hiç çalıştırılmamış rollback planı plan değil, hipotezdir.

Hesap Makinesinin Ötesinde Maliyet Modeli

Naif maliyet modelleri on-demand liste fiyatlarını amorti edilmiş donanımla karşılaştırır ve yazarın istediği sonuca varır. Dürüst bir model şunları içerir: iki ortamın birden canlı olduğu çifte-çalışma dönemi, migrasyon sırasındaki egress ve veri transferi, migrasyon araçları ve insan gücü ile geride tutulan envanterin işletme maliyeti. Reserved Instances veya Savings Plans taahhüdünü yalnızca iş yükleri rightsizing'den geçtikten ve kullanım oturduktan sonra verin — büyük boyutlu bir ayak izine taahhüt, israfı bir ila üç yıla kilitler. Yayına geçince iş sürekli optimizasyona döner; bulut maliyet düşürme rehberimiz o döngüyü ayrıntısıyla anlatıyor.

Yaygın Başarısızlık Kalıpları

  • Bilinmeyeni taşımak: bağımlılık haritasını atlayıp entegrasyonları geçiş gecesi 02.00'de keşfetmek.
  • Landing zone yokluğu: iş yüklerini yapısız bir hesaba indirip yeniden temellendirmeyi sonra ödemek.
  • Rehost tahminini nihai saymak: taşı-geç bir başlangıç pozisyonudur, kalıcı durum değil; rightsizing olmadan fatura hayal kırıklığıdır.
  • Test edilmemiş rollback: geri dönülebilirliği prova etmek yerine varsaymak.
  • İnsanları unutmak: operasyon ekipleri bulut becerilerine ilk olaydan sonra değil, yayına geçmeden önce ihtiyaç duyar.
  • Ölümsüz "geçici" ortam: kimse kapatmayı sahiplenmediği için bir yıl sessizce faturalanan çifte-çalışma kurulumları.

Nereden Başlamalı?

Keşfi çalıştırın, her iş yüküne yedi R'den birini atayın, landing zone'u kurun ve mekanizmayı uçtan uca denemek için önce düşük riskli bir dalgayı taşıyın. Plana deneyimli eller isterseniz — değerlendirmeden geçişe kadar — bulut ekibimiz AWS, Azure ve GCP'de migrasyon programları yürütür; yönetilen hizmetler ekibimiz vardığınızda ortamı işletir.

Taşınma planlıyor musunuz? AWS migrasyon hizmetimiz sizi 8–16 haftada Well-Architected bir temele taşır — sabit fiyat, kademeli geçiş, yazılı rollback planı.

Etiketler: #Bulut #Migrasyon #AWS #Azure #GCP #Strateji