- 01Cloud migration strategy tüm şirket için tek bir karar değil, her workload için ayrı seçilmesi gereken bir hedef yaklaşımıdır.
- 02Rehost minimum değişiklik ve hızlı geçiş sağlar; replatform sınırlı modernizasyonla operasyon yükünü azaltır; refactor ise daha yüksek engineering yatırımıyla mimariyi dönüştürür.
- 03Retain, retire, replace ve relocate seçenekleri de gerçek migration programının parçasıdır; her workload'un cloud'a taşınması gerekmez.
- 04Migration strategy workload'un nasıl taşınacağını, migration wave ise hangi sırayla taşınacağını belirler.
- 05Doğru strateji iş değeri, uygulama ömrü, bağımlılık, downtime, lisanslama, RPO/RTO ve teknik borç birlikte değerlendirilerek seçilir.
Kısaca
Cloud migration strategy, her workload için hedef ortama nasıl geçileceğini belirleyen karar çerçevesidir. Rehost en az değişiklikle hızlı taşımayı, replatform sınırlı modernizasyonla operasyon yükünü azaltmayı, refactor ise uygulama kodu veya mimarisini daha kapsamlı değiştirerek cloud-native yeteneklerden yararlanmayı hedefler. Dynamis Teknoloji, migration stratejisini tüm şirket için tek bir etiket olarak değil; iş yükü, bağımlılık, teknik borç, lisanslama, downtime toleransı ve ürün ömrüne göre workload bazında belirler.
Cloud migration strategy nedir?
Cloud migration strategy, bir uygulama veya iş yükünün mevcut ortamdan hedef ortama hangi yöntemle taşınacağını belirler.
Tek bir şirket içinde farklı uygulamalar için farklı stratejiler kullanılabilir.
Örneğin:
- Eski fakat kritik ERP uygulaması rehost edilebilir
- Web uygulamasının veritabanı replatform ile yönetilen servise geçirilebilir
- Stratejik SaaS ürünü refactor edilebilir
- Kullanılmayan uygulama retire edilebilir
- SaaS alternatifi bulunan sistem replace edilebilir
AWS ve Microsoft güncel migration rehberlerinde benzer şekilde workload bazında birden fazla strateji kullanılmasını önerir.
7R migration strategy nedir?
AWS'nin 7R modeli yedi temel yaklaşımı tanımlar:
- Rehost
- Replatform
- Refactor
- Repurchase
- Retire
- Retain
- Relocate
Bu modelin amacı her uygulamayı cloud'a taşımak değildir.
Bazı uygulamalar:
- olduğu gibi taşınabilir
- kısmen modernize edilebilir
- yeniden geliştirilebilir
- mevcut yerde tutulabilir
- tamamen kapatılabilir
Doğru migration programı bu seçeneklerin tamamını değerlendirmelidir.
Rehost nedir?
Rehost, uygulamayı minimum değişiklikle yeni altyapıya taşımaktır.
Bu yaklaşım bazen lift-and-shift olarak adlandırılır.
Örnek:
Mevcut ortam:
- Windows Server VM
- IIS
- SQL Server
- local disk
Hedef ortam:
- yeni cloud VM
- benzer Windows Server
- benzer IIS configuration
- benzer SQL Server yapısı
Uygulama koduna minimum müdahale edilir.
Rehost ne zaman uygundur?
Rehost özellikle zaman baskısı yüksek olduğunda değerlidir.
Örnek nedenler:
- veri merkezi sözleşmesi bitiyor
- donanım ömrü doluyor
- VMware maliyeti arttı
- mevcut sağlayıcıdan hızlı çıkış gerekiyor
- migration deadline sabit
Bu senaryolarda migration ile modernizasyonu aynı projede birleştirmek gereksiz risk yaratabilir.
Önce workload yeni altyapıya taşınabilir, ardından optimizasyon ayrı fazda yapılabilir.
Rehost'un avantajları
- Daha hızlı migration
- Daha az application değişikliği
- Daha düşük proje riski
- Test kapsamı daha sınırlı
- Ekip mevcut mimariyi koruyabilir
Rehost'un dezavantajları
Rehost mevcut teknik borcu da beraberinde taşıyabilir.
Örneğin:
- aşırı büyük VM
- eski işletim sistemi
- manuel deployment
- local storage bağımlılığı
- yüksek lisans maliyeti
yeni ortamda devam edebilir.
Bu nedenle rehost sonrası rightsizing ve modernizasyon backlog'u hazırlanmalıdır.
Replatform nedir?
Replatform, uygulamanın ana mimarisini korurken bazı altyapı bileşenlerini daha yönetilen veya cloud-native servislerle değiştirmektir.
Örnek:
Mevcut yapı:
- VM üzerinde PostgreSQL
- VM üzerinde Redis
- application VM
Replatform sonrası:
- managed PostgreSQL
- managed Redis
- application VM veya container
Uygulama kodunda sınırlı değişiklik gerekebilir.
Amaç tüm sistemi yeniden yazmak değil, yüksek operasyon yükü yaratan bileşenleri sadeleştirmektir.
Replatform ne zaman uygundur?
Replatform şu durumlarda güçlü adaydır:
- Database operasyonu ekip için yük oluşturuyor
- Backup/HA işlemleri manuel
- Application büyük refactor gerektirmeden managed service kullanabiliyor
- Cloud'a geçişle birlikte operasyon yükü azaltılmak isteniyor
- Uygulamanın yaşam süresi uzun
Replatform çoğu şirket için hız ile modernizasyon arasında orta yol olabilir.
Replatform'un riskleri
Managed service'e geçiş her zaman basit değildir.
Kontrol edilmesi gerekenler:
- extension desteği
- database version
- network latency
- backup modeli
- connection limit
- authentication
- provider-specific özellikler
Örneğin self-hosted PostgreSQL'den managed PostgreSQL'e geçerken kullanılan extension'ların desteklenmediği fark edilebilir.
Bu nedenle compatibility testi migration öncesinde yapılmalıdır.
Refactor nedir?
Refactor, uygulamanın kodunu veya mimarisini cloud ortamının yeteneklerinden daha fazla yararlanacak şekilde değiştirmektir.
Örnekler:
- monolith'i servis sınırlarına ayırmak
- local filesystem'i object storage'a taşımak
- session state'i dış servise almak
- event-driven architecture kullanmak
- uygulamayı container platformuna göre yeniden düzenlemek
Refactor migration stratejileri içinde en yüksek değişiklik miktarına sahip seçeneklerden biridir.
Refactor ne zaman uygundur?
Refactor şu durumlarda anlamlıdır:
- uygulama stratejik ve uzun ömürlü
- mevcut mimari ölçeklenmeyi engelliyor
- geliştirme hızı düşüyor
- yüksek availability hedefi mevcut yapıyla karşılanamıyor
- cloud özellikleri ürün avantajı yaratıyor
Ancak refactor sırf cloud'a geçildiği için yapılmamalıdır.
Migration projesi ile application rewrite'ı aynı anda yapmak takvim ve rollback riskini artırabilir.
Refactor'un maliyeti neden yüksektir?
Refactor yalnız altyapı değişikliği değildir.
Şunları gerektirebilir:
- development
- architecture
- test
- data migration
- CI/CD
- observability
- security review
Bu nedenle refactor maliyetini yalnız cloud faturasıyla karşılaştırmak yanlış olur.
Engineering zamanı toplam maliyetin önemli bölümüdür.
Rehost, replatform ve refactor karşılaştırması
| Kriter | Rehost | Replatform | Refactor |
|---|---|---|---|
| Kod değişikliği | Düşük | Düşük-Orta | Yüksek |
| Migration süresi | Kısa | Orta | Uzun |
| Proje riski | Düşük-Orta | Orta | Yüksek |
| Operasyon kazancı | Sınırlı | Orta-Yüksek | Yüksek olabilir |
| Cloud-native kullanım | Düşük | Orta | Yüksek |
| Rollback kolaylığı | Daha kolay | Orta | Daha zor |
| Engineering ihtiyacı | Düşük | Orta | Yüksek |
Bu tablo tek başına karar vermek için yeterli değildir.
Uygulamanın iş değeri ve kalan ömrü de hesaba katılmalıdır.
Retain nedir?
Retain, workload'u şimdilik mevcut ortamda bırakmaktır.
Bu başarısız migration anlamına gelmez.
Örneğin:
- lisans sözleşmesi devam ediyor
- uygulama 12 ay sonra kapanacak
- latency nedeniyle on-prem kalması gerekiyor
- migration riski iş değerinden yüksek
ise retain doğru karar olabilir.
Her workload'u cloud'a taşımak zorunlu değildir.
Retire nedir?
Retire, kullanılmayan uygulamanın kapatılmasıdır.
Migration inventory sırasında bazı sistemlerin:
- artık kullanılmadığı
- başka sistemle değiştirildiği
- yalnız birkaç kişinin eriştiği
- iş değeri kalmadığı
ortaya çıkabilir.
Bu workload'ları taşımak gereksiz migration maliyeti yaratır.
Bu nedenle inventory aşamasında retire adayları erken bulunmalıdır.
Replace veya repurchase nedir?
Bazı legacy uygulamaları taşımak yerine SaaS ürünle değiştirmek daha mantıklı olabilir.
Örnek:
- eski ticket sistemi → SaaS helpdesk
- self-hosted CRM → SaaS CRM
- eski file collaboration → modern collaboration platformu
Bu strateji application migration yerine business capability migration olarak düşünülmelidir.
Relocate nedir?
Relocate, özellikle sanallaştırma veya platform seviyesinde workload'u büyük application değişikliği yapmadan farklı ortama taşımayı ifade eder.
Örneğin belirli VMware ortamlarının benzer virtualization stack üzerinde cloud'a taşınması bu kategoriye girebilir.
Dynamis'in Broadcom sonrası VMware çıkış planı bu kararı lisans ve platform açısından ayrıca ele alır.
Strateji workload bazında seçilmelidir
Tüm uygulamaları tek migration stratejisiyle taşımak büyük hata olur.
Her workload için şu bilgiler toplanmalıdır:
- iş değeri
- kullanıcı sayısı
- downtime toleransı
- RPO/RTO
- bağımlılıklar
- teknik borç
- işletim sistemi
- database
- lisans
- security
- data location
- application owner
- beklenen yaşam süresi
Bu envanter olmadan “her şeyi rehost edeceğiz” veya “her şeyi Kubernetes'e taşıyacağız” kararları risklidir.
Uygulama ömrü stratejiyi değiştirir
Önümüzdeki 12 ay içinde kapanacak uygulamayı kapsamlı refactor etmek ekonomik olmayabilir.
Benzer şekilde 5-10 yıl çalışması beklenen stratejik SaaS uygulamasını yalnız lift-and-shift ile taşımak uzun vadeli maliyeti artırabilir.
Basit çerçeve:
Kısa ömür
- retain
- rehost
- retire
daha güçlü adaydır.
Orta ömür
- rehost
- replatform
değerlendirilebilir.
Uzun ömür ve stratejik değer
- replatform
- refactor
- rearchitect
daha fazla değer üretebilir.
Lisanslama migration stratejisini etkiler
Windows Server, SQL Server, Oracle, VMware ve ticari yazılımlar migration kararını doğrudan etkileyebilir.
Kontrol edin:
- lisans cloud'a taşınabiliyor mu?
- core/socket metriği değişiyor mu?
- shared infrastructure kullanım hakkı var mı?
- yeni ortamda subscription gerekiyor mu?
- support policy değişiyor mu?
Lisans maliyeti yüksek bir workload'da rehost teknik olarak kolay olsa bile ekonomik olarak yanlış olabilir.
Stateful workload'lar ayrı değerlendirilmelidir
Database ve dosya sistemi gibi stateful workload'lar migration stratejisinde daha dikkatli planlanmalıdır.
Sorular:
- veri ne kadar büyük?
- replication mümkün mü?
- downtime penceresi nedir?
- consistency nasıl korunacak?
- rollback sırasında veri nasıl geri dönecek?
Application server'ın rehost edilmesi kolay olabilir, ancak 5 TB database migration'ı projenin kritik yolunu belirleyebilir.
Rehost ile başlayıp sonra replatform etmek mümkün mü?
Evet.
Migration stratejisi tek seferlik karar olmak zorunda değildir.
Örnek iki aşamalı model:
Faz 1
Veri merkezi kapanmadan workload'u rehost edin.
Faz 2
Stabilizasyon sonrası:
- database managed service'e
- object storage'a
- container platformuna
geçirin.
Bu yaklaşım deadline ile modernizasyon riskini birbirinden ayırır.
Migration strategy ile migration wave aynı şey değildir
Migration strategy, workload'un nasıl taşınacağını belirler.
Migration wave ise workload'ların hangi sırayla taşınacağını belirler.
Örnek:
- ERP → rehost
- API → replatform
- eski reporting sistemi → retire
Bunlar strategy kararlarıdır.
Daha sonra bağımlılıklara göre:
- Wave 0: pilot
- Wave 1: düşük riskli servisler
- Wave 2: ERP + bağımlı database
şeklinde sıra belirlenebilir.
Bulut göçü migration wave planı sıralama kararını ayrı olarak açıklar.
Hızlı strateji matrisi
| Workload durumu | İlk değerlendirilecek strateji |
|---|---|
| Deadline çok yakın | Rehost |
| Operasyon yükü yüksek, kod büyük ölçüde uygun | Replatform |
| Stratejik uygulama, mimari büyümeyi engelliyor | Refactor |
| 12 ay içinde kapanacak | Retain veya retire |
| SaaS alternatifi güçlü | Replace |
| VMware ortamı platform seviyesinde taşınabilir | Relocate |
| Yüksek teknik borç, düşük iş değeri | Retire veya replace |
Bu tablo başlangıç noktasıdır.
Final karar discovery ve dependency analizi sonrası verilmelidir.
Migration öncesi pilot neden önemlidir?
Pilot workload seçimi migration stratejisinin gerçek ortamda doğrulanmasını sağlar.
İyi pilot:
- iş açısından kritik değildir
- gerçek dependency içerir
- gerçek network ve security modeli kullanır
- geri dönüş planı test edilebilir
Pilot yalnız teknik proof-of-concept olmamalıdır.
Aynı zamanda:
- runbook
- monitoring
- rollback
- cost
- operasyon
modelini test etmelidir.
Başarı kriteri önceden yazılmalıdır
Migration tamamlandı demek VM'in açılması değildir.
Her workload için başarı kriteri belirleyin.
Örnek:
- p95 latency eski ortamdan kötü değil
- tüm kritik transaction testleri geçti
- backup başarılı
- monitoring aktif
- RPO/RTO hedefi doğrulandı
- beklenen cloud maliyeti aralığında
Bu kriterler cutover kararını ölçülebilir hale getirir.
Rollback planı strategy seçimiyle birlikte yazılmalıdır
Her migration yaklaşımının rollback modeli farklıdır.
Rehost
Eski VM veya ortam belirli süre açık tutulabilir.
Replatform
Yeni managed service'e yazılan verinin eski ortama nasıl geri taşınacağı planlanmalıdır.
Refactor
Rollback daha karmaşık olabilir çünkü yeni application version ile data model değişmiş olabilir.
Migration başlamadan önce geri dönüş sınırı belirlenmelidir.
Örneğin:
“Cutover'dan sonraki ilk 60 dakika içinde kritik transaction başarısızlık oranı %X'i aşarsa eski ortama döneceğiz.”
AWS'den çıkışta strateji nasıl seçilir?
AWS'den çıkarken her workload'u başka provider'da aynı servisle birebir eşleştirmek zorunda değilsiniz.
Örneğin:
- EC2 workload → rehost
- RDS → managed PostgreSQL ile replatform
- eski Lambda workload → container ile refactor
- kullanılmayan test sistemi → retire
AWS'den çıkış bulut göçü planı sağlayıcı çıkışını maliyet ve migration planı açısından ayrıca ele alır.
Dynamis'te cloud migration strategy yaklaşımı
Dynamis'in bulut göçü çalışmalarında ilk adım hedef cloud'u seçmek değildir.
Önce:
- workload inventory
- dependency map
- iş değeri
- lisanslama
- RPO/RTO
- downtime
- teknik borç
- uygulama ömrü
çıkarılır.
Ardından her workload için:
- rehost
- replatform
- refactor
- retain
- retire
- replace
- relocate
kararı verilir.
Daha sonra workload'lar dependency ve risk durumuna göre migration wave'lerine ayrılır.
Amaç en fazla workload'u modernize etmek değil, en düşük iş riskiyle doğru hedef mimariye geçmektir.
Sık yapılan hatalar
Her workload'u rehost etmek: Hızlıdır ancak teknik borcu ve maliyet problemlerini yeni ortama taşıyabilir.
Her workload'u refactor etmek: Modernizasyon kapsamını gereksiz büyütür ve migration deadline'ını riske atabilir.
Strategy ile wave'i karıştırmak: Önce nasıl taşınacağı, sonra hangi sırayla taşınacağı belirlenmelidir.
Uygulama ömrünü hesaba katmamak: Yakında kapanacak sistemi modernize etmek gereksiz yatırım olabilir.
Rollback'i cutover günü düşünmek: Geri dönüş modeli migration tasarımının parçası olmalıdır.
Sırada ne var
- Cloud migration sırasında downtime nasıl minimuma indirilir?: strategy seçildikten sonra full copy, sürekli replication ve kontrollü cutover ile iş kesintisini azaltın.
- Cloud Migration Checklist: buluta geçmeden önce 30 kontrol: strategy kararından sonra cutover öncesi envanter, network, yedekleme, test ve rollback hazırlığını doğrulayın.
- Bulut göçü sırası: migration wave planı: workload strategy kararlarını bağımlılıklara göre migration sırasına dönüştürün.
- AWS'den çıkış: maliyeti düşüren bulut göçü planı: AWS workload'ları için çıkış ve hedef platform kararını planlayın.
- Broadcom sonrası VMware: lisanslama ve çıkış planı: VMware workload'larında relocate, rehost ve platform değişimi seçeneklerini karşılaştırın.
- Cloud Migration hizmetini inceleyin: mevcut workload'larınız için migration stratejisini değerlendirin.
Kaynaklar
Kaynaklar
- 1.Migration strategiesAmazon Web Services · 2026-09-21
- 2.Prioritization and migration strategyAmazon Web Services · 2026-09-21
- 3.Select cloud migration strategiesMicrosoft Learn · 2026-09-21
- 4.Modernization guidanceMicrosoft Learn · 2026-09-21
Sık sorulan sorular
Rehost, replatform ve refactor arasındaki fark nedir?
Rehost, uygulamayı minimum değişiklikle yeni altyapıya taşır. Replatform, uygulama mimarisini büyük ölçüde korurken veritabanı veya çalışma ortamı gibi bazı bileşenleri yönetilen hizmetlere geçirir. Refactor ise uygulama kodu veya mimarisinde daha kapsamlı değişiklik yaparak cloud-native yeteneklerden yararlanmayı hedefler.
Cloud migration stratejisi workload bazında mı seçilmeli?
Evet. Tek bir şirket için tüm uygulamalara aynı migration stratejisini uygulamak yerine her workload; iş değeri, bağımlılıkları, teknik borcu, downtime toleransı, lisanslama ve modernizasyon ihtiyacına göre ayrı değerlendirilmelidir.
Rehost hangi durumda daha uygundur?
Rehost; hızlı veri merkezi çıkışı, donanım sonu, lisans veya sözleşme takvimi gibi zaman baskısı olduğunda ve uygulamayı aynı anda modernize etmek gereksiz risk yaratıyorsa uygundur. Ancak mevcut verimsizlikleri yeni ortama taşıyabileceği için migration sonrası optimizasyon planı gerekir.
Refactor her zaman en iyi cloud migration stratejisi midir?
Hayır. Refactor daha fazla geliştirme, test ve geçiş riski yaratabilir. Uygulamanın stratejik değeri düşükse, kısa ömürlü ise veya mevcut mimari iş hedeflerini karşılıyorsa rehost, replatform, retain, retire veya replace daha uygun olabilir.
Migration wave ile migration stratejisi arasındaki fark nedir?
Migration stratejisi bir workload'un nasıl taşınacağını belirler; migration wave ise hangi workload'ların hangi sırayla ve birlikte taşınacağını belirler. Önce workload bazında hedef strateji seçilir, ardından bağımlılıklar ve risklere göre wave planı oluşturulur.