Magento 1 przestało otrzymywać oficjalne wsparcie już w 2020 roku, ale wiele sklepów nadal działa na tej platformie. Zwykle nie dlatego, że właściciel ignoruje problem. Powód jest bardziej praktyczny: sklep ma lata modyfikacji, działa z ERP-em, PIM-em, kurierami i płatnościami, a każda zmiana wydaje się ryzykowna. Dobrze przygotowana migracja z Magento 1 nie jest jednak wymianą systemu dla samej technologii. To projekt, który ma ograniczyć koszty utrzymania, poprawić szybkość zakupów i przygotować sprzedaż na dalszy wzrost.
Największym błędem jest traktowanie Magento 2 jako aktualizacji Magento 1. To dwa odrębne systemy. Kod motywów, rozszerzeń i indywidualnych modyfikacji nie przechodzi automatycznie. Migracja wymaga decyzji biznesowych: co zachować, co przebudować, a czego już nie warto utrzymywać.
Dlaczego migracja z Magento 1 nie powinna czekać
Stary sklep może nadal przyjmować zamówienia, ale jego rzeczywisty koszt często pozostaje niewidoczny. Zespół poświęca czas na ręczne poprawki, aktualizacje wymagają ostrożności, a znalezienie specjalistów znających historyczne rozwiązania staje się coraz trudniejsze. Do tego dochodzi bezpieczeństwo danych klientów, zgodność z wymaganiami operatorów płatności oraz ryzyko problemów z wydajnością przy rosnącym ruchu i katalogu.
Z perspektywy klienta problem wygląda jeszcze prościej. Wolna karta produktu, nieczytelny koszyk, błędy na urządzeniach mobilnych czy długi proces finalizacji zamówienia obniżają konwersję. Klient nie analizuje przyczyny technicznej – po prostu przechodzi do konkurencji.
Magento 2 daje lepszą bazę do rozwoju, ale sama zmiana silnika nie gwarantuje wyniku. Można przenieść stare problemy do nowego sklepu: nadmiar rozszerzeń, niejasne reguły cenowe, ciężki frontend i integracje bez właściciela po stronie biznesowej. Dlatego projekt zaczynam od analizy, nie od kopiowania danych.
Audyt przed migracją: najpierw cele, potem zakres
Przed przygotowaniem wyceny trzeba ustalić, co obecny sklep rzeczywiście robi. Nie chodzi wyłącznie o liczbę produktów, klientów i zamówień. Kluczowe są procesy, które odróżniają firmę od prostego sklepu detalicznego: indywidualne ceny B2B, limity kredytowe, wielopoziomowe cenniki, zamówienia cykliczne, konfiguratory, logika promocji, obsługa wielu magazynów czy wymiana danych z systemem ERP.
W praktyce analizuję cztery obszary: dane, funkcje, integracje i cele sprzedażowe. Dane odpowiadają na pytanie, co należy przenieść. Funkcje pokazują, które elementy są potrzebne, a które powstały wiele lat temu i dziś tylko komplikują utrzymanie. Integracje ujawniają zależności operacyjne. Cele sprzedażowe pomagają ustalić priorytety dla frontendu, wyszukiwarki, filtrowania, procesu zakupowego i panelu B2B.
To etap, na którym warto podważyć założenie „przenosimy wszystko”. Przykładowo, konto klienta z historią zamówień zazwyczaj ma dużą wartość. Natomiast stare, nieużywane atrybuty katalogowe, nieaktywne reguły promocyjne czy konta bez zgody marketingowej mogą być balastem. Mniejszy i lepiej uporządkowany zakres danych oznacza prostsze testy oraz niższe ryzyko błędów po uruchomieniu.
Co przenosimy, a co budujemy od nowa
Dane produktowe, kategorie, klienci, adresy, zamówienia, faktury, kupony i reguły cenowe można migrować, ale każdą grupę trzeba wcześniej zweryfikować. Magento 1 często zawiera duplikaty klientów, produkty archiwalne, rekordy testowe i pola utworzone przez nieużywane moduły. Techniczna możliwość przeniesienia nie jest jeszcze uzasadnieniem biznesowym.
Osobną decyzją są rozszerzenia. W Magento 1 wiele funkcji realizowano przez moduły instalowane bez wspólnej architektury. W Magento 2 część potrzeb pokrywa standard platformy, część warto rozwiązać nowym modułem, a część można obsłużyć po stronie ERP, PIM lub systemu marketing automation. Nie rekomenduję odtwarzania funkcjonalności tylko dlatego, że istnieje w starym sklepie.
Szczególnej uwagi wymaga frontend. Sklep oparty na Magento 2 i Hyvä może wyraźnie poprawić szybkość działania oraz komfort zakupów, zwłaszcza na urządzeniach mobilnych. Nie jest to jednak automatyczny wybór dla każdego projektu. Jeśli firma ma niestandardowy motyw, rozbudowany konfigurator lub wiele komponentów zależnych od dotychczasowego frontendu, trzeba sprawdzić kompatybilność i koszt dostosowań. Celem nie jest wdrożenie modnego rozwiązania, lecz szybsza droga klienta do zakupu i rozsądny koszt dalszego rozwoju.
Integracje są zwykle największym ryzykiem
W sklepach B2B i rozwiniętych kanałach B2C platforma e-commerce rzadko działa samodzielnie. Pobiera stany magazynowe i ceny, przekazuje zamówienia, aktualizuje statusy, wystawia dokumenty, komunikuje się z przewoźnikami i systemami płatności. Gdy integracja działa od lat, często brakuje jej aktualnej dokumentacji, a wiedza o wyjątkach znajduje się tylko u kilku osób w firmie.
Dlatego przed rozpoczęciem prac ustalamy właściciela każdego procesu. Kto odpowiada za dane produktowe? Który system jest źródłem prawdy dla stanów? Co powinno się wydarzyć, gdy klient B2B przekroczy limit kupiecki albo produkt przestanie być dostępny po złożeniu zamówienia? Takie pytania są ważniejsze niż sama metoda połączenia API.
Dobra migracja uwzględnia również sytuacje awaryjne. Integracja powinna mieć kolejkę, monitoring, czytelne logi i procedurę obsługi błędów. Bez tego zespół handlowy dowiaduje się o problemie dopiero wtedy, gdy klient pyta, dlaczego zamówienie nie trafiło do realizacji.
SEO i ciągłość sprzedaży wymagają osobnego planu
Przeniesienie sklepu na nową platformę może poprawić wyniki organiczne, ale nie dzieje się to samo. Największe zagrożenie to zmiana adresów URL bez przekierowań, utrata meta danych, błędna indeksacja środowiska testowego albo usunięcie wartościowych stron kategorii. Sklep po migracji może wyglądać lepiej, a jednocześnie stracić ruch z wyszukiwarki.
Plan SEO powinien obejmować inwentaryzację ważnych adresów, mapę przekierowań 301, zachowanie kluczowych treści i weryfikację danych strukturalnych. Po uruchomieniu kontrolujemy błędy indeksowania, ruch na najważniejszych landing pages oraz sprzedaż z kanału organicznego. Warto mierzyć także konwersję, średnią wartość koszyka, liczbę błędów w checkoutcie i wydajność kluczowych widoków. Sama pozycja frazy nie pokazuje pełnego efektu biznesowego.
Nie zawsze opłaca się zachować identyczną strukturę adresów. Jeżeli obecna architektura kategorii jest nieczytelna lub tworzy problemy z duplikacją, zmiana może być uzasadniona. Musi jednak wynikać z planu, nie z przypadku.
Jak wygląda bezpieczne uruchomienie Magento 2
Wdrożenie nie powinno opierać się na założeniu, że „na produkcji jeszcze sprawdzimy”. Najpierw przygotowuję środowisko testowe, na którym zespół klienta może przejść przez rzeczywiste scenariusze: zakup detaliczny, logowanie klienta B2B, naliczenie indywidualnej ceny, przekazanie zamówienia do ERP, zwrot, fakturę i aktualizację statusu.
Następnie wykonujemy próbną migrację danych. Dzięki temu można sprawdzić czasy importu, jakość rekordów, poprawność powiązań produktów oraz zachowanie kont klientów. Końcowy import odbywa się tuż przed przełączeniem, aby ograniczyć różnicę między starym i nowym sklepem. W zależności od skali sprzedaży planujemy okno serwisowe albo mechanizm obsługi zamówień z obu źródeł przez ograniczony czas.
Przed publikacją konieczna jest checklista obejmująca płatności, dostawy, e-maile transakcyjne, podatki, zgody, wydajność, przekierowania, analitykę i dostęp administracyjny. Po starcie zespół musi wiedzieć, kto monitoruje zamówienia, błędy i integracje. Pierwsze dni po uruchomieniu nie są końcem projektu – to okres świadomej obserwacji i szybkich korekt.
Budżet migracji zależy od złożoności, nie od liczby produktów
Pytanie o cenę migracji jest zasadne, ale odpowiedź „od” bez analizy niewiele pomaga w podjęciu decyzji. Katalog z 50 tysiącami prostych produktów może być łatwiejszy do przeniesienia niż sklep z 5 tysiącami produktów, wieloma typami klienta, indywidualnymi cenami i kilkunastoma integracjami.
Na budżet wpływają przede wszystkim stan danych, liczba procesów niestandardowych, zakres frontendu, integracje, wymagania B2B oraz potrzeba zachowania SEO. Transparentny model fixed price ma sens wtedy, gdy poprzedza go dobrze opisany zakres. Pozwala firmie zaplanować inwestycję i uniknąć sytuacji, w której fundamentalne elementy pojawiają się jako kosztowny „dodatek” w trakcie prac.
W APK Studio traktuję migrację jako moment na uporządkowanie platformy sprzedażowej, a nie odtworzenie wszystkich decyzji technologicznych z poprzedniej dekady. Właściwie zaplanowany projekt daje zespołowi nie tylko nowy sklep, lecz także większą kontrolę nad rozwojem, integracjami i kosztami utrzymania.
Jeżeli Magento 1 nadal obsługuje ważną część sprzedaży, najrozsądniejszym pierwszym krokiem nie jest wybór motywu ani modułu. Jest nim rzetelna mapa procesów, danych i ryzyk. Dopiero na niej można zbudować Magento 2, które wspiera ambicje firmy, zamiast tworzyć kolejne ograniczenie na kilka następnych lat.
