Błąd 1: brak audytu modułów
▶ 00:24Zanim zaczniesz migrację, zajrzyj na zaplecze sklepu i przejrzyj moduły: z czego korzystasz, czego już nie używasz i co wymaga zmiany. Stare, nieużywane wtyczki można odinstalować, bo im starsze, tym bardziej podatne na ataki. Sprawdź też, czy nie płacisz z karty za aktualizacje modułu, którego już nie używasz.
Jeśli sklep jest pod opieką software house'u, zapytaj, co było zmieniane, i spisz mapę funkcji. E-commerce managerowie często zmieniają pracę co 2–3 lata, więc nowa osoba może nie mieć kogo zapytać. Źródłem prawdy będzie wtedy software house. Jerzy poleca taki przegląd także bez migracji, bo model biznesowy się zmienia, a opłaty roczne zostają.
Błąd 2: brak płatnej analizy przedwdrożeniowej
▶ 03:03Niektóre software house'y twierdzą, że analiza nie jest potrzebna. Przy prostym sklepie pudełkowym może to przejść, ale przy sklepie z pięcioletnią historią, integracjami i listą życzeń czekających na nowe środowisko Jerzy radzi wybrać firmę, która przed umową robi płatną analizę. Płatną, bo to praca ludzi.
Dobry dokument analizy opisuje zadanie po zadaniu: integracje, funkcje, zmiany na karcie produktu i listingach. Analityk wie, co jest standardem, a co wymaga konfiguracji lub programowania, i przy każdej pozycji podaje liczbę godzin. Dzięki temu lepiej poznajesz swoje potrzeby i dostajesz precyzyjną kwotę, do której dolicza się opiekę analityka, PM-a i testy.
Błąd 3: brak osoby odpowiedzialnej po stronie klienta
▶ 06:05To według Jerzego krytyczny problem, który spowalnia całą migrację. Potrzebna jest osoba, która może poświęcić choćby pół etatu na pracę z software house'em: odpowiedzi, potwierdzanie wykonanych zadań i doprecyzowanie rzeczy, które wcześniej nie zostały opisane. Jeśli ktoś siada do tego raz w tygodniu i zatwierdza bez czytania, projekt nie dojedzie na czas i nie będzie taki, jak trzeba.
Ta osoba musi mieć decyzyjność: zatwierdzać zadania, zmieniać założenia i przyjmować dodatkowe wyceny do ustalonej liczby godzin bez pytania przełożonych. Inaczej, jak mówi Jerzy, nie jest managerem, tylko osobą, która przekazuje zadania dalej.
Błąd 4: start przed pikiem sprzedaży
▶ 08:45Przez siedem lat wdrożeń Jerzy widział wiele sezonowych biznesów: grille, baseny ogrodowe, choinki, materace turystyczne. Najgorszy pomysł to zaczynać prace tuż przed sezonem albo uruchamiać nowy sklep właśnie na szczyt sprzedaży.
Po uruchomieniu zawsze przychodzi okres stabilizacji. Nawet przy dobrych testach pojawiają się nowe wyzwania i pomysły, a agencje SEO przychodzą z rekomendacjami. Przez 2–3 miesiące jest wysyp zleceń. Dlatego rozmowy z wykonawcami warto zacząć 3–4 miesiące przed planowanym startem, zamknąć negocjacje w miesiąc i uruchamiać sklep po sezonie, a nie przed nim, gdy np. bramka płatności może nie zadziałać.
Próbna migracja danych
▶ 12:19Ważny element każdej migracji to weryfikacja baz danych: próbne importy, czyszczenie starych danych i przeniesienie historii zamówień, klientów oraz subskrybentów ze zgodami marketingowymi. Stare środowisko zostanie wyłączone, a za backup też trzeba płacić.
Warto już na etapie analizy udostępnić software house'owi próbkę danych, żeby mógł zobaczyć ich strukturę. Integracja z danym ERP czy przerobiony szablon często wymagają, żeby zespół najpierw zrozumiał, co się w nich wydarzyło.
Błąd 5: spadki w SEO i brak przekierowań 301
▶ 13:25Sklep latami buduje widoczność, a potem jest przepinany z dnia na dzień bez informowania agencji SEO. Roboty Google wchodzą cyklicznie, trafiają na inne adresy, stare zwracają błąd 404, więc sklep leci w dół.
Przy zmianie silnika, np. z Magento albo Shopera na PrestaShop, struktura adresów URL zmienia się całkowicie: domena zostaje, ale wszystko po ukośniku jest inne. Trzeba wyciągnąć wszystkie stare adresy i ustawić stałe przekierowania 301 w nowym silniku. Programiście zajmuje to zwykle około godziny, a większość sklepów ma do tego narzędzia.
Warto też przejrzeć strukturę treści, np. nagłówki H1 i H2, i zapytać agencję SEO, co zrobić przed przeniesieniem, np. czy usunąć z mapy strony adresy produktów, których już nie ma.
Błąd 6: nieznane koszty po migracji
▶ 16:05W starym układzie koszty są znane, a u nowego dostawcy infrastruktura często zmienia się skokowo, np. na chmurę z replikacją i automatycznym dokładaniem zasobów w szczytach. Do tego nowe moduły i wtyczki, nowe metody płatności z opłatami, np. raty, których nie było w Magento poniżej wersji 2, i koszty transportu.
Przy dużym skoku wersji, np. z PrestaShop 1.6 na 9, część modułów nie jest już rozwijana i trzeba kupić inne. Dochodzi też koszt mocniejszego SLA czy dodatkowych zasobów na kampanie. Wszystko to warto spisać przed migracją.
Błąd 7: przenoszenie długu technologicznego
▶ 18:45„Na nowym sklepie wszystko ma być tak samo, tylko silnik inny” to według Jerzego najgłupsza rzecz przy migracji. Przy odświeżeniu raz na 2–5 lat zmieniają się trendy w projektowaniu sklepów i oczekiwania klientów, a konkurencja mierzy zachowania użytkowników.
Przeniesienie starego wyglądu na nowy szablon to ciągnięcie za sobą tych samych problemów. Najpierw warto sprawdzić w analityce i na mapach ciepła, jak klienci poruszają się po sklepie, gdzie szukają informacji i dlaczego opuszczają strony. To wskaże, jak przebudować karty produktów czy bloga. Lepszej okazji do odświeżenia sklepu nie będzie.
Błąd 8: integracja z ERP i WMS oraz testy
▶ 20:55Podłączenie ERP do nowego sklepu to spotkanie dwóch standardów wymiany danych. Analityk dostaje dokumentację API i sklep się do niej dostosowuje, ale mogą wyjść dodatkowe komplikacje: serwer pośredni, żeby nie testować na produkcji, albo zmienione nazwy i położenie pól u dostawcy ERP. Przy każdym systemie, z którym sklep wymienia dane, trzeba uwzględnić szlifowanie.
Wycena dobrego wdrożenia powinna zawierać godziny na testy (QA). Testy automatyczne nie wystarczą, trzeba też sprawdzić ręcznie front, backend, przekazywanie danych przez API do ERP i bramki płatności w środowiskach testowych. To zwykle 10–15% budżetu. Przy wdrożeniu na 300–400 godzin walka o 30 godzin testów wynika z niezrozumienia roli testera.
Silosy informacyjne
▶ 24:35Część wiedzy o tym, jak działają narzędzia i moduły, siedzi tylko w czyjejś głowie. Punktem wyjścia powinien być dokument analizy przedwdrożeniowej, aktualizowany przy każdej zmianie, np. nowym kalkulatorze, module rat czy sliderze.
Jerzy radzi zbierać informacje o modułach i funkcjach w jednym miejscu, np. w Confluence, i zobowiązać się do ich aktualizowania, żeby wiedza została w firmie, gdy ktoś odejdzie.



