Taşıma projelerinde ilk toplantı hep aynı cümleyle başlıyor: "Ürünleri aktarırız, birkaç günde biter." Ürünleri aktarmak gerçekten birkaç gün sürüyor. Projeyi haftalara yayan şey ürünler değil; taşınamayan şeyler. Şifreler, kayıtlı kartlar, sipariş geçmişinin detayı, yorumlar, kupon bakiyeleri ve en önemlisi yıllardır biriken adres yapısı.
Bu yazı, o taşınamayanların listesini ve her birinin nasıl yönetileceğini anlatıyor. Amaç korkutmak değil; taşımayı planlanabilir hâle getirmek. Doğru sırayla yürütülen bir geçiş, geçici bir dalgalanmayla atlatılır. Yanlış sırayla yürütülen bir geçiş, aylarca süren bir toparlanmaya döner.
E-ticaret sitesi taşıma neden bir veri kopyalama işi değil?
E-ticaret sitesi taşıma denince akla veritabanından veritabanına aktarım geliyor. Oysa bir mağaza yalnızca veriden ibaret değil; dışarıya verdiği sözlerden de oluşuyor. Arama motoruna verdiği söz belli bir adreste belli bir içeriğin duracağıdır. Müşteriye verdiği söz aynı e-posta ve şifreyle giriş yapabileceğidir. Ödeme sağlayıcısına verdiği söz aynı işletme ve aynı akıştır.
Taşıma, bu sözlerin tamamının yeniden kurulmasıdır. Veri aktarımı bunun yalnızca bir parçası. Aşağıdaki tablo, bir mağazadaki varlıkların taşınabilirlik durumunu özetliyor:
| Varlık | Taşınabilir mi? | Nerede kırılır |
|---|---|---|
| Ürünler, varyantlar, görseller | Evet | Stok kodu tekilliği ve görsel eşleşmesi |
| Kategoriler ve filtreler | Kısmen | Filtre mantığı platforma göre değişir |
| Müşteri kayıtları | Evet | Adres defterleri ve izin kayıtları eksik gelir |
| Müşteri şifreleri | Hayır | Karma algoritmaları uyuşmaz |
| Kayıtlı kartlar / otomatik ödeme | Genelde hayır | Kart verisi ödeme sağlayıcısında saklanır |
| Sipariş geçmişi | Kısmen | Tarih, ödeme durumu ve iade kayıtları korunmaz |
| Ürün yorumları ve sorular | Duruma göre | Üçüncü parti uygulamada tutuluyorsa dışa aktarma sınırlı |
| Kuponlar, hediye çeki, sadakat puanı | Genelde hayır | Bakiyeler platforma özel yapıda tutulur |
| URL yapısı | Hayır | Her platformun adres şeması farklı |
| Meta başlık ve açıklamalar | Evet | Aktarılmadığında sıfırdan üretilir ve değer kaybedilir |
Platform değiştirme kararı ne zaman doğru?
Platform değiştirme, çoğu zaman bir tıkanmanın sonucu olarak gündeme gelir. Karar vermeden önce sorulması gereken soru şudur: tıkanma platformdan mı, yoksa kurulumdan mı kaynaklanıyor? Deneyimimizde taşıma taleplerinin bir kısmı, aslında mevcut platformda yanlış kurgulanmış bir katalog ya da yanlış seçilmiş bir paket yüzünden doğuyor. Bu durumda taşıma, sorunu yeni platforma birlikte götürmek anlamına gelir.
Taşımanın gerçekten haklı olduğu durumlar:
- Maliyet yapısı sürdürülemez hâle geldi. İşlem komisyonu ve uygulama giderleri toplamı, alternatif altyapının toplam maliyetinin belirgin şekilde üstüne çıktıysa.
- İş modeliniz platformun varsaydığı akışa sığmıyor. Her istisna için ek geliştirme ödeniyorsa.
- Kritik bir entegrasyon mümkün değil. ERP, üretim planlama ya da mevzuata bağlı bir zorunluluk platformda karşılanamıyorsa.
- Operasyon paneli ekibi yavaşlatıyor. Günlük sipariş hazırlama ve iade süreçleri panel yüzünden uzuyorsa.
- Veri erişiminiz yok. Kendi verinize ulaşamıyorsanız bu tek başına yeterli bir gerekçedir.
Buna karşılık "yeni platform daha modern görünüyor" ya da "herkes oraya geçiyor" gerekçeleri, taşımanın maliyetini karşılamaz. Karar öncesi maliyet ve sahiplik karşılaştırmasını kirala, satın al, kurdur yazısında, platform bazlı teknik farkları ise ikas ve Shopify karşılaştırmasında bulabilirsiniz.
301 yönlendirme haritası nasıl kurulur?
Taşımanın tek geri dönüşsüz kısmı budur. Platformlar farklı adres şemaları kullanır; bazılarında ürün adreslerinin ön eki sabittir ve değiştirilemez. Yani eski adreslerinizi birebir korumak çoğu zaman mümkün değildir. Yapılması gereken, her eski adresi yeni karşılığına 301 yönlendirme ile bağlamaktır.
1. Envanteri üç kaynaktan çıkarın
Yalnızca site haritasına güvenmeyin; site haritası genelde yayında olan sayfaları içerir, oysa değeri olan adreslerin bir kısmı artık menüde görünmeyen eski sayfalardır. Üç kaynağı birleştirin: site haritası, arama konsolundaki performans raporu (son on iki ay) ve sitenin tam taraması. Üçünün birleşimi, tek başına hiçbirinin vermediği listeyi verir.
2. Listeyi değere göre sıralayın
Tüm adresler eşit değildir. Organik trafiği ve cirosu olan sayfalar önce ele alınır; bunlar için eşleştirme elle doğrulanır. Uzun kuyruktaki adresler kural bazlı yönlendirilebilir.
3. Şu adres tiplerini unutmayın
- Ürün ve kategori sayfaları (herkesin aklına gelen kısım)
- Blog yazıları ve içerik sayfaları
- Filtreli kategori adresleri (renk, beden, marka kırılımları)
- Sayfalama adresleri
- Arama sonuç adresleri (dizine girmişse)
- Görsel ve dosya adresleri (PDF kataloglar, kılavuzlar)
- Eski kampanya sayfaları
- Yayından kaldırılmış ama hâlâ bağlantı alan ürünler
4. Zincir kurmayın
Eski adres A, önce B’ye, sonra C’ye yönleniyorsa zincir oluşur. Zincirler hem yavaşlatır hem değer kaybettirir. Her eski adres doğrudan nihai adrese bağlanmalıdır. Geçmişte bir kez daha taşınmış bir siteyi taşıyorsanız, eski taşımanın yönlendirmelerini de bu listeye dahil edin ve zincirleri düzleştirin.
5. Yönlendirmeleri geçişten önce hazırlayın
Yönlendirme dosyası geçiş anında hazır olmalı, geçişten sonra yazılmaya başlanmamalıdır. Aradaki her saat, kırık adres demektir.
6. Meta verileri birlikte taşıyın
Yönlendirme adresi taşır, değeri korumaz. Sayfa başlıkları, açıklamaları, başlık hiyerarşisi ve kategori metinleri de taşınmalıdır. Yeni platformda "nasılsa yeniden yazarız" denilen içerikler, taşımadan sonraki düşüşün en yaygın sebebidir.
Ürün aktarımı: dosyayı taşımak kolay, kimliği taşımak zor
Ürün aktarımı teknik olarak bir dışa aktarma ve içe aktarma işlemidir; zorluk verinin kendisinde değil, kimlik alanlarındadır. Aktarımdan önce yapılması gerekenler:
- Stok kodlarını tekilleştirin. Yıllar içinde aynı stok kodunun iki farklı varyantta kullanılmış olması sık görülür. Yeni platforma bu hatayla girmek, tüm entegrasyonları bozar.
- Barkod alanını tamamlayın. Pazaryeri eşleşmesi ve yorum aktarımı bu alandan yürür.
- Görselleri yeniden yükleyin. Yeni sitede görselleri eski sunucudan bağlantıyla göstermek geçici bir çözümdür; eski altyapı kapandığında ürün sayfalarınız görselsiz kalır.
- Varyant yapısını gözden geçirin. Taşıma, gereksiz varyantları temizlemek için doğal bir fırsattır. Yeni platforma taşınan her gereksiz varyant, orada da yük olmaya devam eder.
- Fiyat alanlarını ayrıştırın. İndirimli fiyatı ana fiyat alanına yazan eski kayıtlar, taşındığında kampanya öncesi fiyatı kaybettirir.
- Yayından kaldırılmış ürünleri kararlaştırın. Silinecek mi, taşınıp gizlenecek mi? Trafiği olan eski ürün sayfaları için yönlendirme hedefi belirlemeniz gerekir.
Müşteri hesapları: şifre yenileme akışını nasıl kurarsınız?
Şifreler taşınamaz. Bu teknik bir eksiklik değil, güvenlik tasarımının doğal sonucudur: şifreler geri döndürülemez karma değerler olarak saklanır ve platformlar farklı algoritmalar kullanır.
Pratikte yapılması gerekenler:
- Geçişten önce bilgilendirin. Müşterilere geçiş tarihinden birkaç gün önce, ilk girişte şifre yenilemeleri gerekeceğini anlatan bir e-posta gönderin. Habersiz karşılaşılan şifre hatası, destek yükünün en hızlı arttığı andır.
- Yenileme akışını sürtünmesiz kurun. Giriş ekranındaki hata mesajı "şifre hatalı" değil, "yeni sistemimizde şifrenizi bir kez yenilemeniz gerekiyor" olmalıdır.
- Misafir siparişi açık tutun. Geçişten sonraki ilk haftalarda üye girişi zorunluluğu, doğrudan satış kaybıdır.
- Adres defterlerini taşıyın. Şifre taşınamasa da kayıtlı adresler taşınabilir; bu, geri dönen müşterinin işini kolaylaştırır.
- İzin kayıtlarını taşıyın. Ticari ileti izinlerinin tarih ve kaynak bilgisiyle birlikte taşınması gerekir; taşınmazsa izin havuzunuz hukuken savunulamaz hâle gelir. Bu konuyu İYS ve KVKK rehberimizde ayrıntılı ele aldık.
Ödeme tarafında da benzer bir kırılma var: kayıtlı kart bilgileri sizde değil ödeme sağlayıcısında saklanır ve platformlar arasında taşınması genelde mümkün olmaz. Tekrarlayan ödemesi ya da abonelik modeli olan bir işletmeyseniz bu, taşımanın en riskli maddesidir ve sağlayıcınızla geçişten haftalar önce konuşulmalıdır.
Sipariş geçmişi ve yorumlar: iki farklı kayıp
Sipariş geçmişi
Geçmiş siparişleri yeni platforma aktarmak çoğu zaman kısmen mümkündür. Korunması genelde zor olan alanlar: gerçek sipariş tarihi, ödeme ve iade durumu, kargo hareket geçmişi, uygulanan indirim detayı. Bu yüzden yaygın yaklaşım ikili çalışmaktır: analiz ve muhasebe ihtiyacı için ham sipariş verisini ayrı bir arşivde saklamak, yeni platforma ise müşteri bazında özet bilgiyi taşımak.
Arşivi mutlaka satır düzeyinde alın: hangi siparişte hangi üründen kaç adet, hangi fiyattan satılmış. Yalnızca sipariş toplamını içeren bir arşiv, ürün bazlı geçmiş analizi yapmanızı imkânsız kılar.
Yorumlar ve sorular
Yorumlar taşımanın en çok küçümsenen kaybıdır, çünkü kaybı hemen görünmez. Ürün sayfası yayına girer, çalışır görünür; sadece sosyal kanıtı yoktur ve dönüşüm sessizce düşer. Yorumların taşınabilirliği, eski platformda nerede tutulduğuna bağlıdır: platformun kendi altyapısındaysa dışa aktarma genelde mümkündür, üçüncü parti bir uygulamadaysa o uygulamanın izin verdiği kadardır.
Aktarımda dikkat edilecek alanlar: yorum tarihi, puan, yazar adı, ürün eşleşmesi ve varsa görsel. Ürün eşleşmesi barkod ya da stok kodu üzerinden kurulmalıdır; ürün adı benzerliğiyle yapılan eşleştirme, yorumların yanlış ürüne düşmesine yol açar.
Pazaryerinde de satıyorsanız, taşıma sonrası boş kalan ürün sayfalarını oradaki değerlendirmelerle beslemek pratik bir çözümdür; yöntemleri pazaryeri yorumlarını siteye aktarma rehberinde anlattık. Yalnız işaretleme kuralını hatırlatalım: başka siteden toplanan yorum ve puanlar AggregateRating yapısal verisine konmaz.
Mağaza taşıma sırasında en çok gözden kaçan yedi kalem
Mağaza taşıma kontrol listelerinde genelde ürün ve müşteri satırları bulunur; aşağıdakiler ise çoğu listede yoktur ve geçişten sonra sorun çıkarır:
- Kupon ve hediye çeki bakiyeleri. Kullanılmamış bakiyeler taşınmadığında müşteri şikâyeti olarak geri döner. Geçiş öncesi bakiye listesini çıkarıp yeni sistemde manuel karşılık oluşturun.
- Sadakat puanları. Puan programınız varsa bakiyelerin nasıl taşınacağı geçişten önce kararlaştırılmalıdır.
- Otomatik e-posta ve mesaj şablonları. Sipariş onayı, kargo bildirimi, iade bilgilendirmesi gibi şablonlar yeni platformda sıfırdan kurulur ve genelde son güne bırakılır.
- Ödeme sağlayıcısının bildirim adresi. Ödeme sonucu bildiriminin gittiği adres yeni platformda değişir; güncellenmezse siparişler ödendi olarak işaretlenmez.
- Pazaryeri stok senkronu. Geçiş anında iki sistem birden senkron yaparsa stok bozulur. Geçiş penceresinde senkron durdurulmalıdır.
- Ölçüm ve reklam etiketleri. Dönüşüm etiketleri yeni platformda yeniden kurulur; kurulmazsa reklam optimizasyonu veri kaybeder ve yanlış öğrenir.
- Site içi arama geçmişi. Hangi kelimenin arandığı ve hangisinin sonuçsuz kaldığı bilgisi taşınmaz; geçiş öncesi bu raporu dışa aktarıp saklayın, katalog planlamasının en değerli verisidir. Detayları site içi arama yazısında anlattık.
E-ticaret migration planı: geçiş günü saat saat
Bir e-ticaret migration planında geçiş günü, haftalarca süren hazırlığın en kısa ama en gergin kısmıdır. Sağlıklı bir geçiş günü şöyle işler:
| Zaman | Yapılan iş | Kontrol |
|---|---|---|
| Geçişten 48 saat önce | DNS yaşam süresi düşürülür | Değişikliğin yayıldığı doğrulanır |
| Geçişten 24 saat önce | Müşterilere bilgilendirme gönderilir | Şifre yenileme mesajı net mi? |
| Geçişten 2 saat önce | Pazaryeri senkronu durdurulur, son veri aktarımı yapılır | Aradaki siparişler listelendi mi? |
| Geçiş anı | DNS yeni platforma yönlendirilir | Düşük trafikli saat seçildi mi? |
| Geçiş + 15 dakika | 301 yönlendirmeleri aktif edilir | İlk 20 kritik adres elle test edilir |
| Geçiş + 30 dakika | Test siparişi geçilir | Ödeme, fatura, e-posta zinciri çalışıyor mu? |
| Geçiş + 1 saat | Arama motoru engeli kaldırılır, site haritası gönderilir | Yeni sitede kalıntı noindex var mı? |
| Geçiş + 3 saat | Pazaryeri senkronu yeniden açılır | Eşleşme raporu temiz mi? |
| Geçiş + 24 saat | 404 raporu incelenir | Eksik yönlendirmeler eklenir |
Geçiş gününü seçerken iki kural: kampanya dönemine denk getirmeyin ve cuma akşamına koymayın. Sorun çıkarsa müdahale edecek ekibin ertesi gün hazır olması gerekir.
Risk sıralaması: hangi kalem ne kadar ağır?
Kaynağınız sınırlıysa şu sıraya göre ilerleyin. Sıralama, hatanın maliyetine ve geri dönülebilirliğine göre yapıldı:
| Sıra | Risk | Neden bu sırada | Geri dönülebilir mi? |
|---|---|---|---|
| 1 | Eksik 301 yönlendirme haritası | Kalıcı organik trafik kaybının birinci sebebi | Kısmen, gecikmeli |
| 2 | Ödeme akışının çalışmaması | Doğrudan ciro kaybı, saatlik ölçülür | Evet, hızlı |
| 3 | Pazaryeri stok bozulması | Aşırı satış ve ceza riski üretir | Elle düzeltmeyle |
| 4 | Müşteri girişinin kırılması | Tekrar eden müşteri kaybı | Evet, iletişimle |
| 5 | Yorumların taşınmaması | Sessiz dönüşüm kaybı | Zor, yeniden toplanır |
| 6 | Meta veri kaybı | Sıralama dalgalanması | Evet, yeniden yazılabilir |
| 7 | Kupon ve puan bakiyeleri | Müşteri memnuniyetsizliği | Evet, elle karşılık verilerek |
| 8 | Sipariş geçmişi detayı | Analiz kaybı, operasyonu durdurmaz | Arşivle |
Geçişten sonraki ilk 30 gün
Taşıma, yayın anında bitmez; asıl doğrulama sonraki dört haftada yapılır. Günlük takip edilecekler:
- 404 raporu: Her yeni kırık adres için yönlendirme ekleyin. İlk hafta bu rapor günlük okunmalıdır.
- Dizine alınma: Yeni adreslerin dizine girme hızını izleyin; kritik sayfalar için ayrı takip listesi tutun.
- Ödeme hata oranı: Sağlayıcı panelindeki hata kodlarını okuyun; entegrasyon kaynaklı hatalar ilk günlerde ortaya çıkar.
- Giriş başarısı: Şifre yenileme akışını tamamlayan müşteri oranı beklediğinizin altındaysa akışta sürtünme vardır.
- Site içi arama: Sonuçsuz kalan sorgular, taşınmamış ürün ya da bozulan etiket yapısını en hızlı gösteren veridir.
- Sayfa hızı: Yeni platformda ilk ölçümü yayın haftasında alın; sonradan eklenen her uygulama bu taban değeri bozar.
Bu dört haftalık dönemde yeni özellik eklemekten kaçının. Taşımanın etkisini ölçebilmek için değişkenlerin sabit kalması gerekir; aynı hafta yeni tema, yeni kampanya ve yeni entegrasyon devreye alındığında düşüşün sebebini bulmak imkânsız hâle gelir.
Taşımayı kim yürütmeli?
Taşımanın teknik kısmı öğrenilebilir; zor olan, yukarıdaki listelerin hiçbirinin atlanmadığından emin olmaktır. Kendi ekibinizle yürütecekseniz iki kişiyi ayırın: biri veri ve entegrasyon tarafını, diğeri adres ve içerik tarafını takip etsin. Tek kişide toplanan taşıma projelerinde en çok atlanan kalem her zaman yönlendirme haritası oluyor.
Süreci devretmeyi tercih ederseniz, e-ticaret altyapısı hizmetimiz kapsamında geçişi biz yürütüyoruz; siz satışa devam ederken ürün, müşteri ve sipariş verisi aktarılıyor, entegrasyonlar yeniden kuruluyor. Hedef platform belliyse Shopify ve ikas kurulum rehberlerimiz, taşıma sonrası kurulacak yapının kontrol listesini de veriyor.