Bir mağazayı taşırken en yanıltıcı an, yeni ana sayfanın düzgün göründüğü andır. Tasarım çalışıyor olabilir; buna rağmen stoklar farklı konumlara bağlanmış, varyantlar karışmış, eski bağlantılar kırılmış veya sipariş bildirimleri iki kez gönderiliyor olabilir. Geçişin kabul ölçütü ekranın tamamlanması değil, müşterinin ve operasyon ekibinin temel işlerini doğru sonuçla tamamlayabilmesidir.
Bu rehberdeki yaklaşım, geçişi beş ayrı teslim olarak yönetmektir: kapsam envanteri, veri eşlemesi, deneme aktarımı, yayın kontrolü ve geçiş sonrası takip. Aşağıdaki örnekler uygulama yöntemini anlatmak için oluşturulmuştur; gerçek bir müşteri projesinin sonuçları değildir. Tek bir dosyanın bütün mağazayı eksiksiz taşıdığı varsayımıyla başlamayın.
1. Taşınacak şeyleri dosyalardan önce tanımlayın
İlk toplantıda hangi platformdan çıkıldığını sormak yeterli değildir. Ürünün nerede oluşturulduğu, stok bilgisinin nerede tutulduğu ve siparişin hangi sistemde işleme alındığı daha belirleyicidir. Ürünler mağaza panelinde, stoklar bir depo uygulamasında, kargo durumları başka bir entegrasyonda yönetiliyorsa üç ayrı doğruluk kaynağı vardır. Bunları birbirine karıştırmak, düzgün görünen fakat yanlış çalışan bir geçiş üretir.
Her veri grubu için bir sahip belirleyin. Ürün yöneticisi açıklamayı doğrulayabilir; stok miktarını depo sorumlusu, muhasebe ilişkisinin doğruluğunu ilgili uzman kontrol etmelidir. Geliştirici aktarımın teknik sonucunu gösterir. İşletmenin doğruluk kararını tek başına vermez. Böylece bir alanın boş olmasıyla bilinçli olarak taşınmaması arasındaki fark kayıt altına alınır.
| Veri grubu | Karar verilecek konu | Kontrol kanıtı |
|---|---|---|
| Ürün ve varyant | Kimlik, seçenek, SKU ilişkisi | Kaynak ve hedef karşılaştırması |
| Stok | Konum, miktar, satışa uygunluk | Depo bazında mutabakat |
| Müşteri | Aktarılabilir alanlar ve izinler | Alan eşleme ve örnek kayıt |
| Sipariş geçmişi | Hangi dönemin neden gerekli olduğu | İlişkiler ve toplam kontrolü |
| İçerik ve URL | Aynı niyetin yeni karşılığı | Eski URL’den son sayfaya test |
| Entegrasyon | Yeni sistemde yetki ve tetikleyiciler | Kontrollü uçtan uca işlem |
Bu tablo bir görev listesine dönüşmelidir. Her satırın sahibi, tamamlanma ölçütü ve engeli bulunmalıdır. “Ürünler tamam” ifadesi yerine “kaynakta beklenen varyantların tamamı hedefte doğru ürünle eşleşiyor” gibi kontrol edilebilir bir cümle kullanın. Kontrol edilemeyen bir ifade, canlı geçiş kararı için zayıf kanıttır.
2. Aktarım yöntemini her veri grubu için ayrı seçin
Shopify’ın resmi geçiş rehberi CSV, uygulama ve özel aktarım gibi seçenekleri ayırır; her veri türünün aynı yöntemle taşınabileceğini varsaymaz. Rehber ayrıca ürün, müşteri ve geçmiş siparişler arasındaki ilişki nedeniyle aktarım sırasının önemli olduğunu belirtir. Seçilecek yöntemi mağazanızın mevcut yapısı ve ihtiyaç duyulan ilişkiler üzerinden değerlendirin. Shopify geçiş rehberi
İş planında “CSV ile taşınacak” yazması henüz yeterli bir karar değildir. Hangi sütunun hangi hedef alanı dolduracağını, boş değerlerin ne anlama geldiğini ve tekrar içe aktarımın mevcut kaydı güncelleyip güncellemeyeceğini küçük bir örnekle doğrulayın. Dosya hazırlayan kişiyle mağaza tarafında kontrol yapan kişinin aynı veri sözlüğünü kullanması gerekir.
Örneğin kaynak sistemde renk=Kum olan bir seçenek, yeni sistemde renk=Bej olarak yeniden adlandırılabilir. Bu estetik bir değişiklik gibi görünür; fakat görsel eşleşmesi, filtreler ve entegrasyon kuralları etkilenebilir. Ad değişikliğini veri temizliği olarak kaydedin. Otomatik düzeltme sırasında sessizce uygulamayın. Sonradan bulunması en zor hatalar genellikle bu tür küçük yorum farklarıdır.
3. Ürün kimliği ile görünen adı birbirinden ayırın
Ürün adı müşteriye yöneliktir; SKU ve kaynak kimlikleri sistemler arası eşleşmeye hizmet eder. Aynı ada sahip iki ürünün tek kayıt sayılmaması gerekir. Benzer biçimde bir ürünün adı değiştiğinde geçmiş sipariş ilişkisi kopmamalıdır. Eşleştirme anahtarını yazılı olarak belirleyin ve tekrar kullanılan, boş veya çakışan değerleri aktarım öncesinde raporlayın.
Varyant kontrolünde yalnız toplam sayıyı karşılaştırmayın. Kaynakta on beden-renk birleşimi varsa hedefte de on varyant bulunması, doğru on birleşimin bulunduğunu kanıtlamaz. Olmayan bir renk eklenmiş, geçerli bir beden kaybolmuş olabilir. Karşılaştırma; ürün kimliği, seçenek kombinasyonu, SKU, fiyat, stok konumu ve görsel ilişkisi üzerinden yapılmalıdır.
Özellikle paket, set, kişiselleştirme veya ön sipariş ürünlerini ayrı örnek grubuna alın. Basit bir ürünün başarılı taşınması karmaşık katalog davranışını doğrulamaz. Test kümeniz, en kolay kayıtları değil hata ihtimali yüksek iş kurallarını temsil etmelidir. Az satan ama operasyonu karmaşık ürünler de bu nedenle önemlidir.
4. Deneme aktarımını gerçek kabul testine dönüştürün
Önce sınırlı ve temsil gücü yüksek bir veri kümesiyle deneme yapın. Tek varyantlı ürün, çok seçenekli ürün, tükenen varyant, uzun açıklama, farklı görsel oranı, özel karakter ve eksik alan içeren örnekleri bilinçli seçin. Amaç yalnız başarı senaryosunu görmek değil, hatanın nerede görünür hâle geldiğini anlamaktır.
Deneme sonucunu üç düzeyde kontrol edin. İlk düzey kayıt sayısıdır: beklenen nesneler geldi mi? İkinci düzey alan değeridir: fiyat ve seçenekler doğru mu? Üçüncü düzey iş akışıdır: müşteri doğru varyantı seçip satın alabildiğinde sipariş doğru stok kaydını etkiliyor mu? İlk iki düzeyin geçmesi üçüncü düzeyin yerine geçmez.
Hataları yeniden üretilebilir biçimde yazın. “Bazı görseller yanlış” yerine ilgili kaynak kimliğini, beklenen görseli, hedef sayfayı ve görülen farkı kaydedin. Düzeltmeden sonra yalnız sorunlu kaydı değil, aynı kuralı kullanan diğer kayıtları da kontrol edin. Böylece tek bir örneğin düzelmesiyle bütün veri grubunun düzeldiği varsayılmaz.
5. Eski URL’leri tasarım kararlarına kurban etmeyin
URL envanteri yalnız sitemap değildir. Arama verileri, site içi bağlantılar, bilinen kampanyalar ve dış bağlantılar birlikte düşünülmelidir. Yeni tasarımda görünmeyecek bir sayfanın hâlâ ziyaretçi getiriyor olması mümkündür. Veri bulunmaması da sayfanın değersiz olduğunu kanıtlamaz. Her adresin arama niyetini ve yeni sitedeki karşılığını ayrı değerlendirin.
Karar dosyanızda eski adres, hedef adres, gerekçe ve test sonucu bulunsun. Aynı konu aynı adreste devam ediyorsa adresi korumak gereksiz hareketi azaltır. İçerik gerçekten birleşiyorsa en yakın eşdeğer sayfaya yönlendirin. Bütün eski yazıları ana sayfaya göndermek, ziyaretçinin beklediği cevabı sağlamaz. Kaldırılacak içeriğe ayrıca gerekçe yazın.
Shopify yönlendirmelerinin platforma özgü kısıtları vardır; bir yönlendirme kaydının eklenebilmesi, her URL biçiminin aynı davranacağı anlamına gelmez. Uygulama öncesi güncel kuralları kontrol edin ve eski adresi gerçekten açarak son hedefi doğrulayın. Shopify URL yönlendirmeleri
6. Canlı geçiş penceresini veri hareketi etrafında planlayın
Veri dışa aktarılırken mağaza sipariş almaya devam ediyorsa ilk dosya kısa sürede eskiyebilir. Son aktarım ile alan adı geçişi arasındaki farkın nasıl kapatılacağını belirleyin. Yeni siparişler, stok değişiklikleri ve müşteri güncellemeleri için sorumluluk tanımlanmamışsa geçiş saati kararı erkendir. Sadece “gece yapalım” demek bu farkı çözmez.
Bir kesim zamanı belirleyin ve her sistem için o anda ne olacağını yazın. Eski mağaza sipariş almaya devam edecek mi? Depo entegrasyonu ne zaman yeni kaynağa bağlanacak? Bekleyen iadeler nerede işlenecek? Bu soruların cevabı teknik ekip, operasyon ve işletme sahibi tarafından aynı şekilde anlaşılmalıdır. Gerekirse geçiş penceresini büyütmek, belirsizliği canlıya taşımaktan daha kontrollüdür.
Geri dönüş planı da yalnız eski dosyayı saklamak değildir. Yeni mağazada alınmış siparişlerin ne olacağı, iki sistem arasındaki farkın nasıl uzlaştırılacağı ve karar yetkisinin kimde olduğu belirlenmelidir. Geri dönmenin kendi veri maliyeti vardır. Bu yüzden sorun eşiğini ve karar saatini geçişten önce yazın.
7. Yayın kararı için beş somut kanıt isteyin
Yayın öncesinde temsilî ürünlerin doğru görünmesi, stokların mutabık olması, kritik eski adreslerin doğru karşılığa ulaşması, kontrollü siparişin operasyon akışını tamamlaması ve ölçümün beklenen şekilde çalışması gerekir. Bu alanlardan biri “sonra bakarız” durumundaysa kalan riski açıkça kaydedin. Her sorunun aynı ağırlıkta olmadığını da unutmayın.
Bir yazım hatasıyla yanlış fiyatın etkisi aynı değildir. Kontrol listesini yalnız kırmızı-yeşil olarak değil, müşteriye ve işletmeye etkisiyle birlikte yönetin. Ödemeyi, stoğu veya sipariş teslimini etkileyen sorunlar yayın kararında daha yüksek öncelik taşır. Küçük görsel farklılıklar ise ayrı iyileştirme listesinde kalabilir.
İlk gün için bir takip sorumlusu ve kontrol aralığı atayın. Sipariş adedi düşükse oranlar yanıltıcı olabilir; önce gerçek işlemleri ve hata kayıtlarını inceleyin. Arama görünürlüğünü tek günlük dalgalanmadan yorumlamayın. Eski ve yeni dönemin karşılaştırılabilir olması için yayın zamanını ve önemli değişiklikleri kayıt altına alın.
Kullanılabilir teslim paketi
Geçiş sonunda elinizde beş belge bulunmasını öneririm: veri envanteri, alan eşleme tablosu, URL karar listesi, kabul testi sonuçları ve geçiş/geri dönüş planı. Bunlar bürokrasi üretmek için değil, farklı ekiplerin aynı gerçeği görmesi için vardır. Bir dosyanın en güncel sürümünün nerede olduğu da herkes tarafından bilinmelidir.
Her belgenin bir sonraki eylemi göstermesi önemlidir. Açık bir hata varsa sahibi ve çözüm tarihi görünmelidir. Bir kapsam dışı alan varsa neden dışarıda bırakıldığı anlaşılmalıdır. Bir yönlendirme onaylandıysa son hedefin test sonucu bulunmalıdır. Bu düzen, geçiş sonrası soruların kişisel hafızaya bağımlı kalmasını önler.
Shopify’a geçişi yalnız mağaza kurulumu olarak ele almak, asıl riski operasyon tarafında bırakır. Daha sağlam başlangıç; veri, URL, ölçüm ve sipariş akışını tek kabul planında birleştirmektir. Kendi mağazanızın bağımlılıklarını ortaya çıkarmak ve geçiş kapsamını belirlemek için birlikte çalışma yaklaşımını inceleyebilirsiniz.