- 01Database migration yalnız veri kopyalamak değildir; schema, database objeleri, application bağımlılıkları, validation, cutover ve rollback birlikte planlanmalıdır.
- 02Homogeneous migration aynı database engine ailesinde, heterogeneous migration ise farklı engine'ler arasında yapılır ve daha fazla compatibility çalışması gerektirebilir.
- 03Full load ve CDC/ongoing replication kombinasyonu büyük veriyi önceden taşıyıp cutover sırasında kalan veri farkını azaltmaya yardımcı olabilir.
- 04Migration sonrası row count tek başına yeterli değildir; checksum, field-level kontrol ve business reconciliation birlikte kullanılmalıdır.
- 05Production migration öncesinde performance baseline, cutover runbook ve rollback sınırı yazılı ve test edilebilir olmalıdır.
Kısaca
Database migration, bir kaynak veritabanındaki veri, schema ve ilgili database nesnelerinin hedef veritabanına taşınması ve doğrulama sonrası uygulamanın hedef sistemi kullanacak şekilde cutover edilmesi sürecidir. Migration yalnız veri kopyalama işi değildir; schema uyumluluğu, uygulama bağlantıları, güvenlik, performans, veri doğrulama, rollback ve kesinti penceresi birlikte planlanmalıdır. Dynamis Teknoloji, database migration çalışmalarını kaynak ve hedef sistem arasındaki teknik farkları kapatan kontrollü bir geçiş projesi olarak ele alır.
Database migration nedir?
Database migration, bir veritabanını mevcut platformundan, sürümünden, sağlayıcısından veya engine'inden başka bir hedef sisteme taşıma sürecidir.
Kaynak ve hedef şu kombinasyonlardan biri olabilir:
- PostgreSQL → PostgreSQL
- SQL Server → SQL Server
- MySQL → MySQL
- SQL Server → PostgreSQL
- self-hosted database → managed database
- on-premise database → cloud database
- bir cloud sağlayıcısından başka bir sağlayıcıya database geçişi
Google Cloud'un database migration rehberi migration'ı, kaynak database'den hedef database'e veri ve ilgili database yapılarının taşınması olarak tanımlar. Kaynak ve hedef aynı engine ailesinde olabilir veya farklı teknolojiler kullanabilir.
Migration'ın tamamlanmış sayılması için yalnız hedefte veri bulunması yeterli değildir. Uygulama hedef database'e bağlanmalı, kritik veriler ve transaction'lar doğrulanmalı, cutover kriterleri karşılanmalı ve gerekiyorsa eski kaynak sistem kontrollü biçimde devreden çıkarılmalıdır.
Schema migration ile database migration aynı şey değildir
"Database migration" terimi bazen yalnız uygulama schema değişiklikleri için kullanılır.
Örneğin bir uygulamanın yeni sürümünde:
- yeni kolon eklemek
- tablo oluşturmak
- index değiştirmek
- constraint eklemek
bir schema migration işlemidir.
Bu içerikte ele aldığımız database migration ise daha geniştir:
- veri
- schema
- stored procedure
- function
- trigger
- kullanıcı ve yetki
- uygulama bağlantıları
- backup
- replication
- cutover
- validation
gibi tüm geçiş alanlarını kapsar.
İki kavram birbirine bağlı olabilir ancak aynı şey değildir.
Homogeneous ve heterogeneous migration farkı nedir?
AWS Database Migration Service, migration'ları aynı engine ailesi ile farklı engine'ler arasındaki geçişler olarak ayırır.
Homogeneous migration
Kaynak ve hedef aynı veya büyük ölçüde uyumlu database engine'ini kullanır.
Örnek:
- PostgreSQL → PostgreSQL
- MySQL → MySQL
- SQL Server → SQL Server
Bu senaryolarda:
- datatype uyumluluğu daha yüksek olabilir
- native backup/restore veya replication araçları kullanılabilir
- stored procedure ve query değişikliği daha sınırlı olabilir
Ancak aynı engine olması migration'ın risksiz olduğu anlamına gelmez.
Sürüm farkı, extension, collation, authentication, managed-service limitleri ve network tasarımı yine kontrol edilmelidir.
Heterogeneous migration
Kaynak ve hedef farklı database engine'leri kullanır.
Örnek:
- SQL Server → PostgreSQL
- Oracle → PostgreSQL
- MySQL → PostgreSQL
Bu durumda yalnız veri taşınmaz.
Ayrıca:
- datatype
- schema
- sequence
- function
- stored procedure
- trigger
- index
- SQL syntax
- application query davranışı
uyumluluğu değerlendirilir.
SQL Server'dan PostgreSQL'e geçiş rehberinde heterogeneous migration sırasında hangi nesnelerin ve özelliklerin uyarlanması gerektiğini ayrıca ele alıyoruz.
Şirketler neden database migration yapar?
Database migration tek bir nedenle yapılmaz.
Yaygın gerekçeler:
- veri merkezi veya hosting sağlayıcısı değişikliği
- public cloud'a veya private cloud'a geçiş
- managed database kullanmak
- destek süresi biten database sürümünden çıkmak
- lisans maliyetini yeniden değerlendirmek
- mevcut platformdaki kapasite veya operasyon sorunlarını çözmek
- database consolidation
- şirket birleşmesi veya altyapı standardizasyonu
- uygulama modernizasyonu
Migration nedeni teknik tasarımı etkiler.
Örneğin yalnız veri merkezi değiştiren bir şirket için aynı engine ile rehost daha düşük riskli olabilir. Lisans maliyetini azaltmak isteyen bir şirket ise farklı engine'e geçişi değerlendirebilir ve bu durumda compatibility çalışması daha kapsamlı olur.
Migration öncesinde database envanteri çıkarılmalıdır
İlk teknik adım "veriyi kopyalamaya başlamak" değildir.
Kaynak database'in envanteri çıkarılmalıdır.
En az şu bilgileri kaydedin:
- database engine ve sürüm
- toplam veri boyutu
- günlük büyüme
- transaction/change rate
- schema sayısı
- tablo sayısı
- index'ler
- constraint'ler
- view'lar
- stored procedure'ler
- function'lar
- trigger'lar
- extension veya plugin'ler
- kullanıcı ve roller
- job/scheduler
- linked server veya external connection
- uygulama connection string'leri
- backup yöntemi
- RPO/RTO
- maintenance window
- mevcut performans baseline'ı
Database Migration Öncesi Envanter Kontrol Listesi bu adımı daha ayrıntılı bir checklist olarak ele alır.
Envanter eksikse migration sırasında "bu obje neden hedefte çalışmıyor?" sorusu cutover penceresinde ortaya çıkar.
Uygulama bağımlılıklarını ayrıca çıkarın
Database yalnız başına çalışmaz.
Bağımlılıklar şu alanlarda bulunabilir:
- web uygulaması
- API
- batch job
- ETL
- reporting
- BI
- authentication
- backup
- monitoring
- third-party integration
- cron/scheduled task
- data warehouse
- file export/import süreçleri
Özellikle connection string'in hangi uygulamalarda ve secret store'larda bulunduğunu bilmek gerekir.
Cutover sırasında database hedefe geçtiği halde eski connection string'i kullanan tek bir batch job eski sisteme veri yazmaya devam edebilir.
Bu nedenle dependency map teknik envanterin parçasıdır.
Schema ve code compatibility migration riskini belirler
Homogeneous migration'da bile kaynak ile hedef arasında sürüm ve özellik farkı olabilir.
Heterogeneous migration'da compatibility daha kritik hale gelir.
Kontrol edin:
- datatype eşleşmeleri
- default değerler
- identity / sequence davranışı
- timestamp ve timezone
- collation
- case sensitivity
- index özellikleri
- constraint'ler
- stored procedure
- function
- trigger
- vendor-specific SQL
- extension
- partitioning
- JSON/XML davranışı
- transaction semantics
Örneğin SQL Server'daki T-SQL stored procedure doğrudan PostgreSQL üzerinde çalışmayabilir.
Migration planı "hangi veri taşınacak?" kadar "hangi uygulama ve database kodu uyarlanacak?" sorusunu da yanıtlamalıdır.
Database migration yöntemleri nelerdir?
Migration yöntemi downtime hedefi, veri boyutu ve kaynak sistemin değişim hızına göre seçilir.
Offline export/import
Basit model:
- Uygulama yazmaları durdurulur
- Kaynak database export veya backup alınır
- Veri hedefe yüklenir
- Validation yapılır
- Uygulama hedefe yönlendirilir
Avantajı sadeliktir.
Dezavantajı veri boyutu büyüdükçe kesinti penceresinin uzamasıdır.
Düşük kritikliyete sahip küçük database'lerde uygun olabilir.
Full load
Kaynak database aktifken mevcut veri hedefe taşınabilir.
Full load tamamlandığında ilk veri seti hedefte bulunur ancak kaynakta bu sırada oluşan değişikliklerin ayrıca ele alınması gerekir.
Full load + ongoing replication / CDC
AWS DMS gibi araçlarda full load ile birlikte ongoing replication kullanılabilir.
Genel akış:
- İlk veri kopyası yapılır
- Kaynakta oluşan yeni değişiklikler izlenir
- Bu değişiklikler hedefe aktarılır
- Replication lag düşürülür
- Cutover penceresinde yazma kontrol edilir
- Son değişiklikler hedefe taşınır
- Uygulama hedef database'e yönlendirilir
Bu model daha kısa cutover penceresi sağlayabilir ancak operasyonel karmaşıklık artırır.
CDC ne işe yarar?
Change Data Capture veya benzer değişiklik yakalama mekanizmaları, source database'deki insert, update ve delete işlemlerinin hedef sisteme taşınmasına yardımcı olur.
CDC'nin amacı:
- ilk full load sırasında oluşan değişiklikleri kaybetmemek
- source ve target arasındaki farkı küçültmek
- cutover sırasında taşınacak son delta'yı azaltmak
olabilir.
Ancak CDC tek başına "zero downtime" garantisi değildir.
Şunlar hâlâ planlanmalıdır:
- schema değişiklikleri
- replication lag
- transaction consistency
- unsupported datatype/object
- cutover sırası
- application write freeze
- validation
- rollback
CDC ile veri doğrulama rehberinde hedef verinin source ile nasıl karşılaştırılacağını ayrıca ele alıyoruz.
Downtime nasıl planlanır?
Her database migration aynı kesinti modeline sahip değildir.
Kesinti süresini etkileyen başlıca faktörler:
- veri boyutu
- source change rate
- network throughput
- migration yöntemi
- index oluşturma süresi
- schema conversion
- validation süresi
- uygulamanın yeniden başlatılması
- DNS veya connection string değişimi
- cache ve connection pool davranışı
Offline migration'da tüm veri cutover penceresinde taşınabilir.
CDC kullanılan modelde ise büyük veri önceden taşınır ve cutover sırasında çoğunlukla final delta ile uygulama yönlendirmesi yapılır.
Amaç "zero downtime" iddiası değil, iş gereksinimine uygun ölçülmüş bir kesinti hedefidir.
Veri doğrulama yalnız row count değildir
Migration sonrası kaynakta ve hedefte aynı sayıda satır görmek yararlı ancak yeterli değildir.
Daha sağlam validation katmanları:
Row count
Tablo bazında satır sayıları karşılaştırılır.
Checksum veya hash
Belirli alanlar normalize edilerek karşılaştırılabilir.
Field-level validation
Örnek veri veya kritik kayıtlar kolon seviyesinde karşılaştırılır.
Constraint ve object kontrolü
Index, primary key, foreign key, sequence ve diğer database objeleri doğrulanır.
Business reconciliation
Teknik olarak en değerli kontrollerden biridir.
Örneğin:
- toplam açık sipariş sayısı
- günlük ödeme toplamı
- müşteri bakiyesi
- son invoice numarası
- kritik rapor sonucu
source ve target arasında karşılaştırılır.
Migration başarısı yalnız byte seviyesinde değil, uygulamanın iş sonucunda da doğrulanmalıdır.
Performance baseline migration öncesinde alınmalıdır
Yeni database hedefinin "çalışması" yeterli değildir.
Migration öncesi kaynak sistemden baseline alın:
- CPU
- memory
- storage latency
- IOPS
- connection sayısı
- transaction rate
- query latency
- p95/p99 response time
- lock/wait istatistikleri
- database size
- growth rate
Cutover sonrası aynı metrikler karşılaştırılabilir.
Hedef sistem teknik olarak ayakta olsa bile kritik query'ler 3 kat yavaşladıysa migration başarı kriteri karşılanmamış olabilir.
Cutover runbook önceden yazılmalıdır
Database cutover sırasında yapılacak adımlar sıra ve sorumluyla yazılmalıdır.
Örnek:
- Change freeze başlat
- Source replication lag'i kontrol et
- Uygulama yazmalarını durdur
- Son delta'nın hedefe ulaştığını doğrula
- Kritik tabloları validate et
- Connection string / secret değiştir
- Uygulamayı yeniden başlat veya connection pool'u yenile
- Smoke test çalıştır
- Business transaction doğrula
- Monitoring ve error rate kontrol et
- Go/no-go kararı ver
Database Cutover: CDC ile Planlı Geçiş bu süreci ayrı olarak detaylandırır.
Cutover günü bu adımların ilk kez düşünülmesi migration riskini artırır.
Rollback planı migration başlamadan yazılmalıdır
"Problem çıkarsa geri döneriz" rollback planı değildir.
Şunları belirleyin:
- rollback kararı kimde?
- hangi metrik rollback tetikler?
- eski database ne kadar süre çalışır durumda tutulacak?
- yeni target'a yazılan veri source'a nasıl geri dönecek?
- cutover sonrası kaç dakika/saat içinde dönüş mümkün?
- connection string geri dönüşü nasıl yapılacak?
- source ve target arasında çift yazma var mı?
- point of no return nedir?
Özellikle target'a production write başladıktan sonra rollback karmaşıklaşabilir.
Migration tasarımında rollback sınırı açıkça yazılmalıdır.
Güvenlik migration sırasında zayıflatılmamalıdır
Migration projelerinde "geçici" geniş yetkiler kalıcı hale gelebilir.
Kontrol edin:
- migration user least privilege mi?
- credential nerede saklanıyor?
- source ve target bağlantısı TLS kullanıyor mu?
- network erişimi hangi IP/subnet'lere açık?
- backup şifreli mi?
- target database public erişime açıldı mı?
- migration bittikten sonra geçici user/firewall rule kaldırıldı mı?
- audit log aktif mi?
Migration kolay olsun diye production database'i internete açmak doğru çözüm değildir.
Database migration süresi neye bağlıdır?
Yalnız database boyutuna bakarak süre tahmini yapmak yanıltıcıdır.
100 GB database, düşük change rate ve yüksek network throughput ile kolay taşınabilirken daha küçük bir database karmaşık stored procedure ve compatibility sorunları nedeniyle daha uzun proje olabilir.
Süreyi etkileyen faktörler:
- data volume
- source change rate
- network throughput
- source I/O kapasitesi
- target write kapasitesi
- index yapısı
- LOB/BLOB veri
- schema conversion
- validation
- application dependency
- test döngüsü
- maintenance window
- approval süreçleri
Bu nedenle production migration öncesinde gerçek data sample veya pilot migration ile throughput ölçmek daha sağlıklıdır.
Database migration ne zaman ayrı bir proje olarak ele alınmalıdır?
Küçük ve non-critical bir aynı-engine database taşıması kısa bir operasyon olabilir.
Ancak şu durumlarda migration'ı ayrı proje olarak yönetin:
- production database
- yüksek transaction hacmi
- düşük RPO/RTO
- farklı database engine'i
- büyük veri hacmi
- çok sayıda uygulama bağımlılığı
- stored procedure ağırlığı
- lisans değişikliği
- regülasyona tabi veri
- sınırlı maintenance window
- rollback karmaşıklığı
Bu durumda discovery, test migration, cutover rehearsal ve rollback planı için ayrı zaman ayrılmalıdır.
Dynamis'te database migration yaklaşımı
Dynamis'in database migration çalışmalarında ilk adım migration tool'u seçmek değildir.
Önce:
- engine ve version
- schema ve database objeleri
- workload bağımlılıkları
- data volume ve growth
- performance baseline
- backup/recovery
- RPO/RTO
- migration window
- target database
- compatibility
- security
- validation kriterleri
çıkarılır.
Ardından workload'a göre:
- native backup/restore
- full load
- replication
- CDC
- export/import
yaklaşımı seçilir.
Production cutover öncesinde validation ve rollback adımları runbook'a bağlanır.
Planlama, migration ve cutover kapsamını değerlendirmek için Database migration hizmetini inceleyebilirsiniz.
Sık yapılan hatalar
Yalnız veriyi taşımak: Schema, stored procedure, kullanıcı, job ve application bağımlılıkları unutulabilir.
Row count eşitse migration tamamdır demek: Business-level reconciliation yapılmalıdır.
CDC varsa downtime yoktur sanmak: Final cutover, application connection ve consistency hâlâ planlanmalıdır.
Rollback'i cutover günü düşünmek: Target'a write başladıktan sonra geri dönüş zorlaşabilir.
Performance baseline almamak: Target'ın gerçekten daha iyi veya en az eşdeğer olduğu ölçülemez.
Migration user'a geniş ve kalıcı yetki vermek: Geçici yetkiler proje bitiminde kaldırılmalıdır.
Database boyutundan tek başına süre çıkarmak: Change rate, network, compatibility ve validation çoğu zaman daha belirleyicidir.
Sırada ne var
- SQL Server'dan PostgreSQL'e geçiş: heterogeneous migration sırasında schema ve code uyumluluğunu inceleyin.
- Database Migration Öncesi Envanter Kontrol Listesi: kaynak database ve bağımlılıkları migration öncesinde çıkarın.
- CDC ile Veri Doğrulama: source ve target verisini row count, checksum ve alan seviyesinde karşılaştırın.
- Database Cutover: CDC ile Planlı Geçiş: full load sonrası final delta, write freeze, validation ve rollback adımlarını planlayın.
- Database migration hizmeti: production database geçişini discovery, migration, validation ve cutover kapsamıyla değerlendirin.
Kaynaklar
Kaynaklar
- 1.Homogeneous data migrationsAmazon Web Services · 2026-10-12
- 2.Getting started with a database migrationAmazon Web Services · 2026-10-12
- 3.What is AWS Database Migration Service?Amazon Web Services · 2026-10-12
- 4.Database migration concepts and principlesGoogle Cloud · 2026-10-12
Sık sorulan sorular
Database migration nedir?
Database migration, bir kaynak veritabanındaki veri, schema ve ilgili database nesnelerinin hedef veritabanına taşınması ve doğrulama sonrası uygulamanın hedef sistemi kullanacak şekilde cutover edilmesi sürecidir.
Homogeneous ve heterogeneous database migration arasındaki fark nedir?
Homogeneous migration aynı veya uyumlu database engine ailesi arasında yapılır; örneğin PostgreSQL'den PostgreSQL'e. Heterogeneous migration ise SQL Server'dan PostgreSQL'e geçiş gibi farklı engine'ler arasında yapılır ve schema, datatype veya stored procedure dönüşümü gerektirebilir.
CDC database migration sırasında ne işe yarar?
Change Data Capture, ilk veri kopyası devam ederken veya tamamlandıktan sonra kaynak veritabanındaki yeni değişiklikleri hedefe aktararak cutover anındaki veri farkını küçültmeye yardımcı olur. CDC tek başına zero-downtime garantisi vermez.
Database migration sırasında downtime zorunlu mudur?
Her migration için aynı downtime gereksinimi yoktur. Küçük offline taşımalarda uygulama daha uzun süre durabilir; full load ve CDC kullanılan production senaryolarında yazma dondurma ve final senkronizasyon penceresi daha kısa tutulabilir. Kesinti hedefi workload ve veri tutarlılığı gereksinimine göre planlanmalıdır.
Database migration sonrası veri nasıl doğrulanır?
Doğrulama yalnız satır sayısı karşılaştırmasıyla yapılmamalıdır. Row count, checksum veya hash, alan bazlı karşılaştırma, constraint ve index kontrolleri ile kritik business transaction doğrulamaları birlikte kullanılmalıdır.