Çoğu kişi e-pin satış scripti göçünü bir dosya kopyalama işi sanır. Veritabanını dışa aktarırsın, dosyaları yeni sunucuya atarsın, DNS'i çevirirsin, bitti. Gerçekte göç bir dosya işi değil, para akışını durdurmadan raylarını değiştirme işidir. Sen taşırken müşteri bakiye yüklüyor, banka bildirimi geliyor, bayi API'si sipariş açıyor, otomatik teslimat kuyruğu kod dağıtıyor. Bu hareketli parçaların hepsini aynı anda iki yerde canlı tutmak mümkün değil; ama hangisinin ne zaman durması gerektiğini bilirsen kesinti müşteriye hiç görünmez.
Bu yazıda sana ajanslardan duymadığın kısmı anlatacağım: neden asıl risk DNS değil kuyruklardır, neden "bakım moduna al" demek bir plan değildir, ve iyi bir dijital ürün satış scripti göçünün neden geriye dönüş tuşuyla birlikte tasarlandığını. Elindeki e-pin yazılımı hangi nesil olursa olsun, aşağıdaki sıra değişmez. Çünkü sıra teknolojiden değil, paranın fizik kurallarından geliyor.
Göçü Neden Hâlâ Bir Dosya Kopyalama İşi Sanıyorsun?
Statik bir kurumsal siteyi taşımak gerçekten kopyalama işidir; çünkü sen taşırken içerik değişmez. Bir e-pin satış scriptinde ise veritabanı her saniye yazılıyor. Dışa aktarma dosyanı aldığın saniye ile yeni sunucuda içe aktarmayı bitirdiğin saniye arasında geçen her dakika, kaybolma riski taşıyan gerçek para demektir. Bir müşteri o aralıkta 500 TL yükler, eski veritabanına yazılır, senin taşıdığın kopyada yoktur. Sonuç: destek talebi, güven kaybı, elle düzeltme.
Bu yüzden göç planının ilk maddesi teknik değil muhasebeseldir: hangi tabloların para tuttuğunu listele. Bakiye hareketleri, sipariş satırları, ödeme bildirimleri, kupon kullanımları, bayi kredi kayıtları. Bunlar "son dakika" katmanıdır ve en sona bırakılır. Ürün açıklamaları, kategoriler, blog yazıları, tema dosyaları ise günler önce taşınabilir; çünkü bunlar değişmez veya değişse de zararı yoktur.
Kesintisiz Geçişin Gerçek Sırrı: Tek Yön Değil Çift Koşu
Profesyonel göçlerde yeni sistem, eskisi hâlâ canlıyken günlerce çalıştırılır. Buna çift koşu denir. Yeni e-pin satış yazılımını gizli bir alt alan adında ayağa kaldırırsın, gerçek verinin bir kopyasıyla besler, gerçek ödeme sağlayıcısının test anahtarlarıyla bağlarsın. Ekibin oradan sipariş açar, teslimat yapar, rapor çeker. Böylece göç gecesine geldiğinde yeni sistemi ilk kez görmüyorsun; yüzlerce işlem geçmiş, alışkanlıklar oturmuş oluyor.
Çift koşunun ikinci faydası daha az konuşulur: eksik veri eşleşmelerini para akmadan yakalarsın. Eski kurulumda kategori kimlikleri farklıysa, kupon mantığı başka çalışıyorsa, stok birimi adet değil kod havuzuysa bunu canlı müşteri üzerinde değil test koşusunda görürsün. Pinova tarafında bu aşamada eşleştirme haritasını bir tabloya döküp her alanın yeni karşılığını yazmanı öneriyorum; o tablo sonradan hem devir belgesi hem hata ayıklama kılavuzu oluyor.
| Katman | Dondurma anı | Taşıma yöntemi | Kabul kriteri |
|---|---|---|---|
| Tema, statik dosyalar, görseller | Dondurma yok | Günler önce senkron | Görsel kırığı sıfır |
| Kategori ve ürün kataloğu | Cutover - 24 saat | Toplu içe aktarma + eşleştirme haritası | Ürün sayısı birebir eşit |
| Müşteri hesapları | Cutover - 2 saat | Artımlı aktarma | Kayıt sayısı ve e-posta tekilliği |
| Bakiye ve cüzdan hareketleri | Cutover anı | Son artımlı + toplam mutabakat | Toplam bakiye kuruş kuruş aynı |
| Açık siparişler ve teslimat kuyruğu | Cutover - 60 dakika | Eski sistemde bitirilir, taşınmaz | Bekleyen kuyruk sıfırlanmış |
| E-pin stok havuzu | Cutover - 30 dakika | Kilitli aktarma, satış kapalı | Kullanılmamış kod sayısı eşit |
DNS'i Değiştirmeden Önce Hangi Musluğu Kapatmalısın?
Sıralamayı yanlış yapan herkes aynı hatayı yapıyor: önce DNS'i çeviriyor, sonra veriyi taşıyor. Doğrusu tersidir. Kapatılacak muslukları sırayla düşün. Birinci musluk yeni satış: sepeti ve ödeme adımını kapatırsın, site hâlâ açıktır, müşteri gezinir ama para yatmaz. İkinci musluk otomatik teslimat kuyruğu: bekleyen işleri bitirir, yeni iş almaz. Üçüncü musluk dış bildirimler: ödeme sağlayıcısının bildirim adresini geçici olarak kuyruklayan bir uca alırsın ki cutover sırasında gelen bildirim kaybolmasın. Dördüncü ve en son musluk DNS'tir.
DNS'in TTL değerini göçten en az bir gün önce 300 saniyeye düşürmeyi unutma. Aksi halde 86400 saniyelik bir kayıt yüzünden müşterilerin bir kısmı bir gün boyunca eski sunucuya düşer, orada sipariş verir ve o siparişler yeni sisteme hiç gelmez. Bu, göç sonrası en sık yaşanan ve en pahalı hatadır. Eski sunucuyu hemen kapatmak da çözüm değildir; doğru hamle eski kurulumu satış kapalı, sadece bilgilendirme veren bir sayfaya çevirmektir.
Göç sonrası yaşanan aksaklıkların kaynağı
- Sıra hatası ve kuyruk kaybı 45%
- Ödeme bildirimi kopması 25%
- DNS ve önbellek gecikmesi 20%
- Sunucu yapılandırma farkı 10%
Cutover Gecesinin Saat Saat Haritası Nasıl Çıkar?
Göç gecesi doğaçlama yapılacak yer değildir. Bir sayfaya, saat aralıklarıyla, her adımın yanında sorumlusu ve geçme kriteri yazılı bir harita çıkar. Örnek bir akış: 23.00'te satış kapanır ve duyuru yayınlanır. 23.15'te teslimat kuyruğu boşalır. 23.30'da son artımlı aktarma başlar. 00.00'da mutabakat sorguları koşar; toplam bakiye, sipariş sayısı, kullanılmamış stok sayısı iki tarafta karşılaştırılır. 00.20'de DNS çevrilir. 00.30'da ekip yeni sistemde gerçek kartla küçük tutarlı bir test siparişi geçer. 01.00'de satış açılır.
Bu haritanın en kıymetli tarafı her adımın bir sayısal kriteri olması. "Aktarma tamamlandı" bir kriter değildir; "müşteri tablosu 14.208 satır, iki tarafta eşit" kriterdir. Kriteri sağlamayan adımda durursun, bir sonrakine geçmezsin. Göç kazalarının neredeyse tamamı, sağlanmamış bir kriterin üzerinden atlanmasıyla başlar. Yeni kurulumun teknik gereksinimlerini ve modül listesini önceden özellikler bölümünden karşılaştırmak, bu haritayı hazırlamayı çok kolaylaştırır.
Cutover gecesi SQL yazmaya çalışmak en kötü fikirdir. Toplam bakiye, açık sipariş, kullanılmamış stok ve müşteri sayısını veren dört sorguyu günler önce hazırla ve iki sistemde de dene. Gece yapacağın tek iş sonuçları yan yana koymak olsun.
Geri Dönüş Planın Yoksa Aslında Planın Yok
Dürüst konuşalım: her göç plana göre gitmez. Bir ödeme sağlayıcısı yeni alan adından bildirim göndermeyi reddedebilir, sunucuda bir eklenti eksik çıkabilir, teslimat entegrasyonu beklenmedik bir zaman aşımı verebilir. Bu yüzden planın ikinci yarısı geri dönüş olmalı. Geri dönüş kararının bir eşiği olsun: örneğin cutover başlangıcından 90 dakika sonra gerçek test siparişi hâlâ geçmiyorsa geri dönülür, tartışılmaz.
Geri dönüş mümkün olsun diye eski sistemi silmezsin, dokunmazsın ve veritabanının cutover anındaki fotoğrafını ayrı bir yerde tutarsın. Kritik nokta şu: geri dönersen, yeni sistemde açılmış işlemleri elle eski sisteme işlemen gerekir. Bu iş küçük kalsın diye satışı en son açarsın ve ilk yarım saat düşük hacimle çalışırsın. Bir e-pin scripti göçünde "önce küçük dalga, sonra tam açılış" yaklaşımı, sıfırdan risk almaktan çok daha ucuzdur.
| Kontrol | Ne zaman | Sorumlu | Geçme kriteri |
|---|---|---|---|
| DNS TTL 300 saniyeye düşürüldü | Cutover - 24 saat | Teknik | Sorgu yanıtı 300 gösteriyor |
| Ödeme sağlayıcısı yeni alan adı beyaz listede | Cutover - 12 saat | Muhasebe + teknik | Sağlayıcı panelinde onaylı |
| Test koşusunda 20 uçtan uca sipariş | Cutover - 3 gün | Operasyon | Hatasız 20/20 |
| Teslimat kuyruğu boşaltıldı | Cutover - 60 dakika | Operasyon | Bekleyen kayıt sıfır |
| Dört mutabakat sorgusu eşit sonuç verdi | Cutover anı | Teknik | Dördü de birebir |
| Gerçek kartla düşük tutarlı canlı sipariş | DNS sonrası 10 dakika | Sahibi | Teslimat otomatik ulaştı |
| Eski sunucu satış kapalı bilgi sayfasına alındı | Cutover + 24 saat | Teknik | Sipariş alınamıyor |
Göçten Sonra İlk 72 Saat Neden Asıl Sınav?
Cutover bittiğinde göç bitmiş olmaz; izleme dönemi başlar. İlk 72 saatte üç şeyi günde birkaç kez kontrol et: ödeme bildirimlerinin düşme oranı, teslimat gecikme süresi ve hata kayıtlarının hacmi. Bu üçünden biri sapıyorsa sebebi neredeyse her zaman göçle ilgilidir; üçüncü gün ortaya çıkan "rastgele" hata diye bir şey yoktur. Ayrıca ilk hafta boyunca yedeklemenin gerçekten koştuğunu gözünle gör; yeni sunucuda zamanlanmış görevlerin taşınmadığını fark etmek için müşteri şikâyetini beklemek pahalı bir öğrenme yöntemi.
Son olarak göç sonrası ilk faturalandırma dönemini, lisans ve altyapı maliyetini yeniden gözden geçirmek için kullan. Çoğu işletme eski kurulumun şişmiş sunucu ihtiyacını yeni sisteme olduğu gibi taşıyor ve gereksiz para ödüyor. Yeni bir e-pin satış scriptine geçerken gerçek kaynak ihtiyacını ölçüp fiyatlandırmayı buna göre planlamak, göçün getirdiği ikinci kazançtır.
Göçü riske atmadan yapmak istiyorsan
Pinova, katman katman aktarma, mutabakat raporları ve geri dönüş dostu kurulum yapısıyla kesintisiz geçiş için tasarlandı. Mevcut kurulumunu anlat, geçiş haritanı birlikte çıkaralım.
Göç sırasında sitemi tamamen kapatmam şart mı?
Hayır. Siteyi açık tutup yalnızca sepet, ödeme ve bakiye yükleme adımlarını kapatabilirsin. Böylece ziyaretçi gezinmeye devam eder, arama motoru hata görmez, sen de yazma işlemlerini dondurmuş olursun.
Eski sunucuyu ne zaman kapatabilirim?
En az 14 gün bekle. DNS önbellekleri, ödeme sağlayıcısının eski bildirim adresi ve arama motoru taramaları bir süre eski adrese gelmeye devam eder. Bu süre boyunca satış kapalı bir bilgilendirme kurulumu bırakmak en güvenlisi.
Kullanılmamış e-pin kodlarını aktarmalı mıyım?
Evet, ama satış kapalıyken ve kilitli biçimde. Aktarma sonrası kullanılmamış kod sayısı iki tarafta birebir eşit değilse cutover'a devam etmemelisin; eksik kod doğrudan zarar demektir.
Göç için ne kadar süre ayırmalıyım?
Hazırlık ve test koşusu için 1-2 hafta, cutover gecesi için 4-6 saat, izleme için ilk 72 saat. Cutover'ı tek başına 2 saate sığdırmaya çalışmak, hazırlığın eksik olduğunun işaretidir.
Göç, korkulacak bir ameliyat değil; sırası önceden yazılmış bir kontrol listesi. Sıralamayı doğru kurarsan müşterinin fark ettiği tek şey, ertesi sabah panelin daha hızlı açılması olur. Yeni bir dijital ürün satış yazılımına geçmeyi düşünüyorsan, önce arayüzü ve akışları kendi gözünle görmen işini kolaylaştırır: canlı demo üzerinden sipariş, teslimat ve raporlama akışını dene, sonra göç haritanı bu akışa göre yaz.