Epin Satış Paneli Göçünde Müşteri Hesaplarını Taşımak: Şifreleri Sıfırlamadan, Bakiyeyi Kuruşu Kuruşuna Koruyarak Geçmenin Yolu

Çoğu işletme sahibi panel değiştirirken şöyle düşünür: "Müşteriler zaten yeniden kayıt olur, şifre sıfırlama maili atarım, olur biter." Bu cümle, göçün en pahalı kararıdır. Çünkü bir e-pin satış scripti değiştirirken sattığın ürün değişmez; değişen tek şey müşterinin alıştığı kapıdır. O kapıyı kilitlersen, yıllarca ödediğin edinme maliyetini bir gecede çöpe atarsın.

Asıl mesele de burada: müşteri hesabı sadece e-posta ve şifreden oluşmaz. Bakiyesi, bayi seviyesi, özel iskontosu, doğrulanmış telefonu, geçmiş adresleri ve kendisine açılmış kredi limiti vardır. Yeni epin yazılım kurulumuna geçerken bunların hepsi tek bir mantıkla eşlenmezse, ortaya "girebilen ama parası görünmeyen" ya da "bakiyesi duran ama giremeyen" müşteriler çıkar. İkisi de aynı yere varır: güven kaybı.

Şifreleri gerçekten taşıyabilir misin, yoksa herkesi sıfırlamak zorunda mısın?

Cevap eski sistemin şifreleri nasıl sakladığına bağlı. Eğer bcrypt gibi modern bir yöntem kullanılıyorsa, hash'leri olduğu gibi taşıyıp müşteri şifresini hiç değiştirmeden giriş yapmasını sağlayabilirsin. Eski panellerin bir kısmı ise md5, sha1 ya da tuzsuz karma kullanır; bunlar taşınabilir ama olduğu gibi bırakılmamalı.

Burada işe yarayan yöntem girişte yeniden karmalamadır. Müşteri eski şifresiyle giriş yapar, sistem eski yöntemle doğrular, doğruysa aynı anda şifreyi modern yöntemle yeniden kaydeder. Müşteri hiçbir şey fark etmez; sen birkaç hafta içinde tüm veritabanını sessizce güvenli hâle getirirsin.

Sadece çok eski veya çözülemeyen bir karma varsa sıfırlama kaçınılmazdır. O durumda bile herkese toplu mail atmak yerine, girişte "güvenlik güncellemesi nedeniyle tek seferlik şifre yenileme" akışı kurmak dönüşümü belirgin biçimde korur.

Bakiye göçünde neden "tek sayı" taşımak yanlıştır?

Eski panellerin çoğu bakiyeyi kullanıcı satırında tek bir alan olarak tutar. Yeni bir dijital ürün satış yazılımı ise genelde hareket tabanlı çalışır: her yükleme, her harcama, her iade bir kayıttır ve bakiye bu kayıtların toplamıdır. İki mantık arasında geçiş yaparken tek sayıyı kopyalarsan defter boş, bakiye dolu olur; sonra ilk iade işleminde tutarsızlık başlar.

Doğrusu, her müşteri için "göç açılış kaydı" oluşturmaktır. Açıklaması net olan tek bir hareket: eski sistemden devir. Böylece bakiye toplamı tutar, hareket geçmişi de baştan tutarlı başlar. Müşteri kendi hesap ekranında bakiyesinin nereden geldiğini görebilir.

Mutabakat adımını atlamak burada en sık yapılan hata. Göç sonrası şunu kontrol et: eski sistemdeki tüm bakiyelerin toplamı ile yeni sistemdeki toplam birebir aynı mı? Fark varsa hangi kullanıcılarda? Kuruş farkı bile sessizce kapatılmamalı, sebebi bulunmalı; çünkü genelde yuvarlama değil, atlanmış bir kullanıcı grubudur.

Çift hesaplar ve bozuk e-postalar göçü nasıl kilitler?

Eski sistemler genelde e-postada benzersizlik zorlamaz. Sonuç: aynı müşterinin üç hesabı, birinde bakiye, birinde sipariş geçmişi. Yeni panel benzersizlik istediğinde aktarım hata verir ve sen gece yarısı hangi kaydın gerçek olduğunu tahmin etmeye çalışırsın.

Bunu göçten önce çöz. Çift kayıtları listele, hangisinin son giriş tarihi yeni, hangisinde para var, hangisinde sipariş var diye işaretle. Kural koy: bakiyeler ana hesapta birleşir, sipariş geçmişi ana hesaba bağlanır, diğerleri pasif arşivlenir. Karar gece değil, tabloda verilmeli.

Aynı şekilde geçersiz e-postaları temizle. Bir kez de olsa doğrulanmamış, teslim edilemez adresler yeni sistemde bildirim kuyruğunu şişirir ve gönderen itibarını düşürür. Göç, aslında kullanıcı listesini yıllardır yapmadığın biçimde temizlemek için en iyi fırsattır.

KVKK ve oturum güvenliği tarafında neyi atlıyorsun?

Müşteri hesabı taşımak kişisel veri işlemektir. Yeni sisteme taşınan alanların gerçekten gerekli olup olmadığını sor: eski panelde tutulan kimlik numarası, IP geçmişi, yıllar önceki adres kayıtları sana bugün ne sağlıyor? Gerekmeyeni taşımamak en güçlü koruma yöntemidir.

İkinci konu oturumlardır. Göç anında tüm aktif oturumlar geçersiz kılınmalı, çerezler yenilenmeli. Eski oturum anahtarlarını taşımak konfor değil, açık kapı bırakmaktır. Müşteri bir kez yeniden giriş yapar, bunu kimse sorun etmez.

Üçüncüsü iletişim: göç öncesi kullanıcıya hangi verinin taşındığını, hangi tarihte sistemin değiştiğini bildiren kısa bir duyuru yap. Bu hem yasal tarafı, hem de "bu mail gerçek mi" sorusundan doğan kimlik avı şüphesini ortadan kaldırır.

İlk giriş dalgasını nasıl karşılarsın?

Yayına aldıktan sonraki ilk 48 saat, hesap göçünün gerçek sınavıdır. Şifre sıfırlama talebi yükselir, mail kuyruğu şişer, destek kanalı dolar. Buna hazırlık üç şeyle yapılır: gönderim altyapısını önceden ısıtmak, giriş ekranına açıklayıcı bir bilgi notu koymak ve destek ekibine hazır cevap seti vermek.

Ölçmen gereken tek gösterge şu: göç öncesi 30 günde giriş yapan kullanıcıların yüzde kaçı göç sonrası ilk 7 günde giriş yaptı? Bu oran yüzde 70'in altındaysa bir yerde tıkanma var; genelde şifre akışı ya da e-posta teslimidir.

Son olarak eski panelin giriş ekranını hemen kapatma. Bir süre yönlendirme sayfası olarak dursun, "panelimiz taşındı, buradan giriş yapabilirsin" desin. Bu basit sayfa, dönmeyen müşterilerin önemli bir kısmını geri kazandırır. Yeni e-pin scripti ne kadar iyi olursa olsun, müşteriyi kapıya kadar getirmezsen faydası olmaz.

Hesap göçünü başarılı yapan şey teknik ustalık değil, müşterinin hiçbir şey fark etmemesidir: aynı şifreyle girer, aynı bakiyeyi görür, aynı iskontoyla alışveriş yapar. Bu deneyimi kurmadan önce cüzdan hareketlerinin ve bayi kademelerinin nasıl göründüğünü kendi gözünle test et; canlı demo içinde bir test hesabı açıp bakiye yükleyip harcayarak göç planındaki eşleme kararlarını daha ilk günden netleştirebilirsin.