İçeriğe geç

Operasyon

E-Ticaret Altyapısı Değiştirirken Veri Taşıma Rehberi: Ürün, Müşteri ve Sipariş

E-ticaret altyapısı değiştirirken ürün, müşteri ve sipariş verisi nasıl taşınır? 301 yönlendirme, SEO koruma, test ve canlıya geçiş için adım adım kontrol listesi.

Mavi ışıklı veri merkezinde modern sunucu birimi – E-Ticaret Altyapısı Değiştirirken Veri Taşıma Rehberi: Ürün, Müşteri ve Sipariş
Okuma süresi9 dakika
YazarSoftCrafter Ekibi
  • 9 dk

    Okuma süresi

    Önce kısa cevap, ardından ayrıntılı anlatım.

  • 8 Ekim 2026

    Yayın tarihi

    Yazının ilk yayımlandığı tarih.

  • 9 Ekim 2026

    Son güncelleme

    Rakamları ve önerileri düzenli olarak gözden geçiriyoruz.

  • Operasyon

    Konu

    SoftCrafter Ekibi tarafından hazırlandı.

E-ticaret altyapısını değiştirmek çoğu işletmenin ertelediği bir karardır. Haklı bir çekince bu: mevcut mağaza çalışıyor, müşteriler alışveriş yapıyor, arama motorlarında sıralamalar kazanılmış ve her şeyin tek hamlede bozulabileceği korkusu var. Öte yandan mevcut platformun sınırlarına takılmak da fark edilmeden büyüyen bir maliyettir: artan abonelik ücretleri, yapılamayan özelleştirmeler, entegrasyon kısıtları ya da verinin başkasının sisteminde kalması. Altyapı değiştirmek, doğru planlandığında bu sınırları kaldırır; yanlış planlandığında ise trafik, sipariş ve güven kaybettirir. Aradaki fark çoğunlukla veri taşımanın ne kadar planlı yapıldığıdır. Aşağıdaki on adımlık kontrol listesi, her adımda ne yapılması gerektiğini ve en sık görülen hataları gösteriyor. Kaynak platformun veri dışa aktarma imkânları (dosya, API, veritabanı erişimi) platforma göre farklılaşır; bu yüzden kapsam ve yöntem her projede keşif aşamasında netleşir.

Neden veri taşıma bir proje gibi yönetilmeli?

Altyapı değiştirmek yalnızca yeni bir site kurmak değildir; yıllar içinde biriken ürün, müşteri, sipariş ve arama görünürlüğü verisini kaybetmeden taşımaktır. En çok sorun çıkan noktalar şunlardır:

  • Veri eşleme hataları: Bir platformda “varyasyon” olan yapı diğerinde ayrı ürün ya da seçenek kombinasyonudur. Eşleme yanlışsa ürünler eksik ya da karışık görünür.
  • Yönlendirme eksikleri: Eski adresler yeni adreslere yönlendirilmezse arama motorlarındaki sıralama kaybolur, ziyaretçi 404 hatası görür.
  • Entegrasyonların unutulması: Ödeme, kargo, muhasebe ve reklam bağlantıları tek tek yeniden kurulmazsa canlıya geçişten sonra bir şeyler çalışmaz.
  • Müşteri hesabı ve parola sorunları: Parolalar çoğu platformda tek yönlü şifrelenmiştir ve aynen taşınamayabilir.
  • Sipariş durumları ve geçmiş: Eşlenmeyen durumlar raporlamayı bozar.
  • Zamanlama ve kesinti: Plansız geçiş, yoğun dönemde satış kaybı demektir.

Bu yüzden planlı ilerlemek gerekir. Genel çerçeve için platform geçişi sayfamıza da bakabilirsiniz.

Adım adım kontrol listesi

1. Envanter çıkarın

Mevcut sitenizdeki her şeyi listeleyin: ürünler, kategoriler, özellikler, varyasyonlar, markalar, müşteri hesapları, sipariş geçmişi, kupon ve kampanyalar, içerik sayfaları, blog yazıları, entegrasyonlar (ödeme, kargo, muhasebe, pazaryeri), bildirim şablonları, analiz ve reklam kodları, yönlendirme kuralları. Envanter çıkarmanın bir yararı da, artık kullanılmayan şeyleri fark etmenizdir.

2. Neyin taşınacağına karar verin

Her kalem için “taşınsın / yeniden kurulsun / bırakılsın” kararı verin. Kullanılmayan eski ürünleri, bitmiş kampanyaları ve yıllardır girilmemiş müşteri hesaplarını taşımak gereksiz yüktür. Temiz bir başlangıç, yeni sistemin hızına ve yönetim kolaylığına katkı sağlar. Sipariş geçmişi için hukuki ve muhasebe saklama yükümlülüklerini mali müşavirinizle netleştirin; hangi verinin nerede ne kadar süreyle saklanacağı mevzuata bağlıdır.

3. Yedek alın

Dosya ve veritabanının tam yedeğini alın ve geri yüklenebildiğini doğrulayın. Yedek, eski sistemden bir iz bırakır: geçişten sonra eksik fark edilirse ve geri dönmek gerekirse elinizdeki tek güvence odur. Yedeği ayrı bir konumda saklayın ve geçişten sonra da uzun süre tutun.

4. Alan eşlemesi yapın

Kaynak sistemin alanlarını hedef sistemin alanlarına eşleyin: ürün adı, SKU, fiyat, stok, kategori, görsel, varyasyon, müşteri bilgileri, sipariş durumları. Biçim ve zorunlu alan farklarını belirleyin. Örneğin kaynak sistemde isteğe bağlı olan bir alan hedefte zorunluysa, boş kayıtlar için varsayılan değer belirlemek gerekir. Eşleme tablosu yazılı olmalıdır; sözlü anlaşmalar kaybolur.

5. Test taşıma

Önce küçük bir örnek veriyle, sonra tamamıyla test ortamına taşıyın; sayıları ve örnek kayıtları kontrol edin. Kaç ürün taşındı, kaç müşteri taşındı, toplam sipariş tutarı kaynakla uyuşuyor mu? Rastgele seçilen yirmi ürünü elle kontrol edin: açıklama, görsel, fiyat, varyasyon ve kategori doğru mu? Test taşıma birkaç kez tekrarlanabilir; her turda bulunan hatalar düzeltilir.

6. Adres (URL) eşleme ve 301 yönlendirme

Eski adreslerin yenilerine bire bir eşlendiği bir tablo hazırlayın. Her eski adres, kalıcı (301) yönlendirmeyle yeni adresine gitmelidir. Böylece arama motorları sıralamayı yeni sayfaya aktarır ve ziyaretçiler 404 görmez. Google’ın site taşıma dokümantasyonu da adres değişikliklerinde kalıcı yönlendirmeyi ve süreci izlemeyi önerir. Kurallar:

  • Her eski adres, en uygun yeni karşılığa gitmeli; karşılığı olmayan sayfalar için en yakın ilgili kategori ya da sayfaya yönlendirin.
  • Tüm sayfaları ana sayfaya yönlendirmek genellikle iyi bir uygulama değildir.
  • Zincir yönlendirmeleri (A→B→C) önleyin.
  • Mümkünse yeni sistemde eski adres yapısını koruyun; böylece yönlendirme ihtiyacı azalır.
  • Yönlendirmeleri canlıya geçişin ilk günü devreye alın.

7. İçerik ve SEO öğelerini koruyun

Başlık, açıklama ve içerik yapısını mümkün olduğunca koruyun; iç bağlantıları yeni adreslere güncelleyin; site haritasını yenileyin; canlıya geçtikten sonra arama konsolunda dizinleme ve hataları izleyin. Yapılandırılmış veri (ürün fiyat ve stok işaretlemesi) yeni sistemde de çalışmalıdır. Ayrıntılar için CS-Cart SEO sayfamıza bakabilirsiniz. Geçiş sonrasında genellikle geçici dalgalanmalar görülür; sonucu garanti etmek mümkün değildir, ancak planlı bir geçiş dalgalanmayı azaltır.

8. Entegrasyonları yeniden bağlayın

Ödeme, kargo, muhasebe ve bildirim servislerini yeni altyapıya bağlayın ve test edin. Hazır eklentilerimiz için entegrasyonlar sayfasına bakabilirsiniz: iyzico, PayTR, Paraşüt, Navlungo gibi. Analitik ve reklam etiketleri de bu adımda yeniden kurulur; ölçüm kaybı yaşamamak için canlıdan önce test edin.

9. Uçtan uca test

Sepet, ödeme (başarılı ve başarısız), iade, kargo, fatura, e-posta, mobil görünüm ve hız testleri. Test siparişlerini farklı müşteri tipleriyle (misafir, kayıtlı, kuponlu) yapın. Yönetim panelinde sipariş durumlarının doğru çalıştığını, stoğun düştüğünü ve bildirimlerin gittiğini kontrol edin.

10. Planlı canlıya alma

Satış yoğunluğunun düşük olduğu bir zaman seçin; geri dönüş planı hazır olsun. Geçiş sırasında yeni sipariş kaybı olmaması için eski sistem ile yeni sistem arasındaki son veri senkronizasyonuna dikkat edin. Canlıya geçişten sonra kırık bağlantı ve dizinleme taraması yapın; ilk günlerde siparişleri, hata kayıtlarını ve trafiği yakından izleyin.

Müşterilere iletişim

Geçişte müşterilere önceden bilgi vermek, destek taleplerini ve güvensizliği azaltır. Parola yenileme gerekecekse bunu önceden duyurun; geçiş günü kısa bir bakım penceresi varsa belirtin. Yeni sitede müşteri hesabı ve sipariş geçmişinin korunduğunu vurgulayın. Aynı zamanda e-posta şablonlarını, fatura biçimlerini ve yasal sayfaları yeni sistemde güncel tutun. Kişisel verilerin taşınması ve saklanması kişisel veri mevzuatı çerçevesinde değerlendirilmelidir; hukuki sorularınız için hukuk danışmanınıza başvurun.

En sık hatalar

  • Yönlendirmeleri sona bırakmak veya eksik yapmak.
  • Sipariş durumlarını eşlememek.
  • Müşterilere şifre/hesap geçişini önceden bildirmemek.
  • Entegrasyonları test etmemek.
  • Canlıya geçiş sonrası izlememek.
  • Veri temizliğini atlamak: Eski sistemdeki hatalı ve tekrarlı veri yeni sisteme de taşınır.
  • Eski siteyi hemen kapatmak: Yedek ve eski ortam bir süre erişilebilir kalmalı.
  • Kampanya döneminde geçmek: Yoğun satış dönemi öncesi büyük değişiklik risklidir.

Geçiş sonrası ilk 30 gün

Canlıya geçiş bitiş çizgisi değil, yeni bir izleme döneminin başıdır. İlk günlerde sipariş akışını, ödeme başarı oranını, hata kayıtlarını ve sayfa hızını günlük izleyin. İlk haftalarda arama konsolundaki tarama hatalarını, dizine alınan sayfa sayısını ve organik trafiği takip edin; beklenmedik düşüşleri yönlendirme ve içerik açısından inceleyin. Müşteri geri bildirimlerini toplayın: giriş sorunları, eksik ürünler, yanlış fiyatlar. Bulunan sorunları hızla düzeltmek, güveni korur. Bir ay sonunda geçişin sonuçlarını (satış, trafik, hata oranı) kaynak sistemin önceki dönemiyle karşılaştırın ve gerekli iyileştirmeleri planlayın.

Geçiş ekibi ve rol dağılımı

Başarılı bir geçiş, net rol dağılımı gerektirir. Projede genellikle şu roller bulunur: proje sorumlusu (takvim ve iletişimi yönetir), teknik sorumlu (veri taşıma, yönlendirme, entegrasyon), içerik/katalog sorumlusu (veri temizliği ve doğrulama), satış ve operasyon temsilcisi (sipariş akışını test eder), SEO/pazarlama sorumlusu (yönlendirme, ölçüm ve reklam bağlantıları) ve karar verici (onayları verir). Küçük işletmelerde bir kişi birden çok rolü üstlenebilir; önemli olan her rolün sahibinin belli olmasıdır.

Geçiş sırasında sık yaşanan sorun, onayların gecikmesidir: tasarım onayı, veri doğrulama ya da canlıya geçiş kararı belirsiz kişilere bırakıldığında takvim kayar. Bu yüzden toplantı ritmi (haftalık kısa durum toplantısı), karar süreleri ve acil durum iletişimi baştan tanımlanmalıdır. Dış bir ekiple çalışıyorsanız tek muhatap belirlemek iletişim kopukluklarını azaltır. Geçiş günü için ayrıca bir iletişim planı hazırlayın: kim hangi saatte ne kontrol edecek, sorun çıkarsa kim karar verecek, geri dönüş ne zaman tetiklenecek?

Geçişte sorun çıkarsa: geri dönüş planı

Her ciddi geçişin bir geri dönüş planı olmalıdır. Geri dönüş, yeni sistemde kritik bir sorun çıktığında (ödeme alınamıyor, siparişler kayboluyor, siteye erişilemiyor) eski sisteme güvenli biçimde dönebilmeyi ifade eder. Bunun için eski sistemin canlıya geçişten sonra bir süre ayakta tutulması, alan adı yönlendirmesinin hızla geri alınabilmesi ve geçiş sırasında yeni sistemde oluşan siparişlerin kaybolmaması gerekir. Hangi koşullarda geri dönüleceği (örneğin ödeme başarı oranı belirli bir seviyenin altına düşerse) önceden yazılı kararlaştırılmalıdır. Plan umulur ki hiç kullanılmaz; ama varlığı, hem ekibe hem yöneticilere güven verir ve panikle yapılan hatalı kararları önler.

Veri doğrulama için örnek kontrol tablosu

Test taşıma sonrasında veriyi sistematik doğrulamak için basit bir tablo yeterlidir. Satırlar: ürün sayısı, kategori sayısı, müşteri sayısı, sipariş sayısı, toplam sipariş tutarı, kupon sayısı, içerik sayfası sayısı. Sütunlar: kaynak değer, hedef değer, fark, açıklama. Fark sıfır değilse sebebi açıklanmalıdır (bilerek taşınmayan veriler gibi). Ayrıca rastgele seçilen yirmi ürün ve on siparişi elle karşılaştırın; açıklama, görsel, varyasyon, fiyat ve durum doğru mu? Bu tablo, canlıya geçiş kararının dayanağı olur ve ileride bir veri sorusu çıktığında kayıt görevi görür.

Destek alın

Geçişi kendiniz yapabilirsiniz; ancak veri hacmi ve entegrasyon yoğunsa uzman destek zaman ve risk açısından değerlidir. SoftCrafter’ın platform geçişi hizmeti bu adımları kapsar; hangi sistemden geldiğinizi ön görüşmede paylaşın. Altyapı seçimi konusunda kararsızsanız en iyi e-ticaret altyapısı ve kiralık SaaS mı, sahip olunan altyapı mı yazılarımıza bakabilirsiniz. Sonraki güncellemeler için sürüm yükseltme hizmetimiz bulunur.

Sık sorulan sorular

Müşterilerimin parolaları taşınır mı?

Parolalar çoğu platformda tek yönlü şifrelenir ve aynen taşınamayabilir; bu durumda müşteriler ilk girişte parolalarını yeniler. Bunu önceden bildiren bir iletişim planı hazırlanır.

Ürün görselleri de taşınır mı?

Evet. Görseller kaynak sitedeki adreslerinden alınıp yeni mağazaya yüklenir ve ilgili ürünlere bağlanır. Görsel sayısı fazlaysa bu adım zaman alabilir. Dosya adlarının ve alternatif metinlerin korunması, görsel aramadaki görünürlük için de önemlidir.

Taşımadan önce verileri temizlemeli miyim?

Evet, öneririz. Satışta olmayan ürünler, tekrar eden müşteri kayıtları ve eksik bilgiler taşınmadan önce ayıklanırsa yeni mağaza daha düzenli başlar. Hangi kayıtların taşınacağına kapsam aşamasında birlikte karar veririz.

Eski siteyi ne zaman kapatmalıyım?

Yönlendirmeler çalıştıktan, siparişler ve ödemeler yeni mağazada sorunsuz ilerlemeye başladıktan sonra eski site kapatılabilir. Eski sitenin ve veritabanının yedeğini bir süre saklamak, sonradan ihtiyaç duyulabilecek kayıtlar için güvence sağlar.

Geçiş ne kadar sürer?

Veri hacmine, entegrasyon sayısına ve kaynak platformun dışa aktarma imkânlarına bağlıdır. Standart kapsamda yeni mağaza lisans alımından sonra 7–14 gün içinde hazır olur; veri taşıma ek planlama gerektirir. Kesin takvim teklifte yer alır.

Teklif ve ön görüşme

Formu bırakın, sizi 15 dakika içinde arayalım; mevcut sitenizi birlikte inceleyelim ve kalem kalem teklifinizi 1 iş günü içinde hazırlayalım.

Merak edilenler

Sık sorulan sorular

Aradığınız cevap burada yok mu?

Ekibimize sorun; 15 dakika içinde sizi arayalım.

Hangi veriler taşınmalı?
Genellikle ürünler, kategoriler, varyasyonlar, görseller, müşteriler, sipariş geçmişi ve içerik sayfaları taşınır; eski adresler için yönlendirmeler de kurulur.
Sipariş geçmişini taşımak zorunlu mu?
Zorunlu değil ama müşteri hizmeti, raporlama ve yasal saklama için faydalıdır. Kapsam planlama aşamasında belirlenir.
SEO sıralamam düşer mi?
Geçici dalgalanma olabilir. 301 yönlendirmeleri kurmak, içerik ve başlık yapısını korumak ve geçişten sonra sıralamaları izlemek bu riski azaltır.
Geçiş sırasında satış durur mu?
Planlı bir canlıya alma ile kesinti kısa tutulur; satış yoğunluğu düşük bir zaman seçilir.

Ücretsiz ön görüşme

Projenizi birlikte planlayalım.

Formu bırakın; 15 dakika içinde sizi arayalım, teklifinizi 1 iş günü içinde hazırlayalım. Görüşme ücretsiz ve taahhütsüzdür.