- 01Minimum downtime migration'ın temel modeli full copy, sürekli replication, kısa write freeze, final delta ve trafik cutover akışıdır.
- 02Zero downtime her workload için gerçekçi değildir; stateful sistemlerde çoğu zaman ölçülmüş kısa bir write freeze penceresi gerekir.
- 03DNS TTL, network, certificate, monitoring ve target application cutover öncesinde hazır olmalıdır.
- 04Rollback yalnız eski ortamı açık tutmak değildir; yeni ortama yazılan verinin geri dönüş stratejisi önceden belirlenmelidir.
- 05Blue-green ve canary modelleri stateless uygulamalarda trafik geçişini ve rollback'i daha kontrollü hale getirebilir.
Kısaca
Cloud migration sırasında downtime'ı minimuma indirmek için kaynak ve hedef ortamı mümkün olduğunca uzun süre paralel çalıştırmak, veriyi önceden taşımak, son değişiklikleri sürekli replikasyonla senkron tutmak ve cutover penceresini yalnız son delta ile trafik geçişine ayırmak gerekir. Dynamis Teknoloji, zero downtime ifadesini garanti olarak kullanmaz; hedef, workload'un teknik yapısına ve iş kabul kriterlerine göre ölçülmüş ve önceden onaylanmış minimum kesinti penceresidir.
Zero downtime migration ne anlama gelir?
Zero downtime migration, kullanıcıların geçiş sırasında hizmet kesintisini fark etmemesi veya kesintinin kabul edilebilir kadar kısa olması hedefidir.
Bu hedef her workload için mümkün değildir.
Özellikle stateful sistemlerde:
- database write
- session state
- file upload
- queue
- background job
- cache invalidation
gibi sürekli değişen durumlar vardır.
Bu nedenle birçok gerçek projede "sıfır kesinti" yerine "minimum downtime" daha doğru hedeftir.
Downtime neden oluşur?
Migration sırasında kesinti çoğunlukla şu nedenlerden biri yüzünden oluşur:
- son veri senkronizasyonu
- DNS veya load balancer geçişi
- application configuration değişikliği
- database endpoint değişimi
- certificate veya network değişikliği
- source sistemin write'a kapatılması
- smoke test ve validation
- rollback kararı
Kesinti süresini azaltmanın ana yolu bu işlerin mümkün olduğunca çoğunu cutover öncesinde bitirmektir.
Kesintiyi azaltmanın temel modeli
En yaygın düşük kesintili model şu şekildedir:
- Hedef ortamı önceden kur
- Full data copy yap
- Kaynak ve hedef arasında değişiklik replikasyonu başlat
- Hedef uygulamayı test et
- DNS ve network hazırlığını bitir
- Replication lag'i azalt
- Kısa write freeze uygula
- Son delta'yı senkronize et
- Trafiği hedefe geçir
- Smoke test yap
- Monitoring'i doğrula
- Rollback penceresini açık tut
Bu model cutover penceresinde yapılacak işi minimuma indirir.
Full copy neden cutover gününden önce yapılmalıdır?
Büyük veri setini migration günü kopyalamak downtime'ı doğrudan uzatır.
Örneğin 2 TB database'in tamamını cutover penceresinde taşımaya çalışmak yerine:
- full copy günler önce yapılır
- sonrasında yalnız değişiklikler replikasyonla taşınır
Böylece migration günü yalnız küçük delta kalır.
Bu yaklaşım database migration araçlarında change data capture veya sürekli replication modelleriyle uygulanabilir.
Change Data Capture nasıl yardımcı olur?
Change Data Capture, kaynak database'deki yeni değişikliklerin hedefe sürekli aktarılmasını sağlar.
Tipik akış:
- initial full load
- CDC başlat
- target sürekli güncel kalsın
- cutover öncesi lag'i düşür
- kısa write freeze
- final delta
- application endpoint değiştir
Bu model database migration downtime'ını önemli ölçüde azaltabilir.
Ancak source ve target engine uyumluluğu, schema değişiklikleri ve unsupported data type'lar önceden test edilmelidir.
Native replication ne zaman kullanılmalı?
Database'in kendi replication özelliği destekleniyorsa çoğu zaman güçlü seçenektir.
Örnekler:
- PostgreSQL logical replication
- MySQL replication
- SQL Server Always On veya replication modelleri
- managed database replication
Ancak engine sürümü, extension, collation ve authentication farkları migration öncesi doğrulanmalıdır.
Uygulama write freeze neden gerekir?
Stateful migration'da son senkronizasyon için kısa süreli write freeze gerekebilir.
Write freeze sırasında:
- yeni kayıt alınmaz
- update yapılmaz
- background job durdurulur
- queue consumer gerekirse pause edilir
Amaç source ile target arasında yeni fark oluşmasını engellemektir.
Write freeze penceresi ne kadar kısa olursa kullanıcı etkisi o kadar azalır.
Read-only mode nasıl kullanılabilir?
Tam outage yerine uygulamayı geçici read-only moda almak bazı sistemlerde daha iyi deneyim sağlayabilir.
Örneğin kullanıcılar:
- raporları görebilir
- geçmiş veriyi okuyabilir
- dashboard açabilir
ancak yeni kayıt oluşturamaz.
Bu model özellikle back-office uygulamalarda işe yarayabilir.
Ancak business owner read-only davranışı önceden onaylamalıdır.
Blue-green migration nedir?
Blue-green yaklaşımda eski ve yeni ortam paralel çalışır.
- Blue: mevcut production
- Green: yeni target
Green ortam önceden:
- deploy edilir
- veri ile senkron tutulur
- test edilir
- monitoring'e bağlanır
Cutover anında trafik green ortama yönlendirilir.
Sorun çıkarsa trafik tekrar blue ortama döndürülebilir.
Bu yaklaşım rollback'i hızlandırabilir.
Blue-green her workload için uygun mu?
Hayır.
Stateless web uygulamalarında kolaydır.
Stateful sistemlerde veri senkronizasyonu karmaşıktır.
Eğer blue ve green aynı anda write alırsa:
- split-brain
- duplicate transaction
- veri divergence
oluşabilir.
Bu nedenle write ownership net olmalıdır.
DNS cutover downtime'ı nasıl etkiler?
DNS geçişi trafik yönünü değiştirmek için sık kullanılan yöntemdir.
Ancak DNS cache davranışı nedeniyle değişiklik anında tüm kullanıcılar yeni adrese geçmez.
Kesintiyi azaltmak için:
- TTL migration öncesinde düşürülür
- eski ve yeni ortam paralel çalışır
- her iki ortam geçici süre request kabul eder
- geçiş stabil olduktan sonra TTL yükseltilir
DNS tek başına zero downtime sağlamaz.
Application ve database katmanının da paralel çalışmaya uygun olması gerekir.
DNS TTL ne zaman düşürülmeli?
Mevcut yüksek TTL değerinin cache'lerden çıkması için cutover'dan önce düşürülmelidir.
Pratikte çoğu ekip bunu migration'dan bir veya iki gün önce yapar.
Örneğin:
- mevcut TTL: 24 saat
- migration'dan 48 saat önce: 300 saniyeye düşür
- cutover sonrası stabiliteyi doğrula
- sonra tekrar normal değere çıkar
Bu süre mevcut TTL ve resolver davranışına göre değişebilir.
Load balancer ile cutover daha kontrollü olabilir
DNS yerine load balancer veya reverse proxy üzerinden backend değişimi yapılabiliyorsa geçiş daha kontrollü olabilir.
Örnek:
- Yeni backend pool oluştur
- Health check doğrula
- Trafiğin küçük kısmını yeni ortama gönder
- Error rate ve latency izle
- Trafiği kademeli artır
- Eski backend'i çıkar
Bu model weighted traffic veya canary migration olarak uygulanabilir.
Canary migration ne sağlar?
Canary modelinde tüm trafik bir anda yeni ortama geçmez.
Örneğin:
- %5
- %20
- %50
- %100
şeklinde kademeli artış yapılabilir.
Bu sırada:
- error rate
- latency
- CPU
- database connection
- transaction success
izlenir.
Sorun görülürse trafik kolayca geri çevrilebilir.
Database endpoint değişikliği nasıl yönetilmeli?
Application içinde database IP veya hostname hardcode edilmemelidir.
Tercihen:
- environment variable
- secret
- service discovery
- internal DNS alias
kullanılmalıdır.
Bu sayede cutover sırasında kod değişikliği yerine configuration değişikliği yapılabilir.
Session state downtime yaratabilir mi?
Evet.
Application session bilgisi local memory veya local disk'te tutuluyorsa kullanıcılar yeni ortama geçtiğinde session kaybedebilir.
Bunu azaltmak için:
- external Redis
- shared session store
- token-based session
kullanılabilir.
Migration öncesi session architecture kontrol edilmelidir.
Dosya yüklemeleri nasıl taşınmalı?
Local disk'e yazılan user file'ları migration'ı zorlaştırır.
Çünkü source ve target aynı anda farklı dosyalar alabilir.
Daha güvenli modeller:
- shared object storage
- shared filesystem
- continuous file sync
- write freeze
olabilir.
Uzun vadede application state'i local disk'ten çıkarmak migration kolaylığı sağlar.
Queue ve background job nasıl yönetilmeli?
Background worker'lar migration sırasında duplicate işlem yaratabilir.
Cutover öncesi:
- worker pause
- queue depth kontrolü
- in-flight job takibi
- idempotency
planlanmalıdır.
Source ve target worker aynı queue'yu aynı anda tüketiyorsa beklenmeyen işleme davranışı oluşabilir.
Cron ve scheduled task'lar unutulmamalıdır
Scheduled task'lar migration sırasında çift çalışabilir.
Örneğin:
- invoice generation
- billing
- report
- backup
job'ları source ve target'ta aynı anda tetiklenirse duplicate sonuç oluşabilir.
Cutover runbook içinde scheduled task ownership açık olmalıdır.
Firewall ve network cutover önceden test edilmelidir
Migration günü firewall rule açmak downtime'ı uzatır.
Target ortamdan önceden test edin:
- database
- API
- SMTP
- LDAP/AD
- object storage
- external service
- monitoring
bağlantıları çalışıyor mu?
Network readiness Cloud Migration Checklist içindeki go/no-go kontrollerinden biridir.
Certificate geçişi nasıl hazırlanmalı?
Yeni ortam TLS trafiği alacaksa certificate önceden hazır olmalıdır.
Kontrol edin:
- certificate
- private key
- intermediate chain
- hostname
- renewal
- load balancer configuration
Cutover sonrası certificate üretmeye başlamak kesinti penceresini gereksiz büyütür.
Monitoring cutover öncesinde çalışmalıdır
Yeni ortam production trafiği almadan önce telemetry akmalıdır.
En az şu sinyalleri takip edin:
- HTTP error rate
- p95 latency
- CPU
- RAM
- database connections
- queue
- disk
- application exceptions
Cutover sonrası ilk 15-60 dakika en kritik observation penceresidir.
Başarı kriteri cutover öncesinde yazılmalıdır
Migration başarılı sayılmadan önce hangi testlerin geçmesi gerektiği belirlenmelidir.
Örnek:
- login başarılı
- ödeme başarılı
- write/read transaction başarılı
- latency baseline içinde
- error rate normal
- database replication tamam
- backup aktif
Bu kriterler olmadığında ekip “çalışıyor gibi” değerlendirmesi yapar.
Rollback kriteri de önceden yazılmalıdır
Rollback kararı migration sırasında tartışılmamalıdır.
Örnek kriterler:
- kritik transaction başarısız
- error rate kabul edilen sınırın üzerinde
- data consistency problemi
- target database lag
- latency ciddi artmış
Bunlardan biri gerçekleşirse geri dönüş otomatik veya manuel olarak tetiklenmelidir.
Rollback neden zamanla zorlaşır?
Yeni ortam write almaya başladıktan sonra source ve target veri setleri farklılaşır.
Bu nedenle rollback penceresi sonsuz değildir.
Örneğin:
- ilk 30 dakika kolay rollback
- 4 saat sonra daha karmaşık
- 24 saat sonra reverse replication gerekebilir
Bu yüzden point of no return migration öncesinde tanımlanmalıdır.
Eski ortam ne kadar açık tutulmalı?
Eski ortam yeni production stabil olduğu doğrulanana kadar korunmalıdır.
Ancak yalnız açık tutmak yeterli değildir.
Şunlar belirlenmelidir:
- read-only mi?
- write kabul edecek mi?
- replication devam edecek mi?
- ne zaman kapatılacak?
- backup alınacak mı?
Bu karar workload'a göre değişir.
Zero downtime migration için hangi mimari daha uygundur?
Aşağıdaki özellikler geçişi kolaylaştırır:
- stateless application
- external session store
- object storage
- replicated database
- load balancer
- immutable deployment
- automated configuration
- monitoring
- Infrastructure as Code
Bu özellikler migration için özel geliştirilmiş olmak zorunda değildir.
İyi production mimarisi doğal olarak migration riskini azaltır.
Monolith migration neden daha zor olabilir?
Monolith uygulamalarda:
- application
- local file
- session
- database
- scheduled task
birbirine sıkı bağlı olabilir.
Bu durumda bile tüm sistemi refactor etmek zorunlu değildir.
Önce rehost veya replatform ile düşük downtime migration yapılabilir.
Modernizasyon daha sonra ayrı faz olarak yürütülebilir.
Cloud migration strategy rehost, replatform ve refactor seçimini ayrıca açıklar.
Migration wave downtime riskini nasıl azaltır?
Tüm sistemi tek cutover penceresine koymak riski büyütür.
Wave yaklaşımında:
- pilot
- düşük riskli workload
- orta kritik workload
- kritik workload
şeklinde ilerlenebilir.
İlk wave'lerden öğrenilen:
- DNS
- network
- tool
- runbook
- rollback
sorunları kritik workload'a geçmeden düzeltilir.
Bulut göçü sırası bu planı dependency bazında açıklar.
Cutover provası yapılmalı mı?
Evet.
Production öncesi dry run şu alanları doğrular:
- süre
- komut sırası
- veri transferi
- DNS
- test
- owner
- rollback
Gerçek cutover süresi tahmin yerine ölçülmüş olur.
Cutover runbook örneği
Adım 1: Go/no-go onayı
Checklist tamamlanmış olmalı.
Adım 2: Change freeze
Yeni deploy ve config değişikliği durdurulur.
Adım 3: Replication lag kontrolü
Target source'a yakın olmalıdır.
Adım 4: Write freeze
Gerekliyse uygulama read-only moda alınır.
Adım 5: Final delta
Son değişiklikler hedefe aktarılır.
Adım 6: Application endpoint değişimi
Database ve internal servis endpoint'leri target'a çevrilir.
Adım 7: Trafik geçişi
DNS, load balancer veya proxy yönlendirilir.
Adım 8: Smoke test
Kritik transaction çalıştırılır.
Adım 9: Monitoring kontrolü
Error rate ve latency izlenir.
Adım 10: Business owner onayı
İş fonksiyonu doğrulanır.
Adım 11: Rollback penceresi
Eski ortam korunur.
Kesinti bütçesi nasıl hesaplanmalı?
Cutover öncesinde tahmini süreyi parçalara ayırın.
Örnek:
| Adım | Süre |
|---|---|
| Write freeze | 2 dk |
| Final sync | 5 dk |
| Endpoint change | 2 dk |
| Smoke test | 5 dk |
| Business validation | 5 dk |
Bu örnekte teorik minimum downtime yaklaşık 19 dakikadır.
Ama retry, DNS cache ve beklenmeyen validation süresi için buffer eklenmelidir.
Bu tablo gerçek workload verisiyle hazırlanmalıdır.
Zero downtime hedefi ne zaman gereksiz olabilir?
Her workload için sıfır kesinti tasarlamak maliyeti artırabilir.
Örneğin:
- iç raporlama sistemi
- hafta sonu kullanılmayan ERP
- düşük kritik test ortamı
için 30 dakikalık bakım penceresi kabul edilebilir olabilir.
Bu durumda complex active-active mimari kurmak gereksizdir.
İş hedefi teknik idealden önce gelmelidir.
Dynamis'te downtime azaltma yaklaşımı
Dynamis'in Cloud Migration hizmetinde migration cutover planı workload bazında hazırlanır.
Önce:
- kabul edilen downtime
- data change rate
- replication yöntemi
- DNS
- network
- rollback
- business validation
belirlenir.
Ardından full copy ve replication cutover öncesinde tamamlanır.
Migration günü yalnız son delta ve trafik geçişi yapılır.
Amaç "zero downtime" etiketi satmak değil, iş açısından kabul edilen kesinti penceresini ölçülebilir biçimde küçültmektir.
Sık yapılan hatalar
Full data copy'yi cutover gününe bırakmak: Veriyi önceden taşıyın ve yalnız delta'yı migration gününde senkronize edin.
DNS TTL'yi geç düşürmek: Cache süresini migration öncesinde azaltın.
Monitoring'i migration sonrası kurmak: Target production olmadan telemetry hazır olmalı.
Rollback'i yalnız eski VM'i açık tutmak sanmak: Yeni verinin source'a nasıl döneceğini planlayın.
Source ve target worker'ı aynı anda çalıştırmak: Duplicate job riskini kontrol edin.
Zero downtime'ı her workload için zorunlu hedef yapmak: İş tarafından kabul edilen bakım penceresini önce belirleyin.
Sırada ne var
- Cloud Migration Checklist: cutover öncesi go/no-go hazırlığını tamamlayın.
- Cloud migration strategy: workload'un nasıl taşınacağını belirleyin.
- Bulut göçü sırası: kritik workload'ları doğru sıraya yerleştirin.
- Cloud Migration hizmetini inceleyin: migration downtime ve rollback planınızı değerlendirin.
Kaynaklar
Kaynaklar
- 1.Ongoing replication using AWS DMSAmazon Web Services · 2026-09-22
- 2.Migration cutoverAmazon Web Services · 2026-09-22
- 3.Plan your migrationMicrosoft Learn · 2026-09-22
- 4.DNS migrationGoogle Cloud · 2026-09-22
Sık sorulan sorular
Zero downtime migration gerçekten mümkün mü?
Bazı stateless veya aktif-aktif mimarilerde kullanıcı tarafından fark edilmeyen geçiş mümkün olabilir. Ancak stateful uygulamalarda çoğu zaman kısa bir write freeze, son veri senkronizasyonu ve cutover penceresi gerekir. Bu nedenle hedef çoğu projede mutlak sıfır kesinti değil, ölçülmüş ve kabul edilmiş minimum kesinti olmalıdır.
Cloud migration sırasında downtime nasıl azaltılır?
Kaynak ve hedef sistemi bir süre paralel çalıştırın, veriyi önceden kopyalayın, değişiklikleri sürekli replikasyonla senkron tutun, DNS ve ağ hazırlığını önceden tamamlayın, cutover runbook'u prova edin ve son yazma durdurma penceresini yalnız son delta için kullanın.
Database migration için minimum downtime nasıl sağlanır?
Full copy sonrasında change data capture veya database-native replication kullanarak kaynak ve hedefi senkron tutun. Cutover öncesi replication lag'i kabul edilen seviyeye indirin, kısa süreli write freeze uygulayın, son değişiklikleri hedefe aktarın ve uygulamayı yeni database'e yönlendirin.
DNS TTL migration öncesinde ne zaman düşürülmeli?
TTL değişikliğinin mevcut DNS cache'lerinden çıkması için cutover'dan yeterince önce yapılmalıdır. Uygulamaya ve mevcut TTL değerine göre çoğu senaryoda 24-48 saat önceden düşürmek kullanışlıdır. Geçiş stabil olduktan sonra TTL yeniden normal seviyeye yükseltilmelidir.
Migration rollback için eski ortam ne kadar süre açık tutulmalı?
Süre workload'un veri değişim hızına, rollback yöntemine ve kabul testlerine bağlıdır. Eski ortam, yeni production'ın kritik işlevleri ve veri bütünlüğü doğrulanana kadar korunmalıdır. Ancak yeni ortama veri yazılmaya başladıktan sonra rollback yönteminin nasıl çalışacağı cutover öncesinde tanımlanmalıdır.