Migracja z Magento 1: co przenieść, a co pisać od nowa?

Z Magento 1 da się uratować wyłącznie czyste dane biznesowe: bazę produktów z atrybutami EAV, historię zamówień, konta klientów oraz strukturę adresów URL kluczową dla SEO. Cała reszta — motyw graficzny, pliki layoutów XML, kod PHP, integracje z systemami ERP oraz moduły zewnętrznych dostawców — musi zostać napisana całkowicie od nowa. Magento 2 (aktualnie w wersji 2.4.7-p1) to odrębny silnik e-commerce, który z poprzednikiem dzieli wyłącznie nazwę i część logiki bazodanowej. Jeśli planujesz wdrozenia Magento 2 i Adobe Commerce, musisz traktować ten proces jak budowę nowego systemu z operacją precyzyjnego przeszczepu danych ze starego organizmu.

Dlaczego utrzymywanie Magento 1 w 2026 roku to bezpośrednie ryzyko biznesowe?

Wsparcie dla Magento 1 zakończyło się w czerwcu 2020 roku. Jeśli Twój sklep nadal działa na tej platformie, funkcjonuje w środowisku technologicznym z innej epoki. Magento 1 projektowano pod PHP 5.6 i wczesne wydania PHP 7, podczas gdy nowoczesne środowiska produkcyjne wymagają PHP 8.2 lub 8.3 oraz OpenSearch 2.x w miejsce wycofanego z dystrybucji Elasticsearcha. Utrzymywanie starej platformy oznacza brak łatek bezpieczeństwa dla podatności typu RCE (Remote Code Execution) i SQL Injection, co przy audycie PCI-DSS natychmiast dyskwalifikuje sklep z możliwości przetwarzania płatności kartowych.

W polskich realiach gospodarczych 2026 roku dochodzi twarda ściana prawno-fiskalna. Krajowy System e-Faktur (KSeF) stał się standardem wymaganym przez Ministerstwo Finansów. Na Magento 1 nie istnieje ani jeden oficjalnie certyfikowany i rozwijany moduł obsługujący dwukierunkową komunikację z bramką KSeF, weryfikację numerów rachunków na Białej Liście VAT czy generowanie struktur JPK_V7 z kodami GTU. Dopisywanie takich integracji do martwego frameworka to topienie budżetu w długu technologicznym, którego nikt później nie zechce serwisować.

Co dokładnie da się bezstratnie przenieść z bazy danych Magento 1?

Podczas migracji bazy danych nie kopiujemy plików 1:1, lecz przeprowadzamy transformację schematów. Oficjalne narzędzie Data Migration Tool od Adobe lub dedykowane skrypty eksportowe pozwalają uratować najważniejszy kapitał sklepu:

• Katalog produktów i drzewo kategorii: Przenoszone są produkty proste, konfigurowalne, powiązane (bundle/grouped), powiązania w relacjach cross-sell/up-sell, stany magazynowe oraz kompletna struktura kategorii. Układ atrybutów EAV z tabel catalog_product_entity_* wymaga jedynie zmapowania do nowej struktury Magento 2.4.7.
• Baza klientów i adresy: Pełna lista zarejestrowanych kont z książkami adresowymi (domyślny adres dostawy i rozliczeniowy) oraz przypisaniem do grup klientów (np. hurt/detal w modelach B2B).
• Hasła klientów: Magento 1 używało haszowania MD5 lub SHA-256 z solą (format hash:salt). Magento 2 natywnie stosuje bezpieczniejsze algorytmy (Argon2ID13 lub SHA-256 z wielokrotnym haszowaniem). Podczas migracji zachowuje się stare hashe — mechanizm Magento 2 weryfikuje je przy pierwszym logowaniu użytkownika, a po poprawnym uwierzytelnieniu automatycznie podmienia hash w bazie na nowy. Klient nie musi resetować hasła.
• Historia transakcji: Zamówienia (ze wszystkimi powiązanymi wpisami w tabelach sales_order_*), faktury, wysyłki oraz noty kredytowe. Uratowanie tych danych jest niezbędne dla zachowania ciągłości kont klientów i historii zakupów.
• Rewritingi URL i metadane SEO: Ścieżki z tabeli core_url_rewrite z Magento 1 muszą trafić do url_rewrite w Magento 2. Zachowanie identycznych slugów produktowych i kategorialnych zapobiega tąpnięciu pozycji organicznych w Google.

Czego nie da się uratować i dlaczego stary kod nadaje się do kosza?

Architektura kodu w Magento 2 została zaprojektowana od zera. O ile silnik bazodanowy nadal opiera się na schemacie EAV i relacyjnych tabelach MySQL/MariaDB, o tyle warstwa backendowa i frontendowa nie wykazują żadnej wstecznej kompatybilności.

Próba przeniesienia plików szablonu .phtml z Magento 1 do Magento 2 skończy się natychmiastowym błędem krytycznym Fatal error: Uncaught Error. W M2 nie istnieje globalny obiekt Mage::getModel() ani Mage::helper().

Do całkowitego przepisania lub zastąpienia nowymi rozwiązaniami kwalifikują się:

1. Frontend i layouty: Stary stos technologiczny (Prototype.js, archaiczne kontrolery bloków) zastępuje się nowoczesnym frontendem. Standardowa Luma na bazie RequireJS i Knockout.js jest obecnie odradzana. W SISL standardem dla nowych wdrożeń jest Hyvä Themes — lekki frontend oparty na Tailwind CSS i Alpine.js, który bez trudu osiąga wyniki 95+ w Google PageSpeed Insights.
2. Moduły firm trzecich: Wszelkie rozszerzenia zakupione w latach ubiegłych od vendorów takich jak Amasty, Mirasvit czy MageWorx trzeba zakupić w wersjach dedykowanych dla Magento 2. Kod PHP w M2 opiera się na wstrzykiwaniu zależności (Dependency Injection), interceptorach (Plugins/Around/Before/After) oraz deklaratywnych kontraktach serwisowych (Service Contracts).
3. Pliki konfiguracyjne: Konfiguracje XML z plików config.xml zostały rozbite na wyspecjalizowane pliki: di.xml, events.xml, routes.xml, acl.xml czy view.xml.

Jak zorganizować integracje z polskim ekosystemem (ERP, Płatności, Logistyka)?

W 2026 roku polski e-commerce wymaga stabilnych, asynchronicznych integracji. Bezpośrednie zapytania SQL do bazy danych, często praktykowane w czasach Magento 1 przez integratory desktopowe, są w Magento 2 błędem sztuki. Prowadzą do zakleszczeń tabel (table locks) i uszkodzenia indeksów.

Nowoczesną komunikację z systemami Comarch ERP Optima czy Subiekt GT / nexo realizuje się za pośrednictwem natywnego REST API Magento 2 lub dedykowanych kolejek komunikatów (RabbitMQ). Pozwala to na bezbłędną synchronizację stanów magazynowych w czasie rzeczywistym, przekazywanie cenników indywidualnych B2B oraz generowanie dokumentów handlowych bez spowalniania panelu administracyjnego.

W warstwie płatności standardem są moduły Przelewy24, PayU czy Autopay wspierające BLIK Level 0 (wpisywanie kodu BLIK bezpośrednio na formatce sklepu, bez przekierowania). W logistyce niezbędny jest oficjalny moduł InPost z obsługą Geowidgetu v5 do wyboru Paczkomatów na etapie checkoutu, zintegrowany z API ShipX.

Ile kosztuje i ile trwa migracja na Magento 2.4.7 w 2026 roku?

Budżet migracji zależy od stopnia skomplikowania logiki biznesowej, liczby integracji zewnętrznych oraz wybranego frontendu. U nas w projektach migrację dzielimy na twarde etapy: audyt bazy M1, instalację środowiska Magento 2.4.7 na PHP 8.3 z OpenSearch 2.x, wdrożenie motywu Hyvä, migrację danych, development integracji ERP i testy wydajnościowe.

Realne widełki cenowe na polskim rynku kształtują się następująco:

• Średni sklep B2C (do 20 000 SKU, 3-4 integracje: ERP, P24, InPost): 60 000 – 95 000 PLN netto. Czas realizacji: 2.5 – 4 miesiące.
• Rozbudowany sklep B2B / B2C (powyżej 50 000 SKU, indywidualne cenniki, zaawansowane reguły koszykowe, Comarch Optima/XL, Baselinker/Allegro): 110 000 – 180 000 PLN netto (ok. 25 000 – 40 000 EUR). Czas realizacji: 4 – 6 miesięcy.
• Koszty licencyjne i narzędziowe: Jednorazowa licencja na Hyvä Themes (€1,000), pakiet modułów funkcyjnych (Amasty/Mirasvit — ok. €1,200 – €2,500), dedykowana infrastruktura chmurowa lub VPS pod Magento 2 (Varnish Cache, Redis, RabbitMQ, PHP-FPM — od 600 do 2 000 PLN netto miesięcznie).

Plan działania: jak przeprowadzić migrację krok po kroku bez przestojów w sprzedaży?

Największym błędem jest próba migracji „na żywym organizmie”. Prawidłowy proces składa się z sześciu wyodrębnionych faz:

1. Czyszczenie bazy Magento 1: Usunięcie zbędnych logów z tabel log_url, log_visitor, wyczyszczenie porzuconych koszyków z sales_flat_quote oraz naprawa uszkodzonych wpisów EAV. Zmniejsza to objętość bazy często o kilkadziesiąt gigabajtów.
2. Przygotowanie środowiska produkcyjnego M2: Konfiguracja serwera z PHP 8.3, MariaDB 10.6+, OpenSearch 2.11+, Varnish 7.x oraz instalacja Magento 2.4.7.
3. Próbna migracja danych (Dry Run): Mapowanie struktury i weryfikacja integralności danych testowych przy użyciu CLI: bin/magento migrate:data.
4. Development i integracje: Wdrożenie layoutu Hyvä, konfiguracja metod płatności, spięcie z ERP i weryfikacja logiki koszyka. Na tym etapie wykonuje się kompilację DI: bin/magento setup:di:compile oraz generowanie assetów statycznych.
5. Testy akceptacyjne (UAT) i testy wydajnościowe: Weryfikacja ścieżki zakupowej, poprawności naliczania podatków, fakturowania oraz generowania etykiet kurierskich.
6. Finalne przełączenie (Delta Migration): W nocy wdrożenia sklep na M1 przełączany jest w tryb maintenance. Uruchamiany jest skrypt migracji przyrostowej, który zaciąga wyłącznie nowe zamówienia i klientów zarejestrowanych od czasu pierwszego zrzutu bazy. Następuje przepięcie rekordów DNS i wyczyszczenie pamięci podręcznej: bin/magento cache:flush. Przestój operacyjny dla klientów wynosi zazwyczaj poniżej 60 minut.

Jeśli Twój sklep nadal działa na Magento 1, a koszty utrzymania przestarzałego serwera i ryzyko awarii przewyższają zyski, czas zamknąć ten rozdział techniczny. Jeśli chcesz przeanalizować bazę danych swojego sklepu i oszacować precyzyjny koszt wdrożenia — napisz do nas.