Çoğu kişi veri göçünü şöyle sanır: eski panelin veritabanını dışa aktarırsın, yeni e-pin scripti kurulumunu yaparsın, dosyayı içe alırsın, akşam yemeğine yetişirsin. Bu hikâye kulağa güzel geliyor ama sahada iki gün süren bir kâbusa dönüşmesinin sebebi tam olarak bu iyimserlik. Çünkü göç ettirdiğin şey "tablolar" değil; yıllardır müşterinin güvendiği bakiye, teslim edilmiş kod, açık talep ve muhasebe izidir.
Gerçek şu ki eski sistemler nadiren temizdir. İçinde elle düzeltilmiş siparişler, iki kez girilmiş ürünler, silinmiş sanılan ama hâlâ ilişkili kalan kategoriler ve bir zamanlar "geçici" diye açılan sütunlar vardır. Yeni bir dijital ürün satış scriptine geçerken bu kirliliği olduğu gibi taşırsan, sorunları da lisansıyla birlikte satın almış olursun. Bu yazıda göçü bir dosya kopyalama işi gibi değil, kontrollü bir devreye alma projesi gibi ele alıyoruz.
Veri göçü neden "kopyala-yapıştır" değil, yeniden inşa işidir?
Eski panelinle yeni e-pin satış yazılımı aynı işi yapsa da aynı dili konuşmaz. Birinde ürün fiyatı tek sütunda tutulur, diğerinde alış-satış-bayi fiyatı ayrışmıştır. Birinde stok bir sayıdır, diğerinde stok kodların kendisidir. Bu yüzden göç aslında bir çeviri işlemidir: eski yapının anlamını yeni yapının alanlarına doğru eşlemek.
Bu eşlemeyi yapmadan aktarım denediğinde tipik olarak şu olur: veriler girer, hata vermez, ama panelde ürünler fiyatsız, kategoriler boş, bakiyeler sıfır görünür. Hata mesajı almadığın için her şeyin yolunda olduğunu sanırsın; müşteri ilk siparişi verdiğinde gerçek ortaya çıkar. Sessiz başarısızlık, gürültülü hatadan çok daha pahalıdır.
Doğru yaklaşım, göçü üç katmana ayırmaktır: sabit veri (ürün, kategori, ayar), kullanıcı verisi (hesap, bakiye, adres) ve hareket verisi (sipariş, kod, log). Her katmanın kendi doğrulama testi olur ve bir katman geçmeden diğerine geçilmez.
Eski panelinin veritabanı sana ne saklıyor?
Göçe başlamadan önce yapılacak tek doğru iş envanter çıkarmaktır. Tablo sayısı, satır sayısı, kullanılmayan tablolar, tarih formatları ve karakter seti. Türkçe karakter sorunu göçlerin klasik tuzağıdır: eski sistem latin5 ya da karışık bir derlemeyle çalışıyorsa, aktarımdan sonra ürün adlarının yarısı bozuk çıkar.
İkinci bakacağın şey ilişkilerdir. Sipariş satırı hangi ürüne bağlı? O ürün hâlâ var mı? Silinen bir kategorinin altında hayalet ürünler kalmış mı? Bunlar eski panelde görünmez, ama yeni epin yazılım kurulumu tutarlılık beklediği için ilk raporda seni bulur.
Üçüncüsü hassas veridir: kod havuzları, API anahtarları, ödeme sağlayıcı kimlikleri. Bunların düz metin mi, şifreli mi tutulduğunu göç öncesi bilmek zorundasın; çünkü şifreleme anahtarı eski sistemde kalırsa taşıdığın kodlar okunamaz hale gelir.
| Veri grubu | Eski scriptteki tipik hâli | Yeni sistemde karşılığı | Risk |
|---|---|---|---|
| Ürün ve kategori | Tek fiyat sütunu, düz kategori | Çok kademeli fiyat, ağaç kategori | Orta |
| E-pin kod havuzu | Düz metin, tek tablo | Şifreli havuz, durum alanlı | Yüksek |
| Bakiye ve cüzdan | Kullanıcı tablosunda tek alan | Hareket tabanlı defter | Yüksek |
| Siparişler | Tek tablo, karışık durum metni | Sipariş + kalem + durum kodu | Yüksek |
| Ayarlar ve içerik | Dosya içinde sabit | Panel ayarı | Düşük |
| Loglar | Şişmiş, indekssiz | Arşiv tablosu | Düşük |
E-pin kodlarını taşırken en tehlikeli an hangisi?
En tehlikeli an, göç ile yayına alma arasındaki boşluktur. Kodları akşam 21:00'de dışa aktarıp yeni sistemi 23:00'te açtıysan, arada eski panelden satılan her kod yeni sistemde "kullanılabilir" görünür. Aynı kod iki müşteriye gider; birinin parası iade, itibarın ise tamir edilmesi zor bir yerde olur.
Çözüm basit ama disiplin ister: göç penceresi açıldığı anda eski panelde satış kapatılır. Bakım moduna alınır, ödeme sağlayıcıları duraklatılır, ardından son ve tek geçerli aktarım alınır. Kod havuzu göçü her zaman son adımdır, ilk adım değildir.
Bir de mutabakat adımı vardır: aktarım sonrası "satılmış", "rezerve" ve "boşta" kod sayıları eski sistemle birebir karşılaştırılır. Sayılar tutmuyorsa yayına geçilmez. Bu kontrol beş dakika sürer ve seni günlerce sürecek bir telafi sürecinden kurtarır.
Göç sırasında zamanın nereye gittiği
- Veri temizliği ve eşleme 45%
- Kuru prova ve doğrulama 25%
- Yayına alma ve mutabakat 20%
- Sonrası düzeltmeler 10%
Kuru prova yapmayan neden iki kere taşınır?
Kuru prova, gerçek veriyle ama gerçek müşteri olmadan yapılan tam bir göç denemesidir. Alt alan adında yeni e-pin satış scripti kurulumunu yaparsın, verileri aktarırsın, test siparişi geçirirsin, bakiye düşürürsün, kod teslim edersin. Amacın site açmak değil; hangi adımın kaç dakika sürdüğünü ve nerede patladığını öğrenmek.
İlk provada mutlaka bir şey kırılır. İkincisinde çoğu sorun düzelmiştir. Üçüncüsünde artık senaryo ezberlenmiştir ve gerçek gece için elinde dakikası belli bir plan olur. Provasız göçlerin "bir gece" sürmesinin nedeni, provanın canlı sistemde yapılmasıdır.
Provanın bir yararı da geri dönüş planını test etmektir. Yayına aldıktan 40 dakika sonra ciddi bir hata bulursan ne yapacağını önceden bilmelisin: DNS'i geri almak mı, eski paneli tekrar açmak mı, yoksa ileri gidip düzeltmek mi?
Cuma akşamı taşıma yapma. Sorun çıktığında destek alabileceğin, ödeme sağlayıcısına ulaşabileceğin bir gün seç; salı ya da çarşamba gecesi en güvenli penceredir.
Kesinti penceresini 4 saatten 15 dakikaya nasıl indirirsin?
Sır, işi ikiye bölmektir. Değişmeyen veriyi (ürün, kategori, içerik, ayar) göç gecesinden günler önce taşı ve yeni panelde kontrol et. Böylece gece yalnızca hareketli veri kalır: son siparişler, güncel bakiyeler, kod havuzu durumu.
İkinci hamle, hazırlığı önceden bitirmektir. SSL sertifikası kurulu, alan adı yönlendirmesi hazır, TTL süresi düşürülmüş, ödeme sağlayıcı sandbox testi geçilmiş olmalı. Gece yapılacak tek şey son aktarım ve anahtarı çevirmek.
Üçüncüsü iletişim: müşterine bir gün önceden "şu saat aralığında sistem bakımda" duyurusu yap. Planlı 15 dakikalık kesinti güven artırır; plansız 2 saatlik kesinti tam tersini yapar. Yeni dijital ürün satış yazılımına geçtiğini ayrıca duyurmak, panelde göreceği değişikliği sürprize dönüştürmez.
Göç sonrası ilk 72 saatte neyi izleyeceksin?
Yayına almak bitiş değil, izlemenin başlangıcıdır. İlk 72 saat boyunca üç şeyi günlük takip et: başarısız ödeme oranı, teslim edilmeyen sipariş sayısı ve destek taleplerinin konusu. Taleplerin çoğu "şifremi kabul etmiyor" ya da "bakiyem eksik" diyorsa, göçün kullanıcı katmanında bir eşleme hatası vardır.
İkinci olarak arama motoru tarafını kontrol et. Ürün adresleri değiştiyse kalıcı yönlendirmeleri kur, site haritasını yeniden üret. Trafik kaybı genelde göçün teknik başarısızlığından değil, yönlendirme ihmalinden çıkar.
Son olarak eski sistemi hemen silme. En az bir ay salt-okunur bir yedek olarak dursun. İhtilaflı bir sipariş, eski bir fatura ya da unutulmuş bir kod havuzu için ona dönmen gerekebilir.
| Kontrol adımı | Ne zaman | Kabul ölçütü | Durum |
|---|---|---|---|
| Karakter seti ve Türkçe kontrolü | Prova 1 | Ürün adlarında bozulma yok | Zorunlu |
| Ürün-kategori ilişki testi | Prova 1 | Sahipsiz ürün sıfır | Zorunlu |
| Bakiye toplam mutabakatı | Prova 2 | Toplam fark 0,00 TL | Zorunlu |
| Kod havuzu sayım mutabakatı | Yayın gecesi | Satılan/boşta sayıları birebir | Zorunlu |
| Test siparişi ve teslim | Yayın gecesi | Kod otomatik teslim edildi | Zorunlu |
| Yönlendirme ve site haritası | İlk 24 saat | Kırık adres yok | Önemli |
| Eski sistem salt-okunur yedek | İlk hafta | 30 gün saklama | Önemli |
Göçü tek gecede, kayıpsız bitirmek istersen
Pinova, eski panelden gelen veriyi eşleyecek yapıyla kurulur: kademeli fiyat, hareket tabanlı cüzdan, durum kodlu sipariş ve şifreli kod havuzu. Özellikleri ve lisans seçeneklerini inceleyip planını bugün çıkarabilirsin.
Göç için eski scriptin kaynak kodu şart mı?
Hayır, çoğu durumda veritabanı yedeği yeterlidir. Ancak şifreleme kullanan bir kod havuzu varsa, şifre çözme mantığını görmek için kaynak dosyalara ya da anahtara ihtiyaç duyulur.
Kesinti olmadan göç mümkün mü?
Tamamen sıfır kesinti pratikte risklidir. Değişmeyen veriyi önceden taşıyıp sadece hareketli veriyi gece aktarırsan, kesintiyi 10-15 dakikaya indirebilirsin.
Eski siparişleri hiç taşımasam olur mu?
Olur ama önerilmez. Müşteri geçmiş teslimlerini göremezse destek yükü artar; muhasebe ve garanti taleplerinde de kanıt kaybedersin.
Göç ne kadar sürer?
Veri hacminden çok, verinin düzenliliği belirler. Temiz bir yapıda iki prova artı bir yayın gecesi; dağınık bir yapıda temizlik için birkaç gün daha ayırman gerekir.
Göç, panelini değiştirmek değil işletmenin hafızasını taşımaktır; o hafıza doğru taşındığında müşterin hiçbir şey fark etmez ve senin destek yükün gözle görülür biçimde düşer. Planını çıkarmadan önce yeni sistemin sipariş, cüzdan ve kod havuzu ekranlarını kendi gözünle gör: canlı demo üzerinden test siparişi geçirip hangi alanların hangi veriyi beklediğini not alman, göç gecesinde sana en az iki saat kazandırır.