Veri Göçü: Eski Sistemden Veri Aktarımı

Kısa cevap: veri göçü bir kopyalama işi değil, üç ayrı işin toplamıdır — alan eşleme, veri temizliği ve mutabakat. Bu yüzden de yeni yazılım projelerini en çok geciktiren kalem neredeyse her zaman veri göçüdür. İşin doğru yapıldığının tek ölçüsü şudur: göç bittiğinde kaynak sistemle yeni sistem arasında kayıt adedi ve toplam tutar birebir tutuyor mu? Ayrıca göç tek seferlik bir olay değildir; canlıya geçmeden önce en az iki-üç kez prova edilir.

Veri göçü neden tahmin edilenden uzun sürüyor?

Teklif aşamasında veri göçü çoğu zaman tek satırlık bir kalem olarak görünür: “mevcut veriler aktarılacak”. Gerçekte süreyi belirleyen şey kayıt sayısı değil, verinin kalitesidir. Sahada en sık karşılaştığımız tablo şöyle.

• Tekrarlı kayıt: Aynı müşteri üç farklı yazımla üç kez kayıtlı. Hangisinin doğru olduğuna yazılım karar veremez; bu bir iş kararıdır ve karar verecek kişinin adı baştan belli olmalıdır.
• Boş zorunlu alan: Yeni sistemde vergi numarası zorunluysa ama eski sistemde binlerce kayıtta boşsa, göç durur. Çözüm ya alanı geçici olarak isteğe bağlı yapmak ya da toplu tamamlamaktır.
• Serbest metin alanları: Eski sistemde tek bir “adres” ya da “not” alanında tutulan bilgi, yeni sistemde beş ayrı alana bölünür. Ayrıştırma her zaman yüzde yüz doğru çalışmaz, elle kontrol payı bırakın.
• Biçim farkları: Tarih (gg.aa.yyyy mi, aa/gg/yyyy mi), ondalık ayracı, para birimi, KDV dahil mi hariç mi. Bir ondalık hatası tüm bakiyeleri yüz kat kaydırabilir.
• Karakter kodlaması: Eski sistemlerden gelen dosyalarda Türkçe karakterlerin bozulması klasik bir sorundur; dosyayı almadan önce kodlamayı (UTF-8) netleştirin.
• İlişkilerin kopması: Sipariş taşındı ama sipariş satırı hangi ürüne bağlıydı bilgisi kayboldu. En pahalı hata türü budur, çünkü göçten haftalar sonra fark edilir.

Veri göçünün süresini kayıt sayısı değil, verinin kalitesi belirler. Beş bin temiz kayıt bir günde taşınır; beş bin kirli kayıt iki haftaya mal olabilir.

Önce karar: neyin taşınacağı

Göç maliyetini düşürmenin en etkili yolu pazarlık değil, kapsamı daraltmaktır. Her verinin yeni sisteme girmesi gerekmez ve “hepsini taşıyalım” kararı çoğu projede gereksiz yere yüzde otuz-kırk ek iş üretir.

• Mutlaka taşınır: Açık bakiyeler, aktif müşteri ve tedarikçiler, güncel stok, açık siparişler, aktif kullanıcılar ve yetkiler, ürün/hizmet kataloğu.
• Genelde taşınır: Son bir-iki yılın hareketleri (rapor karşılaştırması ve mevsimsel analiz için gerekir).
• Çoğu zaman taşınmaz: On yıllık geçmiş hareket, kapanmış kayıtlar, eski kampanya verisi. Bunları salt okunur bir arşiv veritabanında ya da tek seferlik bir rapor çıktısında tutmak hem ucuz hem yeterlidir.
• Kesinlikle taşınmaz: Artık kullanılmayan alanlar, test kayıtları ve gereksiz kişisel veri. Göç, envanteri temizlemek için doğal bir fırsattır.

Bu ayrımı yapmak aynı zamanda bir bütçe kararıdır; kapsamın maliyeti nasıl belirlediğini özel yazılım maliyeti yazısında ayrıntılandırdık.

Dört adımlı yöntem

• 1. Envanter ve profil çıkarma: Hangi kaynaklardan (veritabanı, Excel dosyaları, muhasebe programı çıktısı) kaç kayıt geliyor? Her tabloda boş alan oranı, tekrar oranı ve uç değerler çıkarılır. Bu rapor olmadan verilen süre tahmini tahmin bile değildir.
• 2. Alan eşleme tablosu: Kaynak alan, hedef alan, dönüşüm kuralı ve sorumlu. Bu tablo göçün sözleşmesidir; tartışmaların tamamı buraya bakılarak çözülür.
• 3. Prova göçü: Gerçek veriyle, test ortamına, baştan sona çalıştırma. İlk prova neredeyse her zaman hatalıdır; asıl amacı hata bulmaktır. En az iki prova yapılır, sonuncusu canlı kurulumun aynısı olan bir ortamda koşar.
• 4. Kesme (cutover) planı: Eski sistemin dondurulacağı saat, delta göçü, doğrulama listesi ve geri dönüş senaryosu yazılı olarak hazırlanır.

Mutabakat: göç “bitti” değil, “tuttu” olmalı

Göçün başarısı gözle kontrol edilmez. Her göç çalıştırmasının sonunda otomatik bir mutabakat raporu üretin: iki tarafta kayıt adedi ve para alanlarının toplamı eşit mi, ilişkisi kopmuş kayıt var mı? Bu rapor, canlıya geçme kararının tek dayanağıdır.

-- Mutabakat 1: kayit adedi ve toplam tutar iki tarafta esit mi?
select 'kaynak' as taraf, count(*) as adet, sum(tutar) as toplam
from legacy.siparisler where durum <> 'iptal'
union all
select 'hedef', count(*), sum(total_amount)
from public.orders where status <> 'cancelled';

-- Mutabakat 2: yetim kayit var mi? (siparis var, musterisi tasinmamis)
select o.id, o.customer_id
from public.orders o
left join public.customers c on c.id = o.customer_id
where c.id is null;

-- Mutabakat 3: en riskli alan - bakiyesi degisen musteriler
select c.id, c.title, l.bakiye as eski, c.balance as yeni
from public.customers c
join legacy.cariler l on l.kod = c.legacy_code
where round(l.bakiye, 2) <> round(c.balance, 2);

Üç sorgunun üçü de boş dönmüyorsa göç tamamlanmamıştır. Bu sorguları prova göçlerinde de çalıştırın; her provada listenin kısalması, işin ilerlediğinin tek nesnel göstergesidir.

Kesme günü: dondurma, delta ve paralel çalışma

Kesme günü planı tek sayfa olmalı, çünkü o gün kimse uzun doküman okumaz. Sıra genelde şöyle işler.

• Dondurma penceresi: Eski sisteme veri girişi belirlenen saatte durur. Genelde hafta sonu ya da mesai sonrası seçilir; bu saat müşteriye ve sahaya önceden duyurulur.
• Delta göçü: Son prova ile dondurma arasında oluşan yeni kayıtlar taşınır. Bu adım unutulursa iki gün önce girilen siparişler yeni sistemde görünmez.
• Doğrulama: Mutabakat sorguları çalıştırılır ve sonuç yazılı olarak paylaşılır. Onay veren kişi baştan belli olmalıdır.
• Paralel çalışma: Eski sistem bir süre salt okunur biçimde açık kalır. Silmek için acele etmeyin; ilk ay içinde geçmişe bakma ihtiyacı mutlaka doğar.
• Geri dönüş senaryosu: Hangi koşulda eski sisteme dönüleceği ve bunun kaç dakika süreceği yazılı olsun. Bu planın nasıl kurulduğu veri yedekleme ve felaket kurtarma yazısındaki RPO/RTO mantığıyla aynıdır.

Teklifte veri göçü nasıl fiyatlanır?

Veri göçü sabit fiyatlanması en zor kalemdir, çünkü fiyatı belirleyen şey (veri kalitesi) teklif anında görülmez. Sağlıklı teklif şu üç maddeyi ayırır.

• Kaynak sayısı: Tek veritabanından göç ile dört ayrı Excel dosyası ve bir muhasebe programından göç arasında kat kat fark vardır.
• Temizliği kim yapıyor: Verinin doğrusunu yalnızca işi yapan kurum bilir. Sözleşmede “temizlenmiş veri müşteri tarafından sağlanır” maddesi yoksa, göç süresi tahmin edilemez hâle gelir.
• Prova sayısı: İki prova standarttır; üçüncüsü çoğunlukla kapsam değişikliğinin sonucudur ve ek iştir.
• Kabul kriteri: Göçün ne zaman “kabul edildiği” yazılmalıdır — genelde mutabakat raporunun üç sorgusunun da temiz dönmesi. Bu madde olmadan proje kapanmaz. Neyin nasıl yazılacağını yazılım geliştirme sözleşmesi yazısında anlattık.

KVKK: göç, veri temizliği için doğal bir fırsattır

Eski sistemlerde çoğu zaman artık hiçbir işe yaramayan kişisel veri birikir: on yıl önceki aday özgeçmişleri, silinmesi istenmiş müşteri kayıtları, gereksiz kimlik bilgileri. Bunları yeni sisteme taşımak, sorumluluğu da taşımak demektir. İki pratik kural: yalnızca işleme amacı devam eden veriyi taşıyın ve test ortamında gerçek kişisel veri kullanmayın — ad, telefon ve e-posta alanlarını maskeleyin. İlkelerin tamamı KVKK uyumlu web sitesi yazısında.

Sonuç

Veri göçü, yeni yazılım projelerinin en çok küçümsenen ve en çok geciktiren adımıdır; teknik zorluğu değil, karar sayısı yüksektir. Kapsamı daraltın, alan eşleme tablosunu baştan yazın, en az iki prova yapın ve “bitti” yerine mutabakat raporuna bakın. Mevcut sisteminizden yeni bir yazılıma geçmeyi planlıyorsanız kapsamı birlikte çıkaralım: özel yazılım geliştirme hizmetimize göz atabilir ya da veri kaynaklarınızı konuşmak için teklif alabilirsiniz.