Migracja z Magento 2.3 na 2.4.x - upgrade w sklepie B2B

Upgrade vs wymiana platformy

Pierwsze pytanie, które zadaję na każdym audycie pre-upgrade: czy w ogóle warto zostać na Magento? Bo upgrade za 60 tys. zł nie ma sensu, jeśli sklep i tak za rok przejdzie na Shopware. Decyzja nie jest oczywista i nie da się jej wziąć z liczby SKU.

Praktyczna reguła, której używam: zostań na Magento, jeśli sklep działa stabilnie (a stabilność to brak akumulacji architektonicznego długu, nie brak alertów Sentry), masz mniej niż 30 custom modułów i większość z nich to zmiany kosmetyczne lub drobne integracje, zespół ma realne kompetencje Magento i nie planuje zmiany stacku, a inwestycja w obecny sklep jest do trzech-czterech lat. Wszystkie cztery warunki, nie dwa z czterech.

Migruj na inną platformę, jeśli sklep ma ponad 50 custom modułów albo widoczne customizacje rdzenia ("nadpisaliśmy w Customerze metodę X"), wydajność jest fundamentalnie zła i nie wynika z błędnej konfiguracji tylko z architektury, zespół tak czy tak idzie w stronę innego stacku albo biznes już zdecydował o redesign plus rebranding, a upgrade byłby trzeci dochodzony w ostatnich pięciu latach.

Liczbowo dla typowego sklepu B2B z 30 tys. SKU i 20 modułami: upgrade kosztuje 2-3 razy mniej niż migracja na nową platformę i daje porównywalny efekt techniczny (PHP 8, Elasticsearch, MySQL 8). Dla 80 tys. SKU z 60 modułami koszty się zrównują, bo upgrade staje się de facto przepisaniem 30 modułów, i wtedy lepiej zainwestować w platformę, która lepiej spina B2B z pudełka.

Magento / Adobe Commerce dla B2B - jeśli decydujesz się zostać.

Audyt kompatybilności modułów

Audyt zaczynam od inwentarza. Komenda jest banalna:

bin/magento module:status
composer show --installed | grep magento

Wynik dzielę na cztery kategorie i każdej przypisuję inną decyzję. Pierwsza - moduł ma wersję 2.4.7 w composerze, kompatybilność z PHP 8.2 zadeklarowana. Większość komercyjnych modułów Amasty, Mageworx, Mirasvit jest tam, gdzie powinna być - update przez composer plus regresja jako test. Druga - moduł porzucony przez autora, czyli ostatni release sprzed lat, GitHub bez nowych commitów. Tutaj decyzja jest binarna: znajdź zastępcę albo przepisz funkcjonalność jako własny moduł. Większość prostych modułów (dodanie pola do kartoteki, custom block w PLP) szybciej przepisać niż szukać zastępcy.

Trzecia - moduł ma wersję 2.4, ale wymaga zakupu nowej licencji. To typowe dla Amasty i Aheadworks, którzy traktują 2.3 → 2.4 jak nową generację. Zaplanuj budżet, bo to nie 10-15% upgrade'u tylko często pełna cena modułu od zera. Czwarta i najgorsza - moduł zmienił API i nie jest kompatybilny z resztą sklepu. Tutaj musisz przepisać warstwę, która z niego korzystała, i czasem łatwiej w ogóle wymienić moduł na coś prostszego.

Dla 30 modułów audyt z decyzjami zajmuje 2-3 dni intensywnej pracy. Brzmi dużo, ale bez tego upgrade zamienia się w trzymiesięczny debug, w którym co tydzień znajdujesz nowy moduł, który się nie buduje na 8.2.

Testy na staging

Staging dla upgrade'u to nie świeży klon repo. To klon produkcji z aktualnym dumpem bazy, podpiętym pod testowe instancje ERP i PIM. Bez tego testy nie pokrywają realnego ryzyka, bo największe problemy widać przy realnych danych - kontrahent ze 2 tys. historycznych zamówień, produkt z 80 atrybutami w PIM, kategoria z 12 tys. produktów.

Co konkretnie testuję:

Funkcjonalnie pełen przebieg zamówienia dla każdego typu klienta osobno - B2B z cennikiem indywidualnym, B2C, gość niezalogowany. Quick order CSV jeśli używany. PunchOut jeśli zintegrowany. Synchronizacja z ERP w obie strony - zamówienie tam, zmiana statusu z powrotem. Płatności online (Stripe, PayU, Tpay) plus offline (przelew terminowy B2B). Wyszukiwarka z zapytaniami, które realnie generują problemy - długie ciągi, polskie znaki, częściowe SKU.

Wydajnościowo Lighthouse na czterech typach stron (PDP, PLP, koszyk, checkout) z porównaniem do produkcji. Load test w k6 na 100 wirtualnych użytkowników jednocześnie, scenariusz "kliknij kategorię, przejrzyj listę, dodaj do koszyka, zacznij checkout". Czas reindeksowania pełnego katalogu - czy mieści się w oknie nocnym 4-7 rano.

Regresji wizualnej snapshoty Percy lub Chromatic na 20-30 reprezentatywnych stronach, ze szczególnym naciskiem na motyw. Jeśli sklep jest na Hyvä, sprawdź template'y - upgrade Magento bywa skorelowany z wymianą wersji Hyvä, co potrafi przesunąć layout o kilkanaście pikseli.

Integracji - po jednym pełnym teście E2E na każdą integrację zewnętrzną. ERP, PIM, OMS, kurier, brama płatności. Pełen test, nie smoke - bo smoke pokaże "działa", a E2E pokaże "działa też dla zamówień z 20 pozycjami i podzielonej wysyłki".

SEO podczas migracji - strukturę URL-i sprawdź przed cutoverem, nie po.

Upgrade silnika i bazy

Sama sekwencja komend nie jest specjalnie skomplikowana, ale kolejność ma znaczenie i nie można jej dziedziczyć z notatek z poprzedniego upgrade'u, bo zmienia się między wersjami.

Dla skoku 2.3.x na 2.4.7 robię tak:

mysqldump --single-transaction sklep > backup_pre_upgrade.sql

bin/magento maintenance:enable

composer require magento/product-community-edition=2.4.7-p3 --no-update
composer update

bin/magento setup:upgrade

bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f pl_PL en_US

bin/magento indexer:reindex

bin/magento cache:flush

bin/magento maintenance:disable

Cztery pułapki, które potrafią zatrzymać upgrade w pół drogi, są specyficzne dla B2B. Pierwsza to Elasticsearch. Magento 2.4 wymaga Elasticsearch 7.x lub OpenSearch 2.x. Jeśli sklep stał na 2.3 z domyślnym MySQL search (bo nikt nie zainstalował Elastica), to teraz jest osobna migracja indeksu plus konfiguracja klastra Elastica plus testy wyszukiwarki. Druga to MySQL 8. Rekomendowana wersja dla 2.4.7. Migracja z 5.7 wymaga przebudowy indeksów ze względu na zmianę domyślnego collation (utf8mb4 zamiast utf8). Trzecia to PHP 8.2. Wszystkie custom moduły muszą przejść kompatybilność - typy zwracane, deklaracje, brak each(), brak nullable bez ?. Czwarta to Composer 2.x z bezpieczeństwem pluginów. Każdy plugin musi być explicit allow'ed w composer.json, inaczej composer update odmawia współpracy.

Custom moduły - aktualizacja deklaracji

Każdy custom moduł napisany dla 2.3 wymaga przeglądu. Lista minimalna, po której idę:

W composer.json modułu wymóg PHP i wersji framework:

{
  "require": {
    "php": "~8.1.0 || ~8.2.0 || ~8.3.0",
    "magento/framework": "103.0.*"
  }
}

W module.xml bump wersji setup, żeby uruchomić patche danych:

<module name="Klient_NazwaModulu" setup_version="2.0.0"/>

Przegląd deprecated API. \Magento\Framework\Model\AbstractModel::load() wciąż działa, ale Adobe rekomenduje SearchCriteriaBuilder - czas zacząć migrować. ObjectManager bezpośrednio w kodzie biznesowym idzie do kosza i przechodzi na constructor injection (formalnie wymagane było już wcześniej, ale w 2.4 weryfikacja jest ścisła). Helper classes używane do widoków migrują na ViewModels.

Migracje skryptów. InstallSchema.php i UpgradeSchema.php przepisuję na db_schema.xml w declarative schema. InstallData.php i UpgradeData.php zamieniam na patch classes w Setup/Patch/Data/. To zwykle praca, której nie chce się robić, ale Magento 2.4.x odmawia uruchomienia starych migracji w niektórych ścieżkach, więc nie ma wyjścia.

Moduł napisany dobrze dla 2.3 wymaga 1-3 dni adaptacji. Moduł napisany "na szybko" z bezpośrednimi wywołaniami ObjectManagera i hardkodowanymi ścieżkami - tydzień lub więcej. Jeśli masz 30 modułów po średnio 2 dni, to 60 dni roboczych dla jednego seniora - czyli trzy miesiące w realnym kalendarzu. To dobry powód, żeby modułów było mało, a nie dużo.

Cutover - downtime czy zero-downtime

Cutover to nie miejsce na ambicje. Większość sklepów B2B nie potrzebuje zero-downtime - klienci kontraktowi nie składają zamówień w sobotnie noce, a okno techniczne 23:00-03:00 jest akceptowalne biznesowo.

Najprostszy wariant to maintenance window 2-4 godziny. Sklep wchodzi w maintenance mode, composer update, setup:upgrade, smoke testy, koniec maintenance. Niska komplikacja, niskie ryzyko desynchronizacji bazy z plikami. Klienci nie składają zamówień przez kilka godzin, ale jeśli okno jest w nocy i komunikujesz to z tygodniowym wyprzedzeniem, nikt nie traci snu.

Blue-green daje zero-downtime kosztem podwojonej infrastruktury i dodatkowej komplikacji sesji. Środowisko Blue żyje, Green dostaje upgrade, smoke testy, przełączenie load balancera. Sesje albo migrujesz (Redis współdzielony między środowiskami), albo akceptujesz, że klienci aktywnie zalogowani się rozłączą. Sensowne dla sklepów z ruchem 24/7 - większości polskich B2B się nie opłaca.

Najbardziej zaawansowany wariant to blue-green z rolling upgrade bazy - migracje wstecznie kompatybilne, baza może być używana przez obie wersje jednocześnie. Adobe Commerce z native cloudem to wspiera, samodzielnie postawione Magento - praktycznie nie. Pomijam na wdrożeniach mniejszych niż enterprise.

Dla typowego sklepu B2B 30 tys. SKU rekomenduję pierwszy wariant z oknem sobota 23:00-03:00. Ryzyko niskie, koszt niski, klient w niedzielę rano widzi nową wersję i nie wie, że coś się stało. Jeśli coś idzie nie tak - rollback z backupu w godzinę.

Plan cutover migracji - operacyjne szczegóły dla różnych typów migracji.

FAQ

Ile trwa upgrade Magento 2.3 na 2.4.7 dla średniego sklepu? Średni sklep B2B z 30 tys. SKU, 20 modułami i podstawowymi integracjami: 4-6 tygodni od decyzji do produkcji, włącznie z audytem, testami i cutoverem. Duży sklep z 80 tys. SKU, 50 modułami i kilkoma integracjami zewnętrznymi: 2-4 miesiące. Jeśli zespół robi to pierwszy raz, dodaj 30-50% na naukę.

Czy upgrade naprawi problemy z wydajnością? Częściowo. 2.4.x ma lepsze cache'owanie, optymalizacje indeksów i nowszy PHP, więc bazowe metryki idą w górę. Ale jeśli sklep miał fundamentalny problem - brak Varnisha przed sklepem, źle skonfigurowany Redis, niezaindeksowane fasety - upgrade tego nie naprawi. Audyt wydajności przed upgrade'em, nie po.

Co zrobić z modułami które nie mają wersji dla 2.4? Trzy ścieżki. Pierwsza i najczęstsza - znaleźć zastępcę, bo dla większości popularnych modułów istnieje aktualizowany odpowiednik. Druga - przepisać funkcjonalność jako własny moduł, zwykle szybsza niż walka z porzuconym kodem. Trzecia - usunąć i zobaczyć, czy biznes czuje brak. Co najmniej 20% modułów na każdym audycie okazuje się nieużywane przez nikogo od dwóch lat.

Czy mogę skoczyć z 2.3 prosto na 2.4.7, bez wersji pośrednich? Tak, Magento wspiera skok przez kilka wersji minor. Composer ogarnie zależności. Jedyne, co warto sprawdzić, to porządek migracji declarative schema, jeśli kiedykolwiek były ręczne ingerencje w bazę. W praktyce robię to tak prawie zawsze i nie pamiętam, żeby krok pośredni był koniecznością.

Czy upgrade wymaga zatrudnienia Adobe partnera? Nie dla Magento Open Source. Samodzielny upgrade jest pełnoprawną ścieżką. Adobe partner ma sens dla Adobe Commerce z certyfikacją PCI, sklepów wpisanych w SLA Adobe lub sytuacji, w której zespół wewnętrzny po prostu nie ma kompetencji. Wynagrodzenie partnera to typowo 30-50% wyższy budżet niż własny zespół - z drugiej strony partner przejmuje ryzyko niedotrzymania terminu.

Co dalej

• Migracje platform e-commerce: Migracje e-commerce
• Plan cutover w praktyce: Plan cutover migracji sklepu
• SEO podczas zmiany platformy: SEO podczas migracji