Wdrożenie i migracja PrestaShop brzmią podobnie, ale to dwa różne projekty: pierwsze buduje sklep od zera, drugie przenosi istniejący. W liczbach wygląda to tak: nowe wdrożenie to zwykle 40–80 godzin, migracja z 1.6 do 8.x to 60–100 godzin, a przejście z WooCommerce, Shopera czy sklepu pisanego pod zamówienie potrafi zająć 80–140 godzin. Poniżej porządkujemy stronę organizacyjną: jak odróżnić jedno od drugiego, ile to realnie trwa i kosztuje w regionie lubelskim oraz co przygotować, zanim podpiszesz zlecenie. Przykład uporządkowania takiego projektu na mniejszym rynku opisaliśmy we wpisie o wdrożeniach i migracjach PrestaShop Biłgoraj.
Rozmowa z klientem często zaczyna się tak: „chcę migrację sklepu na PrestaShop”, a po pięciu minutach okazuje się, że sklepu jeszcze nie ma. To wdrożenie. Różnica jest prosta, ale wprost przekłada się na budżet.
Wdrożenie to zbudowanie sklepu od zera: instalacja PrestaShop 8.x, konfiguracja środowiska, szablon, moduły, produkty, testy. Migracja to przeniesienie istniejącego sklepu — na nowszą wersję, na inną platformę albo na inny serwer. Nie ma tu pracy „od zera”, jest praca „z tym, co zastaniemy”, a to zwykle więcej niewiadomych i większe ryzyko.
Standardowe wdrożenie na PrestaShop 8.x obejmuje:
Migracje dzielą się na trzy typy: wersji (1.6 → 8.x), platformy (WooCommerce, Shoper, sklep pisany pod zamówienie → PrestaShop) i hostingową (ta sama wersja, nowy serwer). Godziny różnią się drastycznie: nowe wdrożenie 40–80 h, migracja wersji 30–60 h, migracja z innej platformy 60–140 h. Jak uporządkować taki projekt na mniejszym rynku, opisaliśmy na przykładzie organizacji wdrożeń i migracji PrestaShop w Biłgoraju.
| Projekt | Co obejmuje | Typowe godziny |
|---|---|---|
| Wdrożenie | Nowy sklep od zera: instalacja, konfiguracja, szablon, moduły, produkty, testy | 40–80 h |
| Migracja wersji | 1.6 lub 1.7 → 8.x: moduły, szablon, baza, przekierowania | 30–60 h |
| Migracja platformy | WooCommerce, Shoper lub sklep native → PrestaShop | 60–140 h |
Słowo „migracja” opisuje cztery różne projekty o skrajnie różnym ryzyku. Dopóki nie ustalisz scenariusza, żadna wycena nie ma sensu.
A: 1.7.x → 8.x (30–50 h). Najprostszy wariant. Sprawdzamy moduły pod PHP 8.1 — część starszych wtyczek sypie błędami, a szablon pod hooki 8.x. Struktura URL-i (/kategoria/ID-produkt.html) zostaje, zdjęcia leżą na miejscu, zamówienia i baza klientów przechodzą bez zmian.
B: 1.6.x → 8.x (60–100 h). Upgrade to kilka przeskoków (1.6 → 1.7 → 8) robionych na kopii. Szablon z 1.6 praktycznie zawsze do przepisania, moduły w większości do wymiany. Zdjęcia przenosimy i regenerujemy miniatury, stare adresy .html wymagają przekierowań 301, hasła klientów mogą wymagać resetu.
C: WooCommerce, Shoper lub sklep pisany pod zamówienie → PrestaShop (80–140 h). Najdroższy scenariusz. Atrybuty trzeba zmapować na kombinacje, kategorie i stany na model danych PrestaShop, hasła nie przechodzą (inne hashowanie), więc część kont wymaga resetu hasła. Zamówienia najczęściej przenosimy jako archiwum albo zostawiamy w starym systemie w trybie tylko do odczytu. Zdjęcia wchodzą przez CSV lub API plus generowanie miniatur.
D: ta sama wersja, nowy hosting lub VPS (4–16 h). Dump bazy, rsync plików, poprawka parameters.php, przełączenie DNS, przeniesienie cronów (feedy, maile, importy) i test wydajności. Po przeniesieniu porównaj Core Web Vitals przed i po — słabszy VPS potrafi dołożyć kilkaset milisekund do LCP i przewrócić wyniki, które wcześniej były zielone. Kolejność prac, kopie i okno serwisowe przy takich projektach rozpisaliśmy w materiale o tym, co zaplanować przy migracji PrestaShop w Zwierzyńcu.
| Scenariusz | Zakres | Godziny | URL-e, zdjęcia, dane |
|---|---|---|---|
| A: 1.7.x → 8.x | Zgodność modułów i szablonu | 30–50 h | URL-e bez zmian, zdjęcia na miejscu, zamówienia i klienci zostają |
| B: 1.6.x → 8.x | Nowy szablon, wymiana modułów, kilka przeskoków wersji | 60–100 h | 301 ze starych .html, regeneracja miniatur, możliwy reset haseł |
| C: z innej platformy | Mapowanie atrybutów na kombinacje, kategorie, stany | 80–140 h | Reset haseł, zamówienia jako archiwum, zdjęcia przez CSV/API |
| D: nowy hosting | Dump bazy, rsync, DNS, crony, test wydajności | 4–16 h | Bez zmian w treści, wymagany test wydajności po przenosinach |
Stawka godzinowa jest zwykle największym elementem wyceny. Dla MŚP w regionie lubelskim w 2024/2025 realny przedział to 120–220 zł/h netto. Górna granica pojawia się przy pilnych terminach, pracy na produkcji bez okna serwisowego, integracjach z ERP lub API, wielojęzyczności, wielosklepowości oraz wtedy, gdy wykonawca bierze na siebie odpowiedzialność za dane klientów.
Trzy punkty odniesienia, które pozwalają zweryfikować ofertę:
Koszty poza godzinami: licencje modułów 150–1 500 zł za rok (płatności, feedy, fakturowanie, SEO), szablon 300–1 200 zł jednorazowo, VPS 80–300 zł miesięcznie. Razem 100–400 zł kosztów stałych miesięcznie, których zwykle nie widać w pierwszej ofercie.
Wycena w godzinach jest bezpieczniejsza dla klienta, bo zakres jest policzalny: wiesz, ile kosztuje przekroczenie, i widzisz w raporcie, na co poszły godziny. Cena „za projekt” prawie zawsze zawiera bufor na ryzyko wykonawcy — płacisz go niezależnie od tego, czy ryzyko się zmaterializuje. Rozliczenie „do skutku” oznacza, że ten bufor rośnie w trakcie.
Co realnie wydłuża projekt: brak dostępu do bazy lub panelu u dostawcy hostingu, produkty bez SKU (nie da się dopasować stanów i wariantów), nietypowe warianty (trzy atrybuty i tysiące kombinacji), stary szablon z hardkodowanymi zmianami, brak aktualnej kopii zapasowej i brak dokumentacji integracji z systemem księgowym. Przy 6–8 godzinach rozliczeniowych dziennie 50 h to około dwóch tygodni pracy jednego dewelopera, a 80 h — trzy do czterech tygodni. Do tego dochodzi czas na treści i akceptacje po stronie klienta.
| Projekt | Godziny | Koszt netto przy 120–220 zł/h |
|---|---|---|
| Nowe wdrożenie PrestaShop 8.x | 40–80 h | 4 800–17 600 zł |
| Migracja 1.7.x → 8.x | 30–50 h | 3 600–11 000 zł |
| Migracja 1.6.x → 8.x | 60–100 h | 7 200–22 000 zł |
| Migracja z WooCommerce lub Shopera | 80–140 h | 9 600–30 800 zł |
| Przeniesienie na nowy hosting/VPS | 4–16 h | 480–3 520 zł |
Każda pozycja z tej listy, której brakuje w dniu startu, oznacza przestój zespołu i godziny dopisane do faktury. Zbieranie tych danych zajmuje klientowi zwykle 3–6 godzin — to dokładnie ta praca, którą wykonawca wycenia później po 120–180 zł/h.
Dostępy (6 punktów):
Punkt drugi i trzeci to najczęstsze źródło poślizgu: gdy stary sklep obsługuje zewnętrzna firma, która „przekaże dostępy później”, projekt stoi kilka dni bez żadnej pracy do wykonania.
Dane do importu: eksport produktów w CSV z SKU, EAN/GTIN, ceną netto i brutto ze stawką VAT, stanem magazynowym oraz wagą (bez wagi nie policzysz kosztu kuriera). Zdjęcia w oryginalnej rozdzielczości, nie miniaturki pobrane z frontu sklepu.
Decyzje biznesowe: zachowujecie stare URL-e 1:1 czy zmieniacie strukturę kategorii? Co z historią zamówień i kontami klientów — przenosicie je, czy klienci zakładają nowe? Przy starych skrótach haseł z 1.6 i tak trzeba zaplanować kampanię resetu hasła przed startem, nie po nim.
Integracje i maile: klucze API InPost (ShipX), DPD, DHL, dane do bramki płatniczej, dostęp do ERP lub Fakturowni. Lista maili transakcyjnych razem z nadawcą, a rekordy SPF, DKIM i DMARC ustawione przed startem — bez tego potwierdzenia zamówień trafiają do spamu. Podobny zestaw kontrolny dla projektu prowadzonego mniejszym zespołem opisaliśmy przy okazji organizacji wdrożenia PrestaShop w Krasnobrodzie.
| Grupa | Co konkretnie | Kto dostarcza | Realny czas |
|---|---|---|---|
| Dostępy | Hosting, FTP/SFTP, SSH, baza, domena, GSC, GA4, Merchant Center | Klient + poprzedni wykonawca | 1–3 dni (zależnie od poprzedniej firmy) |
| Dane do importu | CSV z SKU, EAN, VAT, stanem, wagą; zdjęcia w pełnej rozdzielczości | Klient | 2–4 h |
| Decyzje biznesowe | URL-e, struktura kategorii, historia zamówień, konta klientów | Właściciel sklepu | 1–2 h |
| Integracje i maile | Klucze API kurierów, bramki, ERP, lista maili, SPF/DKIM/DMARC | Klient + dostawcy usług | 2–5 dni (oczekiwanie na dane od API) |
Etap 1 — audyt. Crawl starego sklepu (Screaming Frog w darmowej wersji obsłuży do 500 URL-i), lista adresów z kodami odpowiedzi, lista modułów i wtyczek, eksport z Search Console za 16 miesięcy (Skuteczność → Strony) i dane z GA4. Wychodzi dokument, który jest podstawą mapy przekierowań.
Etap 2 — kopia zapasowa. Pliki plus dump bazy, a potem sprawdzenie, czy kopia faktycznie się odtwarza. Backup, którego nikt nie odtworzył, nie jest backupem.
Etap 3 — staging. Subdomena w rodzaju staging.twojadomena.pl, zabezpieczona hasłem w .htpasswd i nagłówkiem X-Robots-Tag: noindex. Sam wpis w robots.txt nie wystarcza, jeśli do stagingu prowadzą jakiekolwiek linki.
Etap 4 — mapowanie danych. Kategorie do kategorii, produkty po SKU (nie po nazwie — nazwy się powtarzają), warianty na kombinacje, klienci i zamówienia. Jeden arkusz, jeden wiersz na rekord.
Etap 5 — import i weryfikacja. Liczba produktów wejście vs wyjście, liczba kombinacji, zdjęć, produktów bez kategorii, ceny z VAT. Do tego losowa kontrola 20 SKU — taniej sprawdzić ręcznie niż tłumaczyć się klientowi po starcie.
Etap 6–7 — integracje i test end-to-end. Konfiguracja kurierów, bramki, maili, a potem pięć scenariuszy: kurier, płatność online, płatność za pobraniem, kod rabatowy, zwrot.
Etap 8 — przełączenie DNS (TTL obniżony 24 h wcześniej), mapa przekierowań 301 zgodna z semantyką trwałego przeniesienia zasobu opisaną w RFC 9110, nowa sitemap, walidacja w Search Console i monitoring 24–72 h: logi 404, webhooki płatności, wysyłka maili. Kolejność etapów w projekcie położonym dalej od Lublina opisaliśmy w materiale o migracji PrestaShop w Szczebrzeszynie.
| Etap | Kluczowy efekt | Na co uważać |
|---|---|---|
| 1. Audyt | Raport URL-i, modułów, ruchu | Bez eksportu z GSC mapa 301 będzie niepełna |
| 2. Kopia | Odtworzalny backup | Test odtworzenia, nie samo wykonanie kopii |
| 3. Staging | Środowisko na subdomenie | Htpasswd + X-Robots-Tag: noindex |
| 4. Mapowanie | Arkusz 1:1 | Klucz to SKU, nie nazwa produktu |
| 5. Import | Zgodna liczba rekordów | Kontrola wariantów, zdjęć, VAT |
| 6–7. Integracje i test | Zamówienie przechodzi pełną ścieżkę | Pięć scenariuszy, w tym zwrot |
| 8. Start | DNS, 301, sitemap, monitoring | Monitoring minimum 24 h po starcie |
Największe ryzyko terminu nie siedzi w samym sklepie, a na stykach z systemami zewnętrznymi — i prawie zawsze wynika z braku specyfikacji.
Kurierzy. InPost ma dwa różne światy: nowsze ShipX API i starsze Przesyłki Kurierskie. Trzeba ustalić, gdzie powstaje etykieta, czy obsługujecie pobranie (kwota musi przejść z zamówienia), jak zapisywany jest paczkomat wybrany przez klienta i czy mapa punktów odbioru działa na mobile. DPD i DHL mają własne API, formaty etykiet i limity zapytań. Sandbox rzadko zachowuje się jak produkcja — zaplanuj 1–2 dni bufora.
ERP, Subiekt, Fakturownia. Ustalcie kierunek przepływu (sklep → ERP zamówienia i płatności, ERP → sklep stany, ceny, kody), częstotliwość synchronizacji (co 5 minut czy webhook), numerację dokumentów, mapowanie statusów, jednostki miary i stawki VAT. Najczęstszy błąd: nikt nie zdecydował, kto jest źródłem prawdy o stanie magazynowym. Efekt to sprzedaż produktu, którego nie ma.
Płatności: BLIK, Przelewy24, PayU, Stripe. Kluczowa jest obsługa webhooka zwrotnego, weryfikacja podpisu, idempotencja (te same zdarzenia przychodzą dwa razy), ponowienia przy nieudanej płatności oraz zgodność z PSD2 i 3DS. Zwroty i refundy muszą dać się zrobić z panelu sklepu, nie z panelu operatora.
Rekomendacja: każdą integrację zamknij w osobny zakres godzinowy z kryterium akceptacji, np. „10 etykiet generuje się kolejno, waga pobrana z produktu, pobranie doliczone”. Osobny zakres to osobna pozycja na fakturze i jasny punkt odbioru.
Kiedy własny moduł wygrywa z kolejną płatną wtyczką: niestandardowe reguły wysyłki (darmowa dostawa liczona po rabacie, nie przed), logika B2B — ceny grupowe, płatność odroczona, limity kredytowe. Gotowa wtyczka kosztuje kilkaset złotych rocznie, ale takich reguł nie obsłuży. Sposób rozbicia takich zadań na zakresy opisaliśmy przy organizacji wdrożenia PrestaShop w Biłgoraju.
| Integracja | Co ustalić przed startem | Typowe opóźnienie |
|---|---|---|
| InPost (ShipX) | Skąd etykieta, pobranie, zapis paczkomatu, mapa punktów | 1–3 dni na testy etykiet i punktów |
| DPD / DHL | Format etykiet, limity zapytań, dane umowy | 1–2 dni, głównie na różnice sandbox/produkcja |
| ERP / Subiekt / Fakturownia | Kierunek przepływu, częstotliwość, numeracja, statusy, źródło prawdy o stanie | 3–10 dni, zależnie od dostępu do API |
| Płatności (BLIK, P24, PayU, Stripe) | Webhook zwrotny, podpis, idempotencja, PSD2/3DS, zwroty | 2–5 dni na testy scenariuszy błędów |
Migracja PrestaShop rzadko psuje się widowiskowo. Najczęściej psuje się cicho: sklep wstaje, klient kupuje, a po trzech tygodniach okazuje się, że 40% starych adresów zwraca 404, a na 200 produktach cena różni się o 15% od tej z systemu przed migracją. Poniżej sześć pułapek, które widzimy najczęściej, wraz z metodą weryfikacji — tak, żebyś mógł sprawdzić jakość pracy sam, bez czekania na raport wykonawcy.
SELECT reference, COUNT(*) FROM ps_product GROUP BY reference HAVING COUNT(*) > 1. Każdy zwrócony wiersz to potencjalny błąd koszyka albo zdublowana pozycja w katalogu.ps_product_shop.price ceną z hurtowni.noindex ze stagingu albo Disallow: / w robots.txt, sklep nie istnieje dla Google, choć działa dla klientów.Jak rozpisujemy taki zakres etapami na mniejszym rynku, opisaliśmy przy okazji organizacji wdrożenia PrestaShop w Zwierzyńcu.
| Pułapka | Jak wykryć | Sygnał, że jest źle |
|---|---|---|
| Zniknięte / zdublowane URL-e | Crawl Screaming Frog + test 50 losowych adresów | 404, 302, łańcuch 301, wszystko na stronę główną |
| Duplikaty SKU | Zapytanie GROUP BY reference w obu bazach | Więcej niż jedno wystąpienie tej samej referencji |
| Ceny i stany magazynowe | Raport różnic dla 20 losowych produktów | Rozjazd ceny lub ilości między systemami |
| Zablokowana indeksacja | Search Console + test live URL | noindex, Disallow: /, brak wpisów w indeksie po 7 dniach |
| Wydajność | PageSpeed Insights, TTFB, liczba zapytań SQL | TTFB powyżej 400 ms, zapytania rosnące z liczbą produktów |
| Sesje i maile | Zamówienie testowe z 2 przeglądarek, kontrola skrzynki klienta | Brak maila, pusty koszyk po powrocie z płatności |
Start to nie koniec migracji, tylko początek miesiąca, w którym można stracić albo utrzymać pozycje. Plan działań wygląda tak.
Mapa przekierowań 301. Zrób ją z danych, nie z pamięci: eksport z Google Search Console i Analitycs z ostatnich 12 miesięcy, adresy z co najmniej jednym wejściem → przekierowanie 1:1 na nowy odpowiednik. Produkty wycofane ze sprzedaży i puste tagi → 410, nie 301. Kategorie i filtry → 301 na najbliższą istniejącą kategorię. Nie przekierowuj masowo wszystkiego na stronę główną, bo Google czyta to jako soft 404. W PrestaShop reguły wrzucasz w Narzędzia → SEO i URL albo przez moduł przekierowań — zależnie od tego, co stoi w projekcie.
Pliki techniczne i Search Console. Nowa sitemap.xml (moduł Google Sitemap), przejrzany robots.txt bez wpisów ze stagingu, zgłoszenie sitemapy, sprawdzenie raportu „Zmiana adresu”, jeśli zmieniała się domena — wymaga weryfikacji własności obu stron. Raport 404 w GSC przeglądasz codziennie przez pierwszy tydzień.
Core Web Vitals. Cele: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — definicje i sposób pomiaru na web.dev. Co realnie poprawić: obrazy do WebP/AVIF z poprawnym srcset i lazy loadingiem poniżej pierwszego ekranu, cache Smarty i cache stron na CDN, kompresja Brotli na serwerze, wyłączenie modułów dorzucających skrypty do hooków na stronie głównej i kategorii. Jedna karuzela potrafi dodać 300 ms do LCP.
Dane strukturalne. Product, Offer, BreadcrumbList — walidacja przez Rich Results Test. Sprawdź, czy moduł SEO nie generuje duplikatów i czy wyniki nie straciły rozszerzeń (cena, dostępność, oceny).
| Kiedy | Co sprawdzasz | Na co patrzysz |
|---|---|---|
| Dzień 1 | 404 i przekierowania w GSC, sitemapa, noindex | Nowe 404, kod odpowiedzi na 50 starych URL-ach, liczba zgłoszonych adresów |
| Dzień 7 | Indeksacja i ruch | Liczba zaindeksowanych stron, ruch z fraz brandowych, spadek lub wzrost kliknięć |
| Dzień 30 | Konwersja i wydajność | Konwersja i przychód vs poprzedni okres, LCP/INP/CLS w grupie URL-i produktowych |
Ofert na wdrożenie PrestaShop w Lublinie zobaczysz kilkanaście i większość będzie wyglądać podobnie: zakres, kwota, termin. Różnice wychodzą dopiero po pytaniach.
Pytania na rozmowie:
Co powinno być w umowie. Zakres etapów (audyt → staging → import danych → testy → start → monitoring), kamienie milowe z płatnościami, liczba godzin na poprawki w cenie (realnie 8–16 h), kryterium akceptacji w formie listy testów: przekierowania, zamówienie testowe, maile transakcyjne, dane strukturalne. Koniecznie warunki przekroczenia budżetu — stawka godzinowa i próg, od którego potrzebna jest pisemna zgoda, np. +10%.
SLA powdrożeniowe. Zapisz czas reakcji (np. 4 h w dni robocze), czas usunięcia awarii krytycznej (24 h), kanał zgłoszeń (mail i telefon, nie Messenger), zakres backupów i retencję (baza i pliki, codziennie, 30 dni) oraz zobowiązanie do testu odtworzenia kopii raz na kwartał. Bez tego zapisu „zrobimy backup” oznacza zwykle kopię, której nikt nigdy nie sprawdził. Punkt odniesienia dla takiego układu obowiązków znajdziesz w opisie organizacji wdrożeń i migracji PrestaShop w Biłgoraju.
| Element | Zapytanie do wykonawcy | Zapis w umowie / SLA |
|---|---|---|
| Środowisko pracy | Prace na produkcji czy na stagingu? | Staging + procedura rollbacku z terminem |
| Zakres | Ile etapów i co dokładnie obejmują? | Lista etapów i kamieni milowych z płatnościami |
| Poprawki | Ile godzin na poprawki w cenie? | 8–16 h w cenie, dalej stawka godzinowa |
| Odbiór | Po czym poznacie, że projekt jest gotowy? | Lista testów akceptacyjnych: przekierowania, zamówienie, maile, dane strukturalne |
| Budżet | Co przy przekroczeniu zakresu? | Pisemna zgoda powyżej +10% budżetu |
| Wsparcie | Jaki macie czas reakcji? | 4 h reakcja, 24 h usunięcie awarii krytycznej, kanał zgłoszeń |
| Backupy | Jak często i gdzie? | Baza i pliki codziennie, retencja 30 dni, test odtworzenia raz na kwartał |
Klient kupuje „migrację PrestaShop” jako jedną usługę, nie mówiąc, z jakiej wersji i z jakiej platformy startuje.
Jak wykryć: Oferta zawiera jedną cenę i jedno widełkowe „od–do”, a wykonawca nie zapytał o wersję źródłową, liczbę modułów ani platformę docelową.
Jak naprawić: Poproś o rozbicie projektu na scenariusz: 1.7.x → 8.x, 1.6.x → 8.x, z innej platformy albo sam hosting. Każdy z nich ma inny zakres i inne ryzyko.
Praca bezpośrednio na produkcji, bez środowiska testowego.
Jak wykryć: W harmonogramie nie ma etapu „staging”, a wykonawca prosi o wyłączenie sklepu na czas prac.
Jak naprawić: Ustal klon sklepu na subdomenie z wyłączoną indeksacją, testy robisz tam, a produkcję przełączasz po odbiorze.
Zmiana adresów URL bez mapy przekierowań 301.
Jak wykryć: Po migracji sprawdź kilka starych adresów produktów i kategorii – jeśli zwracają 404 zamiast 301, przekierowania nie zostały wdrożone.
Jak naprawić: Przygotuj tabelę stary URL → nowy URL i wdróż przekierowania po stronie serwera. Semantykę kodów HTTP opisuje RFC 9110.
Import produktów bez SKU i EAN, na pliku wyeksportowanym „jak leci” z panelu.
Jak wykryć: Policz kombinacje wariantów przed migracją i po niej – jeśli liczby się nie zgadzają, część wariantów się scaliła albo zgubiła.
Jak naprawić: Uzupełnij SKU w starym sklepie przed eksportem. Bez unikalnego identyfikatora import tworzy duplikaty, a warianty tracą powiązanie ze stanem magazynowym.
Brak kopii bazy danych i plików z datą, przed pierwszym kliknięciem w migrację.
Jak wykryć: Zapytaj, gdzie leży dump bazy i archiwum plików oraz z którego dnia. Brak odpowiedzi oznacza brak kopii.
Jak naprawić: Wymagaj eksportu bazy i katalogu plików (łącznie z katalogiem zdjęć i motywem) przed startem prac. To koszt kilku minut, a ratuje cały projekt.
Wycena ryczałtowa „do skutku”, bez listy prac i limitu godzin.
Jak wykryć: W umowie nie ma zakresu prac, liczby godzin ani punktu odbioru. Wszystkie niejasności są rozwiązywane na Twoją niekorzyść.
Jak naprawić: Rozliczaj w godzinach z podanym zakresem i limitem. Wtedy wiesz, za co płacisz, a każda dodatkowa praca jest osobną decyzją, nie niespodzianką na fakturze.
Wdrożenie i migracja PrestaShop to dwa różne projekty, a sama migracja ma co najmniej cztery warianty o skrajnie różnym zakresie – od 4 godzin przy zmianie hostingu do 140 godzin przy przejściu z innej platformy. Wycena w godzinach z jasno opisanym zakresem jest dla zamawiającego bezpieczniejsza niż ryczałt „do skutku”, bo pozwala porównać oferty i kontrolować narastanie kosztów. Największą oszczędnością nie jest jednak negocjacja stawki, a przygotowanie dostępów, danych produktowych i decyzji biznesowych przed startem. Dobrze przygotowany projekt skraca się o dni, a czasem o tygodnie. Kolejny przykład uporządkowania takich prac znajdziesz we wpisie o wdrożeniach i migracjach PrestaShop Zwierzyniec.
Samo wdrożenie to zwykle 40–80 godzin pracy, czyli przy typowym tempie 4–8 tygodni kalendarzowo. Na ten czas składa się instalacja i konfiguracja serwera, ustawienie PHP 8.1 lub nowszego, bazy MySQL i SSL, wdrożenie szablonu, modułów, import produktów i testy. Największą zmienną nie jest liczba godzin programisty, a czas, w jakim otrzyma kompletne dane produktowe.
Tak, ale to osobny etap pracy, a nie efekt uboczny aktualizacji. Dane trzeba przenieść świadomie, z uwzględnieniem zmian w strukturze tabel między wersjami, a klientom po migracji zwykle trzeba zresetować hasła. Przy 1.6 do 8.x dochodzi przepisanie szablonu i wymiana większości modułów, dlatego realny zakres to 60–100 godzin.
Nie zawsze. PrestaShop 8.x działa na dobrym hostingu współdzielonym, jeśli ma zagwarantowane PHP 8.1+, odpowiednią pamięć i nie jest ograniczany limitami procesów. VPS rozważ, gdy sklep ma duży katalog produktów, wielu równoczesnych użytkowników albo nietypowe integracje. Pamiętaj, że sama zmiana serwera to 4–16 godzin pracy i wymaga testu wydajności przed przełączeniem.
Zaszkodzi wtedy, gdy stare adresy zwrócą 404. Przy poprawnie wdrożonych przekierowaniach 301 ruch przenosi się wraz z adresami, choć kilka tygodni może trwać stabilizacja. Mapę przekierowań przygotowuj z listy zaindeksowanych URL-i z Google Search Console, a nie z pamięci. Zasady budowania treści, które warto utrzymać także po migracji, opisuje dokumentacja Google Search Central.
Zrób test wydajności na klonie sklepu przed przełączeniem DNS, a nie po nim. Sprawdź czas odpowiedzi serwera i stabilność kluczowych widoków: strony głównej, listy kategorii i karty produktu z wariantami. Punktem odniesienia są wskaźniki opisane w web.dev – Web Vitals. Jeśli wyników nie ma w raporcie, testu prawdopodobnie nie wykonano.
Godziny są policzalne i weryfikowalne, a ryczałt zwykle zawiera ukryty zapas na nieprzewidziane sytuacje. Przy stawce 120–220 zł/h netto w regionie lubelskim wiesz, że 50 godzin to 6 000–11 000 zł netto, a 80 godzin to 9 600–17 600 zł netto. Dodatkowo, gdy projekt się wydłuża z powodu braku dostępu do bazy albo produktów bez SKU, widzisz dokładnie, na co poszły pieniądze.
Jeśli chcesz policzalną wycenę wdrożenia albo migracji PrestaShop, wyślij nam adres obecnego sklepu i wersję, na której działa – powiemy, do którego scenariusza się kwalifikuje. W DropDigital prowadzimy PrestaShop, WordPressa i WooCommerce, a także serwery i SEO techniczne, więc zakres prac nie kończy się na samym wgraniu plików.