Aylardır sorunsuz çalışan bir e-pin sitesini yeni bir sunucuya taşımak, çoğu site sahibinin en çok ertelediği işlerden biridir. Sebep basit: platform 7/24 gerçek para akışı olan bir sistemdir, tek bir yanlış adım siparişlerin kaybolmasına, bayi bakiyelerinin şaşmasına ya da ödeme sağlayıcısının bağlantıyı kesmesine yol açabilir. Peki bu geçiş gerçekten o kadar korkulacak bir şey mi, yoksa doğru sırayla ilerlendiğinde birkaç saatte bitecek rutin bir işlem mi?
Bir e-pin sitesi neden sunucu değiştirmek zorunda kalır?
Kimse keyfi olarak sunucu değiştirmez. E-pin ve dijital ürün satan sitelerde taşınma kararı genelde şu üç durumdan birinden doğar: mevcut barındırma artık trafiği kaldırmıyordur, tedarikçi API'lerine (Turkpin, Pinabi gibi) yapılan sorgular gecikiyordur ya da bayi sayısı arttıkça paylaşımlı hosting'in kaynak sınırlarına takılmaya başlanmıştır.
- Yoğun kampanya dönemlerinde site yavaşlıyor veya 503 hatası veriyor
- Mevcut sağlayıcı SSH/cron erişimini kısıtlıyor, otomasyonlar çalışmıyor
- Daha ucuz veya daha güçlü bir VPS/sunucu bulunmuş
- Domain aynı kalırken altyapı sıfırdan kurulan bir sisteme (örneğin Pinova) geçiyor
Hangi sebep olursa olsun, taşınma işleminin özünde değişmeyen bir gerçek var: canlı bir ticaret sitesinde her dakika bir sipariş gelebilir, bu yüzden plan yapmadan başlamak en büyük hata olur.
Taşımaya başlamadan önce hangi kontrol listesi tamamlanmalı?
Sunucu geçişinin en çok can yakan kısmı genelde teknik zorluk değil, unutulan bir detaydır. İşe koyulmadan önce aşağıdaki listeyi eksiksiz gözden geçirmek, geçiş gününde sürpriz yaşamamanın en garantili yoludur.
- Tam veritabanı yedeği alınmalı ve yerelde açılıp doğrulanmalı
- Yüklenen dosyalar (ürün görselleri, fatura/PDF şablonları, log klasörleri) ayrı bir arşive kopyalanmalı
- Ortam/config dosyaları (.env, ödeme API anahtarları, tedarikçi kimlik bilgileri) not edilmeli — bunlar genelde repo dışında tutulur ve unutulur
- Cron görevleri listelenmeli (otomatik stok senkronu, sipariş durumu kontrolü, bakiye raporu gibi)
- DNS TTL değeri taşımadan birkaç gün önce düşürülmeli ki geçiş anında hızlı yayılsın
- Bayilere ve müşterilere, kısa bir bakım penceresi olabileceğine dair önceden bilgi verilmeli
Bu liste sıkıcı görünse de aslında taşımanın yüzde sekseni budur. Geri kalanı sadece dosyaları kopyalayıp doğru sırayla devreye almaktan ibarettir.
Veritabanı ve dosyalar hatasız şekilde nasıl aktarılır?
E-pin scriptlerinde veritabanı sadece ürün listesi değildir; sipariş geçmişi, bayi bakiye hareketleri, kupon kullanımları ve tedarikçi işlem logları da aynı tabloların içindedir. Bu yüzden aktarım sırasında iki şeye özellikle dikkat etmek gerekir: karakter kodlaması (utf8mb4 tutarlılığı) ve büyük tabloların kesintisiz aktarılması.
Pratikte izlenen yol genelde şöyledir: eski sunucuda `mysqldump` ile tam yedek alınır, yeni sunucuda boş bir veritabanı oluşturulup içine aktarılır, ardından dosyalar SFTP veya rsync ile taşınır. Taşıma bittiğinde eski ve yeni ortamdaki kayıt sayıları karşılaştırılarak veri kaybı olup olmadığı doğrulanır.
| Taşıma Adımı | Manuel / Elle | Pinova ile |
|---|---|---|
| Veritabanı şeması kurulumu | Tablo yapısı ve kolonlar tek tek elle oluşturulur, hata riski yüksek | Kurulum sihirbazı şemayı otomatik oluşturur |
| Bayi bakiyeleri ve işlem geçmişi | SQL sorgularıyla elle doğrulanır | Bakiye bütünlüğü kurulum sonrası otomatik kontrol edilir |
| Ödeme entegrasyonu (PayTR/Shopier/havale) | Her sağlayıcı için API anahtarları ayrı ayrı elle girilir ve test edilir | Panelden tek ekrandan yapılandırılır |
| Tedarikçi API bağlantısı (Turkpin/Pinabi) | IP değişince whitelist ve config dosyaları elle güncellenir | Yeni IP tek noktadan sisteme tanıtılır |
| Ürün görselleri ve dosyalar | FTP ile elle kopyalanır, path hatası riski yüksek | Dosya yöneticisiyle toplu taşınır |
Yeni sunucuyu doğrudan ana domaine bağlamadan önce geçici bir alt alan adında (örneğin test.siteadi.com) çalıştırıp bir gün boyunca test edin. Böylece DNS'i çevirmeden önce siparişten teslimata kadar tüm akışı gerçek trafik olmadan doğrulamış olursunuz.
Ödeme ve tedarikçi API bağlantıları taşımada neden en kritik nokta?
Sunucu taşımada en çok gözden kaçan kısım, aslında dosyalarla ilgili değil, dışarıdaki servislerle ilgilidir. PayTR ve Shopier gibi ödeme sağlayıcıları, callback (bildirim) URL'lerini ve bazı durumlarda mağaza domaini üzerinden gelen istekleri kontrol eder. Sunucu IP'si değiştiğinde bu bağlantı otomatik olarak taşınmaz — panelden yeniden onaylanması veya güncellenmesi gerekir.
Turkpin ve Pinabi gibi tedarikçi API'leri ise çoğu zaman IP tabanlı beyaz liste (whitelist) kullanır. Yani yeni sunucunun IP adresi tedarikçi panelinde tanımlanmadan stok sorgulama ve teslimat istekleri sessizce başarısız olabilir; bu da sitenin "çalışıyor görünüp" aslında sipariş teslim edememesi gibi tehlikeli bir duruma yol açar.
- Ödeme sağlayıcılarının bildirim (callback) URL'lerini yeni domain/sunucu ile güncelleyin
- Tedarikçi panellerinde IP whitelist kaydını yeni sunucu IP'siyle değiştirin
- Geçişten hemen sonra küçük tutarlı gerçek bir test siparişi verin, teslimatın otomatik gerçekleştiğini gözünüzle görün
- SMTP ayarlarını (sipariş onay maili, fatura gönderimi) yeni sunucuda yeniden test edin
DNS geçişini kesintisiz yapmanın sırrı nedir?
Doğru hazırlanan bir DNS geçişi, ziyaretçilerin fark bile etmeyeceği kadar sorunsuz olabilir. Bunun anahtarı, geçişten birkaç gün önce DNS kayıtlarındaki TTL (Time To Live) değerini düşürmektir. Yüksek TTL ile yapılan bir değişikliğin dünya genelinde yayılması saatler, hatta bazı sağlayıcılarda bir güne kadar sürebilir; düşük TTL ile bu süre dakikalara iner.
Eski sunucuyu geçişten sonra hemen kapatmamak da önemli bir güvenlik önlemidir. DNS önbelleği hâlâ eski IP'ye yönlendiren bir ziyaretçi olabilir; eski sunucuyu 24-48 saat daha (salt-okunur ya da bakım moduna alınmış şekilde) ayakta tutmak, o süre zarfında gelen istekleri kayıpsız yönetmenizi sağlar.
- Geçişten 2-3 gün önce TTL'i 300 saniyeye (5 dk) düşürün
- Yeni sunucuda SSL sertifikasını (Let's Encrypt vb.) önceden hazırlayın, DNS değiştiği anda devreye girsin
- A kaydını değiştirdikten sonra `dig` veya online DNS kontrol araçlarıyla yayılımı izleyin
- E-posta (MX) kayıtlarına dokunmuyorsanız bile bir kez kontrol edin — bazı sağlayıcılar A kaydı değişince yanlışlıkla MX'i de sıfırlar
Taşıma sonrası hangi testler asla atlanmamalı?
Site yeni sunucuda "açılıyor" görünmesi, her şeyin doğru çalıştığı anlamına gelmez. E-pin sitelerinde asıl kritik olan, arka planda dönen otomasyonların sorunsuz devam etmesidir. Aşağıdaki kontrol listesi, geçiş sonrası ilk 24-48 saat içinde mutlaka tamamlanmalıdır.
- Gerçek bir ödeme ile satın alma yapıp otomatik teslimatın (e-posta veya panel üzerinden) çalıştığını doğrulayın
- Bayi panelinde giriş yapıp bakiye ve komisyon oranlarının doğru göründüğünü kontrol edin
- Cron görevlerinin (stok senkronu, bekleyen sipariş kontrolü) yeni sunucuda çalıştığından emin olun
- SSL sertifikasının geçerli olduğunu ve karışık içerik (mixed content) uyarısı vermediğini kontrol edin
- Site hız testini tekrar yapın — yeni sunucu genelde daha hızlı olmalı, değilse yapılandırma eksik olabilir
- Hata loglarını ilk gün boyunca yakından takip edin, sessiz kalan bir hata büyük kayıplara dönüşebilir
Bu adımların hepsi tek tek küçük görünse de, bir arada atlanmadığında geçiş süreci müşteriye tamamen görünmez şekilde tamamlanır. Asıl başarı ölçütü budur: kimsenin sunucunun değiştiğini fark etmemesi.
Ya bu süreci hiç yaşamadan, sağlam bir temelle mi başlasanız?
Pinova, kendi sunucunuza kurulan lisanslı bir e-pin ve dijital ürün satış yazılımı olduğu için kurulum baştan sizin altyapınıza göre planlanır; otomatik teslimat, tedarikçi API entegrasyonu, bayi sistemi ve ödeme altyapısı tek pakette gelir. Mevcut bir scriptten geçiş yapıyorsanız da kurulum ve veri aktarımı desteğiyle süreç günler değil saatler sürer.
E-pin scripti taşınırken sipariş geçmişi ve bayi bakiyeleri kaybolur mu?
Doğru yapılan bir veritabanı aktarımında hiçbir kayıt kaybolmaz. Riski ortadan kaldırmanın yolu, aktarımdan sonra eski ve yeni sunucudaki kayıt sayılarını (sipariş, bakiye hareketi, kullanıcı) karşılaştırarak doğrulamaktır.
Taşıma sırasında site ne kadar süre kapalı kalır?
Hazırlık iyi yapıldıysa (yeni sunucu önceden test edilmiş, DNS TTL düşürülmüşse) gerçek kesinti süresi genelde birkaç dakika ile birkaç saat arasında olur. Asıl uzun süren kısım DNS yayılımı değil, hazırlık ve test aşamasıdır.
Domain değişmeden sadece sunucu değişirse süreç daha mı kolay olur?
Evet, domain aynı kalıp yalnızca sunucu (IP) değiştiğinde SEO ve e-posta itibarı gibi konularla uğraşmanız gerekmez. Ancak yine de ödeme sağlayıcıları ve tedarikçi API'lerindeki IP tabanlı ayarların güncellenmesi zorunludur.
Eski bir e-pin scriptinden Pinova'ya geçerken veri aktarımı yapılabilir mi?
Evet, mevcut ürün, kategori ve genellikle sipariş geçmişi verileri uygun formatta hazırlanarak Pinova kurulumuna aktarılabilir. Aktarımın kapsamı eski scriptin veri yapısına göre değişir, bu yüzden kurulum öncesi mevcut veritabanının incelenmesi önerilir.