Epin Yazılımı Göçü Öncesi Veri Temizliği: Yeni Scripte Taşımadan Önce Veritabanında Gizlenen Kirliliği Nasıl Ortaya Çıkarırsın?

Çoğu işletme sahibi veri temizliğini göçten sonra yapılacak bir düzenleme sanır. "Önce taşıyalım, sonra bakarız" cümlesi kulağa makul gelir; oysa taşıdığın her kirli satır yeni sistemde iki katı sorun üretir. Çünkü yeni bir epin yazılımı, eskisinin gevşek davrandığı yerlerde kuralları sıkı uygular: e-posta tekilliğini zorlar, sipariş satırını bir ürüne bağlamak ister, para alanını ondalık olarak bekler. Eski kurulumunda yıllarca sessizce duran tutarsızlık, içe aktarma anında yüzlerce hata satırına dönüşür.

Daha sinsi bir sonuç da var: içe aktarma hatası vermeyen kirlilik. Bunlar hata üretmez, sadece raporlarını yanlış gösterir. Toplam ciro şişer, müşteri sayısı gerçekten yüksek görünür, dönüşüm oranın anlamsızlaşır. Bu yazıda göç öncesi veri temizliğini bir arınma ritüeli değil, ölçülebilir bir mühendislik işi olarak ele alacağız: hangi kirlilik türünü nasıl bulacaksın, neyi düzeltip neyi arşivleyeceksin, ve hangi eşiği geçmeden aktarmaya başlamayacaksın.

Temiz Veri Diye Sandığın Şey Aslında Neydi?

Panelinde hata görmüyorsan verin temiz sanırsın. Ama panel sadece sorgulayabildiğini gösterir. Veri kalitesi üç ayrı eksende ölçülür: bütünlük (her sipariş satırı gerçek bir ürüne ve gerçek bir müşteriye bağlı mı), tekillik (aynı kişi kaç kez kayıtlı) ve biçim (tarih, para, telefon, karakter seti tutarlı mı). Göç öncesi yapılacak ilk iş bu üç ekseni sayıya dökmek. Tahmin değil sayı; çünkü "biraz karışık" cümlesiyle plan yapılmaz.

Pratik yöntem şu: her tablo için satır sayısı, boş kalan kritik alan sayısı ve ilişkisi kopmuş satır sayısını içeren tek sayfalık bir envanter çıkar. Bu sayfayı göçten önce ve göçten sonra karşılaştıracağın referans belge olarak sakla. Envanter çıkarmadan temizliğe girişirsen ne kadar ilerlediğini bilemezsin ve bir noktada durmak yerine ucu açık bir uğraşa dönüşür.

Mükerrer Müşteri Kayıtları Neden Bakiye Kaybına Dönüşür?

Yıllar içinde aynı kişi büyük harfli e-posta, nokta eklenmiş e-posta veya farklı telefon biçimiyle iki üç kez kayıt olur. Eski kurulum buna izin vermişse elinde bir müşterinin üç ayrı cüzdanı olur. Yeni e-pin satış yazılımı e-postayı tekil kabul ettiğinde bu üç kayıttan ikisi aktarılamaz veya birleştirilir. Birleştirme yanlış yapılırsa bakiye ya kaybolur ya çift sayılır. İkisi de kabul edilemez.

Doğru sıra: önce e-postaları küçük harfe indir ve baş-son boşlukları kırp, sonra normalleştirilmiş hâliyle grupla. Aynı gruptaki kayıtlar için en eski kaydı ana kayıt seç, diğerlerinin bakiye hareketlerini ana kayda taşı, kapatılan kayıtları silmek yerine birleştirildi olarak işaretle. Birleştirme sonunda toplam bakiye tutarının değişmediğini tek sorguyla doğrula. Bu doğrulama yapılmadan bir sonraki adıma geçmek, göçün en pahalı hatasını davet etmek olur.

Yetim Sipariş Satırları Raporlarını Nasıl Zehirliyor?

Yetim satır, bağlı olduğu kaydı artık var olmayan satırdır: silinmiş bir ürüne ait sipariş satırı, hesabı kapatılmış müşterinin cüzdan hareketi, olmayan kategoriye bağlı ürün. Eski kurulum bunları görmezden gelir; sen de fark etmezsin çünkü panel listelerken ilişkiyi zorunlu tutmaz. Ama yeni bir dijital ürün satış scriptine aktarırken bu satırlar ya reddedilir ya da boş alanlarla içeri girer ve ciro raporunda kaynağı belirsiz tutarlar olarak karşına çıkar.

Yetim satırları silmek ilk akla gelen çözüm ama en kötüsü. Bunlar geçmiş muhasebenin parçası; bir gün bir müşteri üç yıl önceki siparişini sorabilir. Doğru yaklaşım arşiv: yetim satırları ayrı bir tabloya, bulunduğu tarih ve gerekçe etiketiyle taşı. Aktarmaya sokma, ama elinin altında tut. Böylece yeni sistemin veri bütünlüğü bozulmaz, geçmişe erişim de kapanmaz.

Karakter Seti ve Biçim Kirliliği: Göçün Sessiz Katili

Bir gün ürün listende "Kahramanlar Paketi" yerine soru işaretleriyle dolu bir isim görürsen sebep neredeyse kesin olarak karakter seti uyumsuzluğudur. Eski veritabanı bir kodlamayla, yeni kurulum başka bir kodlamayla çalışır; arada yapılan dışa aktarma bu bilgiyi taşımaz. Hatanın en kötü yanı geri dönüşü zor olmasıdır: bozulmuş metni doğru hâline döndürmek her zaman mümkün olmuyor. Bu yüzden dışa aktarma komutunda kodlamayı açıkça belirtmek ve küçük bir örnek grubu önce test etmek zorunludur.

Biçim kirliliği daha görünmezdir ama operasyonu doğrudan vurur. Telefon alanında bazı kayıtlar ülke kodlu, bazıları sıfırla başlıyor, bazıları boşluklu. Göçten sonra kampanya bildirimi gönderdiğinde üçte biri düşmez ve sen bunu "yeni yazılım bildirim göndermiyor" diye yorumlarsın. Aynısı tarih alanları için de geçerli: karışık biçimler yüzünden dönemsel raporlar yanlış aralık verir. Bu iki alanı göçten önce tek biçime çekmek, bir günlük iş karşılığında haftalarca kafa karışıklığı önler.

Kullanılmamış E-pin Stoku Göçe Girmeli mi?

Bu sorunun cevabı basit bir "evet" değil. Kullanılmamış kodları üç gruba ayır. Birinci grup satışta ve geçerli olanlar: mutlaka aktarılır, üstelik aktarma sırasında sayımı birebir doğrulanır. İkinci grup süresi geçmiş veya tedarikçi tarafından iptal edilmiş olanlar: bunlar aktarılmaz, arşive alınır; yeni sistemde satışa açık görünmeleri müşteriye bozuk kod teslim etmek anlamına gelir. Üçüncü grup şüpheli olanlar: kaynağı belirsiz, tedarikçi kaydı eksik kodlar. Bunlar için göçü bekletme; ayır, tedarikçiyle mutabakat yap, sonra karar ver.

Stok tarafında sık yapılan hata, kodları aktarırken şifreleme yöntemini değiştirmeyi hesaba katmamaktır. Eski kurulumda düz metin tutulan kodlar yeni sistemde şifreli tutuluyorsa aktarma sırasında bir dönüştürme adımı gerekir; bu adım atlanırsa kodlar teslim edilemez hâle gelir. Yeni kurulumun stok ve teslimat mimarisini özellikler listesinden önceden okuyup dönüştürme ihtiyacını planına yazmak en güvenli yol.

Silme Değil Arşivleme: Denetim İzini Nasıl Korursun?

Veri temizliği kelimesi insanı silmeye iter, oysa e-ticarette silmek hemen her zaman yanlış cevaptır. Vergi mevzuatı geçmiş satış kayıtlarının saklanmasını gerektirir; müşteri talebi geldiğinde geçmiş siparişine bakabilmen gerekir; bir anlaşmazlıkta teslimat kaydı senin savunman olur. Bu yüzden göç öncesi temizlikte ilkeyi tersine çevir: aktarma dışı bırak, ama hiçbir şeyi yok etme.

Pratikte bunu üç kovayla yapabilirsin. Birinci kova aktarılacak temiz veri. İkinci kova arşive alınacak geçmiş veri; yeni sistemde değil, salt okunur bir yedekte tutulur. Üçüncü kova kişisel veri talebi üzerine anonimleştirilecek kayıtlar; burada kişiyi tanımlayan alanlar maskelenir ama satışın tutar ve tarih bilgisi korunur. Bu üç kovayı bir tabloya döküp göçten önce karar vermek, sonradan "bu kayıt nereye gitti" sorusuna cevap verebilmenin tek yolu.

Veri temizliği göçün en sıkıcı ama getirisi en yüksek aşaması; çünkü burada harcadığın her saat, cutover gecesinde iki saat kazandırıyor. Envanterini çıkar, üç kovanı belirle, sayıları tutturmadan aktarmaya başlama. Yeni kurulumun içe aktarma ekranlarını ve doğrulama raporlarını görmek istersen canlı demo üzerinden dolaş; hangi alanların zorunlu tutulduğunu baştan bilmek, temizlik listeni yarı yarıya kısaltır.