Wdrożenie PrestaShop to projekt liczony w godzinach, nie w tygodniach oczekiwania — proste sklepy zamykają się w 60–100 godzinach pracy wykonawcy, a migracja z innej platformy zwykle w 50–120 godzinach plus prace po stronie firmy. Największy koszt projektu nie siedzi w samym PrestaShop, tylko w danych: brak EAN, duplikaty kategorii, tysiące zdjęć bez nazw. Ten tekst porządkuje stronę organizacyjną: co zamówić, jak rozliczyć wykonawcę, kiedy pracować na stagingu, a nie na produkcji, i jakich zapisów wymagać w umowie. Wszystkie liczby traktuj jako widełki do weryfikacji w ofercie, nie jako cennik DropDigital.
Wdrożenie i migracja to dwa różne projekty, które inaczej się wycenia i inaczej odbiera. Wdrożenie oznacza start od zera lub na nowej domenie: czysta instalacja PrestaShop 1.8.x na PHP 8.1/8.2, konfiguracja szablonu, stref podatkowych i walut, podłączenie płatności (Przelewy24, PayU, Stripe, płatność za pobraniem), kurierów (InPost Paczkomaty, DPD, DHL), wygenerowanie regulaminu, polityki prywatności i zasad zwrotów. Migracja to przeniesienie istniejącego sklepu z WooCommerce, Shopify, IdoSell, Magento albo ze starego PrestaShop 1.6/1.7 — dochodzi mapowanie danych, przekierowania 301 i pytanie, czy źródło w ogóle pozwala na eksport.
Typowy zakres wdrożenia, o który pytasz w ofercie: instalacja na hostingu z osobnym stagingiem i produkcją, certyfikat SSL, harmonogram backupów, konfiguracja szablonu (nagłówek, menu, karta produktu, koszyk, checkout, lista zmian w plikach .tpl), strefy podatkowe (23%, 8%, 5%, 0% dla WNT), moduły płatności i kurierów z cennikami wagowymi i progowymi, integracja z Google Analytics 4 i Search Console oraz testy wydajności po uruchomieniu.
Po stronie firmy z Bydgoszczy zostają: dane produktowe (nazwy, opisy, EAN, waga, wymiary), zdjęcia, treści stron, decyzje o kosztach wysyłki i zwrotach oraz zatwierdzenia na stagingu. Wykonawca nie wymyśli za Ciebie ceny dostawy ani opisu, który sprzedaje.
Wdrożenie PrestaShop nie wymaga obecności wykonawcy na miejscu — 90% pracy to dostęp do serwera i panelu. Zamiast wizyt lokalnych wpisz do umowy: kanał komunikacji (ticket lub mail z odpowiedzią w 1 dzień roboczy), okno konsultacji (np. dwie telekonferencje po 60 minut), terminy kamieni milowych, listę dostępów (SFTP, panel hostingu, DNS, Search Console) i zasadę, że każda zmiana idzie najpierw na staging. Zakres modułów i hooków, które będą modyfikowane, opisuje dokumentacja PrestaShop dla deweloperów — sprawdź, czy wykonawca pisze własne moduły, czy nadpisuje core, bo to wpływa na koszt przyszłych aktualizacji.
| Element | Wdrożenie od zera | Migracja z innej platformy |
|---|---|---|
| Punkt startowy | nowa domena, pusta baza | istniejący sklep, działający ruch |
| Dane | wprowadzasz lub importujesz sam | eksport, czyszczenie, mapowanie, import |
| Adresy URL | ustalane od początku | przepisanie na 301, ryzyko spadku pozycji |
| Główne ryzyko | brak treści i zdjęć na start | niekompletny eksport ze starego systemu |
| Typowy czas | 60–100 h | 50–120 h |
Decyzję da się podjąć szybko, jeśli zbierzesz liczby, a nie opinie. Cztery kryteria: liczba SKU, liczba modułów lub wtyczek na starej platformie, jakość danych i realny koszt utrzymania obecnego rozwiązania (abonament, płatne wtyczki, poprawki po każdej aktualizacji).
Progi orientacyjne są proste. Do około 500 SKU i prostego katalogu zwykle wygrywa przebudowa od zera — import i tak wymaga czyszczenia, a stara baza ciągnie za sobą błędy. Powyżej 2–3 tys. SKU migracja danych staje się główną pozycją projektu, więc nie warto jej pomijać w budżecie. Przy 15 i więcej wtyczkach bez dokumentacji licz dodatkowe 20–40 h na audyt tego, co musi działać po przenosinach.
Przenosisz zwykle: produkty, kategorie, klientów, historię zamówień, opinie, treści CMS i adresy URL. Każda z tych rzeczy musi mieć potwierdzony eksport przed podpisaniem umowy. Historia zamówień i konta klientów to najczęstszy punkt sporny — bez nich klient nie zaloguje się do starego konta, a Ty tracisz dane do zwrotów i reklamacji.
Kiedy migracji nie robić: gdy stara platforma nie daje eksportu kluczowych danych (produkty z wariantami, opinie, zamówienia), gdy nie masz dostępu do bazy i plików, gdy dostawca odmawia wydania danych albo gdy panel działa tylko przez API bez dokumentacji. Wtedy taniej wychodzi wdrożenie od zera i ręczne przepisanie katalogu — z kontrolą jakości opisów przy okazji. Ramy takiego projektu opisujemy w sekcji o wdrożeniach i migracjach PrestaShop realizowanych dla firm w innych miastach.
| Kryterium | Wynik | Wniosek |
|---|---|---|
| Liczba SKU | do ok. 500, prosty katalog | przebudowa od zera zwykle tańsza |
| Liczba SKU | 2–3 tys. i więcej | migracja danych to główna pozycja budżetu |
| Moduły / wtyczki | 3–5, w tym własne | trzeba odtworzyć funkcje, licz +10–20 h |
| Moduły / wtyczki | 15+ bez dokumentacji | audyt przed wyceną, 20–40 h |
| Jakość danych | brak EAN, duplikaty kategorii | czyszczenie przed importem, +15–30 h |
| Koszt utrzymania | 300–800 zł/mies. na abonamenty | porównaj z kosztem 12 miesięcy |
Pracę wycenia się w godzinach, nie w tygodniach kalendarzowych. Proste wdrożenie na gotowym szablonie, z podstawowymi modułami płatności i kurierów, zamyka się w 60–100 godzinach. Wdrożenie z modułami niestandardowymi, integracjami i nietypowym checkoutem to 100–160 godzin. Migracja to 50–120 godzin zależnie od źródła danych, liczby SKU i zakresu integracji.
Wycena rośnie przewidywalnie. Multistore (2–3 sklepy na jednej instalacji) dodaje 30–60 h. Cenniki B2B i grupy klientów z indywidualnymi rabatami to 20–40 h. Integracja z ERP (Subiekt, Comarch, enova) to 40–100 h, bo trzeba uzgodnić mapowanie pól, stany magazynowe i kolejność synchronizacji. Niestandardowy moduł kurierski to 15–40 h, a import produktów bez EAN — 15–30 h na samo czyszczenie i wygenerowanie identyfikatorów.
O co pytasz w ofercie, żeby dała się zweryfikować: rozbicie na pozycje godzinowe (instalacja, szablon, moduły, import, testy, wdrożenie na produkcję), stawka za godzinę, stawka za prace poza zakresem (zwykle 1,3–1,5 raza wyższa niż podstawowa), limit korekt w cenie oraz to, co dokładnie zawiera utrzymanie po odbiorze — aktualizacje PrestaShop i modułów, wsparcie przy zmianach PHP, backupy i monitoring Core Web Vitals. Rozliczenie etapowe (np. 30% zaliczki, 40% po stagingu, 30% po odbiorze) działa na korzyść obu stron, bo wiąże płatność z widocznym efektem, a nie z deklaracją. Zapytaj też, ile godzin pochłonie organizacja projektu po Twojej stronie — przygotowanie zdjęć i opisów to zwykle drugie tyle pracy, co sam montaż sklepu.
| Zakres prac | Widełki godzinowe |
|---|---|
| Wdrożenie na gotowym szablonie, prosty katalog | 60–100 h |
| Wdrożenie z modułami niestandardowymi i integracjami | 100–160 h |
| Migracja z WooCommerce, IdoSell, Shopify | 50–120 h |
| Migracja z PrestaShop 1.6/1.7 | 50–90 h |
| Multistore (2–3 sklepy) | +30–60 h |
| Cenniki B2B i grupy klientów | +20–40 h |
| Integracja z ERP (Subiekt, Comarch, enova) | +40–100 h |
| Niestandardowy moduł kurierski | +15–40 h |
| Import danych bez EAN | +15–30 h |
Migracja rozjeżdża się prawie zawsze w tym samym miejscu: ktoś zaczyna przenosić dane, zanim zamknięto mapowanie URL-i. Utrzymanie kolejności poniższych etapów kosztuje mniej niż prostowanie tego po starcie.
Disallow: / w robots.txt i nagłówek X-Robots-Tag: noindex. Bez tego Google może zaindeksować kopie i konkurujesz sam ze sobą.Zakres i wycenę takich prac znajdziesz w opisie wdrożeń PrestaShop, a szersze spojrzenie na organizację projektu migracji — w osobnym materiale.
| Etap | Typowo | Kto pilnuje | Najczęstsze potknięcie |
|---|---|---|---|
| 1. Audyt | 8–16 h | wykonawca + firma | brak EAN i nazw zdjęć wychodzi dopiero przy imporcie |
| 2. Staging | 4–8 h | wykonawca | brak noindex — kopie sklepu w indeksie Google |
| 3. Mapowanie URL | 6–12 h zależnie od liczby adresów | wykonawca | mapowanie robione po przełączeniu DNS |
| 4. Dane | 20–60 h | wykonawca + firma | import zamówień przed produktami |
| 5. Hasła | 2–4 h | wykonawca | brak komunikatu o resecie hasła do klientów |
| 6. Integracje | 10–30 h | wykonawca + dostawca ERP | testy tylko na ścieżce szczęśliwej |
| 7. Testy odbiorcze | 8–16 h | wykonawca + firma | brak zamówienia na firmę z NIP |
| 8. DNS | 1–2 h aktywne, do 48 h propagacji | wykonawca + firma | przełączenie w środku dnia handlowego |
| 9. Monitoring | 28 dni | wykonawca + firma | brak osoby reagującej na błędy 500 |
Spadek ruchu po migracji rzadko jest „karą” od Google. Prawie zawsze to mechanika: zgubione przekierowanie, wyzerowane meta opisy, zdublowane adresy filtrów. Poniżej zestaw kontroli, które wyłapują to przed startem.
Praktyczny przebieg migracji z punktu widzenia SEO opisujemy szerzej w osobnym tekście.
| Kontrola | Co sprawdzić | Próg akceptacji |
|---|---|---|
| Mapowanie URL | każdy stary adres → jeden nowy, bez łańcuchów | 0 przekierowań kończących się na 404 |
| Sitemapa | generowana po migracji, bez adresów ze staging | zgodność z faktycznym stanem sklepu |
| Search Console | zgłoszenie sitemapy, zmiana adresu, raport Strony | monitoring przez 28 dni |
| Treści i meta | porównanie przed/po dla 20 kluczowych URL-i | brak pustych i zdublowanych opisów |
| Canonicale i filtry | canonical wskazuje bazową wersję kategorii | brak tysięcy adresów z parametrami w indeksie |
| Crawl | Screaming Frog na stagingu i 7 dni po starcie | spadek liczby błędów 4xx/5xx, nie wzrost |
Ścieżka szczęśliwa — jedno zamówienie, jeden produkt, płatność kartą — przechodzi niemal zawsze. Projekt pęka na scenariuszach brzegowych. Cztery obszary do sprawdzenia przed startem, nie po pierwszych zamówieniach.
Kurierzy: InPost ShipX, DPD, DHL. Sprawdź, czy wybrany punkt odbioru zapisuje się w zamówieniu i na etykiecie, a nie tylko w sesji klienta. Gabaryty: produkt 120 × 40 × 40 cm i 25 kg nie może dostać w koszyku metody Paczkomat — reguły wagi i wymiarów ustawiasz w konfiguracji wysyłki oraz na poziomie produktu. Pobranie (COD) testuj na kwocie obejmującej koszt dostawy i zweryfikuj, czy kwota na etykiecie zgadza się z kwotą pobrania. Zwroty: etykieta zwrotna i poprawny adres nadawcy.
Płatności: Przelewy24/PayU, BLIK, karty. Pełna ścieżka na kwocie 1 zł dla każdej metody. Obsługa płatności nieudanej: zamówienie nie może zostać oznaczone jako opłacone, a koszyk nie może się wyczyścić, zanim bramka potwierdzi transakcję. Sprawdź też zwrot środków za anulowane zamówienie — czy da się go wykonać z panelu i jaki status przyjmuje wtedy zamówienie.
ERP: Subiekt, WFirma, Comarch. Trzy pytania do dostawcy integracji: w którą stronę płyną stany magazynowe, kto wygrywa przy konflikcie i co się dzieje, gdy ERP jest niedostępny. Przy równoległej sprzedaży w sklepie i na marketplace dwa zamówienia mogą zejść z jednego stanu — jeśli integracja bezwarunkowo nadpisuje stany z ERP, sprzedasz towar, którego nie masz. Bezpieczniej rezerwować stan w PrestaShop i synchronizować różnice niż nadpisywać wartości. Faktury wystawia zwykle ERP — ustal, czy numeracja jest ciągła i czy data wystawienia zgadza się z przepisami.
Zanim zamówisz dedykowany moduł, sprawdź gotowe moduły PrestaShop. Sposób komunikacji modułu z koszykiem i zamówieniem opisuje dokumentacja dla deweloperów PrestaShop.
| Obszar | Scenariusz brzegowy | Co się dzieje, gdy nie jest przetestowany |
|---|---|---|
| Kurier | produkt 120 × 40 × 40 cm, 25 kg | klient wybiera Paczkomat, przesyłka wraca do sklepu |
| Kurier | pobranie (COD) na kwotę z dostawą | kwota na etykiecie nie zgadza się z zamówieniem |
| Płatności | płatność nieudana i powrót do sklepu | zamówienie bez opłaty oznaczane jako opłacone |
| Płatności | zwrot środków za anulowane zamówienie | ręczne księgowanie i bałagan w rozliczeniach |
| ERP | równoległa sprzedaż w sklepie i na marketplace | sprzedaż towaru, którego nie ma na stanie |
| ERP | ERP niedostępny przez 2 godziny | zamówienia bez faktur i bez aktualizacji stanów |
| Koszyk | 20 pozycji, w tym produkt bez stanu | błąd koszyka lub wysyłka niedostępnego towaru |
| Zamówienie | firma z NIP i wysyłka za granicę | brak NIP na fakturze, błędne stawki VAT |
Odbiór projektu to moment, w którym wiele firm przestaje patrzeć na sklep. Pierwsze 4–8 tygodni po starcie pokazuje, gdzie wdrożenie jest niedokończone. Zacznij od trzech progów, które warto wpisać do protokołu odbioru:
Te liczby liczy się w 75. percentylu realnych użytkowników (dane z raportu Core Web Vitals widoczne w Search Console), a nie z jednego przebiegu PageSpeed Insights. Sklep z wynikiem 95/100 w laboratorium potrafi mieć czerwony raport terenowy, bo telefon na 4G w Bydgoszczy zachowuje się inaczej niż serwer testowy w chmurze.
Warstwa techniczna do sprawdzenia przy odbiorze: OPcache włączony z pamięcią 128–256 MB (APC to rozwiązanie z czasów PHP 5 — na PHP 8.1/8.2 używa się OPcache plus APCu), PHP 8.1 lub 8.2, MySQL 8 / MariaDB 10.6+, CDN dla plików statycznych i zdjęć oraz cache PrestaShop w Zaawansowane parametry → Wydajność (Smarty, CCC). Przy katalogu 5–10 tys. produktów brak indeksów na tabelach ps_product_lang, ps_category_product i ps_product_attribute zamienia listing kategorii w zapytania po 3–6 sekund.
Administracja: kopia bazy i plików codziennie, ale raz na kwartał z testem odtworzenia na stagingu — kopia, której nikt nie odtworzył, nie jest kopią. Aktualizacje modułów i rdzenia najpierw na kopii, potem na produkcji. Monitoring: błędy 500, TTFB i dostępność sprawdzane co 1–5 minut z alertem na maila lub SMS.
Najczęstsze przyczyny zwolnień: brak indeksów przy tysiącach produktów, dziesiątki płatnych wtyczek (każda dorzuca zapytania do bazy i skrypty do frontu) oraz brak cache po stronie serwera. Zanim dokupisz kolejny moduł, sprawdź, czy wdrożenie PrestaShop zostało domknięte po stronie serwera i bazy.
Te pułapki nie wychodzą na demo. Wychodzą w pierwszym tygodniu po starcie albo przy pierwszej awarii — czyli wtedy, gdy sklep już zarabia i nie można go wyłączyć na spokojnie. Każdą z nich sprawdzisz w rozmowie z wykonawcą, przed podpisaniem umowy, jednym pytaniem.
Migracja na produkcji bez stagingu to najdroższy scenariusz. Jeśli w ofercie nie ma adresu testowego, przyjmij, że prace będą szły na żywym sklepie. Wystarczy jeden nieudany import kategorii, żeby listing przestał działać na kilka dni.
Brak testu płatności na realnej kwocie to drugi klasyk. Scenariusz testowy powinien obejmować: płatność 1 zł, płatność 100 zł, pełny zwrot, anulowanie, powtórne wejście w link po powrocie z bramki i sprawdzenie, czy zamówienie ma poprawny status oraz czy poszedł mail do klienta i do Ciebie.
Kopie zapasowe bez odtworzenia to kopia tylko na papierze. Żądaj pokazania procesu: odtworzenie bazy i plików na środowisku testowym, z datą kopii z przedwczoraj. Bez tego po awarii odbudowujesz katalog z plików CSV i zdjęć z dysku, co przy 3 tys. produktów zajmuje tygodnie.
Reszta sprowadza się do pieniędzy i czasu reakcji — patrz tabela. Przy podziale projektu na etapy warto porównać go z tym, jak wygląda wdrożenie i rozwój sklepu na PrestaShop w typowym zakresie 60–120 godzin.
| Pułapka | Jak wykryć | Skutek |
|---|---|---|
| Migracja na produkcji bez stagingu | Poproś o adres testowy i potwierdzenie, że ma tę samą wersję PHP i tę samą bazę co produkcja | Przerwa w sprzedaży liczona w dniach, spadek pozycji w Google |
| Brak testu płatności na realnej kwocie | Zapytaj o scenariusz: 1 zł, potem 100 zł, zwrot, anulowanie, webhook od operatora | Porzucone koszyki, zamówienia bez potwierdzenia, klient płaci i nie dostaje maila |
| Niesprawdzone kopie zapasowe | Żądaj odtworzenia z kopii na środowisku testowym przy Tobie | Po awarii utrata danych i ręczna odbudowa katalogu |
| Brak zdefiniowanego SLA | Zapytaj o czas reakcji na awarię krytyczną i kanały kontaktu (mail, telefon, panel zgłoszeń) | Sklep leży kilka dni, nikt nie odpowiada na zgłoszenia |
| Płatne wtyczki zamiast modułu pod proces firmy | Zapytaj o liczbę licencji rocznych, ich kwoty i to, kto je odnawia | Koszt rośnie z każdą wtyczką, bez kontroli nad budżetem |
Przy wdrożeniu PrestaShop lokalizacja ma mniejsze znaczenie niż proces. Większość prac wykonuje się zdalnie, a o jakości decyduje nie odległość biura, tylko to, czy wykonawca odpowiada konkretami na sześć pytań.
Kryteria pracy zdalnej. Wspólny kanał zgłoszeń (panel albo jedna skrzynka, nie prywatny komunikator jednego dewelopera), określone godziny dostępności, dostęp do repozytorium Git od pierwszego dnia i środowisko staging pod osobnym adresem z blokadą przed indeksowaniem. Jeśli tych czterech rzeczy nie ma w ofercie, dopisz je przed startem — nie w trakcie.
Kiedy bliskość ma sens. Trzy przypadki: integracja z magazynem i drukarki etykiet na miejscu, wdrożenia sprzętowe (kasy, terminale, czytniki) oraz szkolenie zespołu w siedzibie. Wtedy jeden dzień pracy na miejscu w Bydgoszczy skraca projekt o tydzień maili. Poza tymi sytuacjami szukaj kompetencji, nie adresu — porównanie z tym, jak opisujemy wdrożenia i migracje PrestaShop Szczecin dla firmy, pokazuje, że zakres i pytania są identyczne niezależnie od miasta.
Czerwone flagi w ofercie: brak widełek godzinowych (jedna kwota bez zakresu), brak jakiegokolwiek pytania o dane produktowe (EAN, liczba zdjęć, kategorie, atrybuty), obietnica „zrobimy wszystko” bez pytania o integracje, brak informacji, kto jest właścicielem kodu modułu i praw do niego. To ostatnie ureguluj zapisem w umowie — zgodnie z dokumentacją deweloperską PrestaShop moduł to zwykły kod PHP, więc nie ma technicznego powodu, by zostawał u wykonawcy.
| Pytanie | Dobra odpowiedź | Czerwona flaga |
|---|---|---|
| Kto konkretnie prowadzi projekt? | Imię i nazwisko dewelopera, bezpośredni kontakt | „Zespół projektowy”, brak nazwisk, kontakt tylko przez handlowca |
| Jaki jest czas reakcji na zgłoszenie? | Konkret: np. 4 h robocze zwykłe, 2 h krytyczne, wskazany kanał | „Odpowiadamy szybko” bez liczby |
| Jak wyceniacie — godziny czy ryczałt? | Widełki godzinowe z rozbiciem na etapy | Jedna kwota bez zakresu i bez limitu godzin |
| Co jest w zakresie po odbiorze? | 30 dni na poprawki w cenie, potem opieka w abonamencie | Brak okresu gwarancyjnego i brak ceny opieki |
| Kto jest właścicielem kodu modułu? | Kod i prawa przechodzą na klienta, repozytorium na jego koncie | „Moduł zostaje u nas” |
| Jakie mają pytania o moje dane? | EAN, liczba produktów, zdjęcia, integracje z ERP lub magazynem | Brak pytań o dane produktowe i integracje |
Prace migracyjne prowadzone bezpośrednio na produkcyjnym sklepie, zamiast na kopii staging.
Jak wykryć: Zapytaj wykonawcę, na jakim adresie testuje import i czy w tym czasie klienci mogą składać zamówienia na starym sklepie. Jeśli odpowiedź brzmi „na produkcji”, to sygnał ostrzegawczy.
Jak naprawić: Wymagaj w umowie środowiska staging z wyłączonym indeksowaniem (noindex + wpis w robots.txt + hasło na poziomie serwera) i zakazu zmian na produkcji do dnia przełączenia DNS.
Brak mapowania adresów URL i przekierowań 301 przygotowanych przed przełączeniem domeny.
Jak wykryć: Poproś o arkusz z kolumnami: stary URL, nowy URL, typ przekierowania, status. Jeśli wykonawca mówi, że „zrobi się to po starcie”, projekt jest źle ułożony.
Jak naprawić: Inwentaryzacja URL-i z sitemap.xml i crawla, mapowanie stary → nowy, gotowe reguły 301 wdrożone i przetestowane na stagingu jeszcze przed startem. Google opisuje zasady tworzenia treści i struktury dla ludzi w dokumentacji Search Central: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
Migracja haseł klientów bez planu na ich reset — potem połowa kont nie działa, a nikt o tym nie poinformował.
Jak wykryć: Sprawdź, czy oferta zawiera pozycję dotyczącą haseł i komunikacji do klientów. Jeśli nie ma tam ani słowa, temat został pominięty.
Jak naprawić: Przenosi się skróty haseł, nie hasła jawne — i tylko wtedy, gdy stara platforma używała zgodnego algorytmu. Bezpieczniej zaplanować wymuszony reset hasła przy pierwszym logowaniu i wysłać do klientów jasny e-mail z wyprzedzeniem.
Oferta bez rozbicia na pozycje godzinowe i bez stawki za prace poza zakresem.
Jak wykryć: Jeśli w ofercie widzisz jedną kwotę „za wdrożenie” bez liczby godzin, nie da się jej zweryfikować ani porównać z innymi ofertami.
Jak naprawić: Zażądaj rozbicia: instalacja, szablon i konfiguracja, strefy podatkowe i waluty, płatności, kurierzy, regulaminy, import danych, migracja, testy, przekierowania. Osobno dopisz stawkę godzinową za prace dodatkowe i zakres utrzymania po odbiorze.
Import danych z bałaganem w katalogu: duplikaty, brak EAN, brak jednostek miary, kategorie bez hierarchii.
Jak wykryć: Zrób prosty eksport do CSV i policz: ile wierszy bez EAN, ile produktów w kilku kategoriach jednocześnie, ile zdjęć bez powiązania z SKU. Jeśli braki przekraczają kilkanaście procent, masz problem.
Jak naprawić: Oczyść dane przed migracją, nie w trakcie. Ustal jeden identyfikator główny (SKU), uzupełnij EAN i jednostki, ustal hierarchię kategorii. Import brudnych danych kosztuje godziny i generuje błędy widoczne dla klientów.
Przełączenie DNS w szczycie ruchu i bez planu wycofania zmian.
Jak wykryć: Zapytaj o konkretną godzinę i dzień przełączenia oraz o to, jak długo utrzymywany będzie stary sklep w gotowości do powrotu.
Jak naprawić: Ustal okno poza godzinami największego ruchu, dzień wcześniej zrób pełny test zamówienia na stagingu, a stary sklep zostaw działający i opłacony przez co najmniej 2–4 tygodnie po starcie.
Wdrożenie i migracja PrestaShop to projekt, w którym da się zaplanować godziny, ale nie da się zaplanować wszystkiego za wykonawcę — dane produktowe, treści i decyzje handlowe zostają po stronie firmy. Jako punkt wyjścia przyjmij widełki 60–160 godzin dla wdrożenia i 50–120 godzin dla migracji, rozbite na pozycje w umowie. Zanim podpiszesz cokolwiek, ustal jedno: kto robi inwentaryzację URL-i, kto przygotowuje przekierowania 301 i na jakim środowisku pracujecie do dnia startu. Jeśli masz na to odpowiedzi, ryzyko projektu spada bardziej niż przy jakimkolwiek rabacie w ofercie.
Nie. Wdrożenie i migracja PrestaShop odbywają się zdalnie — cała praca toczy się na serwerze, w panelu i w repozytorium kodu. Jeśli ktoś proponuje Ci wycenę z doliczonym czasem dojazdu, zapytaj, jakie zadanie wymaga obecności na miejscu. W praktyce zamiast wizyty liczą się trzy rzeczy: dostępy do serwera i paneli, ustalony kanał komunikacji oraz zapisany czas reakcji na pytania i awarie.
Widełki godzinowe to zwykle 50–120 godzin pracy wykonawcy, zależnie od źródła danych, liczby SKU i zakresu integracji. Do tego dochodzi czas po stronie firmy: uzupełnienie brakujących danych, akceptacje na stagingu, decyzje o kosztach wysyłki. Projekty rozjeżdżają się najczęściej nie na kodzie, tylko na czekaniu na materiały i zatwierdzenia. Realistycznie licz się z tym, że sam kalendarz projektu będzie dłuższy niż suma godzin z oferty.
Przenosi się skróty haseł, nigdy hasła jawne — nikt ich nie powinien mieć w ręku. To zadziała tylko wtedy, gdy stara platforma używała algorytmu, który PrestaShop obsługuje; w innych przypadkach klienci i tak będą musieli ustawić nowe hasło. Bezpieczniej przyjąć wariant z wymuszonym resetem i wysłać do klientów jasną informację przed startem. Milczenie w tej sprawie kończy się telefonami do obsługi w pierwszym dniu po przełączeniu.
Jeżeli przekierowania 301 są gotowe przed przełączeniem DNS, a struktura kategorii i treści nie została przepisana bez sensu, spadek pozycji jest zwykle przejściowy — od kilku dni do kilku tygodni. Ryzyko rośnie, gdy adresy URL zmieniają się bez mapowania, a stary sklep zostaje wyłączony tego samego dnia. Zadbaj też o to, żeby nowy sklep był szybki i miał poprawne dane strukturalne produktów, bo oba elementy wpływają na widoczność w wynikach.
Gdy katalog jest mały i prosty — orientacyjnie do około 500 SKU — przebudowa z gotowym szablonem jest zwykle szybsza i tańsza niż porządkowanie i przenoszenie starych danych. Drugi przypadek to brak dostępu do bazy i plików starej platformy albo brak eksportu kluczowych danych. Wtedy migracja oznacza ręczne przepisywanie treści, co kosztuje więcej niż start od zera z nowym katalogiem.
Widełki zależą od stawki wykonawcy, więc sensowniej rozmawiać o godzinach: proste wdrożenie z gotowym szablonem to około 60–100 godzin, wdrożenie z modułami niestandardowymi około 100–160 godzin, migracja około 50–120 godzin. Koszt podnoszą multistore, cenniki B2B i grupy klientów, integracja z ERP, niestandardowe moduły kurierskie oraz import danych bez EAN. Zawsze proś o rozbicie oferty na pozycje — jedna kwota bez godzin jest niemożliwa do zweryfikowania.
Jeśli chcesz sprawdzić, czy Twój przypadek to wdrożenie, czy migracja, i jakie to ma przełożenie na godziny, napisz do nas — zaczynamy od krótkiej rozmowy o danych i zakresie, bez zobowiązań. Zobacz też nasze wdrożenia PrestaShop oraz porównywalne realizacje w innych miastach: Szczecin i Zamość.