PrestaShop 10 to nowa duża wersja platformy, a nie pakiet poprawek — dlatego największym kosztem migracji bywa nie sam core, a moduły, override'y i niestandardowy kod w motywie. Zanim cokolwiek wdrożysz, warto spisać stan wyjściowy sklepu i sprawdzić deklaracje zgodności u dostawców integracji. Poniżej znajdziesz listę typowych błędów, checklistę audytu i odpowiedzi na pytania, które najczęściej padają przed startem. Konkretne wersje PHP i Symfony oraz status wydania potwierdź w oficjalnym changelogu i w dokumentacji deweloperskiej PrestaShop — tych liczb nie zgadujemy na pamięć.
PrestaShop 10 to nowa gałąź major, a nie kolejny minor. Zanim wpiszesz ją do harmonogramu, sprawdź trzy miejsca: oficjalny changelog, zakładkę releases w repozytorium PrestaShop na GitHubie oraz dokumentację deweloperską. Statusu na dzień publikacji nie zgadujemy — interesuje Cię konkretnie, czy istnieje wydanie oznaczone jako stabilne, czy wyłącznie alpha, beta lub RC. To pierwsza informacja, która przesądza, czy rozmawiamy o migracji produkcyjnej, czy o testach na stagingu.
Numeracja jest prosta: 8.x, 9.x i 10.x to kolejne duże wersje, trzecia cyfra oznacza poprawki. Duża wersja zmienia reguły gry — podnosi minimalną wersję PHP, aktualizuje Symfony, przebudowuje fragmenty back office i API. Praktyczna konsekwencja: moduły, override'y i motyw napisane pod 8.x dzielisz na trzy koszyki — działa bez zmian, wymaga nowej wersji od dostawcy, przestaje działać. Ten podział to pierwszy arkusz każdego audytu.
Wsparcie bezpieczeństwa PrestaShop prowadzi tylko dla wybranych gałęzi i publikuje tę informację przy wydaniach. Sprawdź, czy linia Twojego sklepu jest jeszcze łatana. Jeśli nie — każdy miesiąc zwłoki to rosnące ryzyko, a nie oszczędność.
Sklep na 1.7: nie czekaj na 10. Linia 1.7 jest historyczna, więc pierwszym krokiem jest wejście na aktualnie wspieraną gałąź 8.x, a dopiero potem decyzja o 10. Sklep na 8.x: jeśli nie masz konkretnego powodu (nowe API, wymóg wydajnościowy, zmiana UX), nie ma sensu wskakiwać na świeży major w środku sezonu. Zbierz dane, przetestuj na kopii i zaplanuj okno na kwartał po stabilnym wydaniu. Punktem wyjścia do rozmowy o zakresie są nasze wdrożenia i migracje PrestaShop.
Zamiast listy funkcji marketingowych sprawdź cztery obszary techniczne. Każdy z nich potwierdź w oficjalnej dokumentacji deweloperskiej PrestaShop i w release notes konkretnego wydania — nie w postach na forach.
Tabela poniżej służy do decyzji, nie do cytowania w ofercie. Konkretne numery PHP i Symfony potwierdź w release notes danego wydania — świadomie nie wpisujemy ich z pamięci, bo zmieniają się między minorami.
Progi decyzyjne w praktyce. Sklep na 1.7 bez wsparcia: migracja jest obowiązkiem, a nie opcją — kolejność to najpierw wspierana gałąź 8.x, potem 10, chyba że i tak planujesz przebudowę, wtedy sensowny jest jeden projekt na 10 z pełnym audytem. Sklep na 8.x stabilny: zostaje, zbiera dane i rezerwuje okno serwisowe na kwartał po stabilnym wydaniu 10. Nowe wdrożenie: 8.x, jeśli moduły płatności i kurierów są potrzebne od pierwszego dnia; 10, jeśli masz 3–6 miesięcy bufora na testy.
Kiedy aktualizacja do 10 to przymus? Wtedy, gdy kończy się wsparcie PHP, na którym stoi sklep — hostingi wyłączają niełatane wersje PHP i sklep po prostu przestaje działać, niezależnie od gotowości modułów. Kiedy decyzja biznesowa? Gdy liczy się wymiana UX, wydajność lub nowe API, a nie deadline. Przykład z życia: integracja InPost z PrestaShop wymaga sprawdzenia wersji modułu przed każdym większym skokiem, bo odpowiada za checkout i etykiety.
Ostrzeżenie: nowa duża wersja to pierwsze 3–6 miesięcy bez dojrzałego ekosystemu. Najpóźniej aktualizują się moduły płatności i kurierów — czyli dokładnie te, których awaria kosztuje najwięcej.
| Wersja | Minimalne PHP | Symfony | Status wsparcia | Rekomendacja |
|---|---|---|---|---|
| 1.7 | linia zamknięta — sprawdź ostatni release notes | 4.4 | poza aktywnym wsparciem — potwierdź daty EOL | Nie zostawiaj sklepu tutaj; pierwszy krok to 8.x |
| 8.x | zależy od minoru — liczba z release notes | 4.4 | wspierana gałąź — sprawdź datę końca dla swojego minoru | Domyślny wybór: stabilny ekosystem modułów |
| 9.x | podwyższone względem 8.x — potwierdź w changelogu | nowsza gałąź — potwierdź w changelogu | gałąź przejściowa | Dla sklepów z zaplanowaną przebudową w tym roku |
| 10.x | nowe minimum — wyłącznie z oficjalnego changelogu | nowa gałąź — potwierdź w changelogu | sprawdź, czy stable, czy alpha/beta/RC | Nie dla sklepu bez okna serwisowego i testów |
W praktyce budżet migracji zjada nie core, a wszystko, co jest do niego przykręcone. Zanim policzysz dniówki dewelopera, policz moduły i override'y — to one decydują, czy projekt zamknie się w dwóch tygodniach, czy w dwóch miesiącach.
Integracje do sprawdzenia w pierwszej kolejności:
Override'y i custom code w motywie to najczęstsze źródło błędów po aktualizacji. Każdy plik w /override/classes i /override/controllers nadpisuje metodę, której po zmianie wersji może już nie być albo która może mieć inne argumenty. Efekt? Biała strona, cichy błąd w koszyku albo zamówienie bez pozycji. W motywie jest identycznie: skopiowany szablon z domyślnego theme'u, modyfikacje w plikach .tpl, własny JavaScript w checkout.
Jak sprawdzić kompatybilność: changelog modułu u dostawcy, deklarowana wersja PHP, test instalacji i pełnej ścieżki zakupowej na stagingu.
Zasada: brak deklaracji zgodności od dostawcy = traktuj moduł jak niezgodny, aż do testu. Nie odwrotnie.
| Integracja | Co konkretnie sprawdzić | Skutek błędu |
|---|---|---|
| Płatności | Deklaracja zgodności w changelogu, wersja PHP, test płatności zakończonej, odrzuconej i porzuconej | Brak możliwości zapłaty = zero zamówień |
| InPost / DPD / DHL | Generowanie przesyłki, numer tracking, wybór punktu w checkout | Ręczne tworzenie etykiet, opóźnienia wysyłek |
| ERP / magazyn | Format plików wymiany, crony, mapowanie statusów | Stany magazynowe rozjeżdżają się z rzeczywistością |
| GA4 | Nazwy eventów, parametry e-commerce, kolejność kroków | Dane w analityce przestają się zgadzać z zamówieniami |
Audyt sam w sobie redukuje ryzyko, bo zmusza do policzenia tego, co dotąd żyło w czyjejś głowie albo w czyimś mailu z 2021 roku.
Inwentaryzacja — cztery liczby. Liczba aktywnych modułów (zapytanie SELECT COUNT(*) FROM ps_module WHERE active = 1), liczba plików w katalogu /override, liczba niestandardowych pól w bazie (porównanie schematu z czystą instalacją tej samej wersji) oraz liczba zmodyfikowanych szablonów (diff z motywem domyślnym). Te cztery liczby wstaw do wyceny — są lepszym estymatorem niż pytanie „ile to potrwa”.
Środowisko testowe jako kopia produkcji. Nie „jakiś staging”, a kopia: te same dane (zanonimizowane), ta sama konfiguracja serwera (PHP-FPM, limity pamięci, OPcache), ta sama wersja PHP, te same zadania cron. Inaczej test zgodności nic nie znaczy — moduł przejdzie na stagingu i wywali się na produkcji.
Pomiar stanu wyjściowego, żeby po migracji wiedzieć, czy coś faktycznie się zepsuło: Core Web Vitals (LCP, INP, CLS) z danych rzeczywistych, czas odpowiedzi serwera, pozycje w GSC dla top 50 fraz i konwersja z ostatnich 30 dni. Punkt odniesienia dla metryk wydajności opisuje dokumentacja Web Vitals.
Lista decyzji przed startem: co przepisujemy jako własny moduł, co porzucamy (funkcja, z której nikt nie korzysta — sprawdź logi i statystyki, nie opinie), co zastępujemy gotowym rozwiązaniem. Warto przy tym zweryfikować, jak zakres i ograniczenia modułów PrestaShop przekładają się na to, co naprawdę da się przenieść bez przepisywania.
| Element inwentaryzacji | Jak zmierzyć | Po co |
|---|---|---|
| Moduły | Zapytanie do tabeli <code>ps_module</code> + lista dostawców | Podstawa wyceny i kolejności testów |
| Override'y | Lista plików w <code>/override</code> z nazwami nadpisywanych klas | Wskazanie kodu do przepisania lub usunięcia |
| Stan wyjściowy | CWV, TTFB, GSC top 50, konwersja 30 dni | Dowód, czy migracja niczego nie popsuła |
| Środowisko testowe | Kopia bazy, konfiguracji serwera i wersji PHP | Wiarygodność testów zgodności |
Kolejność ma znaczenie. Zmiana kolejności to najczęstsza przyczyna „migracji, która trwa”.
Testy akceptacyjne po aktualizacji: ścieżka zakupowa (gość i konto), płatności (sukces, odmowa, porzucenie), generowanie przesyłek, faktury, e-maile transakcyjne (SMTP, szablony, zmienne). Każdy punkt ma wynik tak/nie, nie „raczej działa”.
Rollback musi być gotowy przed wdrożeniem, nie po: kopia bazy sprzed wdrożenia, snapshot serwera, ustalone okno serwisowe i osoba, która podejmuje decyzję o cofnięciu. Zapisz na piśmie, ile zajmie przywrócenie — 15 minut czy 3 godziny to zupełnie inna rozmowa z klientami.
Obsługa URL-i: sprawdź, czy po aktualizacji nie zmieniają się trasy (format adresów produktów, kategorii, stron CMS). Jeśli tak — przygotuj mapowanie starych adresów na nowe, 301 redirecty i nową sitemapę wysłaną w GSC po wdrożeniu. Temat szerzej omawiamy przy okazji Friendly URL w PrestaShop. Szczegóły techniczne wersji potwierdź w dokumentacji deweloperskiej PrestaShop.
| Etap | Punkt kontrolny | Kryterium przejścia dalej |
|---|---|---|
| Kopia bazy i plików | Przywrócenie backupu na stagingu | Sklep na stagingu działa jak produkcja |
| Aktualizacja core | Logi PHP, konsola, back office | Zero błędów krytycznych |
| Moduły | Test pojedynczo, po każdym instalacji | Każdy moduł przechodzi swój test |
| Motyw | Diff szablonów, lista override'ów | Strony renderują się bez notice'ów |
| Testy funkcjonalne | Checklista: koszyk, płatności, przesyłki, faktury, e-maile | 100% checklisty na tak |
| Produkcja | Okno serwisowe, snapshot, plan rollbacku | Zapisany czas przywrócenia i osoba decyzyjna |
Pierwsze 30 dni po wdrożeniu decydują, czy ruch wróci do poziomu sprzed migracji. Ustaw rytm: dni 1–7 codziennie, dni 8–30 dwa razy w tygodniu.
Google Search Console. Raport „Strony” w zakładce Indeksowanie: sprawdzaj powody wykluczenia — „Serwer zwrócił błąd 5xx”, „Nie znaleziono (404)”, „Strona ze skierowaniem”. Jeśli po 72 godzinach rośnie liczba stron „Zindeksowanych, niebędących w indeksie”, problem jest w canonicalach albo sitemapie, nie w treści.
404 i 301. Wyeksportuj z GSC adresy z ostatnich 3 miesięcy i przejdź je crawlerem (Screaming Frog w darmowej wersji skanuje 500 URL-i). Każdy martwy adres dostaje 301 na najbliższy odpowiednik, nie na stronę główną — masowe przekierowanie na home Google czyta jak soft 404 i wycina strony z indeksu.
CTR w klastrach fraz. Podziel frazy na klastry (kategoria, karta produktu, poradnik) i porównaj CTR z 28 dni przed i po. Spadek CTR przy niezmienionej pozycji oznacza zmianę title/meta albo utratę wyników rozszerzonych.
Core Web Vitals. Zmiana wersji PHP i frontu zmienia TTFB oraz LCP. Mierz dane polowe w GSC i CrUX, nie tylko Lighthouse — progi i metodologia są opisane w omówieniu Web Vitals. Cel: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1.
Canonicale, dane strukturalne, sitemap. Sprawdź, czy szablon nie dokleja parametrów do canonicala (?id_lang, ?id_currency). W Rich Results Test przejdź 20 kart produktów — Product z price, availability i offers oraz BreadcrumbList. Nową sitemap zgłaszasz w GSC w dniu wdrożenia i nie może zawierać adresów z 301.
Punkt kontrolny. Lista top 50 fraz z pozycjami zmierzonymi przed migracją to jedyny wiarygodny benchmark. Porównanie w D+7, D+14 i D+30. Spadek średniej pozycji o więcej niż 3 miejsca w klastrze produktowym to sygnał do diagnozy, nie do czekania.
Zmiany we froncie i ich wpływ na konwersję opisujemy szerzej w materiale o PrestaShop UI: front office, back office i UX.
| Co mierzyć | Narzędzie | Próg reakcji |
|---|---|---|
| Indeksacja i błędy 404 | GSC → Indeksowanie stron | wzrost 404 o więcej niż 5% w 7 dni |
| Pozycje top 50 fraz | Senuto / Semrush / Ahrefs | spadek średniej pozycji o więcej niż 3 miejsca w D+30 |
| Core Web Vitals (dane polowe) | GSC → Core Web Vitals, CrUX | LCP powyżej 2,5 s lub INP powyżej 200 ms |
| Dane strukturalne | Rich Results Test | błąd Product lub BreadcrumbList na karcie produktu |
Te cztery sytuacje wracają w niemal każdym wdrożeniu. Każda ma tanią wersję testu i kosztowną wersję naprawy po starcie.
1. Core zaktualizowany, moduły zostały na starych wersjach. Objaw: biała strona, błędy 500 na karcie produktu i w koszyku — moduł woła metodę, której w nowym core już nie ma. Sprawdzenie: na stagingu włącz tryb dev (w config/defines.inc.php ustaw _PS_MODE_DEV_ na true), zajrzyj do var/logs/ i do error_log PHP — stack trace wskaże plik modułu. Naprawa: aktualizacja u dostawcy, a jeśli jej nie ma — decyzja o wyłączeniu albo przepisaniu. Nie poprawiaj plików core, bo przy kolejnej łatce wrócisz do punktu wyjścia.
2. Testy na demo, nie na kopii produkcyjnej bazy. Objaw: czysta instalacja z 20 produktami działa, a sklep z 40 tys. SKU, 8 językami i 15 tys. klientów sypie się na filtrach i historii zamówień. Przyczyna: brak testów na realnych danych — indeksy, sieroty w tabelach, stare rekordy bez produktu. Sprawdzenie: zanonimizowany dump bazy na staging i scenariusze: lista z filtrami, koszyk, checkout w każdej walucie, panel klienta. Zanim podpiszesz odbiór, zestaw deklaracje dostawcy z tym, co faktycznie robi moduł — pomaga w tym materiał o zakresie i ograniczeniach modułów PrestaShop.
3. Zmiana wersji PHP bez sprawdzenia rozszerzeń. Objaw: 500 przy generowaniu miniatur, PDF-ach i wysyłce maili. Sprawdzenie: php -m na serwerze docelowym i porównanie z wymaganiami modułów — intl, mbstring, curl, gd lub imagick, zip, sockets. Limity: memory_limit minimum 256M przy imporcie CSV, max_execution_time 300, post_max_size i upload_max_filesize pod pliki produktowe. Naprawa: wersję PHP zmieniasz przez panel hostingu, nie w .htaccess; brakujące rozszerzenia zgłaszasz do supportu — jeśli ich nie doinstaluje, hosting zmieniasz przed migracją, nie po.
4. Brak monitoringu po wdrożeniu. Objaw: błąd płatności wychodzi po trzech tygodniach, bo wtedy ktoś zauważa spadek zamówień. Sprawdzenie: monitor uptime z interwałem 1 minuty na trzy adresy — stronę główną, koszyk, bramkę płatności; alerty na error_log i na spadek liczby zamówień dzień do dnia o więcej niż 30%. Naprawa: wdrożenie monitoringu przed migracją. To 2–3 godziny, nie projekt.
Widełki podawaj w godzinach, nie w „od X zł” — godziny da się zweryfikować po fakcie, widełki kwotowe nie. Trzy scenariusze z audytów:
Co podnosi wycenę: liczba modułów custom (4–12 h na moduł przy audycie i przepisaniu), integracje zewnętrzne (8–24 h na integrację), front na starym szablonie (20–60 h), dane do posprzątania — duplikaty, sieroty, zdjęcia (20–40 h).
Kiedy taniej przepisać sklep. Trzy kryteria liczbowe: wycena migracji przekracza 50–60% kosztu nowego sklepu na tej samej platformie; liczba modułów custom przekracza 10; szablon bazuje na PrestaShop 1.6 z override’ami w kontrolerach. Wtedy migracja oznacza płacenie za utrzymanie długu, a nie za nową wersję.
Model rozliczenia. Audyt jako osobny, płatny etap (8–16 h) z raportem: moduły, override’y, integracje, ryzyka. Wycena wdrożenia z liczby godzin plus bufor 15–20% na nieprzewidziane. Praca bezpośrednio z deweloperem, który robi audyt — bez pośrednika przepisującego ustalenia. Opieka po wdrożeniu z SLA: reakcja w 4 h w godzinach pracy, monitoring, aktualizacje bezpieczeństwa, miesięczny przegląd logów.
Zakres, przykłady i kolejne kroki znajdziesz w sekcji wdrożenia i migracje PrestaShop.
| Scenariusz | Widełki | Co dominuje w wycenie |
|---|---|---|
| Standardowe moduły z marketplace, brak override’ów, motyw child | 40–70 h | audyt zgodności modułów, testy regresji checkoutu |
| Override’y w kontrolerach i klasach, 3–8 modułów custom | 80–160 h | przepisanie override’ów, testy na kopii bazy produkcyjnej |
| Integracja ERP/API, multi-store, wielojęzyczność | 160–300 h | mapowanie danych, testy integracji, bufor na nieprzewidziane |
Aktualizacja wykonywana od razu na produkcji, bez kopii i środowiska testowego.
Jak wykryć: Nie potrafisz wskazać daty ostatniego backupu z bazą i plikami, a staging albo nie istnieje, albo jest nieaktualny względem produkcji.
Jak naprawić: Postaw kopię 1:1 (dane, konfiguracja serwera, wersja PHP, moduły) i przeprowadź na niej całą aktualizację. Produkcję ruszaj dopiero po testach akceptacyjnych i z gotowym planem wycofania.
Koszt migracji liczony wyłącznie po stronie core, bez inwentaryzacji modułów i integracji.
Jak wykryć: W budżecie jest tylko „aktualizacja PrestaShop”, a nikt nie policzył liczby modułów, ich wersji i dostawców.
Jak naprawić: Zrób listę wszystkich modułów z wersją, dostawcą i deklarowaną zgodnością. Do każdego dopisz, czy ma wersję pod nową gałąź i kiedy ostatnio był aktualizowany.
Brak deklaracji zgodności od dostawcy modułu interpretowany jako „pewnie zadziała”.
Jak wykryć: W changelogu modułu nie ma informacji o nowej gałęzi PrestaShop ani o minimalnej wersji PHP, a moduł nie był testowany od dłuższego czasu.
Jak naprawić: Traktuj taki moduł jak niezgodny, aż do testu na stagingu. Jeśli jest krytyczny (płatności, kurierzy, faktury), zapytaj dostawcę o termin wsparcia pisemnie.
Pominięcie override'ów i modyfikacji szablonu jako „drobiazgu”.
Jak wykryć: W katalogu override leżą pliki klas, a w motywie brakuje dokumentacji zmian — nikt nie wie, co było modyfikowane ręcznie.
Jak naprawić: Spisz każdy override (klasa, metoda, powód) i każdą zmianę w szablonie. Po aktualizacji przejdź je punkt po punkcie — to najczęstsze źródło błędów, których nie widać w logach.
Założenie, że ekosystem modułów jest dojrzały w dniu premiery nowej dużej wersji.
Jak wykryć: Plan zakłada pełny rollout w pierwszym tygodniu po wydaniu, mimo że kluczowe moduły nie mają jeszcze wydanej wersji zgodnej.
Jak naprawić: Zaplanuj bufor czasu na okres przejściowy i ustal, które integracje muszą mieć zgodność potwierdzoną, zanim wystartujesz. Nowa duża wersja oznacza zwykle kilka miesięcy docierania się ekosystemu.
Zmiana wersji PHP i PrestaShop w jednym kroku.
Jak wykryć: Na stagingu aktualizujesz platformę i podbijasz PHP jednocześnie, więc po błędzie nie wiesz, co jest przyczyną.
Jak naprawić: Rozdziel te kroki: najpierw aktualizacja w ramach obecnego PHP, potem osobno podbicie PHP z testem modułów. Łatwiej wtedy zlokalizować regresję.
Brak pomiaru stanu wyjściowego przed migracją.
Jak wykryć: Nie masz zapisanych wyników Core Web Vitals ani czasów odpowiedzi serwera sprzed zmian — po wdrożeniu nie ma z czym porównać.
Jak naprawić: Zapisz metryki sprzed startu (CWV z Google Search Console i web.dev, czasy odpowiedzi kluczowych podstron) i powtórz pomiar po migracji na tym samym urządzeniu i profilu.
W PrestaShop 10 ryzyko nie leży w samym core, a w module, override'ach i ręcznych zmianach w motywie — dlatego audyt przed startem jest tańszy niż naprawa po wdrożeniu. Zanim ruszysz, policz moduły, sprawdź deklaracje zgodności u dostawców i zmierz stan wyjściowy sklepu. Dopiero na tej podstawie da się sensownie zdecydować, czy aktualizujesz teraz, czy czekasz na dojrzenie ekosystemu. Konkretne wersje PHP i Symfony potwierdź w oficjalnej dokumentacji deweloperskiej PrestaShop.
To zależy od statusu wydania w dniu, w którym to czytasz — nie da się tego ustalić raz na zawsze. Sprawdź oficjalny changelog projektu i gałąź na GitHubie, a następnie zweryfikuj, czy Twoje moduły krytyczne mają wydane wersje zgodne z nową gałęzią. Sama dostępność kodu nie oznacza, że ekosystem jest gotowy.
Jeśli sklep działa stabilnie na wspieranej gałęzi, czekanie nie jest stratą — nowa duża wersja zwykle wymaga czasu na dojrzenie modułów. Jeśli natomiast kończy się wsparcie dla Twojej wersji PHP, decyzja przestaje być dobrowolna. W obu przypadkach audyt i tak warto zrobić teraz, bo jego wynik jest niezależny od terminu migracji.
Nie ma jednej liczby — czas wyznacza liczba modułów i override'ów, a nie sam core. Sklep z kilkoma standardowymi modułami i motywem bez modyfikacji to inna skala niż sklep z override'ami, integracją ERP i dwoma modułami płatności. Punktem wyjścia jest audyt, po którym można podać zakres i kolejność prac.
Tylko wtedy, gdy dostawca deklaruje zgodność z nową gałęzią i nie opierają się na wycofanych mechanizmach legacy. Brak takiej deklaracji traktuj jak brak zgodności, aż do testu na stagingu. Szczególnie uważaj na moduły płatności i kurierów — ich awaria blokuje sprzedaż od pierwszego dnia.
Nie zawsze, ale trzeba sprawdzić, czy motyw jest rozwijany pod nową gałąź i czy nie opiera się na zmienionych elementach front office. Największe ryzyko to modyfikacje wprowadzone ręcznie — one nie aktualizują się razem z motywem. Test na kopii produkcji pokaże realny zakres poprawek.
Zwykle tak, jeśli aktualizacja jest testowana na kopii, a przełączenie na produkcji odbywa się w zaplanowanym okienku serwisowym. Kluczowe jest przygotowanie planu wycofania i sprawdzenie po przełączeniu ścieżki zamówienia. Bez tego „bez przestoju” oznacza tylko brak informacji o przestoju.
Od inwentaryzacji: lista modułów z wersjami, liczba override'ów, niestandardowe pola w bazie, modyfikacje szablonu i wersja PHP. To zestawienie kosztuje kilka godzin, a pozwala realnie oszacować nakład pracy. Bez niego każda wycena jest zgadywaniem.
Jeśli chcesz ustalić, ile realnie zajmie przygotowanie Twojego sklepu do PrestaShop 10, zacznijmy od audytu modułów i override'ów — to zwykle kilka godzin, po których wiadomo, z czym pracujemy. Zajrzyj też do naszego huba usług PrestaShop, gdzie opisujemy wdrożenia i migracje.