Jeśli prowadzisz sklep na PrestaShop 1.6, prędzej czy później staniesz przed tą decyzją. Wersja 1.6 nie jest już wspierana: nie dostaje poprawek bezpieczeństwa, coraz mniej modułów ją obsługuje, a nowsze wersje PHP przestają z nią współpracować.
Pytanie nie brzmi więc „czy migrować”, tylko „co się przy tym posypie i ile to potrwa”. Ten wpis jest odpowiedzią na to drugie, z perspektywy kogoś, kto tę migrację przeprowadzał, między innymi dla hurtowni elektrycznej Megakabel.pl, gdzie sklep musiał sprzedawać przez cały czas trwania prac.
To nie jest aktualizacja
Największe nieporozumienie wokół tej migracji polega na tym, że ludzie myślą o niej jak o aktualizacji, czyli kliknięciu przycisku, po którym sklep wygląda tak samo, tylko ma wyższy numer wersji.
Tak nie jest. Między 1.6 a 1.7 zmieniła się architektura szablonu, sposób pisania modułów i mechanizm nadpisań. Twój obecny szablon nie zadziała. Twoje obecne moduły w większości nie zadziałają. Nie dlatego, że coś jest zepsute, tylko dlatego, że zostały napisane pod inny system.
W praktyce migracja 1.6 do 1.7 to budowa nowego sklepu, do którego przenosi się dane i odtwarza funkcje. Kto podejdzie do niej jak do aktualizacji, ten się przeliczy, najczęściej w połowie projektu.
Co przechodzi, a co trzeba zrobić od nowa
Najkrótsze podsumowanie całego projektu mieści się w jednej tabeli. Dane są bezpieczne, warstwa wykonawcza nie.
| Element sklepu | Los przy migracji | Ryzyko |
|---|---|---|
| Produkty, kategorie, ceny, stany magazynowe | Przenoszą się | Niskie |
| Kombinacje i atrybuty produktów | Przenoszą się | Niskie, wymaga sprawdzenia powiązań |
| Klienci, adresy, historia zamówień | Przenoszą się | Niskie |
| Szablon | Do zbudowania od nowa | Wysokie, największa pozycja kosztowa |
| Moduły | Każdy osobno: aktualizacja, zamiennik albo przepisanie | Wysokie |
| Nadpisania i zmiany w rdzeniu | Do znalezienia i odtworzenia | Najwyższe, bo nieudokumentowane |
| Integracje z hurtownią i kurierami | Do przetestowania, często do przepisania | Wysokie przy sklepach hurtowych |
| Adresy podstron | Zmieniają się, wymagają przekierowań | Wysokie, a najczęściej pomijane |
Szablon
Motywy z 1.6 są niekompatybilne z 1.7 i nie da się ich przenieść. Masz dwie drogi: kupić motyw pod nowszą wersję i dopasować albo zbudować szablon od zera.
Przy okazji warto zadać pytanie, którego przy „aktualizacji” nikt nie zadaje: czy chcemy odtworzyć poprzedni wygląd, czy zrobić lepszy? Skoro szablon i tak powstaje od nowa, odtwarzanie kilkuletniego projektu jeden do jednego rzadko jest najlepszym użyciem tych pieniędzy. W Megakabelu przy okazji migracji odświeżyliśmy warstwę wizualną. To nie był dodatkowy projekt, tylko decyzja, jak wykorzystać pracę, którą trzeba było wykonać tak czy inaczej.
Moduły
Każdy moduł trzeba rozpatrzyć osobno i są cztery możliwości. Autor wydał wersję na 1.7, więc kupujesz albo aktualizujesz licencję. Autor porzucił moduł, więc trzeba znaleźć zamiennik, co bywa łatwe, a bywa niemożliwe. Funkcja weszła do rdzenia nowszej wersji, więc moduł jest zbędny i to najlepszy przypadek. Albo moduł był pisany na zamówienie i trzeba go napisać ponownie pod nową architekturę.
Ten czwarty przypadek jest najkosztowniejszy i najczęściej pomijany w pierwszych wycenach. Jeśli poprzedni wykonawca pisał dla Ciebie dedykowany kod, ten kod nie przejdzie.
Praktyczna rada: zrób inwentaryzację modułów, zanim zaczniesz cokolwiek innego. Wypisz wszystkie, zaznacz, które są faktycznie używane, i dopiero potem szukaj odpowiedników. Nierzadko okazuje się, że jedna trzecia modułów w starym sklepie nie robi nic poza spowalnianiem go, a migracja jest okazją, żeby się ich pozbyć.
Nadpisania i zmiany w rdzeniu
Jeśli ktoś w przeszłości modyfikował pliki rdzenia PrestaShopa bezpośrednio, a w sklepach z długą historią to niestety częste, te zmiany trzeba znaleźć, zrozumieć i odtworzyć w nowej wersji.
To najbardziej nieprzewidywalna część projektu. Zmiany w rdzeniu zwykle nie są nigdzie udokumentowane, a osoby, które je wprowadziły, dawno nie pracują przy tym sklepie. Zdarza się, że dopiero po uruchomieniu ktoś zauważa, że pewna reguła rabatowa działała, bo dziesięć lat temu ktoś dopisał trzy linijki w pliku rdzenia.
Rzecz, która decyduje o powodzeniu: adresy podstron
To jest ta część, którą pomija się najczęściej i która najbardziej boli.
PrestaShop 1.7 domyślnie generuje adresy podstron inaczej niż 1.6. Jeśli po migracji adresy produktów i kategorii się zmienią, a nikt nie ustawi przekierowań, to każdy adres zaindeksowany przez wyszukiwarkę i każdy link prowadzący do Twojego sklepu z zewnątrz trafia na stronę błędu.
Skutek jest przewidywalny: sklep po migracji sprzedaje mniej niż przed nią, a właściciel dochodzi do wniosku, że nowa wersja jest gorsza. Nie jest. Po prostu ktoś nie odrobił zadania.
Praca wygląda tak: zrzucić pełną listę adresów ze starego sklepu przed migracją, ustalić, jak będą wyglądać nowe, przygotować mapę przekierowań stary do nowego dla każdego produktu, kategorii i strony, wdrożyć je w dniu uruchomienia, nie tydzień później, a potem sprawdzić i obserwować raport błędów przez kolejne tygodnie. Jest to żmudne i całkowicie mechaniczne. Jest też najtańszym ubezpieczeniem w całym projekcie.
Jak to zaplanować, żeby sklep sprzedawał przez cały czas
Migracji nie robi się na żywym sklepie. U nas zaczyna się ona od bezpłatnej migracji testowej: przenosimy dane na osobne środowisko, patrzymy, co z nich wychodzi, i dopiero na tej podstawie podajemy wycenę i specyfikację. Wycena przed testem byłaby zgadywaniem, a wyceny z sufitu kończą się dopłatami w połowie projektu.
| Etap | Co się dzieje | Stary sklep |
|---|---|---|
| 1. Inwentaryzacja | Lista modułów, integracji, nadpisań i zmian w rdzeniu | Sprzedaje |
| 2. Migracja testowa | Bezpłatna. Po niej wycena i specyfikacja | Sprzedaje |
| 3. Nowy sklep na osobnym środowisku | Instalacja, szablon, moduły | Sprzedaje |
| 4. Odtworzenie funkcji i integracji | Najdłuższy etap | Sprzedaje |
| 5. Testy na rzeczywistych danych | Cała ścieżka zakupowa, płatności, wysyłka, wymiana danych z hurtownią | Sprzedaje |
| 6. Przeniesienie danych na czysto | Tuż przed startem, żeby nie zgubić zamówień z okresu prac | Sprzedaje |
| 7. Przełączenie i przekierowania | Poza szczytem sprzedaży, nie w piątek po południu i nie w listopadzie | Przełączony |
| 8. Obserwacja | Pierwsze dni po starcie, wychodzą rzeczy niewidoczne w testach | Nowy sklep |
Etap szósty ma haczyk, o którym warto wiedzieć: między pierwszym a drugim przeniesieniem danych w starym sklepie pojawiają się nowe zamówienia i nowi klienci. Trzeba z góry ustalić, jak je dobrać, żeby nic nie zginęło i nic się nie zdublowało.
Ile to trwa
Zależy niemal wyłącznie od liczby modułów i integracji, a nie od wielkości katalogu. Sklep z tysiącem produktów i dwoma modułami migruje się szybciej niż sklep ze stoma produktami, dedykowanym systemem rabatowym i integracją bez dokumentacji. Sama migracja danych po zaakceptowanej specyfikacji zamyka się w kilku dniach roboczych. Odtworzenie szablonu i modułów to już projekt liczony w tygodniach, porównywalny z budową nowego sklepu, gdzie minimum to 55 do 60 dni roboczych.
Dlatego pierwszym etapem jest inwentaryzacja. Po niej wycena i termin są konkretne, a przed nią każda liczba jest zgadywaniem.
Czy jest sens migrować, skoro to tyle pracy
Argument za jest prosty i trudny do obejścia: 1.6 nie dostaje poprawek bezpieczeństwa. Sklep przyjmuje płatności i przechowuje dane klientów. Praca na niewspieranej wersji to nie jest oszczędność, tylko odroczony koszt z odsetkami. Do tego nowsze wersje PHP przestają współpracować z 1.6, a hostingi wycofują stare wersje PHP. W pewnym momencie decyzja przestaje być Twoja.
Warto rozważyć trzecią drogę: skoro szablon i tak powstaje od nowa, a moduły trzeba przejrzeć, to być może zamiast migracji na 1.7 lepszym wyborem jest przejście od razu na najnowszą wspieraną wersję PrestaShopa. Nakład jest podobny, a horyzont spokoju dłuższy.
Zanim zaczniesz, zrób audyt
Najgorszy moment na odkrycie, że w rdzeniu sklepu siedzi dwadzieścia niedokumentowanych zmian, to połowa migracji.
Audyt techniczny przed migracją odpowiada na pytania, które i tak padną: ile jest modułów i które są używane, czy ktoś ruszał rdzeń, jak działają integracje, w jakim stanie są dane. Kosztuje od 2 999 zł netto i trwa od 5 do 10 dni roboczych od dostania dostępów. Po nim wycena migracji przestaje być zgadywaniem, a projekt niespodzianką. Jeśli zdecydujesz się na wdrożenie u nas, koszt prac obniżamy adekwatnie do zakresu.
Masz sklep na PrestaShop 1.6 i zastanawiasz się nad migracją? Napisz do nas. Zaczniemy od bezpłatnej migracji testowej i ustalenia, co realnie trzeba przenieść, a to najczęściej wygląda inaczej, niż się wydaje na początku.
Przy okazji przyda Ci się wpis o tym, ile kosztuje sklep na PrestaShop i od czego zależy wycena.
