Wdrożenie i migracja PrestaShop w Hrubieszowie to przede wszystkim projekt organizacyjny, a nie logistyczny. Deweloper nie musi siedzieć w tym samym mieście — musi mieć jasny zakres, terminy i punkty akceptacji. W praktyce 80% opóźnień bierze się z decyzji, które klient i wykonawca odkładają, a nie z odległości. Poniżej rozkładamy organizację na części: błędne założenia, listę kontrolną, harmonogram i odpowiedzi na pytania, które padają najczęściej.
Wdrożenie i migracja to dwa różne projekty, które w ofertach często lądują w jednym worku. Wdrożenie oznacza sklep budowany od zera lub na nowej, czystej bazie — nie ma się do czego odnosić, więc decyzje o strukturze kategorii, atrybutach i cenach zapadają w trakcie. Migracja to przeniesienie istniejącego sklepu wraz z produktami, klientami, zamówieniami i konfiguracją modułów. Tutaj praca zaczyna się od inwentaryzacji tego, co już macie.
Realne widełki czasowe: prosty sklep (jedna wersja językowa, jedna płatność online, standardowy motyw) to 40–80 godzin dewelopera. Sklep z wariantami, kilkoma cennikami, kurierami i integracją magazynową — 120–200 godzin. Sklep B2B z ERP i cennikami per kontrahent — 200–400 godzin. Godziny liczymy od momentu, w którym klient dostarczy dane produktowe i decyzje, nie od podpisania umowy.
Co zmienia lokalizacja? Niedużo. Deweloper pracuje zdalnie na środowisku staging, a na miejscu w Hrubieszowie robimy jednodniowy warsztat startowy — 6–8 godzin przy jednym stole, z listą kategorii, atrybutów i przewoźników. To tańsze niż trzy tygodnie pytań mailowych. Dalej wystarczy zgłoszenie w systemie ticketowym i cotygodniowy call 30 minut. Jakość kodu i czas reakcji nie zależą od geografii, tylko od zapisu w umowie: np. reakcja do 4 godzin w dni robocze. Wymagania środowiska (PHP, baza, wersja PrestaShop) opisuje dokumentacja dla deweloperów PrestaShop.
Największa pułapka nie jest logistyczna — to brak zdjęć i opisów po stronie klienta. To one wstrzymują start, a nie odległość między Hrubieszowem a biurem wykonawcy. Punkt odniesienia dla podobnych projektów znajdziecie w naszych materiałach o organizacji wdrożenia i migracji PrestaShop w Narolu oraz w opisie organizacji projektu wdrożenia PrestaShop w Lublinie.
| Kryterium | Wdrożenie od zera | Migracja |
|---|---|---|
| Punkt startowy | brak bazy, struktura ustalana w trakcie projektu | istniejące produkty, klienci, zamówienia, moduły |
| Typowy czas pracy | 40–200 h | 60–250 h, zależnie od jakości danych |
| Główne ryzyko | przeciągające się decyzje o kategoriach i atrybutach | przeniesienie starych błędów i porzuconych modułów |
| Kiedy wybór ma sens | nowy kanał sprzedaży albo zmiana modelu sprzedaży | sklep działa, ma ruch i historię zamówień |
Zanim zamówicie migrację, zróbcie sześć testów na kopii bazy. Każdy z nich daje liczbę, nie opinię.
Kiedy przenosimy tylko dane? Gdy historia zamówień nie jest już potrzebna (np. nie obsługujecie zwrotów starszych niż 12 miesięcy), gdy katalog jest mały (poniżej 500 produktów) albo gdy część zamówień chcecie trzymać w archiwum. Wtedy produkty, klienci i kategorie idą do nowego sklepu, a zamówienia eksportujecie do CSV i wystawiacie na subdomenie archiwum z parametrem noindex.
Jak te same testy wypadają w mniejszych bazach, pokazujemy przy okazji organizacji migracji PrestaShop w Bełżcu i organizacji wdrożenia PrestaShop w Biłgoraju.
| Test | Co sprawdzamy | Próg decyzyjny |
|---|---|---|
| Baza produktów | produkty bez zdjęć, duplikaty SKU, brak kategorii | powyżej 15% bez zdjęć → nowe wdrożenie z importem CSV |
| Osierocone rekordy | ps_product_attribute, ps_attribute, ps_product_attribute_combination | tysiące wierszy → czyszczenie przed importem |
| Moduły | wsparcie PS 8/9 i PHP 8.1+, data ostatniej aktualizacji | brak wydania od 3 lat → przepisanie |
| Szablon | Smarty (1.6) vs Twig (1.7+) | stary motyw → przepisanie 40–120 h |
| Koszt utrzymania | hosting, aktualizacje, łatanie błędów, przestoje | roczny koszt starej platformy zbliżony do kosztu wdrożenia |
| Proces ręczny | faktury, stany, potwierdzenia obsługiwane ręcznie | kilkadziesiąt zamówień miesięcznie → integracja |
Poniższy harmonogram dotyczy projektu o nakładzie 120–200 godzin. Wszystkie wartości to dni robocze, nie kalendarzowe.
Do sumy dodajcie bufor 15–20%. Jeśli wyliczenie daje 60 dni roboczych, harmonogram piszcie na 70. Bufor nie jest zapasem na wszelki wypadek — to czas na poprawki po testach akceptacyjnych, które zawsze się pojawiają.
Punkty akceptacji działają tylko wtedy, gdy są pisemne. Zasada: brak maila z akceptacją etapu blokuje przejście do następnego. To chroni terminy obu stron i przenosi odpowiedzialność za decyzje na osobę, która je podejmuje. Podobny układ etapów stosujemy przy organizacji wdrożenia PrestaShop we Frampolu i przy organizacji migracji PrestaShop w Józefowie.
| Etap | Dni robocze | Odpowiedzialny | Punkt akceptacji |
|---|---|---|---|
| Discovery i warsztat | 3–5 | deweloper + klient | protokół i backlog zatwierdzone mailem |
| Staging | 2–3 | deweloper | działające środowisko testowe |
| Konfiguracja sklepu | 5–10 | deweloper, treści po stronie klienta | podpisana lista kontrolna ustawień |
| Integracje | 5–15 | deweloper + klient (dostępy) | testowe zamówienie przepuszczone przez ERP |
| Migracja danych | 3–7 | deweloper | raport zgodności liczby rekordów |
| Testy akceptacyjne | 5–10 | klient testuje, deweloper poprawia | lista błędów zamknięta |
| Start produkcyjny | 1–2 | deweloper | potwierdzenie działania na domenie |
Migracja danych to nie „przeniesienie bazy”, tylko mapowanie pól. Zanim ruszy import, przygotuj arkusz z kolumnami: tabela źródłowa, pole źródłowe, pole docelowe, reguła konwersji, osoba decydująca. Nazwy tabel w PrestaShop nie są tajemnicą — opisuje je dokumentacja dla deweloperów PrestaShop, więc nie ma powodu ich zgadywać. Jedno spotkanie na mapowanie oszczędza tydzień poprawek po starcie.
Najczęściej gubią się cztery rzeczy: warianty i kombinacje (produkt wchodzi jako jeden — klient nie ma czego wybrać), tłumaczenia (pola z id_lang, brak opisów w drugim języku), galerie zdjęć (kolejność z ps_image.position, zdjęcia przypisane do kombinacji) i ceny po promocji (ps_specific_price z zakresem dat — przeniesiesz cenę bazową, rabaty znikną). Stany magazynowe w ps_stock_available trzymane są per kombinacja, nie per produkt.
| Element | Gdzie siedzi w bazie | Objaw po pominięciu |
|---|---|---|
| Warianty i kombinacje | ps_product_attribute, ps_product_attribute_combination | produkt wchodzi jako jeden, brak wyboru rozmiaru |
| Tłumaczenia | ps_product_lang (id_lang) | brak opisów w drugiej wersji językowej |
| Galeria zdjęć | ps_image (position) | losowa kolejność zdjęć, brak zdjęć kombinacji |
| Ceny promocyjne | ps_specific_price (from/to) | ceny wracają do poziomu bazowego |
| Stany magazynowe | ps_stock_available | sprzedaż produktu, którego fizycznie nie ma |
Tabela przekierowań 301 (stary URL → nowy URL) musi być gotowa i sprawdzona przed dniem startu, nie po nim. Adresy zbierz crawlem starego serwisu (darmowy Screaming Frog przepuszcza 500 URL-i, większy sklep wymaga licencji) oraz z Google Search Console. Produkty, które nie przechodzą na nową platformę, kieruj 301 na najbliższą kategorię; te trwale wycofane — na 410. Miękkie 404 prowadzące na stronę główną to najkrótsza droga do utraty pozycji.
Dane klientów i historia zamówień wymagają umowy powierzenia przetwarzania (art. 28 RODO): zakres danych, cel, czas retencji, sposób usunięcia po zakończeniu prac. Dokumenty księgowe musisz trzymać 5 lat, więc historia zamówień zostaje w całości. Haseł nie przenoś „na siłę” — przy nowej instalacji zmienia się klucz szyfrowania i klienci i tak ustawiają nowe; przygotuj wcześniej masową wysyłkę z linkiem do resetu.
Test po migracji: 20 losowo wybranych starych adresów sprawdzonych pod kątem 301, 5 pełnych ścieżek zakupowych (gość, konto, kod rabatowy, płatność, e-mail potwierdzający) oraz przegląd Search Console po 24 i 72 godzinach — nowe 404 i spadek liczby zaindeksowanych adresów. Ten sam schemat opisujemy w organizacji wdrożeń i migracji PrestaShop w Lublinie, a różnice wynikające z liczby języków i kategorii — w wdrożeniach i migracjach PrestaShop w Biłgoraju.
Kolejność podłączania nie jest przypadkowa: płatności → kurierzy → faktury → magazyn/ERP. Każda następna integracja zależy od poprzedniej. Faktura musi znać status płatności, a ERP musi dostać jednocześnie zamówienie, fakturę i zaktualizowany stan magazynowy. Odwrotna kolejność kończy się ręcznym poprawianiem dokumentów przez pierwsze tygodnie.
Przed dniem startu zrób na produkcji jedną realną płatność (najtańszy produkt, nie tryb testowy) i wyślij jedną realną przesyłkę na własny adres. Sprawdź cały łańcuch: e-mail potwierdzający, status w panelu operatora płatności, zmianę statusu zamówienia w PrestaShop, wygenerowaną etykietę i numer trackingu widoczny dla klienta w historii zamówienia.
| Integracja | Dowód, że działa przed startem |
|---|---|
| Płatności | jedna realna transakcja, status „opłacone” w panelu operatora i w PrestaShop |
| Kurierzy | jedna realna przesyłka na własny adres, numer trackingu w historii zamówienia |
| Faktury | faktura wygenerowana z realnego zamówienia, poprawny NIP i numeracja |
| Magazyn / ERP | stan po zamówieniu zsynchronizowany w obie strony, bez ręcznej korekty |
Gotowy moduł czy własny? Kryteria są cztery: licencja (czy wolno modyfikować kod i czy nie wygasa), model wsparcia (kto odpowiada za błąd i w jakim czasie), aktualizacje (jak często i czy działają na PHP 8.x oraz PrestaShop 8) oraz zależność od abonamentu — co się stanie, gdy przestaniesz płacić. Jeśli po nieopłaceniu subskrypcji sklep przestaje wystawiać faktury, to nie jest integracja, tylko dzierżawa. Własny moduł pisz tylko wtedy, gdy proces jest nietypowy i żaden gotowy go nie obsłuży; w pozostałych przypadkach kupuj i płać za wsparcie.
Najczęstszy błąd konfiguracyjny to klucze sandbox zostawione na produkcji. InPost ShipX i bramki płatności mają osobne środowiska testowe i produkcyjne. Objaw: w testach wszystko przechodzi, a na produkcji transakcja się nie tworzy albo nie generuje się etykieta. Checklista na dzień przed startem: klucze produkcyjne, produkcyjny adres webhooka, whitelista IP po stronie operatora, aktualny certyfikat SSL. Ten sam schemat integracji sprawdzaliśmy przy organizacji wdrożenia PrestaShop w Narolu — kolejność prac jest identyczna niezależnie od skali sklepu.
Progi trzymaj na 75. percentylu realnych użytkowników: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Mierz na telefonie i na danych użytkowników (CrUX w Search Console), nie w Lighthouse na laptopie w biurze — wynik laboratoryjny bywa o połowę lepszy od tego, co widzi klient. Sposób liczenia tych wskaźników opisuje web.dev – Core Web Vitals.
Sprawdź warstwy po kolei: PHP 8.x z włączonym OPcache (opcache.enable=1), cache obiektów Redis lub Memcached podłączony do sklepu, CDN dla statyków i obrazów, kompresja Brotli lub gzip, obrazy w WebP z srcset, lazy loading poza pierwszym ekranem. Nie lazy-loaduj obrazu LCP — to najczęstszy samobój wydajnościowy po wdrożeniu.
| Warstwa | Co ustawić | Gdzie sprawdzić |
|---|---|---|
| PHP | wersja 8.x, OPcache włączony | phpinfo(), panel hostingu |
| Cache obiektów | Redis albo Memcached podłączony do PrestaShop | Zaawansowane → Wydajność |
| CDN | statyki i obrazy, długi cache-control | nagłówki odpowiedzi (curl -I) |
| Obrazy | WebP, srcset, lazy loading poza ekranem | PageSpeed Insights, DevTools |
| Staging | hasło, noindex, osobny robots.txt | curl -I w dniu startu |
Staging musi być zablokowany na trzech poziomach: hasło na serwerze, noindex (nagłówek X-Robots-Tag albo meta robots) i osobny robots.txt. W dniu startu zdejmij blokadę i sprawdź to, a nie załóż: curl -I na adresie produkcyjnym nie może zwracać nagłówka noindex. Zostawiony noindex to cichy zgon sklepu — strona działa, klienci wracają z newslettera, ale wypadasz z wyników wyszukiwania.
Monitoring pierwszych 30 dni obejmuje cztery liczby: nowe błędy 404 (Search Console → Indeksowanie), liczbę zaindeksowanych adresów, czas odpowiedzi serwera (TTFB) i koszyki bez zamówienia. Wzrost porzuconych koszyków przy pogarszającym się TTFB to prawie zawsze problem z płatnością albo wysyłką, nie z cenami. Sprawdź też, czy dane strukturalne produktów (cena, dostępność, opinie) przechodzą walidację — inaczej tracisz rozszerzone wyniki dla kart produktów.
Kolejność sprawdzeń w pierwszym tygodniu po starcie jest zawsze taka sama. Opisujemy ją również dla mniejszych wdrożeń, np. w organizacji wdrożenia PrestaShop w Bełżcu.
Większość wdrożeń, które ratujemy po poprzednich wykonawcach, nie upadła na technologii, tylko na czterech rzeczach, które da się wykryć przed startem. Ten sam zestaw punktów kontrolnych stosujemy przy organizacji wdrożenia PrestaShop w Biłgoraju i w każdym innym mieście — różni się tylko harmonogram.
1. Staging na nieaktualnej bazie produkcyjnej. Jeśli środowisko testowe powstało z dumpa sprzed trzech tygodni, testy są bezwartościowe. Objaw: klient szuka w wersji testowej produktu, który dodał wczoraj, i go nie znajduje, brakuje kategorii, cen i stanów magazynowych. Test kontrolny: świeży dump, a potem porównanie SELECT COUNT(*) na ps_product, ps_category i ps_orders po stronie produkcji i stagingu. Różnica powyżej 1–2% oznacza, że staging trzeba odtworzyć. Ustal, że dump nie może być starszy niż 48 godzin przed testami akceptacyjnymi.
2. Wyłączona poczta transakcyjna i brak SPF, DKIM, DMARC. Objaw: zamówienie testowe przechodzi, ale mail do klienta nie dochodzi albo ląduje w spamie lub w zakładce „Oferty” w Gmailu. Wykrycie: wyślij test na Gmaila, Outlooka i skrzynkę firmową, sprawdź nagłówek Authentication-Results — potrzebne są spf=pass, dkim=pass, dmarc=pass. W PrestaShop w Zaawansowanych parametrach → E-mail sprawdź, czy wysyłka idzie przez SMTP, a nie przez mail() z serwera.
3. Moduły z licencją przypisaną do starej domeny lub serwera. Objaw: po przenosinach moduł płatności, fakturowania albo feedu przestaje się łączyć, w logach pojawia się błąd autoryzacji licencji. Wykrycie: dwa tygodnie przed startem zrób inwentarz modułów i przejdź przez nie po kolei, pytając dostawcę, czy licencja jest domenowa i co trzeba przepisać.
4. Brak dostępu do repozytorium i dokumentacji po zakończeniu projektu. Objaw: klient nie ma repo, nie wie, gdzie stoi staging, nie zna haseł, a każda zmiana wymaga kontaktu z jednym wykonawcą. Wykrycie: przed odbiorem poproś o to, co dostałby nowy wykonawca, i sprawdź, czy da się z tego postawić kopię sklepu. Ten test zajmuje pół dnia i pokazuje realny poziom uzależnienia.
| Pułapka | Objaw | Test przed startem |
|---|---|---|
| Staging ze starego dumpa | Brakuje produktów dodanych w ostatnich tygodniach | Porównanie COUNT(*) w ps_product, ps_category, ps_orders |
| Poczta bez SPF/DKIM/DMARC | Maile o zamówieniu w spamie lub nie dochodzą | Wysyłka testowa na Gmail/Outlook + nagłówek Authentication-Results |
| Licencje modułów na starą domenę | Integracja pada po przenosinach | Inwentarz modułów i potwierdzenia od dostawców |
| Brak repozytorium i dokumentacji | Każda zmiana przez jednego wykonawcę | Próba postawienia kopii sklepu z przekazanych materiałów |
Cena za „sklep na PrestaShop” nie istnieje. Istnieje stawka godzinowa pomnożona przez liczbę godzin i zakres. Poniżej orientacyjne przedziały, jakie spotykamy w ofertach na polskim rynku — traktuj je jako punkt odniesienia przy porównywaniu propozycji, nie jako cennik. Sposób liczenia jest ten sam, co przy organizacji wdrożenia PrestaShop w Lublinie.
Stawka 60–80 zł/h przy migracji oznacza zwykle jedno z dwóch: brak doświadczenia albo brak godzin w ofercie, które wrócą na fakturach dodatkowych. To nie oszczędność, tylko koszt przesunięty w czasie.
Co podnosi liczbę godzin, zanim ktokolwiek napisze linijkę kodu: liczba kombinacji produktów (jeden produkt w 5 kolorach i 20 rozmiarach to 100 wariantów do wygenerowania i utrzymania), import danych z CSV lub XML z mapowaniem pól, kategorii, atrybutów i zdjęć, każda integracja — płatności, kurier, ERP, feed — oraz moduły niestandardowe, które trzeba napisać i utrzymać przy aktualizacjach.
Koszty, o których zapomina się w wycenie: licencje modułów, szablon i jego późniejsze wsparcie, hosting (VPS kontra shared), certyfikat SSL, wreszcie przestój w dniu startu. Sklep robiący 2 000 zł obrotu dziennie i dwie godziny przerwy w środku dnia traci około 170 zł obrotu — plus klientów, którzy nie wrócą.
Pytania do każdej oferty: ile godzin i czy to szacunek, czy cena stała; co dokładnie wchodzi w zakres; co jest poza zakresem; kto płaci za poprawki po odbiorze i przez ile dni; jaka stawka obowiązuje za godziny ponad zakres.
| Scenariusz | Zakres | Szacunek godzin | Budżet przy 150 zł/h netto |
|---|---|---|---|
| Sklep startowy | do 500 produktów, gotowy szablon, 3–5 modułów, jeden język | 60–120 h | 9 000–18 000 zł |
| Sklep rosnący | 500–5 000 produktów, import z pliku, płatności i kurier/ERP, modyfikacje szablonu | 150–300 h | 22 500–45 000 zł |
| Multi-store / B2B | kilka sklepów lub języków, moduły własne, integracja z magazynem | 350–600 h | 52 500–90 000 zł |
Wdrożenie kończy się odbiorem. Opieka to osobna umowa i osobny zestaw liczb. Model opieki opisujemy też przy organizacji wdrożenia PrestaShop w Narolu — różnica jest w skali, nie w zasadach.
SLA. Minimalny sensowny zestaw: czas reakcji (np. 4 godziny w dni robocze dla awarii krytycznej, 1 dzień roboczy dla pozostałych zgłoszeń), czas naprawy (od 4 godzin do 3 dni roboczych), jeden kanał zgłoszeń — mail albo system ticketowy, nie Messenger — oraz godziny wsparcia, np. 8:00–16:00 w dni robocze. Do tego definicja awarii krytycznej: sklep nie przyjmuje zamówień, płatności nie działają, baza nie odpowiada. Wszystko poza tą definicją to zwykłe zgłoszenie i inne SLA. Ustal też limit: pakiet 5 godzin miesięcznie albo abonament oraz stawkę za godziny ponad pakiet.
Backupy. Codziennie baza, pliki codziennie lub po każdej zmianie, retencja 14–30 dni, kopia poza serwer produkcyjny (inny dostawca lub storage obiektowy). Najważniejszy punkt to jedno udokumentowane odtworzenie kopii. Nie „mamy backupy”, tylko „odtworzyliśmy sklep z kopii, zajęło to 40 minut, protokół jest w załączniku”.
Aktualizacje. Kwartalnie PrestaShop, PHP i moduły, zawsze najpierw na stagingu, w oknie serwisowym poza godzinami sprzedaży. Przed podniesieniem PHP sprawdź macierz zgodności modułów w dokumentacji deweloperskiej PrestaShop — zwłaszcza modułów płatności i fakturowania. Zapisz to w umowie jako obowiązek wykonawcy, a nie działanie „w razie potrzeby”.
Właściciel hostingu i domeny. Umowa powinna wprost mówić, że domena i hosting należą do klienta, faktury są wystawiane na klienta, a wykonawca ma wyłącznie dostępy techniczne, które traci po zakończeniu współpracy. Jeśli domena jest zarejestrowana na wykonawcę, zmiana dostawcy wymaga jego dobrej woli.
| Element umowy | Minimum, które warto zapisać | Dlaczego to ma znaczenie |
|---|---|---|
| Backup bazy | Codziennie, retencja 14–30 dni, kopia poza serwerem produkcyjnym | Awaria serwera nie zabiera razem danych i kopii |
| Test odtworzenia | Co najmniej raz w roku, z krótkim protokołem | Backup bez testu to założenie, nie zabezpieczenie |
| Aktualizacje | Kwartalnie, na stagingu, w oknie serwisowym | Zamiast gaszenia awarii po wyjściu łatek bezpieczeństwa |
| Domena i hosting | Własność klienta, dostępy techniczne dla wykonawcy | Zmiana wykonawcy nie wymaga negocjacji o dostęp |
Brak pisemnej akceptacji etapów — projekt toczy się na czacie i ustnych ustaleniach.
Jak wykryć: Nie potrafisz wskazać maila, w którym klient zatwierdził discovery, konfigurację sklepu ani integracje. Wszystkie ustalenia są rozproszone po rozmowach.
Jak naprawić: Wprowadź zasadę: brak akceptacji mailowej = nie przechodzimy do kolejnego etapu. Jeden krótki mail na etap chroni termin obu stronom i ucina spory typu „ja myślałem, że to już zamknięte”.
Zakładanie, że wszystkie moduły ze starego sklepu zadziałają w PrestaShop 8 lub 9.
Jak wykryć: Zrób listę modułów: nazwa, autor, data ostatniej aktualizacji, zadeklarowana kompatybilność. Wtyczka bez zmian od trzech lat to czerwona flaga.
Jak naprawić: Dla każdego modułu wybierz jedną z trzech dróg: aktualizacja, zamiennik z rynku, napisanie modułu na nowo. Moduły płatności i kurierów wymień zawsze — stare wersje API to najczęstsza przyczyna przesunięcia startu.
Migrowanie wszystkiego, łącznie z historią zamówień sprzed kilku lat.
Jak wykryć: Import bazy trwa nocami, liczba rekordów rośnie, a nikt nie potrafi powiedzieć, ile zamówień faktycznie trzeba przenieść i do czego posłużą.
Jak naprawić: Rozdziel dwie decyzje: katalog, klienci i kategorie idą do nowego sklepu, historia zamówień zostaje w starym jako archiwum do odczytu. Ustal to przed discovery, nie w trakcie importu.
Brak tabeli przekierowań 301 przygotowanej przed dniem startu.
Jak wykryć: W dniu premiery nowego sklepu nie ma pliku z mapowaniem starych adresów na nowe. Ktoś mówi: „zrobimy później, jak będą błędy w Search Console”.
Jak naprawić: Tabelę stary URL → nowy URL przygotowuj razem z migracją danych i wdrażaj w momencie przełączenia domeny. Przekierowania dodane po tygodniu oznaczają utratę ruchu, którego nie odzyskasz.
Start bez realnej płatności i realnej przesyłki testowej.
Jak wykryć: Testy kończą się na etapie „moduł się instaluje i pokazuje formularz”. Nie ma pojedynczej transakcji na produkcji ani jednej etykiety wysłanej na własny adres.
Jak naprawić: Przed startem wykonaj jedną prawdziwą płatność na minimalną kwotę i wyślij jedną paczkę do siebie. Dopiero wtedy uznaj integrację za działającą.
Harmonogram bez bufora na poprawki po testach akceptacyjnych.
Jak wykryć: Plan kończy się dokładnie w dniu startu, a testy akceptacyjne są zaplanowane na dwa dni przed. Każda uwaga klienta z definicji przesuwa premierę.
Jak naprawić: Dolicz 15–20% czasu na poprawki po testach i nie licz tego bufora jako zapasu na opóźnienia po stronie klienta. To osobna pozycja w harmonogramie, nie ukryta rezerwa.
Organizacja wdrożenia lub migracji PrestaShop w Hrubieszowie sprowadza się do trzech rzeczy: zapisanych etapów, pisemnych akceptacji i tabeli przekierowań gotowej przed startem. Lokalizacja nie zmienia jakości kodu ani czasu reakcji — zmienia tylko potrzebę uporządkowanej komunikacji. Każdy etap bez akceptacji to ryzyko przesunięcia całego harmonogramu. Zaplanuj też bufor 15–20% na poprawki i uwzględnij go w terminie, który obiecujesz sobie i klientom.
Prosty sklep z jednym językiem i podstawowymi płatnościami to zwykle 40–80 godzin pracy. Sklep z wariantami, kilkoma metodami dostawy i integracjami schodzi w okolice 120–200 godzin. Projekt z ERP, cennikami B2B i logiką rabatową to 200–400 godzin. Do tego dolicz 15–20% na poprawki po testach akceptacyjnych.
Nie. Jakość kodu, czas reakcji i terminowość nie zależą od odległości, a od zakresu i punktów akceptacji. Sensowny kompromis to jedno spotkanie startowe na miejscu, a resztę prowadzić zdalnie na środowisku testowym. Ten sam model stosujemy w projektach dla firm z Narolu (organizacja projektu) i z Lublina (organizacja projektu).
Rozstrzygają trzy testy: baza, moduły i szablon. Jeśli w katalogu jest dużo duplikatów SKU, produkty bez zdjęć, a połowa modułów nie ma wsparcia dla PrestaShop 8/9, przenoszenie starego bałaganu mija się z celem. Jeżeli dane są czyste, a integracje działają, migracja jest tańsza i szybsza.
Najczęściej przenosimy katalog, klientów, adresy i kategorie, a historię zamówień zostawiamy w starym sklepie jako archiwum do odczytu. Import tysięcy starych zamówień wydłuża projekt i zwiększa ryzyko błędów, a rzadko wnosi wartość dla klienta. Zakres migrowanych danych osobowych ustalamy w umowie powierzenia przetwarzania.
Przed dniem startu, nie po nim. Tabelę stary URL → nowy URL budujesz razem z migracją danych, a wdrażasz w momencie przełączenia domeny. Po starcie sprawdzasz 20 losowo wybranych adresów, pięć pełnych ścieżek zakupowych i przegląd błędów w Google Search Console po 24 oraz 72 godzinach.
Kolejność podłączania to płatności, kurierzy (InPost, DPD, DHL), faktury, a na końcu magazyn lub ERP — każda następna zależy od poprzedniej. Największe ryzyko siedzi w ERP i modułach płatności, bo wymagają uzgodnień z zewnętrznym dostawcą. Dlatego test na produkcji: jedna realna płatność i jedna przesyłka na własny adres, musi się odbyć przed dniem startu.
To zależy od dwóch liczb: rocznego kosztu utrzymania starej platformy i jednorazowego kosztu wdrożenia. Stary sklep generuje stały wydatek — łatanie błędów, brak aktualizacji bezpieczeństwa, moduły bez wsparcia. Nowe wdrożenie to wydatek jednorazowy i zwykle niższy koszt opieki w kolejnych latach, ale wymaga porównania na Twoich danych, nie na ogólnikach.
Jeżeli chcesz przejść przez wdrożenie lub migrację PrestaShop z jasnym harmonogramem i punktami akceptacji, napisz do nas — powiemy wprost, co da się zrobić w Twoim zakresie i terminie.