- 01Bulut göçünde stateless sistemleri her zaman önce taşımak doğru değildir; migration sırası uygulama ve veri bağımlılıklarına göre belirlenmelidir.
- 02İlk migration wave düşük riskli, az bağımlılıklı ve rollback'i kolay bir workload ile migration runbook'unu doğrulamalıdır.
- 03Wave 0 kapsamında network, identity, DNS, monitoring, backup ve security gibi ortak platform servisleri production workload'dan önce hazırlanmalıdır.
- 04Sıkı bağlı uygulama ve veritabanı bileşenlerini ayrı wave'lere bölmek latency, transaction ve kesinti riski yaratabilir.
- 05Rollback kriterleri, veri yazma noktası ve eski ortamın korunma süresi cutover başlamadan önce tanımlanmalıdır.
Kısaca
Bulut göçünde doğru sıra "önce stateless, sonra veri" gibi sabit bir kural değildir. Göç sırası; uygulama bağımlılıkları, iş kritikliği, veri hacmi, bakım penceresi ve rollback kolaylığına göre migration wave'lere ayrılmalıdır. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak ilk wave'i düşük riskli sistemlerle doğrular, sıkı bağlı uygulama ve veri katmanlarını ise bağımlılık haritasına göre birlikte taşır.
Migration wave nedir?
Migration wave, aynı zaman penceresinde birlikte taşınacak iş yükü grubudur.
Amaç tüm sistemi tek seferde taşımak değil, göçü yönetilebilir parçalara bölmektir.
Bir wave şu bileşenleri içerebilir:
- Uygulama sunucuları
- Veritabanı
- Queue veya worker
- Dosya sistemi
- DNS kaydı
- Load balancer
- Secret ve sertifikalar
- Monitoring entegrasyonu
Aynı uygulamanın bu bileşenleri birbirine sıkı bağlıysa ayrı wave'lere bölmek yerine birlikte taşımak daha doğru olabilir.
Önce stateless yaklaşımı ne zaman işe yarar?
Stateless uygulamalar genellikle iyi pilot adaylarıdır çünkü:
- Veri taşıma ihtiyacı düşüktür
- Rollback daha kolaydır
- Uygulama yeniden deploy edilebilir
- Eski ve yeni ortam paralel çalıştırılabilir
- Cutover yalnızca trafik yönlendirmesiyle yapılabilir
Bu nedenle ilk wave için düşük riskli stateless servis seçmek çoğu projede iyi başlangıçtır.
Ancak bu yaklaşımı evrensel kurala çevirmeyin.
Bir stateless API, aynı veri merkezindeki veritabanına milisaniye seviyesinde bağımlıysa yalnız API'yi başka bölgeye taşımak:
- yüksek latency
- cross-cloud transfer maliyeti
- timeout
- transaction performans sorunu
yaratabilir.
Uygulama ve veritabanı ne zaman aynı wave'de olmalı?
Aşağıdaki durumlarda uygulama ve veri katmanını aynı wave içinde değerlendirin:
- Yoğun ve sürekli database trafiği varsa
- Düşük latency gerekiyorsa
- Transaction bütünlüğü kritikse
- Network bağlantısı geçici hibrit modele uygun değilse
- Database endpoint değişikliği uygulamayla birlikte yapılacaksa
- Cutover sırasında dual-write mümkün değilse
Ayrı wave kullanılabilecek durumlar:
- Uygulama yeni ve eski database'e kontrollü bağlanabiliyorsa
- Replikasyon kurulabiliyorsa
- Read replica veya CDC kullanılabiliyorsa
- Network latency kabul edilebilirse
- Geçici hibrit mimari destekleniyorsa
Karar "stateless mı stateful mı?" değil, "bağımlılık seviyesi ne?" sorusuyla verilmelidir.
Migration sırasını dependency map ile oluşturun
Her uygulama için şu bağımlılıkları çıkarın:
| Alan | Sorulacak soru |
|---|---|
| Database | Hangi veritabanına bağlanıyor? |
| Network | Hangi private IP, VLAN veya VPN'e bağımlı? |
| Identity | AD, LDAP, IAM veya SSO bağımlılığı var mı? |
| Storage | Shared filesystem veya object storage kullanıyor mu? |
| Queue | Kafka, RabbitMQ, SQS veya benzeri bağımlılık var mı? |
| DNS | Hangi hostname ve TTL kullanılıyor? |
| External API | Hangi allowlist/IP bağımlılıkları var? |
| Backup | Hangi recovery planı uygulanıyor? |
| Monitoring | Hangi log/metric sistemine bağlı? |
| Batch | Cron veya scheduler bağımlılığı var mı? |
Bu tablo uygulamaların hangi wave'de birlikte taşınması gerektiğini gösterir.
İlk wave düşük riskli olmalıdır
AWS Prescriptive Guidance, ilk migration wave'lerinde daha düşük karmaşıklıktaki uygulamalarla başlamayı ve süreçten öğrenilenleri sonraki wave'lere taşımayı önerir.
İlk wave için iyi aday:
- Kritik olmayan
- Az bağımlılıklı
- Kolay rollback yapılabilen
- İyi monitoring'i olan
- Küçük veri hacmine sahip
- Uygulama sahibinin test yapabildiği
bir sistemdir.
İlk wave'in amacı maksimum VM taşımak değil, migration runbook'unun çalıştığını kanıtlamaktır.
Wave 0 ile altyapıyı hazırlayın
Production workload taşımadan önce hedef ortamda temel platform servisleri hazır olmalıdır.
Wave 0 kapsamında:
- Network
- VPN / private connectivity
- DNS
- IAM / identity
- Logging
- Monitoring
- Backup
- Secret management
- Security policy
- Base images
- CI/CD bağlantıları
kurulur.
Bu katman hazır değilse ilk uygulama migration'ı aynı anda platform kurulum projesine dönüşür.
Wave'leri iş kritikliği ve karmaşıklıkla puanlayın
Basit bir scoring modeli kullanılabilir.
Her workload için 1-5 puan verin:
- İş kritikliği
- Teknik karmaşıklık
- Veri hacmi
- Dependency sayısı
- Downtime hassasiyeti
- Rollback zorluğu
Örnek:
| Workload | Kritik | Karmaşık | Veri | Dependency | Downtime | Rollback | Toplam |
|---|---|---|---|---|---|---|---|
| İç wiki | 1 | 1 | 1 | 1 | 1 | 1 | 6 |
| API | 3 | 2 | 1 | 3 | 3 | 2 | 14 |
| ERP | 5 | 5 | 5 | 5 | 5 | 5 | 30 |
Düşük toplam puanlı workload'lar ilk wave için daha uygun olabilir.
Bu matematik otomatik karar vermez; yalnızca risk görünürlüğü sağlar.
Veri taşıma stratejisini wave'den önce seçin
Stateful workload için veri taşıma yöntemi wave planının temelidir.
Seçenekler:
Backup / restore
Uygun olduğunda:
- Veri hacmi sınırlı
- Downtime kabul edilebilir
- Basit migration
Snapshot / image
Uygun olduğunda:
- VM tabanlı workload
- Hedef platform formatı uyumlu
- Disk-level taşıma yeterli
Replikasyon
Uygun olduğunda:
- Veri hacmi yüksek
- Downtime düşük tutulmalı
- Source ve target bir süre paralel çalışabilir
CDC / dual-write
Uygun olduğunda:
- Database değişikliği var
- Uzun geçiş penceresi gerekiyor
- Uygulama mimarisi destekliyor
Yanlış veri taşıma yöntemi doğru wave planını bozabilir.
Cutover kriterlerini wave başlamadan yazın
Her wave için başarı kriteri önceden tanımlanmalıdır.
Örnek:
- Error rate <%1
- p95 latency <300 ms
- Database replication lag <30 saniye
- Backup başarılı
- Monitoring aktif
- Smoke test geçti
- İş birimi onayı alındı
Bu metriklerden biri karşılanmıyorsa bir sonraki wave'e geçmeyin.
Rollback planı cutover'dan önce hazırlanır
Rollback, migration başarısız olduktan sonra düşünülecek adım değildir.
Wave başlamadan önce şunları yazın:
- Hangi koşul rollback tetikler?
- DNS nasıl geri alınacak?
- Eski database writable kalacak mı?
- Yeni ortamda oluşan veri nasıl ele alınacak?
- Eski ortam ne kadar süre korunacak?
- Hangi ekip rollback kararı verecek?
Stateful sistemlerde rollback en zor konudur çünkü yeni ortamda yazılan verinin eski ortama geri taşınması gerekebilir.
Bu nedenle "geri dönmek kolay" varsayımını test etmeden kullanmayın.
DNS cutover tek başına migration planı değildir
DNS değişikliği uygulama trafik yönlendirmesini çözer; veri, session, queue ve background job problemlerini çözmez.
Cutover öncesinde:
- DNS TTL
- Session persistence
- Queue consumer sayısı
- Scheduled job
- File upload
- Database write
- Webhook
- External allowlist
kontrol edilmelidir.
Aynı job'un eski ve yeni ortamda aynı anda çalışması duplicate işlem üretebilir.
Wave sonrası doğrulama yapın
Her wave tamamlandıktan sonra:
- Uygulama smoke test
- İş akışı testi
- Performance karşılaştırması
- Log kontrolü
- Backup doğrulaması
- Security kontrolü
- Cost kontrolü
- Kullanıcı onayı
yapın.
Wave'i yalnız VM boot ettiği için başarılı saymayın.
Eski ortamı hemen kapatmayın
Migration sonrası eski ortam kısa süre rollback için tutulabilir.
Ancak süre açıkça tanımlanmalıdır.
Örneğin:
- 24 saat teknik gözlem
- 72 saat iş birimi doğrulaması
- 7 gün rollback penceresi
gibi.
Bu süre her workload için farklı olabilir.
Sabit "iki hafta açık tut" kuralı yerine risk ve veri tutarlılığına göre kapanış kriteri kullanın.
Hibrit dönem planın doğal parçasıdır
Büyük migration projelerinde bir süre eski ve yeni ortam birlikte çalışır.
Bu dönemde:
- Network
- Identity
- DNS
- Monitoring
- Backup
- Data replication
iki ortam arasında çalışmalıdır.
Bu geçici mimari bazen haftalar, bazen aylar sürebilir.
Dynamis'in Cloud Migration hizmeti, migration sürecindeki bu geçici veya kalıcı çoklu ortam modelini yönetmek için kullanılabilir.
AWS migration ile genel cloud migration arasındaki fark
AWS'den çıkış rehberi data transfer, AWS servis bağımlılığı ve exit programını detaylandırır.
Bu sayfa ise sağlayıcıdan bağımsız olarak:
- migration wave
- dependency mapping
- pilot seçim
- data movement
- cutover
- rollback
sırasını ele alır.
Bu ayrım iki sayfanın aynı intent'i hedeflemesini önler.
VMware migration'da dependency wave daha da önemlidir
VMware ortamlarında VM'ler teknik olarak kolay listelenebilir; ancak:
- vSAN
- NSX
- Active Directory
- backup
- VLAN
- shared storage
bağımlılıkları wave planını etkiler.
VMware çıkış planı bu bağımlılıkları sanallaştırma ortamı özelinde detaylandırır.
Dynamis'te migration wave planı
Dynamis cloud migration projelerinde önce workload inventory ve dependency map oluşturur.
Sonra:
- Wave 0 altyapı hazırlığı
- Düşük riskli pilot
- Orta kritik workload
- Stateful ve yüksek bağımlılıklı sistemler
- Kritik iş sistemleri
- Eski ortam decommission
sırasını workload özelliklerine göre uyarlarız.
Amaç "önce stateless" gibi bir slogan uygulamak değil, her wave'in riskini ölçülebilir hale getirmektir.
Sık yapılan hatalar
Stateless her zaman önce taşınır sanmak: Database dependency yüksekse ayrı taşımak performans riski yaratabilir.
İlk wave'e kritik sistemi koymak: Pilot wave süreç doğrulamak içindir.
Wave'i VM klasörüne göre oluşturmak: Uygulama dependency'leri esas alınmalıdır.
Data migration yöntemini geç seçmek: Backup/restore veya replication kararı wave yapısını değiştirir.
Rollback'i cutover sonrasına bırakmak: Rollback kriterleri önceden yazılmalıdır.
Eski ortamı süresiz açık tutmak: Net decommission kriteri olmalıdır.
Sırada ne var
-
AWS'den çıkış: maliyeti düşüren bulut göçü planı: AWS workload'ları için exit ve data transfer planını inceleyin.
-
Broadcom sonrası VMware: lisanslama ve çıkış planı: VMware workload'ları için dependency ve migration planını uygulayın.
-
AWS alternatifi: hangi iş yükü nerede kalmalı?: hangi workload'un taşınacağını belirleyin.
-
Cloud Migration hizmeti: geçici veya kalıcı çoklu ortam operasyonunu yönetin.
-
Cloud migration sırasında downtime nasıl minimuma indirilir?: her wave için veri senkronizasyonu, DNS, write freeze ve rollback penceresini ayrı planlayın.
-
Cloud Migration Checklist: buluta geçmeden önce 30 kontrol: wave planı hazır olduğunda cutover öncesi go/no-go kontrollerini tamamlayın.
-
Cloud migration strategy: rehost, replatform ve refactor: migration sırasını oluşturmadan önce her workload'un nasıl taşınacağını workload bazında belirleyin.
Kaynaklar
Kaynaklar
- 1.Wave planningAmazon Web Services · 2026-09-19
- 2.Migration terms and strategiesAmazon Web Services · 2026-09-19
- 3.Plan migration wavesMicrosoft Learn · 2026-09-19
Sık sorulan sorular
Bulut göçünde önce stateless sistemler mi taşınmalı?
Her zaman değil. Düşük riskli ve düşük bağımlılıklı stateless sistemler iyi pilot adayları olabilir; ancak sıkı bağlı uygulama ve veritabanı bileşenlerini yalnızca stateless-first kuralı nedeniyle ayırmak performans ve kesinti riski yaratabilir.
Migration wave nasıl oluşturulur?
Uygulamaları bağımlılık, iş kritikliği, veri hacmi, bakım penceresi ve teknik karmaşıklığa göre gruplandırın. İlk wave'lerde düşük riskli sistemlerle süreci doğrulayın; doğrudan bağımlı bileşenleri mümkün olduğunca aynı wave içinde tutun.
Uygulama ve veritabanı aynı anda mı taşınmalı?
Bağımlılık ve gecikme hassasiyetine bağlıdır. Uygulama ile veritabanı arasında yoğun ve düşük gecikmeli trafik varsa aynı wave daha güvenli olabilir. Bağımlılık zayıfsa ve replikasyon planı varsa ayrı wave'ler kullanılabilir.
İlk migration wave için hangi sistem seçilmeli?
İlk wave için düşük iş riski, sınırlı bağımlılık, kolay rollback ve iyi gözlemlenebilirlik özelliklerine sahip bir iş yükü seçin. Pilotun amacı hedef platformu ve migration runbook'unu doğrulamaktır.
Bulut göçünde rollback planı ne zaman hazırlanmalı?
Cutover'dan önce. Rollback koşulları, eski ortamın ne kadar süre korunacağı, veri yazma noktasının nasıl geri alınacağı ve hangi metrikte geri dönüş yapılacağı migration wave başlamadan tanımlanmalıdır.