- 01Database migration envanteri yalnız server ve database listesinden oluşmaz; application, job, ETL, BI ve diğer writer bağımlılıkları da çıkarılmalıdır.
- 02Exact engine version, edition, vendor-specific nesneler ve data type kullanımı heterojen migration scope'unu doğrudan etkiler.
- 03Target sizing için database size yanında transaction rate, IOPS, throughput, latency, connection ve growth baseline toplanmalıdır.
- 04Backup'ın mevcut olması yeterli değildir; restore edilebilirliği ve restore süresi test edilmelidir.
- 05Envanter ancak validation, rollback ve go/no-go kriterleri de tanımlandığında production migration planına dönüşür.
Kısaca
Database migration başarısızlıklarının önemli bir bölümü cutover gecesinde değil, eksik envanter aşamasında başlar. Kaynak motor ve sürümü, schema nesneleri, job'lar, linked server'lar, application connection'ları, veri büyüklüğü, transaction profili, backup/restore durumu ve bağımlılıklar çıkarılmadan hedef mimari veya cutover süresi güvenilir biçimde planlanamaz.
Dynamis Teknoloji'de migration assessment'ın ilk çıktısı bir "server listesi" değil, owner'ı, kritikliği, bağımlılığı, migration kararı ve test kriteri olan çalışma envanteridir.
Bu checklist'in amacı production migration başlamadan önce eksikliği görünür hale getirmektir.
1. Kaynak ortam envanteri
İlk olarak her database instance için şu bilgileri kaydedin:
- database engine
- edition
- exact version/build
- işletim sistemi
- deployment modeli
- hostname / instance adı
- region / veri merkezi
- CPU ve memory
- storage tipi ve kapasitesi
- encryption durumu
- HA / replication topolojisi
- backup yöntemi
- monitoring aracı
- owner
- business criticality
SQL Server ortamında yalnız major version yazmak yeterli değildir. Exact build ve edition bazı özelliklerin kullanılabilirliğini ve migration yolunu etkileyebilir.
2. Database ve schema listesi
Her instance üzerindeki database'leri ayrı kaydedin.
Her database için:
- boyut
- kullanılan alan
- yıllık/aylık büyüme
- schema listesi
- tablo sayısı
- view sayısı
- stored procedure
- function
- trigger
- sequence/identity
- index
- constraint
çıkarılmalıdır.
Bu aşama migration scope'unun gerçek büyüklüğünü gösterir.
3. Vendor-specific nesneleri işaretleyin
Heterojen migration'da vendor-specific özellikler ayrı iş paketi oluşturabilir.
SQL Server örnekleri:
- T-SQL stored procedure
- SQL Agent Job
- linked server
- CLR
- Service Broker
- replication
- indexed view
- computed column
- FILESTREAM
- SQL Server-specific data type
- cross-database query
PostgreSQL hedefinde bunların birebir karşılığı olmayabilir.
SQL Server'dan PostgreSQL'e geçiş rehberi bu dönüşüm risklerini ayrı olarak ele alır.
4. Dependency map çıkarın
Bir database yalnız database değildir.
Ona bağlı olabilir:
- web uygulaması
- API
- background worker
- queue consumer
- ETL
- BI/reporting
- scheduled script
- cron
- başka bir database
- authentication sistemi
- file export
- üçüncü taraf entegrasyon
Bu bağımlılıkların her biri için:
- owner
- connection yöntemi
- credential kaynağı
- protocol/port
- write/read davranışı
- cutover sırasında ne yapılacağı
yazılmalıdır.
SQL Server içi bağımlılıkları metadata üzerinden çıkarmak mümkündür; ancak application ve network bağımlılıkları ayrıca discovery gerektirir.
5. Connection envanteri
Her database için aktif client bağlantılarını ve connection source'larını bulun.
Örnekler:
- application connection string
- secret manager
- environment variable
- JDBC/ODBC DSN
- reporting tool
- developer workstation
- scheduled script
- integration server
Cutover sonrası eski endpoint'e bağlanan tek bir forgotten client bile split-write veya yanlış rapor üretimine yol açabilir.
Bu nedenle connection inventory ayrı bir tablo olarak tutulmalıdır.
6. Read ve write yapan sistemleri ayırın
Her dependency için şu sınıflandırmayı yapın:
- read-only
- read/write
- batch write
- event-driven write
- admin/manual write
Write freeze planı yalnız web uygulamasını durdurmakla tamamlanmaz.
Queue consumer, cron veya batch job'lar da yazma yapabilir.
7. Veri boyutu ve büyüme profili
Her database için yalnız bugünkü size değil büyüme trendini de kaydedin.
Örnek alanlar:
- total size
- data size
- log/WAL size
- monthly growth
- largest table
- largest index
- LOB/binary data
- archive data
Bu bilgiler:
- hedef storage sizing
- full load süresi
- network transfer süresi
- backup süresi
- validation süresi
için kullanılır.
8. En büyük tabloları ayrıca çıkarın
Top 10 veya Top 20 tablo için:
- row count
- size
- primary key
- partition yapısı
- write rate
- index count
- LOB kolon
çıkarın.
Migration süresini çoğu zaman toplam database boyutundan çok birkaç büyük ve yoğun yazılan tablo belirler.
9. Transaction profili
Kaynağın yoğunluğu bilinmeden CDC ve cutover planlanamaz.
Toplayın:
- average TPS
- peak TPS
- write/read ratio
- peak business saatleri
- batch window
- month-end/year-end yoğunluğu
- largest transaction
CDC throughput hedefi peak yazma hızının altında kalıyorsa backlog sürekli büyür.
10. Performans baseline
CPU ve RAM dışında şunları da kaydedin:
- read IOPS
- write IOPS
- throughput
- storage latency
- connection count
- long-running query
- lock/wait
- buffer/cache davranışı
- p95/p99 query latency
Bu baseline hedef database'in migration sonrası daha kötü performans gösterip göstermediğini anlamak için gereklidir.
11. Kritik sorgular
En kritik business query'lerini belirleyin.
Örnek:
- checkout
- customer login
- order search
- invoice generation
- reporting query
- dashboard query
Migration sonrası yalnız database'in açıldığını değil bu sorguların kabul edilen latency içinde çalıştığını doğrulayın.
12. Backup envanteri
Kaydedin:
- full backup sıklığı
- incremental/differential
- transaction log/WAL backup
- retention
- backup location
- encryption
- restore owner
- last successful restore test
Backup var olması restore edilebilir olduğu anlamına gelmez.
13. Restore süresi
RTO planlamasında restore süresi kritik girdidir.
Ölçün:
- full restore
- log replay
- recovery
- post-restore validation
Cutover rollback ile disaster recovery restore aynı operasyon değildir, ancak restore testleri son güvenlik ağıdır.
14. RPO ve RTO
Her database için iş birimiyle birlikte:
- RPO
- RTO
- acceptable maintenance window
- maximum data loss
tanımlanmalıdır.
Tek bir şirket çapında RPO/RTO varsayımı yapmayın.
15. HA ve DR topolojisi
Kaynakta:
- Always On
- replication
- cluster
- standby
- read replica
varsa hedefte nasıl karşılanacağı yazılmalıdır.
Migration yalnız primary node'u taşımak değildir; production availability modelini de yeniden kurmaktır.
16. Security ve erişim
Envantere dahil edin:
- login/user
- role
- permission
- service account
- certificate
- encryption key
- firewall
- private network
- allowlist
Data başarılı taşınsa bile login veya network erişimi eksikse application çalışmaz.
17. Secret ve credential yönetimi
Credential'ların nerede tutulduğunu bulun:
- Vault
- cloud secret manager
- Kubernetes Secret
- environment variable
- config file
Cutover sırasında hangi secret'ın güncelleneceği ve rollback'te nasıl geri alınacağı yazılmalıdır.
18. Job envanteri
SQL Agent, cron veya external scheduler job'larını ayrı çıkarın.
Her job için:
- schedule
- owner
- source database
- target database
- read/write davranışı
- cutover action
belirleyin.
Unutulan bir batch job eski database'e yazmaya devam edebilir.
19. ETL ve BI bağımlılıkları
ETL pipeline ve reporting araçları çoğu zaman uygulama envanterinden ayrı yönetilir.
Kontrol edin:
- Power BI
- SSRS
- Tableau
- dbt
- Airflow
- custom ETL
- data warehouse connector
Connection değişikliği ve schema değişimi bunları etkileyebilir.
20. Schema change geçmişi
Migration öncesi ne kadar sık schema değiştiğini bilin.
Cutover yaklaşımında:
- freeze tarihi
- emergency schema change prosedürü
- source/target schema sync
tanımlanmalıdır.
21. Data type compatibility
Heterojen migration'da:
- numeric
- datetime
- timezone
- UUID
- binary
- text/collation
- JSON
- boolean
alanlarını ayrı kontrol edin.
Bu alanlarda otomatik dönüşüm sonrası application semantics değişebilir.
22. Primary key ve unique constraint
CDC ve validation için primary key yapısı kritik olabilir.
Primary key olmayan büyük tabloları ayrıca işaretleyin.
Kontrol edin:
- composite key
- natural key
- surrogate key
- duplicate row
- nullable unique field
23. Sequence ve identity
Identity/sequence state migration sonrası yeni insert için doğru noktada olmalıdır.
Envantere:
- current identity
- max key
- increment
- sequence owner
ekleyin.
24. Trigger ve side effect
Trigger'lar:
- audit
- secondary table write
- integration
- notification
üretebilir.
Target'ta CDC apply sırasında trigger'ın açık kalıp kalmayacağı önceden belirlenmelidir.
25. Data quality problemleri
Migration eski veri hatalarını otomatik düzeltmez.
Önceden bulun:
- duplicate
- orphan row
- invalid enum
- corrupt text
- impossible date
- null violation
Migration projesini istemeden data-cleaning projesine çevirmemek için bunları scope'a açıkça yazın.
26. Compliance ve veri sınıflandırması
Veride:
- kişisel veri
- finansal veri
- health data
- credential
- secret
varsa migration yolu, erişim ve loglama buna göre tasarlanmalıdır.
KVKK açısından veri konumu ve yurt dışı aktarım gereksinimleri hukuki değerlendirmeyle birlikte ele alınmalıdır.
27. Network kapasitesi
Ölçün:
- gerçek throughput
- latency
- packet loss
- VPN/private link kapasitesi
- firewall limitleri
Teorik 1 Gbit/s bağlantı ile gerçek migration throughput'u aynı olmayabilir.
28. Full load tahmini
Pilot load ile ölçülen throughput üzerinden yaklaşık full load süresi çıkarın.
Basit formül:
veri boyutu / gerçek efektif throughput
Ama index build, LOB, transformation ve target apply maliyetini ayrıca hesaba katın.
29. CDC feasibility
Kontrol edin:
- kaynak motor/sürüm destekli mi?
- gerekli log ayarları açık mı?
- retention yeterli mi?
- primary key eksikleri var mı?
- LOB desteği uygun mu?
- network sürekli mi?
- target apply kapasitesi yeterli mi?
Database Cutover: CDC ile Planlı Geçiş bu aşamayı ayrıntılı açıklar.
30. Validation planı
Her kritik tablo için doğrulama yöntemi belirleyin:
- row count
- checksum/hash
- field-level comparison
- referential integrity
- business total
- application transaction
CDC ile Veri Doğrulama teknik validation modelini ayrıntılı olarak ele alır.
31. Rollback planı
Yazılı olarak tanımlayın:
- rollback trigger
- decision owner
- old source retention
- target'taki yeni write'ların yönetimi
- connection rollback
- maximum rollback window
Rollback'i cutover sırasında tasarlamayın.
32. Cutover owner ve roller
Cutover için en az:
- technical lead
- database owner
- application owner
- network owner
- business approver
- rollback decision owner
belli olmalıdır.
33. Go / no-go kriterleri
Örnek kriterler:
- full load tamam
- CDC lag kabul edilen sınırda
- validation temiz
- backup/restore doğrulandı
- target monitoring açık
- application smoke test hazır
- rollback yolu hazır
Go/no-go toplantısı yoruma değil bu kriterlere dayanmalıdır.
34. Migration dalgası
Database hangi application'larla aynı wave içinde taşınacak?
Database'i sıkı bağlı uygulamadan farklı wave'e koymak yüksek latency veya split-brain benzeri davranış yaratabilir.
Migration wave planı dependency bazlı sıralamayı açıklar.
35. Envanter tablosu nasıl görünmeli?
Minimum kolonlar:
| Alan | Örnek |
|---|---|
| Database | prod-orders |
| Engine | SQL Server 2022 |
| Owner | Backend Team |
| Criticality | Tier 1 |
| Size | 1.8 TB |
| Growth | 80 GB/ay |
| Peak TPS | 1,200 |
| RPO | 5 dk |
| RTO | 60 dk |
| Dependencies | API, worker, BI |
| Vendor-specific | T-SQL, Agent Jobs |
| Target | PostgreSQL |
| Migration method | Full load + CDC |
| Validation | Row + hash + business total |
| Rollback | Defined |
Bu tablo başlangıçtır; gerçek assessment nesne bazında daha ayrıntılı olmalıdır.
Checklist ne zaman tamamlanmış sayılır?
Envanter şu koşullarda hazır kabul edilebilir:
- her kritik database'in owner'ı belli,
- tüm writer'lar listelenmiş,
- external dependency'ler doğrulanmış,
- unsupported nesneler action item'a dönüştürülmüş,
- backup restore test edilmiş,
- target sizing ölçümle doğrulanmış,
- full load ve CDC yöntemi seçilmiş,
- validation planı yazılmış,
- rollback planı yazılmış,
- go/no-go kriterleri onaylanmış.
Boş hücre bırakmak yerine bilinmeyen alanı açıkça Unknown — action required olarak işaretleyin.
Dynamis'te assessment yaklaşımı
Dynamis'in Database Migration hizmetinde migration projesine doğrudan veri kopyalayarak başlamıyoruz.
İlk aşamada:
- inventory
- dependency map
- compatibility assessment
- performance baseline
- RPO/RTO
- backup/restore
- validation
- rollback
çıkarılır.
Ardından pilot migration ile throughput ve compatibility varsayımları test edilir.
Bu sayede gerçek cutover planı tahmine değil ölçüme dayanır.
Sık yapılan hatalar
Yalnız database size çıkarmak: Dependency ve write profile olmadan migration süresi tahmin edilemez.
Uygulama dışındaki writer'ları unutmak: ETL, cron ve queue consumer eski kaynağa yazabilir.
Backup var diye restore'u test etmemek: Recovery anında sürpriz yaratır.
Exact version/edition toplamamak: Compatibility assessment eksik kalır.
Vendor-specific nesneleri sonradan fark etmek: Heterojen migration scope'u büyütür.
RPO/RTO'yu teknik ekibin tek başına belirlemesi: İş sahibiyle birlikte tanımlanmalıdır.
Envanteri statik bırakmak: Cutover'a kadar değişiklikler takip edilmelidir.
Sırada ne var
- SQL Server'dan PostgreSQL'e geçiş
- Database Cutover: CDC ile Planlı Geçiş
- CDC ile Veri Doğrulama
- Cloud Migration Checklist
- Database migration hizmeti
Kaynaklar
Kaynaklar
- 1.AWS DMS Fleet AdvisorAmazon Web Services · 2026-09-25
- 2.AWS DMS premigration assessmentAmazon Web Services · 2026-09-25
- 3.AWS SCT assessment reportsAmazon Web Services · 2026-09-25
- 4.sys.sql_expression_dependenciesMicrosoft Learn · 2026-09-25
- 5.PostgreSQL pg_dumpPostgreSQL Global Development Group · 2026-09-25
Sık sorulan sorular
Database migration öncesi envanterde hangi bilgiler mutlaka toplanmalı?
En az kaynak motor ve sürüm, database boyutu ve büyüme hızı, tablo ve schema listesi, stored procedure/function/trigger sayıları, job'lar, linked server veya external dependency'ler, kullanıcı/rol yapısı, backup/restore durumu, RPO/RTO hedefleri, yoğun yazma pencereleri, uygulama connection'ları ve kritik sorgular envantere alınmalıdır. Heterojen migration'larda veri tipi ve vendor-specific özellikler ayrıca işaretlenmelidir.
Database migration öncesi dependency map neden gereklidir?
Veritabanı tek başına çalışmaz. Uygulama sunucuları, ETL, BI, batch job, queue consumer, reporting, authentication ve başka database'ler aynı veritabanına bağlı olabilir. Dependency map olmadan bir bağlantının veya scheduled job'ın unutulması cutover sonrası veri kaybı, çift yazma veya servis kesintisi oluşturabilir. SQL Server'da sys.sql_expression_dependencies gibi metadata kaynakları database içi bağımlılıkları çıkarmaya yardımcı olabilir; external bağımlılıklar ayrıca uygulama ve altyapı envanterinden toplanmalıdır.
Migration öncesi backup alınması yeterli midir?
Backup gerekli ama tek başına yeterli değildir. Backup'ın güncel olması kadar restore edilebilirliğinin test edilmiş olması da gerekir. Ayrıca restore süresi, recovery point, encryption key erişimi, transaction log veya WAL retention ve rollback senaryosu bilinmelidir. Migration rollback ile disaster recovery restore aynı operasyon değildir; ikisi ayrı planlanmalıdır.
Database migration envanterinde hangi performans metrikleri toplanmalı?
CPU ve memory tek başına yeterli değildir. Peak ve ortalama transaction rate, read/write IOPS, throughput, connection count, cache hit davranışı, storage latency, long-running query'ler, lock/wait istatistikleri ve büyüme trendi toplanmalıdır. Bu veriler hedef sizing, migration throughput ve cutover maintenance window tahmini için kullanılır.
Database migration checklist ne zaman tamamlanmış sayılır?
Checklist yalnız alanların doldurulmasıyla tamamlanmış sayılmaz. Her kritik dependency'nin owner'ı, migration kararı ve test kriteri olmalı; backup restore testi yapılmış olmalı; unsupported object/action item'lar kapanmış veya kabul edilmiş olmalı; hedef sizing doğrulanmalı; validation ve rollback planı yazılmalı ve cutover go/no-go kriterleri belirlenmelidir.