Migracja Magento do Shopware: importer to najmniejszy problem

Prawdziwa praca polega na odwzorowaniu modelu danych EAV Magento na encje Shopware, przebudowie frontendu i zastąpieniu rozszerzeń. Jeśli budżet opierasz na tym, ile kosztuje uruchomienie importera, wyceniłeś około jednej trzeciej projektu.

Rozwijamy na obu platformach od lat. Ten artykuł opisuje, co importer obsługuje, gdzie się zatrzymuje i – szczerze – kiedy pozostanie na Magento jest lepszą decyzją. Ogólna metodologia migracji jest w artykule o migracji Shopware 5 do 6 oraz w Przewodniku po replatformingu; tutaj skupiamy się na tym, co jest specyficzne dla Magento.

Co obejmuje ten artykuł

• Dlaczego sprzedawcy Magento przechodzą w 2026 r. i kiedy nie powinni

• Co przenosi profil migracyjny Shopware Magento, a czego nie

• Jak model EAV Magento mapuje się na encje Shopware

• Co jest przebudowywane: frontend, rozszerzenia, integracje

• Realia harmonogramu i budżetu

• Kiedy warto zostać na Magento

Dlaczego sprzedawcy migrują z Magento do Shopware w 2026 r.

Trzy siły napędzają większość projektów: kierunek Adobe z Magento, rosnąca przepaść całkowitego kosztu posiadania z każdym rozszerzeniem oraz fakt, że Shopware B2B Suite osiągnęła parytet funkcji dla sprzedawców ze średniego rynku.

Adobe Commerce Cloud to oprogramowanie klasy enterprise – wyceniane i zarządzane w odpowiedni sposób. Sprzedawcy, którzy nie potrzebują pełnego stosu Adobe Experience Cloud, stają wobec kosztów licencji, obowiązkowych umów serwisowych i cyklu wydań, na który nie mają wpływu. Magento Open Source rozwiązuje problem licencji, ale usuwa strukturę wsparcia, pozostawiając sprzedawców odpowiedzialnymi za łatki bezpieczeństwa, aktualizacje PHP i kompatybilność rozszerzeń.

Koszty rozszerzeń to druga dźwignia. Typowa instalacja Magento dla średniego rynku zawiera 20–40 płatnych rozszerzeń. Każde ma własną matrycę kompatybilności, własny cykl aktualizacji i własny kontrakt wsparcia. Każde mniejsze wydanie Magento wyzwala sprawdzenie kompatybilności w całym stosie. Shopware dostarcza więcej funkcjonalności w rdzeniu, a jego marketplace rozszerzeń jest mniejszy, ale bardziej wyselekcjonowany.

Trzeci czynnik to frontend. Motywy Luma i Blank Magento starzeją się; Hyvä poprawiła sytuację, ale wymaga własnego ekosystemu kompatybilnych rozszerzeń. Shopware Storefront to przejrzysta warstwa oparta na Twig, a Shopware Frontends (opcja headless) używa udokumentowanego API, które nie zmienia się przy każdym mniejszym wydaniu.

Kiedy nie powinieneś migrować

Shopware nie jest właściwą odpowiedzią dla każdego sprzedawcy Magento. Przed określeniem zakresu migracji sprawdź, czy którekolwiek z poniższych dotyczy Ciebie.

Korzystasz z Adobe Commerce i aktywnie używasz modułu B2B, Shared Catalogues lub integracji Adobe Experience Cloud (AEM, Target, Analytics). Shopware B2B Suite obejmuje wiele scenariuszy, ale integracje ze stosem Adobe nie mają odpowiednika w Shopware – ich przebudowa to osobny projekt.

Twój katalog zawiera ponad 500 000 SKU ze złożonymi produktami konfigurowalnymi i opcjami niestandardowymi. Shopware obsługuje duże katalogi, ale mapowanie danych z modelu produktów konfigurowalnych/prostych Magento na system wariantów Shopware wymaga starannego planowania; testy wydajności w skali produkcyjnej powinny odbyć się przed podjęciem decyzji.

Mocno dostosowałeś panel administracyjny Magento lub zbudowałeś wewnętrzne narzędzia na bazie API Magento. Te integracje będą musiały zostać przebudowane pod Admin API Shopware, które ma inną strukturę i model uwierzytelniania.

Jeśli żadne z powyższych nie dotyczy Ciebie, Shopware jest realistycznym celem. Jeśli którekolwiek dotyczy, oszacuj koszty przebudowy przed podjęciem decyzji.

Co robi profil migracyjny Shopware Magento

Shopware dostarcza wtyczkę Migration Assistant, która łączy się z bazą danych Magento 2 i importuje dane za pomocą predefiniowanego profilu. Profil obsługuje:

• Klientów i adresy

• Zamówienia i pozycje zamówień (mapowanie statusów jest konfigurowalne)

• Produkty: proste, konfigurowalne, wirtualne i do pobrania

• Kategorie i drzewo kategorii

• Strony i bloki CMS (podstawowe treści, bez Page Buildera)

• Zdjęcia produktów (pobierane ze sklepu źródłowego)

• Grupy klientów

• Reguły i stawki podatkowe

• Zestawy właściwości i atrybuty (mapowane na właściwości Shopware i pola niestandardowe)

Importer działa w panelu administracyjnym Shopware. Odczytuje bezpośrednio z połączenia z bazą danych Magento 2, które konfigurujesz – sklep źródłowy pozostaje aktywny podczas migracji. Możliwe są przebiegi delta: możesz ponownie uruchomić migrację, a aktualizowane są tylko zmienione rekordy.

Czego profil migracyjny nie obejmuje

Luki to miejsca, gdzie większość projektów nie docenia nakładu pracy.

• Produkty pakietowe i grupowane nie mają bezpośredniego odpowiednika w Shopware i wymagają ręcznego przemapowania lub niestandardowego rozszerzenia.

• Dane opcji niestandardowych na prostych produktach (warstwa personalizacji per-produkt Magento) nie są migrowane. Jeśli używasz opcji niestandardowych do personalizacji lub konfiguracji, zaplanuj ich zastąpienie.

• Karty podarunkowe nie są uwzględnione w profilu migracyjnym.

• Treści Magento Page Builder nie importują się do Shopping Experiences Shopware (CMS). Strony zbudowane za pomocą Page Buildera muszą zostać przebudowane w edytorze CMS Shopware.

• Przekierowania URL są importowane jako przekierowania, ale logika mapowania wymaga przeglądu: Magento generuje dużą liczbę przepisań URL, z których wiele to wewnętrzne przekierowania, które nie muszą stawać się adresami URL SEO Shopware.

• Promocje i reguły cen koszyka nie są migrowane. Silnik promocji Shopware ma inną strukturę reguł; wszystkie promocje muszą zostać przebudowane.

• Punkty nagród i kredyt sklepowy nie mają równoważnej ścieżki migracji.

• Subskrybenci newslettera mogą być eksportowani z Magento i importowani do Shopware, ale profil migracyjny nie obsługuje tego automatycznie. Musisz wyeksportować listę subskrybentów i zaimportować ją przez moduł importu/eksportu Shopware.

Jak model EAV Magento mapuje się na Shopware

Tu leży większość złożoności technicznej. Magento używa modelu bazy danych Entity-Attribute-Value (EAV) dla produktów i klientów. Atrybuty są wierszami w osobnej tabeli, nie kolumnami. To daje Magento elastyczność dla dużych zestawów atrybutów, ale sprawia, że zapytania są kosztowne, a schemat nieoczywisty dla zewnętrznych narzędzi.

Shopware używa modelu relacyjnego ze stałym schematem produktu i dwoma mechanizmami rozszerzania: Właściwościami (dla atrybutów filtrowalnych, jak kolor i rozmiar) oraz Polami niestandardowymi (dla danych dodatkowych, które nie są filtrowalne). Profil migracyjny mapuje atrybuty Magento na jeden z tych dwóch mechanizmów na podstawie reguł, które konfigurujesz – ale mapowanie nie zawsze jest oczywiste i wymaga przeglądu dla każdego zestawu atrybutów.

Konkretne kwestie do zaplanowania:

• Zestawy atrybutów Magento stają się grupami właściwości Shopware. Jeśli masz wiele zestawów atrybutów z nakładającymi się atrybutami, konsolidacja przed migracją upraszcza model danych Shopware.

• Opcje produktów konfigurowalnych w Magento (selektory rozmiaru, koloru) stają się opcjami wariantów w Shopware. Mapowanie działa dla prostych przypadków, ale zawodzi, gdy produkty konfigurowalne mają więcej niż dwa wymiary lub gdy wartości opcji nie są spójne w całym katalogu.

• Ceny wielopoziomowe Magento (cennik ilościowy) mapują się na zaawansowane reguły cenowe Shopware. Logika jest podobna, ale struktura danych się różni; zaplanuj ręczny przegląd dla złożonych tabel cenowych.

• Konfiguracje wielu sklepów w Magento (wiele witryn, widoki sklepów) mapują się na strukturę kanałów sprzedaży i języków Shopware. Mapowanie nie jest jeden do jednego: widok sklepu Magento używany do języka to Shopware Language; widok sklepu używany do innej domeny to Shopware Sales Channel. Przejrzyj strukturę sklepu Magento przed rozpoczęciem migracji.

Co jest przebudowywane

Po imporcie danych trzy obszary wymagają przebudowy niezależnie od wyniku migracji.

Frontend. Twój motyw Magento się nie przenosi. Niezależnie od tego, czy używałeś Luma, Blank czy Hyvä, frontend musi zostać przebudowany w Shopware Storefront (Twig) lub jako headless frontend z użyciem Shopware Frontends. Dla większości sprzedawców ze średniego rynku jest to największa pojedyncza pozycja w budżecie projektu.

Rozszerzenia. Każde rozszerzenie Magento, na którym polegasz, potrzebuje odpowiednika Shopware lub niestandardowego zastępstwa. Zacznij od audytu listy rozszerzeń i mapuj każde na aplikację Shopware, wtyczkę Shopware lub niestandardowy development. Rozszerzenia bez odpowiednika Shopware, które obsługują podstawową logikę biznesową, to pozycje wysokiego ryzyka w projekcie.

Integracje. ERP, PIM, CRM, dostawcy płatności, dostawcy wysyłki i wszelkie niestandardowe integracje API muszą zostać przebudowane lub skonfigurowane pod API Shopware. Shopware zapewnia udokumentowane REST API i system webhooków, ale punkty końcowe i model uwierzytelniania różnią się od API Magento. Przydziel czas na każdą integrację osobno.

Realia harmonogramu i budżetu

Migracja z Magento do Shopware dla sprzedawcy ze średniego rynku ze standardowym katalogiem (poniżej 50 000 SKU, jeden storefront, 10–20 rozszerzeń) trwa zazwyczaj od czterech do ośmiu miesięcy od startu do go-live. Sama migracja danych zajmuje dni. Reszta harmonogramu to rozwój frontendu, zastąpienie rozszerzeń, praca integracyjna, testowanie i przebudowa treści.

Punkty kotwiczne budżetu do zaplanowania:

• Przebudowa frontendu: zazwyczaj 30–40% całkowitego budżetu projektu

• Zastąpienie rozszerzeń i niestandardowy development: 20–30%

• Przebudowa integracji: 15–25%

• Migracja danych, QA i go-live: reszta

To są punkty kotwiczne planowania, nie oferty. Rzeczywisty podział zależy od złożoności frontendu, liczby i rodzaju rozszerzeń oraz liczby integracji. Projekt z headless frontendem i dużą integracją ERP będzie wyglądał bardzo inaczej niż standardowy storefront z gotowymi rozszerzeniami.

Ciągłość SEO podczas migracji

Struktura URL to pierwsza kwestia SEO. Magento i Shopware generują adresy URL inaczej. Jeśli Twój sklep Magento używa ścieżek kategorii w adresach URL produktów (np. /kategoria/podkategoria/produkt.html), domyślna struktura URL Shopware nie będzie pasować. Zaplanuj strukturę URL Shopware przed migracją i skonfiguruj przekierowania 301 dla każdego zmienionego adresu URL. Profil migracyjny importuje przepisania URL Magento jako przekierowania SEO URL Shopware, ale przejrzyj wynik: Magento często ma tysiące wewnętrznych przekierowań, które generują szum.

Metadane (tagi tytułu i meta opisy) migrują razem z danymi produktów i kategorii. Sprawdź długości znaków po migracji: Magento i Shopware mają różne domyślne długości pól, a niektóre pola meta mogą zostać obcięte.

Dane strukturalne zmieniają się wraz z przebudową frontendu. Jeśli Twój motyw Magento miał niestandardowy znacznik schema.org, sprawdź, czy został przebudowany w motywie Shopware. Shopware Storefront zawiera podstawowy schemat produktu, ale porównaj go z bieżącą implementacją.

Migracja w praktyce

Migracja z Magento do Shopware, która przebiega dobrze, podąża za spójnym wzorcem: gruntowna faza odkrywania, w której instalacja Magento jest audytowana przed rozpoczęciem jakiegokolwiek developmentu, migracja danych, która startuje wcześnie i iteruje, frontend budowany równolegle oraz plan przejścia minimalizujący przestoje.

Projekty, które napotykają trudności, zazwyczaj mają jedną z trzech cech: faza odkrywania została pominięta lub była zbyt krótka, migracja danych była traktowana jako jednorazowe zdarzenie zamiast procesu iteracyjnego, albo zastąpienie rozszerzeń było określane bez wcześniejszego sprawdzenia marketplace Shopware.

Jeśli jesteś na etapie określania zakresu migracji z Magento do Shopware i chcesz niezależnej oceny tego, co obejmuje Twoja konkretna instalacja, chętnie to sprawdzimy.