Absolutna podstawa

Podstawą, bez której nie warto zaczynać, jest upewnienie się, że serwer docelowy spełnia wymagania Magento 2 (ilość pamięci, wersje PHP, bazy danych, dostęp do ElasticSearch wymagany od wersji 2.4.0). Musimy mieć 100-procentową pewność, że Magento 2 ruszy bez problemu. Możemy oczywiście używać M2 na słabszej konfiguracji, niż ta przedstawiona w oficjalnych wymaganiach, jednak Data Migration Tool nie będzie już taki pobłażliwy w trakcie obróbki gigabajtów danych.

W razie pracy dla klienta musimy pamiętać, by zabezpieczyć się w umowie przed ewentualnymi problemami spowodowanymi przez modyfikacje Magento 1 dokonane w czasie, gdy my będziemy pracować nad migracją. Innymi słowy – należy jasno przedstawić, że wszelkie manipulacje w kodzie lub bazie danych (oczywiście poza normalnym użytkowaniem), takie jak instalowanie/usuwanie modułów, modyfikacje struktury bazy danych, podpinanie kolejnych zewnętrznych skryptów, czy integracji mogą spowodować konieczność rozpoczynania procesu od zera.

Plusy migracji

Wiemy, że wsparcie dla Magento 1 zakończyło się dawno temu, a migracja do Magento 2 pozwoli nam dalej cieszyć się łatkami bezpieczeństwa, nowymi funkcjonalnościami, poprawkami błędów, nowymi modułami czy templatkami. Jednak proces migracji to także doskonała okazja na porządki, zmiany i ulepszenia. Niezależnie od tego, czy przenosisz swój własny sklep, czy wykonujesz projekt dla klienta, warto poświęcić trochę czasu na sporządzenie listy wszystkich funkcjonalności obecnego sklepu i porównanie jej z tym, co oferuje Magento 2 „out of the box”, a następnie wybranie elementów, które muszą znaleźć się na nowej platformie oraz tych, które możemy porzucić lub zastąpić nowszym, optymalnym rozwiązaniem. Nie ma sensu przenosić modułów, które w ostatecznym rozrachunku nie mają żadnego wkładu w proces biznesowy. Przy porządkach warto przemyśleć również kwestię wyglądu sklepu. Przeniesienie szablonu z Magento 1 na Magento 2 zajmie Ci tyle samo czasu co stworzenie nowego szablonu. To z kolei daje wspaniałe możliwości odświeżenia i unowocześnienia oprawy graficznej, w celu dostosowania jej do obecnie panujących trendów, uwzględniając przykładowo dane na temat zachowań użytkowników zebrane przez Google Analytics (dzięki czemu możemy dostosować nową szatę graficzną pod konkretnych odbiorców, lepiej wyodrębniając najczęściej wykorzystywane elementy sklepu, czy zmieniając najpopularniejszy flow na bardziej intuicyjny i łatwy w obsłudze). Są to kwestie, które trzeba poruszyć z klientem, jednocześnie prezentując alternatywy i nowe pomysły.

Data Migration Tool – ładnie go poproś, to zrobi wszystko

Podstawowym narzędziem do migracji jest oczywiście oficjalny Data Migration Tool – narzędzie to pozwala przenosić dane z różnych wersji Magento 1 do Magento 2. Dzięki temu nie jesteśmy skazani na pracę tylko na najnowszych wersjach – najstarsza wspierana przez Data Migration Tool wersja Magento to 1.6.0.0. Daje to pole do popisu i nie wymusza na nas dodatkowych zabiegów w postaci aktualizacji, która może przynieść więcej szkód niż korzyści.

Data Migration Tool jest bardzo elastyczny i posiada ogromne możliwości konfiguracji. Warto dokładnie zapoznać się z jego dokumentacją, by zaoszczędzić sobie problemów ze strukturą tabel, czy chociażby mieć spokój z ręcznym przenoszeniem danych. Migration Tool przeniesie wszystko, czego potrzebujemy, trzeba mu tylko „wytłumaczyć”, jak ma to zrobić :)

Niektórzy skupiają się wyłącznie na podstawowym mapowaniu w pliku map.xml, nie wykorzystując (a może nawet nie wiedząc) o bardziej zaawansowanych funkcjach – w końcu jak coś się nie przeniesie, to przerzucimy ręcznie, prawda? :) Owszem, ta metoda może zadziałać, jednak jest nieefektywna, bardzo podatna na błędy i zostawia nas w ślepym zaułku, kiedy nadchodzi czas na migrację delty.

Jeśli zajrzymy do pliku config.xml, znajdziemy tam listę wszystkich kroków migracji danych, podzielonych na 3 sekcje: settings, data i delta. Jak nietrudno się domyślić, każda z sekcji odpowiada oddzielnemu procesowi migracji. Tutaj też możemy dodawać własne kroki, dzięki czemu mamy dużo większe możliwości w kwestii manipulacji struktury bazy danych i samych danych, niż w przypadku korzystania z samego map.xml. Przy odrobinie wprawy nie będzie stanowiło dla nas problemu przeniesienie tabeli ze starego modułu do Magento 2, gdzie nowy moduł dzieli informacje na kilka tabel, jednocześnie zmieniając typy danych.

Sposobów, w jaki możemy przenieść naszą bazę, jest naprawdę sporo, dlatego też zalecam dokładne zapoznanie się z dokumentacją Data Migration Tool – te kilka godzin czytania zaoszczędzi setki godzin ręcznego przenoszenia danych i naprawiania błędów.

Need backup!

Jak w każdym innym wypadku, tak i tutaj przed przystąpieniem do pracy wypada pamiętać o kopii zapasowej – a nawet dwóch kopiach! Jedna, na której odbywa się cała praca związana z konfiguracją Data Migration Tool, poprawkami w bazie danych, testowaniem migracji itp. oraz druga – która służy do przywracania oryginalnego stanu, kiedy coś nie pójdzie po naszej myśli. Wystarczy kilka kliknięć, czy komend w wierszu poleceń i wracamy do punktu wyjścia (jest to po prostu łatwiejsze, niż pobieranie wszystkiego od nowa z serwera).

Sprawdź bazę danych

Jedną z pierwszych rzeczy, które powinniśmy zrobić przed przystąpieniem do migracji, jest dokładnie sprawdzenie bazy danych Magento 1. Niezależnie, czy sklep działa bez zarzutów od lat, czy też ostatnio poprawiliśmy wszystkie zgłaszane błędy, ten krok jest konieczny, aby migracja zakończyła się sukcesem, a jej efekty nie przyniosły z czasem lawiny problemów. Nigdy nie mamy pewności, czy wszystkie dane są spójne lub, czy ktoś nie wpadł w jakimś skrypcie na genialny pomysł rozwiązania „Integrity constraint violation” za pomocą „SET foreign_key_checks = 0”, ewentualnie że nie natkniemy się na inne cuda. Tego typu niewielkie błędy (z którymi Magento 1 działa bez problemu) mogą być katastrofalne w Magento 2 – począwszy od problemów z edycją niektórych produktów, przez brakujące elementy zamówień (adresy, produkty), problemy z checkoutem, logowaniem klientów, aż po całkowity brak produktów w sklepie (niedziałające indexery) i permanentny „out of stock”. Przydatnym narzędziem może być tutaj n98-magerun z dodatkiem EAV Cleaner. Nie rozwiąże to oczywiście wszystkich problemów, ale pomoże przynajmniej oczyścić tabele związane z atrybutami. Wszystkie wyłapane błędy powinny zostać również poprawione na obecnej (Magento 1) wersji produkcyjnej – zazwyczaj pozwala to zapobiec ich dalszemu rozprzestrzenianiu się.

Sprawdź core

Poza sprzątaniem bazy danych należy również sprawdzić kod core Magento 1. Podobnie jak w przypadku odchyleń w bazie danych, tak i tutaj nie możemy mieć stuprocentowej pewności, że nikt nie zaaplikował jakichś zmian w kodzie czy nieoficjalnych łatek. Nie zawsze muszą być one groźne dla procesu migracji, jednak nie możemy sobie pozwolić na zaufanie w tej kwestii. Tutaj pomoże zwykły diff i kod z oryginalnej instalacji Magento 1 (oczywiście w wersji, z której dokonujemy migracji):

diff -urbB folder_z_oryginalnym_kodem folder_z_kodem_do_migracji | lsdiff

Ta prosta komenda porówna wszystkie pliki i wylistuje te, które zostały zmienione (pomijając porównywanie spacji czy pustych linii). Proste, skuteczne i szybkie. Jeśli zamiast braku odpowiedzi dostaniemy listę plików, musimy niestety sprawdzić, jakie są to zmiany i upewnić się, że nie wpływają one na strukturę danych Magento.

Porządki i ulepszenia

Rozwińmy nieco poruszoną na początku kwestię porządków i ulepszeń – nie chodzi tu bowiem tylko o ewentualne usunięcie modułów, czy znalezienie ich nowych wersji napisanych dla Magento 2. Przede wszystkim powinniśmy spojrzeć na każdy moduł pod kątem procesów biznesowych – czy dany moduł wpływa pozytywnie na te procesy, a może negatywnie lub zupełnie neutralnie? Kilkukrotnie spotkałem się z klientem, który w panelu administracyjnym chciał mieć masę zaawansowanych, obciążających serwer wykresów, jednak nie dlatego że były mu potrzebne, ale dlatego, że „fajnie” i „profesjonalnie” wyglądały (co ciekawe, panel administracyjny nie był prawie w ogóle używany - dane o produktach i zamówieniach były synchronizowane z zewnętrznymi aplikacjami). Innymi słowy – to, że jakiś moduł jest zainstalowany i potencjalnie w jakiś sposób użyty (jak wyświetlanie wykresów), nie znaczy, że faktycznie ma jakieś praktyczne zastosowanie. Nieraz może to być tylko ozdobnik albo czyjeś „widzimisię”, które dzięki migracji mamy okazję po prostu wyrzucić do kosza. Pytajmy nie tylko o to, czy dany moduł jest używany, ale również w jakim celu, jakie ma zastosowanie w tym konkretnym przypadku – po chwili okaże się, że część jest zainstalowana w sumie bez większej potrzeby (ewentualnie w celu zapoznania się z modułem, który ostatecznie się nie przyjął, ale nikt go później nie odinstalował).

Druga sprawa – nawet jeśli moduły posiadają swoje wersje dla Magento 2, na rynku mogła pojawić się już cała masa lepszych zamienników. Warto się im przyjrzeć, wszak poprawnie skonfigurowanym Data Migration Tool bez większych problemów przekonwertujemy dane na nowy format, a zysk (stabilność, wydajność, dodatkowe funkcjonalności) może być ogromny.

Podobnie do modułów powinniśmy podejść do wszystkich zewnętrznych skryptów, które w jakiś sposób modyfikują lub wykorzystują dane z Magento. Część z nich jest prawdopodobnie użyteczna, jednak zawsze może się znaleźć taki, który nie jest już do niczego konkretnego wykorzystany – i tak działa sobie w tle, pochłania zasoby, być może sieje chaos w bazie danych, którą dopiero co naprawiliśmy pod kątem sprawnej migracji. Warto spróbować przerobić zewnętrzne skrypty na moduły dla Magento 2, z zachowaniem zasad i dobrych praktyk związanych z tworzeniem dodatków dla naszej platformy. W ten sposób skrypt będzie zachowywał się tak, jak M2 tego oczekuje, a my zyskamy możliwość lepszej integracji, szereg wbudowanych zabezpieczeń i funkcjonalności (jak chociażby ładna strona konfiguracji, zamiast klepania takowej bezpośrednio w kodzie), nie będziemy musieli martwić się o zmianę haseł do bazy danych w kilku miejscach i skonfigurujemy ACL. Nic nie stoi na przeszkodzie, by wiele mniejszych skryptów zamknąć w jednym module, w końcu możemy skonfigurować kilka cron jobów w razie potrzeby. Skrypty wywoływane przez zapytania HTTP możemy zastąpić nowymi endpointami API, zyskując dodatkowe zabezpieczenia oraz możliwość konfiguracji dostępu (w tym jego szybkiego zablokowania w razie potrzeby). Praktycznie wszystko, na co trafimy powinniśmy przerobić na dodatkowe moduły, jeśli oczywiście sytuacja na to pozwala.

I jeszcze jeden backup

Wspomniałem już o tym na początku, jednak w tym przypadku „za dużo” nie znaczy „nie zdrowo”. Nigdy nie zapominaj o kopii zapasowej – wszelkie próby migracji powinny być najpierw wykonane na kopii, celem upewnienia się, że wszystko działa prawidłowo. Nie chodzi tu tylko o „zielone światło” od migratora, ale również o dokładne sprawdzenie, czy w Magento 2 każdy element wygląda i funkcjonuje, jak należy. Testowania będzie sporo – od struktury danych, przez crona i konfigurację, aż po wszystkie funkcjonalności dostępne dla użytkowników i administratorów.

Dry run

Kiedy wszystko już działa, jak należy, możemy w końcu przeprowadzić dry-run, używając produkcyjnej bazy danych. Można zapytać – skoro wszystko działa, to po co komu ten dry run? A więc - kiedy pracowaliśmy nad migracją na naszych kopiach, w międzyczasie sporo mogło się zmienić w bazie na produkcji. Mimo usunięcia z bazy śmieci i naprawienia relacji między obiektami, jakiś moduł mógł znów coś zepsuć, mogły zmienić się dane części produktów i kategorii, a sam klient bez konsultacji z nami mógł pozmieniać coś w konfiguracji lub dorzucić na szybko jakieś dodatki. Załóżmy jednak, że łatwo uporaliśmy się z potencjalnymi problemami, lub błędy w ogóle się nie pojawiły – wtedy możemy wreszcie wykonać migrację produkcyjnej bazy danych.

Media, linki, ACL

Pamiętaj, że nie wszystko zostanie przeniesione automatycznie – część danych należy dodać do Magento 2 manualnie, a są to:

• folder media,
• konta administratorów,
• ustawienia ACL.

Media wystarczy skopiować do pub/media – po tym wszystko powinno działać tak, jak należy. Administratorów możemy dodać przez panel administratora w Magento 2 lub używając linii poleceń. Ustawienia ACL musimy przenieść ręcznie, jednak nie powinno to zająć zbyt wiele czasu.

Jeśli wszystko poszło dobrze, możemy zabrać się za migrację delty. Ta powinna być uruchamiana często, żeby nie było potrzeby przenoszenia zbyt dużej ilości danych naraz – dzięki temu w razie ewentualnych problemów, czy błędów, dużo łatwiej i szybciej je namierzymy. Delta Migration możemy ustawić jako cronjob, najlepiej z wysyłaniem powiadomień po zakończonym przebiegu.

Jeszcze przed sfinalizowaniem migracji, koniecznie sprawdzamy, czy struktura linków w Magento 2 jest zgodna ze strukturą z Magento 1. Najłatwiej to zrobić, eksportując sitemapy z obu platform i porównując je ze sobą. W razie konieczności dodajemy w Magento 2 wymagane przekierowania.

I w końcu migracja!

Migrację powinniśmy sfinalizować najlepiej w godzinach najmniejszej aktywności na serwerze – im mniej użytkowników odczuje ewentualne niedogodności, tym lepiej. Powinniśmy zacząć od przełączenia Magento 1 w „maintenance mode”. Dzięki temu będziemy mieli pewność, że w trakcie migracji nikt nie złoży nowego zamówienia, które mogłoby się nie przenieść. Następnie należy wyłączyć wszelkie cronjoby związane z Magento 1 – nie tylko te typowo „magentowe”, ale także wszystkich zewnętrznych skryptów, które w jakiś sposób współdziałają z Magento. Czekamy chwilę, aby już uruchomione cronjoby zakończyły swoje zadania (wystarczy sprawdzić, czy dane skrypty wciąż znajdują się na liście procesów). Kiedy wszystkie skrypty zakończyły swoją pracę, uruchamiany finalną Delta Migration, aby mieć w pełni zsynchronizowaną bazę danych w Magento 2. Stąd droga jest już bardzo prosta – dodajemy cronjoby Magento 2 do crontaba, czyścimy cache i uruchamiamy pełną reindeksację. Następnie zmieniamy ustawienia m.in. DNS i load balancerów, by wskazywały na serwer z Magento 2.

W tym momencie nasza migracja powinna być już gotowa do użytku. Na wszelki wypadek warto jeszcze sprawdzić podstawowe funkcjonalności, aby mieć pewność, że klienci będą mogli spokojnie przejść przez pełną ścieżkę od wejścia na stronę główną sklepu, aż po stronę z podziękowaniem za złożenie zamówienia. Upewnij się także, że wszystkie integracje funkcjonują prawidłowo, w tym wszelkiej maści trackery jak Google Analytics, FB Pixel i tym podobne.

Jak widać, migracja nie zawsze jest prostym procesem i może sprawić wiele problemów, dlatego powinniśmy poświęcić odpowiednią ilość czasu na analizę danego przypadku – im więcej wiemy, tym więcej możemy zdziałać i uchronić się przed potencjalnymi problemami. Rozmowy z klientem na temat tego, co powinno się znaleźć na nowej platformie, są konieczne. Musimy przedstawić alternatywne rozwiązania, nowe pomysły oraz odpowiednio wszystko wytłumaczyć i uargumentować (pamiętaj, że klient prawdopodobnie jest osobą „nietechniczną” – dlatego twoim obowiązkiem jest wytłumaczenie mu wszystkiego i rozwianie wątpliwości). Należy wykorzystać tę szansę i usprawnić docelowy produkt (sklep na Magento 2) do granic możliwości – w końcu... to nasza praca :)