- 01Cloud migration checklist yalnız teknik uyumluluğu değil, iş hedefi, sahiplik, güvenlik, operasyon ve rollback hazırlığını birlikte doğrulamalıdır.
- 02Workload envanteri ve bağımlılık haritası tamamlanmadan migration strategy ve wave planı güvenilir şekilde oluşturulamaz.
- 03Backup bulunması yeterli değildir; son recovery point ve gerçek geri yükleme testi cutover öncesinde doğrulanmalıdır.
- 04Monitoring, logging, DNS, sertifika ve security baseline target ortam production trafiği almadan önce hazır olmalıdır.
- 05Go/no-go toplantısında kritik checklist maddelerinden biri eksikse takvim baskısına rağmen migration ertelenmelidir.
Kısaca
Cloud migration checklist, cutover öncesinde teknik ve operasyonel hazırlığın gerçekten tamamlandığını doğrulayan go/no-go kontrol listesidir. Dynamis Teknoloji, buluta geçişte yalnız sunucu ve veritabanı taşımayı değil; envanter, bağımlılık, kimlik, ağ, güvenlik, yedekleme, gözlemlenebilirlik, maliyet, test, rollback ve sorumluluk alanlarını birlikte değerlendirir. İyi bir checklist, migration günü yeni kararlar üretmez; kritik kararların çoğunu önceden kapatır.
Cloud migration checklist neden gereklidir?
Migration projelerinde en pahalı hatalar çoğu zaman taşıma aracından değil, eksik hazırlıktan çıkar.
Yaygın örnekler:
- unutulan DNS kaydı
- görünmeyen üçüncü taraf bağımlılık
- rollback sırasında senkronize edilemeyen veri
- yeni ortamda eksik firewall rule
- lisans kısıtı
- geri yüklenmemiş yedek
- monitoring'in cutover sonrası çalışmaması
- uygulama sahibinin onay kriterinin belirsiz olması
Checklist bu riskleri migration gününden önce görünür hale getirir.
1. İş hedefini yazılı hale getirin
Migration'ın neden yapıldığını tek cümleyle yazabilmelisiniz.
Örnek hedefler:
- veri merkezi kapanışı
- AWS maliyetini düşürmek
- VMware lisanslama riskini azaltmak
- Türkiye lokasyonuna geçmek
- daha yüksek erişilebilirlik
- operasyon yükünü azaltmak
Hedef net değilse teknik ekip “taşıdık” diyebilir ancak proje iş açısından başarısız olabilir.
2. Başarı kriterini önceden belirleyin
Başarı yalnız VM'in açılması değildir.
Her workload için ölçülebilir kriter belirleyin:
- uygulama erişilebilir
- kritik transaction testleri geçti
- p95 latency kabul edilen aralıkta
- veri bütünlüğü doğrulandı
- backup aktif
- monitoring veri topluyor
- beklenen maliyet aralığında
Bu kriterler cutover sonrası go/no-go kararını kolaylaştırır.
3. Workload envanterini tamamlayın
Taşınacak tüm varlıkları listeleyin:
- sanal sunucular
- fiziksel sunucular
- veritabanları
- dosya servisleri
- object storage
- queue
- cache
- load balancer
- DNS kayıtları
- sertifikalar
- cron ve scheduled task
- third-party integration
- monitoring agent
- backup job
Envanterde owner alanı mutlaka bulunmalıdır.
Sahibi belli olmayan workload migration riski taşır.
4. Bağımlılık haritasını çıkarın
Her uygulamanın hangi servislere bağlı olduğunu belirleyin.
Kontrol edin:
- database
- Active Directory veya kimlik servisi
- DNS
- SMTP
- dosya paylaşımı
- lisans sunucusu
- ödeme sağlayıcısı
- üçüncü taraf API
- queue
- cache
- internal API
Bulut göçü sırası: bağımlılıklara göre migration wave planı bu bağımlılıkları taşıma sırasına dönüştürür.
5. Her workload için migration strategy belirleyin
Checklist yalnız readiness kontrolü yapmalı; strategy kararı migration gününe bırakılmamalıdır.
Her workload için aşağıdaki seçeneklerden biri belirlenmiş olmalıdır:
- rehost
- replatform
- refactor
- retain
- retire
- replace
- relocate
Cloud migration strategy bu karar çerçevesini ayrıntılı açıklar.
6. Hedef mimariyi dokümante edin
Yeni ortamın diyagramı migration başlamadan hazır olmalıdır.
En az şu katmanları gösterin:
- network
- subnet
- routing
- firewall
- public/private erişim
- load balancer
- compute
- storage
- database
- backup
- monitoring
- DNS
Migration sırasında mimari tasarlamak cutover riskini artırır.
7. Landing zone hazırlığını doğrulayın
Hedef cloud hesabı veya subscription yapısı önceden hazırlanmalıdır.
Kontrol edin:
- account/project yapısı
- region
- network
- IAM
- log toplama
- tagging
- bütçe uyarıları
- backup policy
- security baseline
Workload hazır olsa bile landing zone hazır değilse migration ertelenmelidir.
8. Kimlik ve erişim modelini kontrol edin
Yeni ortamda kimin neye erişeceği migration öncesinde tanımlanmalıdır.
Kontrol edin:
- admin hesapları
- MFA
- service account
- least privilege
- emergency access
- break-glass hesapları
- SSH/RDP erişimi
- secret yönetimi
Geçiş sırasında geçici olarak oluşturulan geniş yetkiler proje sonunda temizlenmelidir.
9. Ağ bağlantısını test edin
Network sorunları migration günü en sık kesinti nedenlerinden biridir.
Kontrol edin:
- source → target bağlantı
- target → source bağlantı
- DNS çözümleme
- VPN
- private link
- NAT
- firewall
- security group
- proxy
- outbound erişim
Port listeleri uygulama owner'ı ile doğrulanmalıdır.
10. DNS cutover planını hazırlayın
DNS değişikliği için şu alanlar önceden planlanmalıdır:
- kayıt listesi
- TTL
- eski IP
- yeni IP
- değişiklik zamanı
- rollback kaydı
- propagation kontrolü
Cutover'dan önce TTL düşürmek bazı senaryolarda geri dönüşü hızlandırabilir.
Ancak düşük TTL tek başına zero downtime sağlamaz.
11. Sertifikaları doğrulayın
Yeni ortamda TLS sertifikalarının hazır olduğundan emin olun.
Kontrol edin:
- domain
- SAN
- private key
- certificate chain
- expiry
- renewal yöntemi
- load balancer termination noktası
Sertifika migration sonrası ilk kez oluşturulmamalıdır.
12. Lisanslama uygunluğunu kontrol edin
Ticari yazılımların yeni ortamdaki kullanım haklarını doğrulayın.
Özellikle:
- Windows Server
- SQL Server
- Oracle
- VMware
- backup yazılımı
- security ürünü
için lisans modelinin yeni host, core, VM veya cloud kullanımına izin verip vermediğini kontrol edin.
Lisans uygun değilse teknik olarak çalışan migration ticari açıdan hatalı olabilir.
13. Yedeklemeyi migration öncesinde doğrulayın
Migration'dan önce son başarılı yedek görünür olmalıdır.
Kontrol edin:
- son başarılı backup zamanı
- recovery point
- retention
- storage erişimi
- encryption key erişimi
Ancak “backup var” yeterli değildir.
14. Geri yükleme testi yapın
Yedeklemenin geri döndüğünü doğrulayın.
Test sırasında:
- veri açılıyor mu?
- uygulama ayağa kalkıyor mu?
- database consistency doğru mu?
- gerekli credential mevcut mu?
- restore süresi kabul edilebilir mi?
kontrol edilmelidir.
Yedek geri yükleme testi bu süreci ayrı olarak detaylandırır.
15. Veri migration yöntemini belirleyin
Verinin nasıl taşınacağını önceden belirleyin.
Seçenekler:
- offline copy
- snapshot
- replication
- database-native replication
- incremental sync
- export/import
Veri hacmi ve değişim oranı migration penceresini doğrudan etkiler.
16. Son senkronizasyon yöntemini planlayın
Initial copy ile cutover arasındaki yeni verinin nasıl taşınacağını belirleyin.
Örneğin:
- Full copy
- Incremental sync
- Yazma durdurma
- Son delta
- Cutover
Bu akış yazılmadan veri migration başlatılmamalıdır.
17. Rollback planını yazılı hale getirin
Rollback planı migration'ın ayrılmaz parçasıdır.
Şunları yazın:
- rollback kriteri
- karar sahibi
- son geri dönüş zamanı
- eski ortamın ne kadar açık tutulacağı
- yeni verinin eski ortama nasıl döneceği
- DNS geri dönüş adımı
Rollback yalnız “gerekirse eski sisteme döneriz” cümlesi değildir.
18. Rollback sınırını belirleyin
Her migration'ın geri dönülebilir olduğu bir zaman penceresi vardır.
Örneğin yeni ortama birkaç saat veri yazıldıktan sonra eski database'e dönüş karmaşıklaşabilir.
Bu nedenle “point of no return” açıkça tanımlanmalıdır.
19. Monitoring'i cutover öncesinde hazırlayın
Yeni ortam production trafiği almadan önce monitoring aktif olmalıdır.
En az şu sinyalleri kontrol edin:
- CPU
- RAM
- disk
- network
- application error
- latency
- database connection
- HTTP status
- certificate
- backup
Cutover sonrası monitoring kurmaya başlamak geç kalmaktır.
20. Log erişimini doğrulayın
Application ve infrastructure loglarının yeni ortamda erişilebilir olduğundan emin olun.
Kontrol edin:
- timestamp
- timezone
- retention
- central logging
- search
- access permissions
Incident sırasında log toplanmadığını fark etmek troubleshooting süresini uzatır.
21. Performance baseline alın
Migration öncesinde mevcut ortamın performansını ölçün.
En az:
- CPU
- RAM
- disk latency
- network
- application latency
- request rate
- database query latency
baseline olarak saklanmalıdır.
Yeni ortamın performansı ancak eski ortamla karşılaştırıldığında anlamlıdır.
22. Kapasite planını doğrulayın
Yeni kaynakları yalnız mevcut ortamdaki VM boyutlarını kopyalayarak seçmeyin.
Rehost yapıyor olsanız bile:
- gerçek CPU kullanımı
- peak memory
- disk IOPS
- network
- büyüme beklentisi
kontrol edilmelidir.
Eski ortamın aşırı büyük kaynaklarını birebir taşımak cloud maliyetini gereksiz yükseltebilir.
23. Güvenlik baseline'ını uygulayın
Migration öncesinde:
- firewall
- MFA
- admin erişimi
- patch seviyesi
- endpoint protection
- disk encryption
- secret yönetimi
- audit logging
hazır olmalıdır.
Cloud'a geçiş eski güvenlik açıklarını otomatik olarak düzeltmez.
24. KVKK ve veri konumunu kontrol edin
Kişisel veri işleyen workload'larda:
- veri konumu
- aktarım
- erişim
- alt işleyen
- retention
- silme
kararları hukuk ve uyum sahipleriyle birlikte değerlendirilmelidir.
Teknik ekip migration sırasında bu kararı tek başına vermemelidir.
25. Uygulama kabul testlerini hazırlayın
Migration sonrası test edilecek işlevleri önceden listeleyin.
Örnek:
- login
- ödeme
- sipariş
- rapor
- dosya yükleme
- e-posta
- background job
- API integration
“Site açılıyor” kabul testi değildir.
26. Cutover runbook oluşturun
Migration günü yapılacak adımlar sıra numarasıyla yazılmalıdır.
Örnek:
- Change freeze başlat
- Final backup al
- Son senkronizasyonu çalıştır
- Uygulamayı target ortamda aç
- Smoke test yap
- DNS değiştir
- Monitoring kontrol et
- Business owner onayı al
Her adımın sahibi bulunmalıdır.
27. Change freeze penceresini belirleyin
Migration sırasında kaynak ortamda kontrolsüz değişiklik yapılmamalıdır.
Freeze kapsamına göre:
- code deployment
- schema change
- firewall değişikliği
- kullanıcı oluşturma
- config update
geçici olarak durdurulabilir.
Bu karar ilgili ekiplerle önceden paylaşılmalıdır.
28. İletişim planını hazırlayın
Migration günü kimlerin hangi kanalda bulunacağı belli olmalıdır.
Katılımcılar:
- application owner
- infrastructure
- database
- security
- business owner
- provider
olabilir.
Incident escalation zinciri migration başlamadan belirlenmelidir.
29. Go/no-go toplantısı yapın
Cutover'dan hemen önce checklist sonuçları gözden geçirilmelidir.
No-go nedeni olabilecek örnekler:
- restore testi başarısız
- critical dependency belirsiz
- target monitoring çalışmıyor
- rollback planı yok
- lisans uygunluğu doğrulanmamış
- target network tamamlanmamış
Takvim baskısı bu maddeleri görmezden gelmek için gerekçe değildir.
30. Migration sonrası gözlem penceresi belirleyin
Cutover sonrası ekip hemen projeden çıkmamalıdır.
İlk saatlerde:
- error rate
- latency
- business transaction
- resource usage
- queue
- database
- backup
yakından izlenmelidir.
Migration tamamlanma kriteri observation window sonunda verilmelidir.
Hızlı go/no-go kontrol tablosu
| Kontrol | Hazır mı? |
|---|---|
| İş hedefi ve başarı kriteri | ☐ |
| Workload envanteri | ☐ |
| Bağımlılık haritası | ☐ |
| Migration strategy | ☐ |
| Hedef mimari | ☐ |
| Landing zone | ☐ |
| IAM ve erişim | ☐ |
| Network | ☐ |
| DNS | ☐ |
| Sertifika | ☐ |
| Lisans | ☐ |
| Backup | ☐ |
| Restore testi | ☐ |
| Veri senkronizasyonu | ☐ |
| Rollback | ☐ |
| Monitoring | ☐ |
| Logging | ☐ |
| Performance baseline | ☐ |
| Security | ☐ |
| KVKK/veri konumu | ☐ |
| UAT | ☐ |
| Cutover runbook | ☐ |
| Change freeze | ☐ |
| İletişim planı | ☐ |
| Go/no-go onayı | ☐ |
Kritik alanlardan biri eksikse migration tarihini yeniden değerlendirin.
Checklist'i migration runbook'una bağlayın
Checklist'in görevi bir hizmet teklifini anlatmak değil, cutover öncesinde eksik kararları görünür hale getirmektir. İş hedefi, workload envanteri, bağımlılıklar, lisanslama, RPO/RTO, security, network ve operasyon sahipliği kapatılmadan migration tarihini kesinleştirmeyin.
Hazırlık tamamlandığında her workload için migration strategy, wave, rollback sınırı ve kabul kriteri runbook'a aktarılmalıdır. Böylece migration günü yeni karar üretmek yerine önceden doğrulanmış plan uygulanır.
Planlama ve uygulama sorumluluğunu dış kaynakla yürütmek istiyorsanız Cloud Migration hizmeti ticari owner sayfasıdır; bu checklist ise hazırlık ve go/no-go kontrolü için supporting içeriktir.
Sık yapılan hatalar
Yedek var diye geri dönüşün hazır olduğunu sanmak: Restore testini ayrıca yapın.
DNS'i son dakikaya bırakmak: TTL, kayıt ve rollback adımını önceden yazın.
Her workload'u aynı gün taşımak: Dependency ve risk durumuna göre wave planlayın.
Monitoring'i migration sonrası kurmak: Target ortam production olmadan telemetry hazır olmalıdır.
Rollback kriterini belirsiz bırakmak: Ne zaman geri dönüleceğini ölçülebilir şekilde tanımlayın.
Business owner onayını atlamak: Teknik başarı ile iş başarısını ayrı doğrulayın.
Sırada ne var
- Cloud migration sırasında downtime nasıl minimuma indirilir?: checklist tamamlandıktan sonra replication, DNS cutover, write freeze ve rollback ile kesinti penceresini küçültün.
- Cloud migration strategy: rehost, replatform ve refactor: her workload'un nasıl taşınacağını belirleyin.
- Bulut göçü sırası: migration wave planı: workload'ları bağımlılık ve risk durumuna göre sıralayın.
- AWS'den çıkış: maliyeti düşüren bulut göçü planı: sağlayıcı çıkışında checklist'i gerçek migration planına bağlayın.
- Cloud Migration hizmeti: migration planlama, geçiş ve cutover kapsamını değerlendirin.
Kaynaklar
Kaynaklar
- 1.AWS Cloud Adoption FrameworkAmazon Web Services · 2026-09-22
- 2.Application portfolio assessment guideAmazon Web Services · 2026-09-22
- 3.Plan your migrationMicrosoft Learn · 2026-09-22
- 4.Prepare your organization for the cloudMicrosoft Learn · 2026-09-22
Sık sorulan sorular
Cloud migration checklist nedir?
Cloud migration checklist, bir iş yükünü buluta taşımadan önce envanter, bağımlılık, kimlik, ağ, güvenlik, yedekleme, gözlemlenebilirlik, test, rollback ve sorumluluk alanlarının hazır olup olmadığını doğrulayan kontrol listesidir.
Buluta geçmeden önce hangi bağımlılıklar çıkarılmalı?
Uygulamanın veritabanı, DNS, Active Directory veya kimlik servisi, dosya paylaşımı, üçüncü taraf API, lisans sunucusu, SMTP, queue, storage ve diğer iç servis bağımlılıkları çıkarılmalıdır. Bu bağımlılıklar migration wave ve cutover sırasını doğrudan etkiler.
Cloud migration öncesi rollback planı neden gereklidir?
Cutover sonrası kritik işlev, veri bütünlüğü veya performans hedefleri karşılanmazsa eski ortama güvenli dönüş için rollback planı gerekir. Geri dönüş kriteri, karar sahibi, veri senkronizasyon yöntemi ve son geri dönüş zamanı migration öncesinde yazılmalıdır.
Cloud migration öncesi backup yeterli midir?
Hayır. Yedekleme gerekli ancak tek başına yeterli değildir. Geri yükleme testi yapılmalı, son başarılı recovery point doğrulanmalı ve migration sırasında oluşacak yeni verinin rollback senaryosunda nasıl korunacağı ayrıca planlanmalıdır.
Cloud migration readiness nasıl ölçülür?
Readiness yalnız teknik uyumlulukla ölçülmez. İş hedefi, paydaş sahipliği, ekip yetkinliği, yönetişim, güvenlik, platform, operasyon, maliyet, landing zone ve workload hazırlığı birlikte değerlendirilmelidir.