Polski handel ma swoją własną historię z Magento. Od połowy drugiej dekady XXI wieku marki odzieżowe, sklepy z elektroniką i wyspecjalizowana dystrybucja budowały swoje platformy na tym systemie, bo dawał coś, czego żaden inny open source nie oferował: poważny model katalogu, konfigurowalne atrybuty i realną zdolność do obsługi operacji o obrotach liczonych w dziesiątkach milionów złotych rocznie. Dziś, w 2026, pytanie, które regularnie ląduje na naszym biurku, jest inne. Czy dalej opłaca się inwestować w Adobe Commerce, czy nadszedł moment na migracje do WooCommerce headless?
Uczciwa odpowiedź nie brzmi bezwarunkowe tak. Brzmi: tak, ale pod warunkami, i ten artykuł tłumaczy dokładnie, kiedy warunki są spełnione, a kiedy nie.
TL;DR
- Magento Open Source to nadal utrzymywany kod, ale gałąź 2.4 LTS osiągnęła oficjalny koniec wsparcia, a Adobe Commerce skupia teraz poważne inwestycje.
- Adobe Commerce 2.4.7 ukazało się w kwietniu 2024 jako nowa gałąź utrzymaniowa; licencje i złożoność operacyjna nadal ciążą, szczególnie przy polskich marżach.
- WooCommerce, z szacowanym udziałem od 8 do 10 procent globalnego e-commerce według BuiltWith i W3Techs, dojrzało na tyle, by udźwignąć średni handel.
- Połączenie WooCommerce z frontendem Astro 5 lub Next.js 15 na Cloudflare Workers dostarcza konkurencyjne czasy odpowiedzi bez obciążenia operacyjnego Magento.
- Nie każde Magento powinno migrować: B2B z konkretnymi przepływami Adobe, katalogi powyżej 100 000 aktywnych SKU i złożone architektury multi-website zwykle zostają tam, gdzie są.
Dlaczego Magento zdominowało polski rynek
Żeby zrozumieć decyzję z 2026, trzeba spojrzeć wstecz. Kiedy Magento 1 wyrosło na punkt odniesienia open source dla e-commerce, polski rynek online dopiero nabierał rozpędu, a rosnąca presja Allegro wymuszała na sklepach markowych własną, w pełni kontrolowaną platformę zamiast wyłącznej obecności na marketplace. Marki, które chciały budować własny kanał sprzedaży, potrzebowały systemu zdolnego obsłużyć szerokie katalogi, wiele walut, konfiguracje stawek VAT i logistyczną złożoność sprzedaży wysyłkowej. Magento oferowało dokładnie to. Firmy integratorskie z Warszawy, Krakowa, Wrocławia i Trójmiasta zbudowały wyspecjalizowane zespoły, a w wielu przypadkach te zespoły działają do dziś.
W maju 2018 Adobe przejęło Magento za około 1,68 miliarda dolarów. Transakcja nie była zaskoczeniem dla obserwatorów branży: Adobe potrzebowało elementu commerce w swoim Experience Cloud, a Magento wnosiło dojrzały ekosystem. Konsekwencja jednak wyznaczyła kierunek. Platforma została podzielona na dwa produkty: Magento Open Source, darmowe i utrzymywane przez społeczność, oraz Adobe Commerce, płatną edycję z funkcjami korporacyjnymi, takimi jak B2B, zaawansowana segmentacja i ulepszony Page Builder.
Potem przyszła data, którą wielu sprzedawców wciąż wspomina z niesmakiem. 30 czerwca 2020 Magento 1 osiągnęło koniec życia. Dziesiątki polskich sklepów musiały migrować do Magento 2 w napiętych terminach, z nieprzewidzianymi budżetami i wyraźnym poczuciem, że kontrola nad platformą przesunęła się gdzie indziej. Ta wymuszona migracja z 2020 jest w wielu przypadkach źródłem dzisiejszego zmęczenia, które prowadzi do rozważania alternatyw.
Co zmieniło się między 2020 a 2025
W pięć lat krajobraz przesunął się mocniej, niż się wydaje. Znaczą trzy konkretne zmiany.
Po pierwsze, utrzymujący się koszt Adobe Commerce. Roczna licencja nadal liczona jest od przychodu brutto i w sumie z wyspecjalizowaną infrastrukturą, której platforma wymaga, stanowi stałą pozycję, którą wielu średnich sprzedawców kwestionuje, gdy zestawi ją ze swoimi realnymi marżami. Polski handel operuje na cieńszych marżach niż wiele rynków Europy Zachodniej, więc każda stała opłata liczona od obrotu waży tu mocniej.
Po drugie, nagromadzona złożoność ekosystemu Magento. Moduły zewnętrznych dostawców, personalizacje koszyka, konektory z lokalnymi systemami ERP, takimi jak Comarch ERP XL czy enova365, oraz integracje z polskimi bramkami płatności, takimi jak Przelewy24, PayU czy obsługa BLIK, tworzą warstwę, którą po kilku latach mało który zespół potrafi ruszyć bezboleśnie. Nagromadzony dług techniczny staje się argumentem sam w sobie.
Po trzecie, dojrzewanie alternatyw. WooCommerce, które w 2018 uchodziło za zdatne tylko dla małych sklepów, wprowadziło HPOS dla skalowania zamówień, poważne usprawnienia API REST i ekosystem rozszerzeń pokrywający większość przepływów średniego handlu. Jego globalny udział, szacowany przez BuiltWith i W3Techs między 8 a 10 procent światowego e-commerce, trudno zignorować. I przede wszystkim nadeszła era headless: oddzielenie frontendu od backendu sprawia, że szybkość i doświadczenie nie zależą już od tradycyjnej ociężałości monolitu PHP.
Warto też zauważyć zmianę, którą obserwujemy u polskich sprzedawców w praktyce. Wielu z nich prowadzi równolegle sprzedaż na Allegro i we własnym sklepie, a Allegro coraz mocniej domaga się szybkości ładowania i jakości kart produktowych po stronie sprzedawcy. Kiedy własny sklep na klasycznym Magento ładuje się wolniej niż listing na marketplace, właściciel zaczyna zadawać sobie pytanie, po co utrzymuje drogą platformę, która nie wygrywa nawet z kanałem, który miała uzupełniać. To pytanie, nie licencja jako taka, najczęściej uruchamia rozmowę o migracji.
Kiedy migracja ma sens
Decyzja o migracji nie powinna opierać się na modzie ani na presji handlowej. Jest pięć konkretnych kryteriów, które przy spełnieniu co najmniej trzech uzasadniają rozważenie zmiany.
Pierwsze to katalog. Jeśli twój sklep zarządza mniej niż 50 000 aktywnych SKU, z względnie stabilnymi atrybutami i kategoriami, które nie zmieniają się codziennie, WooCommerce działa bez nadzwyczajnego wysiłku. Praktyczna bariera, gdzie krzywa złożoności zaczyna się piąć, zwykle leży w okolicach tej liczby.
Drugie to zespół. Jeśli utrzymanie twojego Magento wymaga zależności od jednego czy dwóch zewnętrznych integratorów, bo wewnątrz firmy nikt nie panuje nad platformą, jesteś w kruchej sytuacji. WooCommerce żyje na WordPressie, a podaż talentu WordPress w Polsce jest znacząco większa. Ludzka śledzalność projektu poprawia się po migracji. Rozwinięcie tej perspektywy znajdziesz na naszej stronie programisty WooCommerce.
Trzecie to postrzegana szybkość. Jeśli czasy ładowania na mobile przekraczają trzy sekundy w LCP mimo optymalizacji Varnish i FPM, tradycyjna architektura Magento osiągnęła sufit dla twojego przypadku. Frontend headless w Astro lub Next.js, serwowany z Cloudflare Workers, dostarcza HTML w milisekundach i uwalnia doświadczenie od ciężaru backendu.
Czwarte to roadmapa. Jeśli twój plan na trzy lata obejmuje bogatsze doświadczenia klienta, integracje z własnymi aplikacjami mobilnymi, treść redakcyjną splecioną z handlem albo szybkie eksperymentowanie z landingami, model headless daje swobodę, której tradycyjny frontend Magento nie przyzna.
Piąte to realny koszt. Nie sam koszt licencji w izolacji, lecz suma licencji, wyspecjalizowanego hostingu, umów utrzymaniowych i godzin programisty. Kiedy ten roczny total przekracza wyraźnie to, ile kosztowałaby w eksploatacji równoważna alternatywa headless, ROI migracji przestaje być teoretyczny. W polskim kontekście dochodzi jeszcze jeden składnik, o którym łatwo zapomnieć: dostępność ludzi. Licencja jest przewidywalna, ale ryzyko, że twój jedyny integrator Magento zmieni branżę albo podniesie stawki, bo takich specjalistów jest coraz mniej, jest realne i rośnie z każdym rokiem. Wycena migracji zawsze jest indywidualna, ale zdolność do zatrudnienia następnego programisty w rozsądnym czasie ma wartość, której faktura nie pokazuje.
Kiedy Magento powinno zostać
Tu przychodzi część, o której mówi się rzadziej. Nie każdy sklep na Magento musi migrować. Są cztery sytuacje, w których uczciwie rekomendujemy pozostanie.
Pierwsza to B2B z konkretnymi funkcjami Adobe Commerce. Jeśli używasz na poważnie Company Accounts, Shared Catalogs, Quick Order czy Requisition Lists, odtworzenie tego wszystkiego w WooCommerce oznacza budowanie wielu rzeczy ręcznie. Wysiłek może się nie opłacić.
Druga to duże katalogi. Powyżej 100 000 aktywnych SKU, zwłaszcza gdy atrybutów jest wiele, a filtry frontowe są intensywne, Magento pozostaje najbardziej naturalnym wyborem. WooCommerce może tam dojść, ale wymaga integracji z zewnętrznymi silnikami wyszukiwania i poziomu optymalizacji, który złożonością dorównuje już utrzymaniu Magento.
Trzecia to architektura multi-website z zaawansowaną segmentacją według kraju, języka i waluty, dzieląca jeden centralny magazyn. Magento ma tę warstwę zaprojektowaną u podstaw; WooCommerce symuluje ją wtyczkami, i różnicę widać.
Czwarta to moment biznesowy. Jeśli twój sklep jest w szczycie sezonu, w trakcie pozyskiwania finansowania albo w transformacji organizacyjnej, to nie jest ten moment. Źle skalibrowana migracja handlu może kosztować kilka miesięcy przychodów. Właściwe okno istnieje, ale trzeba umieć je wybrać.
Ścieżka migracji do WooCommerce headless
Kiedy decyzja to migracja, ścieżka ma cztery wyraźnie oddzielone fazy. Mówimy o realnej migracji, nie o przerysowaniu szablonów.
Pierwsza faza to audyt. Pełna inwentaryzacja katalogu, atrybutów, zestawów atrybutów, kategorii, produktów konfigurowalnych, produktów zgrupowanych, reguł katalogu, reguł koszyka, metod dostawy, zintegrowanych bramek płatności, stref podatkowych, grup klientów i wszelkich personalizacji koszyka. Ta faza produkuje mapę wszystkiego, co istnieje, oraz jawną decyzję o tym, co się zachowuje, co upraszcza, a co usuwa.
Druga faza to mapowanie danych. Każda encja Magento przekłada się na encję WooCommerce. Produkty proste i konfigurowalne mapują się na produkty proste i wariantowe. Atrybuty niestandardowe przechodzą w taksonomie lub meta. Zestawy atrybutów, które w Magento są elementem strukturalnym, spłaszczają się w WooCommerce, bo tam nie istnieją jako takie. Tu już zaczyna wychodzić ukryty dług modelu źródłowego.
Trzecia faza to skrypty migracyjne. Zawsze rekomendujemy pisanie własnego kodu zamiast ślepego polegania na generycznych wtyczkach. Kontrolowany skrypt czyta bazę Magento, transformuje dane i zapisuje w WooCommerce, respektując relacje, kanoniczne SKU i historyczne zamówienia. Zamówienia się nie odrzuca: importuje się je z oryginalnymi statusami, liniami produktów, naliczonymi podatkami i odniesieniami do klienta. Jeśli decydujesz się nie migrować zamówień poniżej pewnego wieku, ta decyzja zostaje udokumentowana i zakomunikowana. Wzorzec przełożenia bramek płatności i logiki koszyka opisujemy dokładniej w przewodniku migracji z Shopify do WooCommerce, bo mechanika transformacji danych jest zbliżona.
Czwarta faza to strategia SEO i przekierowań. Magento generuje URL-e o specyficznych wzorcach, a jakakolwiek zmiana bez przekierowania 301 zabija pozycje wypracowane latami. Każdy stary URL mapuje się na nowy URL w WooCommerce, a plik przekierowań utrzymuje się na poziomie Cloudflare lub Workers. To faza najmniej widoczna i ta, która ratuje najwięcej ruchu organicznego.
Co zwykle idzie źle
Widzieliśmy wiele migracji, własnych i cudzych. Dwa przypadki dobrze pokazują skalę problemu. Sklep z branży wyposażenia wnętrz z katalogiem około 18 000 SKU przeszedł migracje, w której ktoś potraktował produkty konfigurowalne jako proste i po cutoverze połowa wariantów kolorystycznych zniknęła z filtrów. Inny, dystrybutor części z ponad 40 000 SKU, zmigrował katalog i zamówienia poprawnie, ale przez trzy okresy rozliczeniowe wysyłał do JPK_V7 dane bez oznaczeń mechanizmu podzielonej płatności, bo integracja z ERP odwzorowywała tylko stawki VAT, a nie kody procedur. Oba przypadki łączy to samo: błąd nie był widoczny w koszyku ani na stronie produktu, wyszedł dopiero przy raportowaniu i pierwszym audycie stanów. Pięć błędów poniżej powtarza się z niepokojącą regularnością.
Mapowanie SKU. W Magento produkty konfigurowalne mają zwykle SKU rodzica, a powiązane produkty proste mają SKU dzieci. WooCommerce pracuje z produktami wariantowymi i wariacjami, gdzie logika SKU nie jest identyczna. Kto nie usiądzie spokojnie do zmapowania tej odpowiedniości, kończy z duplikatami, osieroconymi produktami i raportami stanów magazynowych, które kłamią.
Migracja haszy klientów. Hasła w Magento przechowywane są z innym algorytmem niż w WordPressie. Nie da się ich przetłumaczyć. Opcje są dwie: wymusić masowy reset, zapowiedziany mailem z wyprzedzeniem, albo wdrożyć most, który waliduje hasło wobec oryginalnego hasza przy pierwszym logowaniu i przepisuje je do natywnego formatu WordPressa. Obie są poprawne, ale wymagają świadomej decyzji, a wobec RODO także udokumentowanej podstawy przetwarzania.
Przełożenie zestawów atrybutów. Jak już wspomniano, attribute sets Magento nie istnieją w WooCommerce. Kto nie spłaszczy tej struktury z rozwagą, kończy z produktami pozbawionymi kluczowych atrybutów na froncie i z filtrami zwracającymi niepełne wyniki. Spłaszczanie wymaga poważnej analizy modelu katalogu, nie automatycznego skryptu.
Konfiguracja stref i reguł podatkowych. To najbardziej polski z pięciu punktów. Polski VAT ma stawki 23, 8 i 5 procent, co samo w sobie jest proste do skonfigurowania. Problem zaczyna się głębiej. Mechanizm podzielonej płatności (split payment) jest obowiązkowy dla wielu towarów wrażliwych powyżej progu kwotowego i wymaga odpowiedniego oznaczania faktur oraz integracji z bramką płatności. Do tego dochodzi raportowanie JPK_V7, gdzie każda transakcja musi trafić do jednolitego pliku kontrolnego z właściwymi kodami. Migracja, która przenosi katalog i zamówienia, ale nie odwzorowuje tej logiki podatkowej w integracji z systemem ERP i księgowością, generuje faktury niezgodne z wymogami, a to problem, który wychodzi na jaw dopiero przy pierwszym rozliczeniu miesiąca. Widzieliśmy sklepy naliczające podatek poprawnie w koszyku, ale wysyłające do JPK dane bez oznaczeń split payment przez kilka okresów, zanim ktoś to wychwycił.
Zachowanie przepisań URL. Magento utrzymuje tabelę url_rewrite, która w praktyce jest żywą historią SEO sklepu. Migracja, która ignoruje tę tabelę, traci wewnętrzne przekierowania nagromadzone przez lata. Trzeba ją wyekstrahować, znormalizować i przełożyć na przekierowania zarządzane w nowym środowisku.
Co oferujemy w WPPoland
W WPPoland od lat budujemy architektury headless dla klientów z realnymi oczekiwaniami wobec wydajności i utrzymania. Nasze podejście zawsze wychodzi od uczciwego audytu, nie od domyślnej propozycji migracji. Jeśli twoje Magento powinno zostać, mówimy to wprost. Jeśli migracja ma sens, projektujemy pełną ścieżkę, wykonujemy skrypty, definiujemy strategię przekierowań i zostawiamy frontend Astro lub Next.js serwowany z Cloudflare Workers, który dostarcza LCP poniżej sekundy na mobile. Szczegółową ofertę znajdziesz na naszej stronie filarowej WordPress headless.
Pracujemy z zespołami seniorskimi, które rozumieją polski kontekst: lokalne bramki płatności takie jak Przelewy24, PayU i BLIK, popularne systemy ERP jak Comarch ERP XL i enova365, specyfikę podatkową z mechanizmem podzielonej płatności i JPK oraz presję marketplace ze strony Allegro. To nie są szczegóły, które da się dopisać na koniec projektu. To warstwa, którą trzeba zaprojektować od pierwszej fazy audytu.
Gdzie osadza się ten artykuł
Ten tekst jest częścią większego klastra o WordPressie klasy enterprise i nowoczesnym e-commerce. Jeśli planujesz migrację, przyda ci się także nasz przewodnik migracji z Shopify do WooCommerce, by zrozumieć, jak mechanika przenoszenia danych i przekierowań wygląda przy innym systemie źródłowym. A jeśli szukasz zespołu do wykonania, zajrzyj na stronę programisty WooCommerce.
Pytanie nie brzmi, czy Magento Adobe Commerce nadal jest poważną platformą. Jest. Pytanie brzmi, czy nadal jest platformą właściwą dla twojego biznesu w 2026. Dla części polskiego handlu uczciwa odpowiedź wskazuje na WooCommerce headless. Dla innej części nie. Jedyne, czego nie rekomendujemy, to decydować bez zmierzenia.
