Magento Open Source, Adobe Commerce oraz Magento 1 kontra 2
Magento Open Source to darmowe, samodzielnie hostowane oprogramowanie e-commerce oparte na PHP; Adobe Commerce (wcześniej Magento Commerce) to płatny wariant z dodatkowymi funkcjami B2B, stagingiem treści i hostingiem w chmurze, działający na infrastrukturze zarządzanej przez Adobe. Magento 1 zakończyło wsparcie lata temu, a sklepy nadal na nim działające migrują zwykle właśnie z tego powodu, niezależnie od jakiejkolwiek decyzji porównawczej dotyczącej platform.
Z uwagi na tę rozpiętość, projekt „migracji z Magento” może oznaczać przeniesienie małego sklepu na Magento 1 na zupełnie inną platformę, przeniesienie z Magento 1 na Magento 2 (nadal Magento, ale przebudowa w ramach głównej wersji) albo przeniesienie się z Adobe Commerce Cloud na coś o innej strukturze kosztów. Ustalamy, który z tych scenariuszy dotyczy Ciebie, zanim cokolwiek wycenimy.
Model danych EAV i konfiguracja wielosklepowa
Magento przechowuje dane produktowe w strukturze EAV (encja-atrybut-wartość), która świetnie sprawdza się w wysoce konfigurowalnych katalogach bogatych w atrybuty, ale strukturalnie różni się od prostszych, płaskich tabel produktowych stosowanych na większości innych platform. Produkty konfigurowalne (odpowiednik wariantów w Magento), niestandardowe zestawy atrybutów oraz nawigacja warstwowa oparta na atrybutach wymagają jawnego mapowania przy przenoszeniu na platformę, która nie ma odpowiednika EAV.
Architektura wielosklepowa/wielowitrynowa Magento — prowadzenie kilku witryn sklepowych, walut czy lokalizacji z jednej instalacji — to kolejna rzecz wymagająca starannego mapowania, ponieważ większość platform obsługuje wielosklepowość inaczej: jako oddzielne sklepy, jeden sklep z ustawieniami specyficznymi dla rynku albo bez żadnego natywnego odpowiednika.
Rozszerzenia, moduły niestandardowe i deweloperzy Magento
Sklepy na Magento zazwyczaj polegają na rozszerzeniach z marketplace i dedykowanych modułach do wszystkiego, co wykracza poza podstawową funkcjonalność — metod płatności, reguł cenowych B2B czy logiki katalogowej specyficznej dla firmy. Ponieważ Magento to platforma mocno deweloperska, znacząca część tego, co sklep „robi”, często żyje w niestandardowym kodzie PHP, a nie w ustawieniach panelu administracyjnego, więc taką logikę trzeba zidentyfikować i albo odbudować, albo zastąpić — a nie tylko wyeksportować.
Motywy podlegają tej samej zasadzie: motywy Magento są zbudowane na własnym systemie layout XML/bloków, który nie ma bezpośredniego odpowiednika gdzie indziej, więc przeniesienie z Magento zazwyczaj oznacza budowę witryny sklepowej od nowa na nowej platformie.
SEO, adresy URL i jak podchodzimy do migracji Magento
Magento zarządza przepisywaniem adresów URL wewnętrznie i obsługuje dość elastyczne struktury URL, ale szczegóły (ścieżki kategorii, przyrostki adresów produktów, adresy URL specyficzne dla widoku sklepu) różnią się znacznie w zależności od konfiguracji danego sklepu. Ta zmienność jest właśnie powodem, dla którego zaczynamy od audytu faktycznych, aktywnych wzorców URL, a nie od założenia domyślnej konfiguracji Magento.
Przy migracji Magento budujemy mapę adresów URL i przekierowań w oparciu o to, co Twój sklep faktycznie robi dzisiaj, obsługujemy warianty URL dla wielu sklepów tam, gdzie ma to zastosowanie, i weryfikujemy, czy metadane oraz tagi kanoniczne przenoszą się poprawnie. Nasza usługa SEO i migracji przekierowań opisuje to bardziej szczegółowo.
Najczęstsze pytania
Nadal używam Magento 1. Czy możecie to zmigrować?
Tak, migracja z Magento 1 to jeden z częstszych projektów, z jakimi się spotykamy, zwykle wynikający z zakończenia wsparcia, a nie z preferencji platformowej. Traktujemy to jako pełną zmianę platformy, ponieważ Magento 1 i 2 mają różne architektury bazowe.
Co stanie się z moimi niestandardowymi modułami Magento?
Ustalamy, co faktycznie robi każdy niestandardowy moduł — na przykład integracja płatności, reguła cenowa czy funkcja katalogowa — i sprawdzamy, czy platforma docelowa ma wbudowany lub rozszerzeniowy odpowiednik, czy potrzebny jest niestandardowy development.
Czy funkcje B2B Adobe Commerce mogą zostać przeniesione na platformę spoza segmentu enterprise?
Zależy, o które funkcje chodzi. Konta firmowe, procesy ofertowe i wielopoziomowe ceny B2B nie mają bezpośredniego odpowiednika na każdej platformie, więc oceniamy to indywidualnie na etapie ustalania zakresu, a nie zakładamy odpowiedniości jeden do jednego.
Jak struktura atrybutów EAV wpływa na czas trwania migracji?
Katalogi z wieloma niestandardowymi atrybutami i zestawami atrybutów zwykle wymagają więcej czasu na mapowanie niż proste, płaskie katalogi, ponieważ każdy atrybut wymaga jawnej decyzji o tym, gdzie znajdzie się na platformie docelowej.