E-ticaret platformu taşırken ürün ve varyantları, müşteri–sipariş ilişkilerini, açık işlemleri ve değerli URLleri koruyun. Başarılı dosya yüklemesi yeterli değildir; hesap erişimi, sipariş ve yönlendirmeler gerçek senaryolarla doğrulanmalıdır.
Veriyi işlevine göre envantere alın
Ürün, varyant, müşteri, geçmiş sipariş, açık sipariş, görsel ve URLleri ayrı veri grupları olarak çıkarın. Kullanılan aktarım aracının her grubu desteklediğini doğrulayın; ürün CSVsi tüm mağaza yedeği değildir.
WooCommerce'in resmi ürün aktarım rehberi, yerleşik CSV aracının ürün verisi için kullanıldığını açıklar. Bu tür bir araç bütün mağaza geçmişini kapsıyor varsayılmamalıdır. Kullanılan aktarım yönteminin hangi veri tiplerini ve özel alanları desteklediğini tek tek doğrulayın.
Alanlardan önce kayıt ilişkilerini koruyun
SKU ve iç kimlikleri eşleştirin; varyantın doğru ana ürüne, siparişin doğru müşteriye bağlandığını test edin. Kayıt sayısının tutması bu ilişkilerin doğru kaldığını kanıtlamaz.
Varsayımsal bir örnekte ürünler aktarılır ama renk seçenekleri yanlış ana ürüne bağlanır. Toplam ürün sayısı doğru görünmesine rağmen müşteri yanlış seçenekle sipariş verebilir. Sayım kontrolünü ilişki ve müşteri deneyimi testiyle tamamlamak bu nedenle gerekir.
Her veri grubuna ayrı kabul ölçütü verin
Önce küçük, istisnalı bir örnek aktarın: varyant, indirim, iptal ve birden fazla adres içersin. Her veri grubuna sayım dışında müşteri açısından bir kabul testi ekleyin.
| Veri grubu | Korunacak ilişki | Kabul kontrolü |
|---|---|---|
| Ürün ve varyasyon | Kod, seçenek, fiyat ve görsel | Doğru varyasyon satın alınabiliyor mu? |
| Kategori ve içerik | Ürün grubu ve açıklama | Gezinme ve filtre mantığı korunuyor mu? |
| Müşteri | Kimlik, erişim ve geçmiş | Doğru kişi doğru kayıtları görüyor mu? |
| Sipariş | Satırlar, tutar ve durum | Açık işler operasyonca sürdürülebiliyor mu? |
| Eski URL | İlgili yeni hedef | Eski bağlantı doğru içeriğe ulaşıyor mu? |
| Entegrasyon | Kaynak ve hedef kimliği | Stok, sipariş ve iptal akışı çalışıyor mu? |
Müşteri hesabı ve geçiş iletişimini ayrıca planlayın
Şifre ve hesap erişiminin taşınabilirliğini hedef platformda doğrulayın. Açık siparişin hangi sistemde tamamlanacağını, son veri farkının ne zaman alınacağını ve müşteriye hangi bilginin gideceğini belirleyin.
Açık siparişlerin hangi sistemde tamamlanacağı da belirlenmelidir. İki sistem aynı anda farklı durum gösteriyorsa destek ekibi yanlış bilgi verebilir. Geçiş anındaki son veri güncellemesi, yeni siparişlerin kaynağı ve iptal süreci yazılı olsun.
Örnek aktarımı gerçek istisnalarla sınayın
Eski URLleri ilgili yeni karşılıklarına eşleyin; hepsini ana sayfaya göndermeyin. Kalıcı yönlendirme, iç bağlantı, canonical, sitemap ve gerçek sipariş testini yayın kontrolüne ekleyin.
Yayın sonrası hata kaydını kimin sahipleneceğini ve eski veriye nasıl erişileceğini belirleyin. Taşıma tamamlandığında satış, destek ve pazarlama ekipleri aynı gerçek kaydı takip edebilmeli; yeni tasarımın açılması operasyonel kabulün yerine geçmemelidir.
Son aktarım ile mağazanın açıldığı an arasında yeni kayıt oluşabilecekse fark aktarımı planlayın. Hangi sistemden yeni sipariş alınacağı ve eski kayıtta hangi değişikliklere izin verileceği belli olsun. Kısa bir deneme geçişiyle süreyi ve eksik alanları görün; yalnız dosyanın yüklenmesini değil operasyonun kaldığı yerden devam etmesini sınayın.