Migracja do Adobe Commerce z Magento Open Source: odbiór i przenośność

Sklep został przeniesiony, katalog się otwiera, ale dealer widzi cenę detaliczną, a ponowione żądanie tworzy dodatkowe zamówienie w systemie ewidencyjnym. Właśnie dlatego migracja do Adobe Commerce z Magento Open Source powinna kończyć się nie prezentacją nowej chmury, lecz sprawdzeniem operacji handlowych. Przed rozpoczęciem prac ustalcie, kto potwierdzi poprawność cen, płatności, stanów magazynowych i historii zakupów oraz w jaki sposób firma otrzyma swoje dane i kod na potrzeby kolejnej migracji.

Potrzebne są dokładna nazwa produktu docelowego, scenariusze odbioru biznesowego i próba przełączenia. Ranking agencji nie zastąpi żadnego z tych dokumentów.

Najpierw ustalcie, którą dokładnie chmurę odbieracie

Nazwa Adobe Commerce Cloud nie jest wystarczająco precyzyjna. Adobe Commerce on cloud infrastructure to platforma jako usługa (PaaS), a Adobe Commerce as a Cloud Service — oprogramowanie jako usługa (SaaS). Tutaj omawiamy przejście Magento Open Source → Adobe Commerce on cloud infrastructure. SaaS wymaga innego planu.

W oficjalnym porównaniu modeli Adobe dla PaaS opisano współdzieloną odpowiedzialność: Adobe zarządza platformą hostingową, a sprzedawca odpowiada za poprawki aplikacyjne, własny kod, konfigurację i wspierane zależności. W SaaS Adobe zarządza rdzeniem i jego aktualizacjami; kodu rdzenia nie można zmieniać, a rozszerzenia tworzy się za pomocą wspieranych interfejsów i usług. Nie należy więc automatycznie zakładać, że dotychczasowy moduł PHP nadaje się do obu modeli.

Zapiszcie produkt, model, właściwe wersje i zakupione możliwości: licencje i rozszerzenia B2B należy potwierdzić osobno. Jeśli potrzebny jest tylko bardziej niezawodny hosting, oceńcie możliwość usprawnienia obecnego Magento Open Source.

Zamieńcie obietnicę „wszystko działa” w kryteria odbioru biznesowego

Kryteria odbioru biznesowego opisują oczekiwany wynik językiem operacji. Dla każdego krytycznego działania określcie dane wejściowe, kroki, oczekiwany stan w sklepie i systemie powiązanym, osobę odpowiedzialną oraz dowód. Nagranie udanego składania zamówienia nie wystarczy, jeśli nie pokazuje, co otrzymały serwis płatniczy, księgowość i magazyn.

Sprawdzajcie reguły, nie tylko strony

W katalogu ważne są powiązania między wariantami produktu, jednostkami sprzedaży i grupami klientów. W cenie — waluta, podatek, zaokrąglenie, rabat i indywidualny warunek. W zamówieniu — jego zawartość, kwota, płatność, rezerwacja i status realizacji. Do każdego scenariusza pozytywnego dodajcie przypadek niepowodzenia: niedostępny produkt, wygasłą ofertę, błąd płatności lub niedostępność systemu ewidencyjnego.

Podzielcie defekty według skutków. Nieprawidłowa pobrana kwota, indywidualna cena innego klienta lub duplikat zamówienia muszą wstrzymywać uruchomienie. Niekrytyczny błąd wizualny można przenieść na uzgodnioną listę poprawek, o ile nie blokuje zakupu. Taki podział należy przyjąć przed testami, a nie ostatniego wieczoru przed przełączeniem.

Wyznaczcie osobę odpowiedzialną za każde potwierdzenie

Dział sprzedaży sprawdza reguły handlowe, zespół finansowy — kwoty i zwroty, a magazyn — rezerwacje i wysyłki. Zespół techniczny potwierdza odtworzenie i usunięcie awarii. W protokole potrzebne są wyniki i nierozwiązane ograniczenia, a nie zbiorowe „brak uwag”.

Rozdzielcie przenoszenie danych, zmianę edycji i zgodność modułów

Sporządźcie rejestr modułów: jakie działanie biznesowe obsługuje każdy z nich, gdzie przechowuje dane, czy ma wsparcie i co się stanie po jego wyłączeniu. Szczególnie dokładnie sprawdźcie ceny, proces zakupowy, dostawę i wymianę danych z ERP — systemem planowania i ewidencji zasobów przedsiębiorstwa.

Uzgadnianie danych nie ogranicza się do łącznej liczby rekordów. Taka sama liczba produktów nie dowodzi, że zachowały się ich warianty, atrybuty i przypisane zdjęcia. Osobno sprawdźcie grupy klientów, adresy, historyczne zamówienia, dokumenty zwrotów i wewnętrzne identyfikatory integracji. Dla danych, których nie przenosicie, uzgodnijcie sposób wyszukiwania w archiwum i osobę odpowiedzialną za dostęp.

Zalecenia Adobe dotyczące aktualizacji przewidują sprawdzenie motywów, rozszerzeń, zależności i odbiór przez użytkowników. Automatyczna analiza zgodności nie sprawdza ustaleń z dealerami: potrzebne są konkretne zamówienia testowe.

Nie dodawajcie opcjonalnego przeprojektowania wyglądu ani wymiany systemu ewidencyjnego: utrudni to szukanie przyczyn awarii. Wspólne zależności uwzględnijcie w planie przygotowania infrastruktury do migracji do chmury.

Przykład hipotetyczny: potwierdzenie zamówienia zaginęło między sklepem a ERP

Rozważmy hipotetyczny sklep z częściami zamiennymi i indywidualnymi cenami dla dealerów. Kupujący zamawia dwa opakowania produktu, a system ewidencyjny rozlicza go w sztukach. Integracja przekazuje uzgodnioną ilość, ERP tworzy zamówienie, ale odpowiedź nie dociera do sklepu. To scenariusz szkoleniowy na potrzeby odbioru, a nie opis klienta ani rezultatu GL.ua.

Proste ponowienie żądania może utworzyć drugi dokument. Uzgodniony wynik jest inny: integracja korzysta ze stałego identyfikatora operacji, ustala stan pierwszego żądania i łączy witrynę z już utworzonym dokumentem. Takie działanie nie wynika z samego przeniesienia do chmury: trzeba je wdrożyć lub potwierdzić w obecnej wymianie danych. Jeśli ERP nie obsługuje wymaganej kontroli, zespół musi uzgodnić inny mechanizm ochrony przed duplikatami.

W teście zapiszcie identyfikator zamówienia, cenę dealerską, przeliczenie opakowań na sztuki i stan rezerwacji. Celowo przerwijcie odpowiedź i powtórzcie działanie. Odbiór jest zaliczony, gdy nie ma dodatkowego dokumentu ani rezerwacji, kwoty się zgadzają, kupujący otrzymał zrozumiały status, a osoba obsługująca zamówienie widzi, jak wznowić przetwarzanie. Sprawdźcie również anulowanie: nie może pozostawiać ukrytego zobowiązania magazynowego.

Sprawdźcie też spóźnione powiadomienie o płatności: kto i na podstawie jakiego potwierdzenia zmienia stan zamówienia. Strona „Dziękujemy” nie dowodzi zakończenia całego łańcucha.

Przeprowadźcie próbę przełączenia z określonymi warunkami zatrzymania

Próba sprawdza kolejność i czas trwania prac na waszych danych. Instrukcja Adobe dotycząca wdrażania w Staging i Production przewiduje testy przedprodukcyjne. Środowisko testowe nie może pobierać prawdziwych pieniędzy ani wysyłać klientom wiadomości szkoleniowych.

1. Zapiszcie stan źródła: wersję kodu, konfigurację, kontrolny zestaw rekordów i listę aktywnych wymian danych.
2. Wykonajcie próbne przeniesienie i sprawdźcie nie tylko rekordy, ale też pełny przebieg zamówienia, niepowodzenie, zwrot i ponowione żądanie.
3. Sprawdźcie końcową aktualizację danych: jakie zmiany nagromadziły się po próbnym imporcie i jak trafią do systemu docelowego.
4. Uzgodnijcie moment zatrzymania zapisów i przełączenia integracji, aby stary i nowy sklep nie przyjmowały jednocześnie niezgodnych zmian.
5. Odtwórzcie krytyczną awarię i decyzję o wycofaniu przełączenia: kto ją podejmuje, co jest przywracane i jak uzgadniane są nowe transakcje.
6. Po testowym otwarciu sprawdźcie zakupy kontrolne, dzienniki wymiany danych, zadania w tle i osoby odpowiedzialne za dyżur.

Na potrzeby wycofania przełączenia określcie moment graniczny, po którym samo przywrócenie starej bazy już nie wystarczy. Jeśli nowy sklep zdążył przyjąć płatność, odtworzenie starej kopii samo w sobie jej nie anuluje. Potrzebna jest procedura uzgadniania takich operacji. To jeden z powodów, by bez próby nie akceptować obietnicy „cofniemy jednym przyciskiem”.

Osobna kontrola SEO obejmuje adresy, przekierowania, canonical i indeksowanie. W planie migracji witryny z zachowaniem SEO znajduje się szersza lista; wyznaczcie osobę odpowiedzialną za jej sprawdzenie.

Udowodnijcie przenośność przez odtworzenie, nie przekazanie archiwum

Przenośność sklepu internetowego to możliwość odtworzenia wymaganych danych i działania w innym uzgodnionym środowisku, z uwzględnieniem licencji. Nie oznacza to, że licencjonowane funkcje Adobe Commerce można bezpłatnie uruchomić w Magento Open Source lub innym CMS. Jeśli firma planuje odejście z platformy, każda taka funkcja wymaga zamiennika lub osobnego rozwiązania.

W pakiecie przekazania uwzględnijcie repozytorium z historią zmian, listę zależności i praw do użytkowania, konfigurację wdrożenia, opis integracji, schemat własnych tabel i procedurę eksportu danych. Dane dostępowe przekazuje się uzgodnionym bezpiecznym kanałem, a nie zapisuje w dokumentacji. Właściciel firmy powinien kontrolować konta organizacji, domenę i prawo do wyznaczenia innego wykonawcy.

Zgodnie z dokumentacją Adobe dotyczącą kopii zapasowych snapshot nie zawiera kodu, a jego kopii nie można pobrać. Nie jest to gotowy pakiet na potrzeby odejścia z platformy. Osobno sprawdźcie eksport bazy danych, plików multimedialnych i kodu oraz ich odtworzenie zgodnie z waszym planem i typem środowiska.

Niech inny upoważniony specjalista, bez podpowiedzi autora, odtworzy środowisko testowe i znajdzie wymagane zamówienie. Błędy ujawnione w tym ćwiczeniu staną się konkretnymi punktami do wykonania przy przekazaniu.

Terminy i budżet szacujcie na podstawie nierozpoznanych zależności

Czas trwania zależy od dostępności kodu źródłowego, stanu modułów, ilości i jakości danych, złożoności integracji oraz udziału zespołów biznesowych w testach. Osobno zaplanujcie analizę, dostosowanie, próbne przeniesienie, poprawki, kolejną próbę i uruchomienie. Datę przełączenia doprecyzowuje się po zmierzonej próbie, a nie tylko na podstawie liczby produktów w katalogu.

W kosztach rozdzielcie licencje i usługi chmurowe, audyt i projektowanie, dostosowanie modułów, czyszczenie i przenoszenie danych, integracje, kontrolę SEO, środowiska testowe, odbiór biznesowy, uruchomienie i wsparcie. Osobnymi pozycjami powinny być okres równoległej pracy oraz przygotowanie pakietu na potrzeby odejścia z platformy. Dzięki temu widać, które koszty znikną po uruchomieniu, a które staną się stałym wydatkiem.

Nie płaćcie za przenoszenie niepotrzebnych funkcji. Jeśli zalety docelowej edycji nie wiążą się z potrzebnym scenariuszem biznesowym, odłóżcie migrację.

Decyzja o uruchomieniu musi opierać się na dowodach

Otwórzcie sklep po zaliczeniu scenariuszy, usunięciu krytycznych defektów i sprawdzeniu pakietu przekazania. Plan odtworzenia musi uwzględniać nowe transakcje. To kontrolowane przejście, a nie gwarancja braku incydentów.

Rozważacie inną architekturę? Przekażcie GL.ua (Глянець) reguły handlowe, integracje i wymagania dotyczące przenośności. W ramach tworzenia witryn i sklepów internetowych na Drupalu omówcie alternatywę i zakres prac przed zawarciem umowy na przeniesienie.