Magento'dan BigCommerce'e Geçiş: Geliştirici Yürütme Detayları

Magento'dan BigCommerce'e geçiş, basitçe veri döküp tema değiştirmek değildir. Çekirdek teknik zorluk, Magento'nun Entity-Attribute-Value kataloğunu BigCommerce'in düz ilişkisel ürün modeline yansıtmak, vitrin için Stencil ve Catalyst arasında seçim yapmak ve DNS değişikliğinden önce her dizinlenen URL'yi kapsayan bir yönlendirme haritası oluşturmaktır. Bu üç şeyi doğru yaparsanız projenin geri kalanı yönetilebilir. Herhangi birini kaçırırsanız aylar boyunca temizleme yaparsınız.

Önemli Çıkarımlar

• EAV-dan ilişkisel katalog projeksiyonu, satır sayısı değil, geçişin en zor kısmıdır.
• BigCommerce, SKU başına maksimum 600 varyanta sahiptir; başlamadan önce bu sınırı aşabilecek herhangi bir konfigüre edilebilir ürünü denetleyin.
• Magento uzantıları otomatik olarak BigCommerce uygulamalarına geçmez. Taahhüt etmeden önce her etkin uzantıyı denetleyin ve bir yedek olduğunu doğrulayın.
• Müşteri parolası hiçbir zaman aktarılmaz. Başlatma günü için zorunlu sıfırlama akışı planlayın.
• Yönlendirilmeyen her URL kalıcı olarak arama değerini kaybeder. Yönlendirme haritasını bellekten değil, Screaming Frog taramasından oluşturun.

Geliştiriciler bu geçişi neden küçümsüyor

Yüzeysel olarak, Magento'dan BigCommerce'e geçiş tanıdık bir SaaS yeniden platformlaması gibi görünür: CSV'leri dışa aktarın, CSV'leri içe aktarın, temayı yeniden oluşturun. Pratikte, veri modelleri birkaç yüz SKU'nun üzerinde otomatikleştirilmiş araçları kıran yapısal olarak uyumsuzdur.

Magento ürün verilerini EAV modelinde depolar: catalog_product_entity artı catalog_product_entity_* değer tabloları, öznitelik kümeleri ve giriş türleri ailesi. Her öznitelik kendi satırıdır. BigCommerce bunu ilişkisel ürün + varyant + özel alan şemasına düzleştirir ve seçenek temelli fiyat ve SKU deltaları için Ürün Değiştiricilerini kullanır. Bir geçiş uzmanının dediği gibi, zor iş EAV-dan ilişkisel projeksiyondur, satır sayısı değil.

Somut olarak, 12 alt basit SKU'ya sahip (her biri kendi renk/boyut kombinasyonuna sahip) bir Magento yapılandırılabilir ürünü, tek bir BigCommerce ürün kaydı olmaktan başlar ve her biri seçenek kombinasyonu, fiyat deltası, ağırlık ve envanteri taşıyan 12 varyant satıra kadar olabilir. Bu daha basit ses gibi geliyor ve öyledir, ama yalnızca her öznitelik kümesini bir BigCommerce seçenek türüne doğru eşledikten sonra.

600 Varyant Tavanı: Başlamadan Önce Denetleyin

BigCommerce her ürünü 600 varyantla sınırlandırır. Çoğu DTC katalogu için bu ilgisizdir. Endüstriyel, tıbbi veya yüksek SKU giyim mağazaları için sert bir duvar.

Projeyi kapsamlandırmadan önce Magento veritabanınızda bu sorguyu çalıştırın:

SELECT
  parent.sku AS parent_sku,
  COUNT(child.entity_id) AS child_count
FROM catalog_product_entity child
JOIN catalog_product_relation rel ON child.entity_id = rel.child_id
JOIN catalog_product_entity parent ON rel.parent_id = parent.entity_id
GROUP BY parent.sku
HAVING child_count > 500
ORDER BY child_count DESC;

600'ün üzerindeki herhangi bir sonuç, geçiş başlamadan önce katalog tasarım kararına ihtiyaç duyar. Seçenekler: ürünü birden çok BigCommerce ürününe bölün (örneğin renk ailesine göre), emekli varyantları etkin katalogdan kaldırın veya varyant derinliği birçok SKU'da gerçekten gerekiyorsa BigCommerce'i hedef olarak yeniden düşünün.

10.000'den fazla etkin SKU'ya sahip bir katalog bulundurum ve varyant tavanı standart giyim veya aksesuarlar için neredeyse hiç tetiklenmez. Endüstriyel parça kataloglarında bir soruna dönüşür; burada bir taban parça numarası yüzlerce spesifikasyon kombinasyonuna sahiptir.

EAV Projeksiyonu: Önemli Veri Haritalama

En çok önemli olan alan düzeyi haritalama şu şekildedir:

Ürün Değiştiricileri bir not hak ediyor: fiyatı etkileyen veya müşteri girdisi gerektiren seçenekleri (oyma metni, özel boyutlar) ele alırlar, ama ayrı envanter izlenen SKU'lar oluşturmazlar. Kendi SKU'su gerektirmeyen seçenekler için bunları kullanın; kendi SKU'su gerektiren seçenekler için Varyantları kullanın. Bu bölüne erkenden yanlış yapmak, kırık envanter akışı ve aşağı akışta kırık ürün akışı oluşturur.

Uzantı Denetimi: Hiç Kimsenin Bütçelendiremediği İş

Mağazanızın çalıştırdığı her Magento uzantısı ayrı ayrı değiştirilmelidir. PHP uzantı kodunun BigCommerce uygulama ekosisteminde geçiş yolu yoktur.

Denetim adımları:

1. app/code ve vendor dizinlerinden tüm etkin modüllerin listesini çekin.
2. Listeden Magento çekirdeği ve çerçeve modüllerini kaldırın.
3. Kalan her uzantı için şunu yanıtlayın: bugün üretimde ne yapıyor?
4. BigCommerce Uygulama Pazarında işlevsel eşdeğer arayın.
5. Pazarında eşleşmeyen herhangi bir uzantı için karar verin: özel BigCommerce API entegrasyonu, üçüncü taraf SaaS veya özellik kullanımdan kaldırılması.

Takımları şaşırtan yaygın boşluklar:

• Bir taşıyıcı modülü olarak oluşturulan özel nakliye oranı mantığı (BigCommerce Nakliye Bölgesi kuralı veya taşıyıcı teklif API entegrasyonu gerektirir)
• Katmanlı gezinme özelleştirmeleri (BigCommerce'in fasetli araması yapılandırılabilir, ancak özel Magento katmanlı nav kadar ayrıntılı değildir)
• Magento B2B modülleri: Şirket Hesapları, Paylaşılan Kataloglar, Müzakere Edilebilir Teklifler (bunlar BigCommerce B2B Sürümü gerektirir; bu ayrı bir lisans seviyesidir)

Çok para birimi ve terk edilen sepet kurtarma; genellikle Magento uzantıları gerektiren, BigCommerce'de ek maliyet olmaksızın yerel olarak sevk edilir, bu da aylık uygulama harcamasında gerçek bir azalmadır.

SEO Yönlendirme Haritası: Bellekten Değil Taramadan Oluşturun

Magento'nun varsayılan URL yüzeyi ürün ve kategori sayfalarında .html sonekleri artı kategori başına katman gezinme filtresi URL'leri kullanır; bunlar düzinelerce parametre varyantı oluşturur. Bu URL düzenlerinin hiçbiri BigCommerce'de varsayılan olarak mevcut değildir.

Doğru süreç:

1. Screaming Frog'u canlı Magento mağazasında çalıştırın ve her dizinlenen URL'yi dışa aktarın (durum 200, tarama derinliği sınırsız).
2. Önemli organik trafiği veya geri bağlantıları taşıyan URL'leri tanımlamak için Google Search Console'daki verileriyle karşılaştırın.
3. Üç sütunlu bir elektronik tablo oluşturun: eski URL, yeni BigCommerce URL'si, yönlendirme türü (kalıcı için 301, eski URL geri dönecekse sadece 302).
4. Haritayı başlatmadan önce BigCommerce'in URL Yönlendirme Yöneticisine yükleyin. Büyük kataloglar (10.000+ URL) için Yönlendirme Yöneticisinin toplu CSV içe aktarmasını kullanın.
5. Başlatma sonrası, canlı BigCommerce mağazasında aynı Screaming Frog taramasını çalıştırın ve her eski URL'nin 404 değil 301 döndürdüğünü doğrulayın.

Yönlendirmesi olmayan herhangi bir URL kalıcı olarak birikmiş arama değerini kaybeder. Başlatmadan sonra birkaç haftadan fazla yönlendirmesiz kalan 404 için kurtarma yolu yoktur.

Magento'nun .html soneki ve katmanlı gezinme URL'leri (örneğin /category/boots.html?color=182&size=168) bireysel kararlar gerektirir. Filtre parametre URL'leri, genellikle yönlendirme haritasından tamamen hariç tutulması en iyisidir (bunlar muhtemelen Magento'da zaten noindex idi). Ürün ve kategori kanonik URL'leri vazgeçilmez.

Vitrin Seçimi: Stencil veya Catalyst

Bu veri modeli çalışmasından sonra ikinci büyük mimari karardır. BigCommerce artık iki farklı vitrin yolu sunar:

2024'te yayınlanan Catalyst, BigCommerce'in Next.js ve React üzerine inşa edilen resmi başsız çerçevesidir ve BigCommerce'e GraphQL Vitrin API'si aracılığıyla bağlanır. Bu daha hızlı bir tema değil; ayrı Node.js uygulaması, kendi barındırma katmanı, CI/CD ardışık düzeni ve React durum yönetimini anlayan bir takım gerektirir.

Hedef altyapı yükünden kaçmak olan bir Magento geçişi için Stencil genellikle doğru seçimdir. Zaten veri geçişi, yönlendirme haritalama ve entegrasyon yeniden oluşturma konusunda önemli enerji harcıyorsunuz. Buna tam başsız bir ön uç eklemek, paralel olarak çalışan ikinci bir büyük projedir. Stencil'in karşılayamayacağı belirli bir performans veya birleştirilebilirlik gereksiniminiz olmadıkça, Stencil'de başlatın ve mağaza kararlı olduktan sonra tanımlanmış bir zaman çizelgesi üzerinde Catalyst'i değerlendirin.

Magento mağazası bir PWA Studio ön ucunda veya tamamen özel bağlantısı kesik bir React uygulamasında çalışıyorsa ve ekibiniz Next.js yeteneğine sahipse, zaten o bakım modeline taahhüt olduğunuz için Catalyst ek yükü değer.

Veri Geçişi Araçları: Her Seçeneğin Gerçekte Ele Aldığı

Veri aktarımı için üç araç yolu mevcuttur:

• Otomatikleştirilmiş SaaS araçları (LitExtension, Cart2Cart, NextCart): Yapılandırması hızlı, standart ürün verilerine sahip 5.000 SKU'nun altındaki kataloglar için yeterli. Bunlar ürünleri, müşterileri, siparişleri ve kategorileri hazır olarak ele alırlar. Özel alanlar, alışılmadık ödeme kuralları ve standart Magento şeması dışında depolanan veriler konusunda zorluk çekerler. LitExtension 79 $ ile başlar ve 60 gün geçiş sonrası destek içerir.
• Manuel CSV ardışık düzeni: Lisanslama maliyetinde ücretsiz, geliştirici zamanında yüksek. BigCommerce'in örnek CSV şablonlarını kullanın ve Magento alanlarını manuel olarak eşleyin. Her alan değeri üzerinde tam kontrol istediğiniz küçük kataloglar için uygulanabilir.
• Özel API komut dosyası: Büyük veya karmaşık kataloglar için doğru seçim. Magento'nun REST API'sini tam EAV grafiğini (öznitelik kümeleri, seçenek değerleri ve medya galerisi girişleri dahil) çıkarmak için kullanın, kodu dönüştürün ve BigCommerce'e V3 katalog API'si aracılığıyla gönderin (/v3/catalog/products?include=variants,images,custom_fields,bulk_pricing_rules). Bu yaklaşım SaaS araçlarının kaçırdığı kenar durumlarını ele alır ve denetlenebilir bir dönüştürme günlüğü üretir.

Müşteri parolası hangi yöntemi kullanırsanız kullanın asla aktarılmaz. Her müşteri hesabı başlatmadan sonra parola sıfırlaması gerektirecektir. Bunu başlatma günü iletişim planınıza dahil edin.

DNS Değişikliğinden Önce Doğrulanacaklar

• [ ] Hazırlama üzerinde uçtan uca test siparişi çalıştırın: sepete ekle, ödeme, ödeme, onay e-postası.
• [ ] Tüm 301 yönlendirmelerin doğru durum kodunu döndürdüğünü doğrulayın (yönlendirme haritası yüklü hazırlama karşısında Screaming Frog kullanın).
• [ ] Envanter seviyelerinin sipariş hacmine göre ilk 50 SKU için Magento dışa aktarması ile eşleştiğini doğrulayın.
• [ ] Müşteri grubu fiyatlandırma kurallarının etkin olduğunu ve oturum açmış hesaplar için doğru fiyatlar döndürdüğünü doğrulayın.
• [ ] Sandbox modunda her ödeme ağ geçidini test edin.
• [ ] Yapılandırılmış verilerin (Ürün şeması) Google'ın Zengin Sonuçlar Testi kullanılarak ürün sayfalarında doğru şekilde işlendiğini doğrulayın.
• [ ] BigCommerce sitemap'inin Google Search Console'a gönderildiğini ve 200 döndürdüğünü doğrulayın.

Katalog veri modelleme kararlarının aşağı akış SEO'sunu nasıl etkilediğine daha derinlemesine bakmak için EAV'ye karşı ilişkisel ürün modelleri hakkındaki sözlük girişine bakın.

Sonuç

Magento'dan BigCommerce'e geçiş, işi doğru sırasıyla diziliyorsa makul bir zaman çizelgesinde kazanılabilir: katalog modeli denetimi önce, uzantı boşluğu analizi ikinci, yönlendirme haritası üçüncü, vitrin oluşturma paralel. EAV projeksiyonu ve 600 varyant tavanı, çoğu proje planının az tahmin ettiği iki konudur. Tek bir veri satırı hareket etmeden önce bu sorunları kağıt üzerinde düzelttiğinizde, yürütmenin geri kalanı öngörülebilir bir yol izler.