Panel değiştirmeye karar veren çoğu işletme sahibi, verinin "aktarılabilir" bir şey olduğunu düşünür. Elinde bir veritabanı vardır, yeni sistemin de bir veritabanı vardır, aradaki işi bir aktarım aracı çözer sanır. Gerçekte iki farklı e-pin scripti aynı kavramları farklı isimlerle, farklı ilişkilerle ve farklı varsayımlarla tutar. Birinde stok kodu ürüne bağlıdır, diğerinde sipariş satırına. Birinde bayi bakiyesi tek bir alanda durur, diğerinde hareket tablosundan hesaplanır. Aktardığın şey satırlar değil, anlamdır.
Bu yüzden veri göçü bir dosya işi değil, bir çeviri işidir. Ve her çeviride olduğu gibi, bazı ifadeler karşı dilde birebir yoktur. Doğru göç planı, neyi taşıyacağını değil neyi taşımayacağını önceden kabul etmekle başlar. Aşağıda bir dijital ürün satış scripti geçişinde hangi veri kümesinin hangi sırayla taşınacağını, nerede mutlaka manuel karar vermen gerektiğini ve göçü kimsenin fark etmeyeceği şekilde bitirmenin yolunu anlatıyorum.
Neden "tüm veriyi taşıyalım" en kötü karardır?
İlk içgüdü her şeyi taşımaktır. Beş yıllık log kayıtları, silinmiş ürünler, iptal edilmiş sepetler, test siparişleri, bir daha girmeyecek üyeler. Bunların hepsini yeni sisteme sokmak göçü hem uzatır hem de yeni panelin raporlarını kirletir. Eski sistemde bozuk olan veri, yeni sistemde de bozuk olacaktır; sadece artık senin yeni yazılımının suçu gibi görünecektir.
Doğru yaklaşım seçici göçtür. Operasyonel olarak zorunlu olanı taşı: aktif ürünler, güncel fiyatlar, kullanılmamış ve kullanılmış stok kodları, gerçek müşteri hesapları, bayi bakiyeleri ve son bir-iki yılın sipariş geçmişi. Kalan tarihsel yığını ise eski veritabanının salt-okunur bir kopyası olarak arşivle. Böylece bir müşteri üç yıl önceki bir siparişi sorduğunda cevabın olur ama yeni e-pin satış yazılımı temiz bir zeminde başlar.
Beş veri kümesi ve aralarındaki taşıma sırası
Göç asla tek hamlede yapılmaz. Veriyi bağımsız kümelere böler, her kümeyi kendi içinde doğrular, sonra bir sonrakine geçersin. Sıra keyfî değil; her küme kendinden öncekinin kimliklerine yaslanır. Kategori olmadan ürün, ürün olmadan stok kodu, kullanıcı olmadan sipariş, sipariş olmadan bakiye hareketi taşınamaz.
Kritik detay şudur: eski sistemdeki her kaydın kimliğini yeni sisteme eşleme tablosu olarak yazmalısın. Yani "eski ürün 418, yeni ürün 92" gibi bir karşılık listesi. Bu tabloyu tutmadan sipariş satırlarını bağlayamazsın ve bir hafta sonra ortaya çıkan bir tutarsızlığı da çözemezsin. Eşleme tablosu göçün karnesidir; göç bittikten sonra da sakla.
| Sıra | Veri kümesi | Bağımlılık | En sık kırıldığı yer |
|---|---|---|---|
| 1 | Kategori ve ürün ağacı | Yok | Çok seviyeli kategori düzleşir |
| 2 | Ürünler, fiyat ve varyantlar | Kategori | Bayi özel fiyatı kaybolur |
| 3 | Stok kodları (kullanılmış + boş) | Ürün | Kullanılmış kod boş sanılır |
| 4 | Kullanıcılar ve bayiler | Yok | Şifre hash formatı uyuşmaz |
| 5 | Siparişler ve bakiye hareketleri | Ürün + kullanıcı | Sipariş satırı ürünsüz kalır |
Kullanılmış stok kodunu taşımazsan aynı e-pini iki kez satarsın
Bu, veri göçünün en tehlikeli tek maddesidir. İnsanlar "kullanılmış kodları neden taşıyayım, onlar bitti" diye düşünür ve sadece boş stoku aktarır. Ama sonra eski sistemden gelen bir müşteri "kodum çalışmıyor" dediğinde elinde kayıt olmaz. Daha kötüsü, tedarikçiden toplu kod dosyası yeniden yüklenirse, daha önce satılmış kodlar yeni sistemde kullanılmamış görünür ve ikinci kez satılır. Müşteri geçersiz kod alır, iade ister, itibarın zarar görür.
Bu yüzden stok kodlarını iki durumla birlikte taşı: kod değeri ve durumu. Kullanılmışsa hangi siparişe, hangi tarihte, hangi müşteriye gittiği bilgisiyle taşı. Yeni sistemde bu kayıtlar satılabilir havuza girmez ama sorgulanabilir kalır. Bir epin yazılım geçişinde bu tek karar, sonradan çıkacak onlarca destek talebini baştan yok eder.
Veri göçünde harcanan emeğin dağılımı
- Sipariş ve stok kodu eşlemesi 40%
- Kullanıcı, şifre ve bayi yapısı 30%
- Kategori ve ürün ağacı 20%
- Bakiye ve cari mutabakatı 10%
Şifreler taşınır mı? Kullanıcıları kaybetmeden geçmenin yolu
Kullanıcı listesi taşınır, ama şifreler her zaman taşınamaz. İki sistem aynı hash algoritmasını kullanıyorsa hash değerini olduğu gibi aktarabilirsin ve müşteri hiçbir şey fark etmez. Farklı algoritma kullanıyorlarsa hash'i çeviremezsin; çünkü hash geri döndürülemez. Bu durumda iki seçeneğin var.
Birincisi zorunlu şifre sıfırlama: tüm kullanıcılara "sistemimizi yeniledik, şifrenizi yenileyin" e-postası gönderirsin. Dürüsttür ama bir kısım pasif müşteriyi kaybedersin. İkincisi kademeli geçiş: eski hash'i ayrı bir alanda saklar, kullanıcı ilk girişinde eski yöntemle doğrular ve doğruladığın anda şifreyi yeni formatta yeniden yazarsın. Kullanıcı hiçbir şey hissetmez, üç ay içinde aktif kitlenin tamamı yeni formata geçer. İkinci yöntem her zaman daha az müşteri kaybettirir; teknik olarak biraz daha iş ister ama dönüşüm açısından farkı büyüktür.
Bayi bakiyelerini tek bir toplam olarak taşımak yerine, hareket kayıtlarından yeniden hesaplat ve eski sistemin gösterdiği toplamla karşılaştır. İki sayı arasında fark varsa eski sistemde zaten bir tutarsızlık vardır ve göç bunu yeni sisteme miras bırakır. Farkı göçten önce kapat.
Prova aktarım: canlıya geçmeden üç kez yanılma hakkın
Veri göçü ilk denemede doğru çıkmaz. Bunu kabul etmek planın parçası olmalı. Bu yüzden göçü canlıya değil, önce bir test ortamına yaparsın. İlk turda tabloların büyük kısmı boş kalır veya hata verir; eksikleri yazarsın. İkinci turda sayılar tutar ama içerik bozulmuştur; kategori isimlerinde karakter sorunu, fiyatlarda ondalık kayması, tarihlerde saat dilimi farkı çıkar. Üçüncü turda hem sayı hem içerik doğrudur ve artık canlıya geçmeye hazırsın.
Her turun sonunda tek bir soruyu cevaplaman gerekir: yeni panelde rastgele seçtiğim beş siparişi açtığımda, eski panelde gördüğümün aynısını görüyor muyum? Müşteri adı, ürün, tutar, tarih, teslim edilen kod, ödeme yöntemi. Bu beş siparişi el ile karşılaştırmak, binlerce satırı otomatik saymaktan daha çok şey öğretir. Yeni panelin sipariş ve stok ekranlarının nasıl kurgulandığını özellikler bölümünden inceleyebilir, göç sonrası hangi raporların hazır geldiğini önceden görebilirsin.
| Doğrulama | Nasıl yapılır? | Kabul ölçütü |
|---|---|---|
| Ürün sayısı eşleşmesi | Aktif ürünleri iki sistemde say | Birebir aynı |
| Boş stok kodu sayısı | Satılabilir havuzu karşılaştır | Birebir aynı |
| Kullanılmış kod durumu | Rastgele 20 kodun durumunu kontrol et | Hiçbiri boş görünmüyor |
| Bayi bakiye toplamı | Hareketlerden yeniden hesapla | Kuruş farkı yok |
| Sipariş satırı bağlantısı | Ürünsüz sipariş satırı ara | Sonuç sıfır |
| Türkçe karakter bütünlüğü | İsim ve adres alanlarını tara | Bozuk kayıt yok |
| Tarih ve saat dilimi | Son 10 siparişin saatini karşılaştır | Kayma yok |
| Kullanıcı giriş testi | Gerçek bir hesapla giriş dene | Başarılı |
Göçten sonra eski sistemi kapatma anını nasıl seçersin?
Göç bittiğinde iki çalışan sistemin olur ve bu tehlikelidir. Gerçeğin tek sahibi belirlenmelidir. Yeni sistem canlıya alındığı andan itibaren eski panelde hiçbir yazma işlemi olmamalı; ne sipariş, ne stok yükleme, ne bakiye ekleme. Personelin eski panele alışkanlıkla girip işlem yapması, göçün en yaygın ölüm nedenidir. Eski panelin yazma yetkilerini teknik olarak kapatmak, ekibe "artık girmeyin" demekten kat kat güvenlidir.
Eski sistemi tamamen kapatmak için ise iki döngü bekle: bir tam fatura dönemi ve bir tam iade/destek penceresi. Bu sürede eski veri salt-okunur kalır, referans olarak kullanılır, sonra arşive alınır. Bu noktadan sonra tek bir dijital ürün satış yazılımı üzerinden çalışıyor olursun ve raporların ilk kez gerçekten güvenilir hale gelir. Lisans ve destek kapsamını fiyat sayfasından netleştirip göç takvimini ona göre kurabilirsin.
Verini kaybetmeden panel değiştir
Pinova, ürün ağacından stok kodu durumuna kadar göçün kritik noktalarını izlenebilir kılan bir yapıyla gelir. Eski sisteminden çıkmak istiyorsan doğru zemin burada.
Eski scriptimden tüm siparişleri taşımak zorunda mıyım?
Hayır. Operasyonel olarak son bir-iki yıl yeterlidir; kalanı salt-okunur arşiv olarak saklayabilirsin. Ancak stok kodlarının kullanım durumunu istisnasız taşımalısın, yoksa satılmış kodlar yeniden satılabilir hale gelir.
Müşterilerim şifrelerini yeniden oluşturmak zorunda kalacak mı?
İki sistemin hash yöntemi aynıysa hayır. Farklıysa kademeli geçiş kurgusuyla kullanıcı ilk girişte eski şifresiyle doğrulanıp arka planda yeni formata alınabilir; bu yöntemde kimse şifre sıfırlamak zorunda kalmaz.
Göç sırasında satış yapmaya devam edebilir miyim?
Prova turları boyunca evet, çünkü test ortamında çalışırsın. Son aktarımda ise kısa bir yazma penceresi kapatman gerekir; aksi halde göç başladıktan sonra eski sisteme düşen siparişler yeni sisteme hiç ulaşmaz.
Eşleme tablosunu neden saklamam gerekiyor?
Çünkü göç sonrası çıkan her tutarsızlığın izini ancak o tablo ile sürebilirsin. Eski kimlik ile yeni kimlik arasındaki karşılık listesi olmadan bir müşteri şikâyetini kaynağına kadar takip etmek pratikte imkânsız hale gelir.
Veri göçü, yeni yazılımın ilk izlenimini belirler. Aynı panel, temiz aktarılmış veriyle "nihayet düzen" hissi verir; bozuk aktarımla ise günlerce hata avlanan bir yük gibi görünür. Aradaki farkı yaratan şey aracın gücü değil, kümelerin sırası ve doğrulama disiplinidir. Pinova'nın ürün, stok ve sipariş ekranlarının göç sonrası nasıl bir düzen kurduğunu görmek için canlı demo içinde gerçek bir siparişin yolunu baştan sona takip et; kendi verinin bu yapıya nasıl oturacağını çok daha net göreceksin.