Wdrożenie i migracja PrestaShop w Zamościu sprowadzają się do jednego pytania: budujesz sklep od zera czy przenosisz istniejący? Proste wdrożenie nowego sklepu to zwykle 2–4 tygodnie, migracja z PrestaShop 1.6/1.7 albo z innej platformy to 4–10 tygodni, a projekt z integracją ERP nawet 8–16 tygodni. Rozliczamy to godzinowo, w widełkach 150–250 zł netto za godzinę pracy dewelopera, bo zakres zależy od liczby produktów, integracji i danych do przeniesienia. Poniżej znajdziesz rozróżnienie wdrożenia i migracji, realne terminy, model wyceny oraz listę kontrolną porządkującą projekt od audytu do startu.
Wdrożenie i migracja to dwa różne projekty, mimo że kończą się tym samym — działającym sklepem na PrestaShop. Wdrożenie oznacza, że sklepu wcześniej nie było: instalujesz PrestaShop 8.x, konfigurujesz szablon, płatności, kurierów, dodajesz produkty z arkusza. Migracja to przeniesienie istniejącego sklepu — z PrestaShop 1.6 lub 1.7 na 8.x albo z WooCommerce, Shopify czy autorskiego CMS-a. Różnica praktyczna siedzi w danych: przy migracji nie zaczynasz od zera, tylko przenosisz kategorie, produkty z kombinacjami, klientów, zamówienia i historię. To zwykle 60–70% pracy w całym projekcie.
Sygnały, że czas na migrację:
Kiedy lepiej zostać i optymalizować? Gdy sklep działa na 1.7.8+ lub 8.x, ma do 200 produktów, TTFB w normie, a jedyny problem to zdjęcia, opisy i struktur danych. Wtedy aktualizacja modułów, kompresja obrazów i poprawki szablonu są tańsze niż migracja. Uwaga na pułapkę: „migracja 1:1” na starej bazie z błędami przenosi te błędy dalej. Jeśli w bazie są duplikaty SKU i puste atrybuty, najpierw je czyścisz, potem migrujesz. Więcej o kolejności prac pisaliśmy w artykule o organizacji wdrożenia PrestaShop w Zamościu, a sąsiednie projekty opisujemy przy okazji wdrożeń PrestaShop w Hrubieszowie.
| Sytuacja w firmie | Rekomendacja | Dlaczego |
|---|---|---|
| Nowa marka, brak sklepu, do 500 produktów | Wdrożenie nowego sklepu | Brak danych do przenoszenia, najkrótszy czas i najniższy koszt |
| PrestaShop 1.6, 300–2000 produktów, sprzedaż trwa | Migracja 1:1 do 8.x | 1.6 nie dostaje poprawek bezpieczeństwa, brak zgodności z PHP 8 |
| Sklep działa, ale checkout gubi klientów | Przebudowa z nowym UX | Sama migracja przeniesie stary lejek sprzedaży |
| PrestaShop 8.x, poniżej 200 produktów, TTFB w normie | Optymalizacja bez migracji | Aktualizacja modułów i treści tańsza niż przenosiny |
Terminy zależą od trzech rzeczy: ilości danych, liczby integracji i tego, jak szybko klient podejmuje decyzje. Realne przedziały dla firmy: proste wdrożenie nowego sklepu 2–4 tygodnie, migracja MŚP 4–10 tygodni, projekt z integracją ERP 8–16 tygodni.
Główne czynniki wydłużające projekt to liczba produktów i kombinacji. 2000 produktów po 5 kombinacji to 10 000 rekordów, a każdy wariant ma własne ID, stan magazynowy i cenę. Do tego kategorie, klienci i zamówienia — przy migracji historii powyżej 10 000 zamówień import seryjnie dzielimy na paczki po kilka tysięcy, bo inaczej baza się zapycha. Hasła klientów nie przeniosą się 1:1 (hash zależy od wersji PrestaShop), więc trzeba wymusić reset hasła przy pierwszym logowaniu.
Integracje płatności, kurierów i ERP odpowiadają za najdłuższy etap, czyli testy. Płatności testujesz w trybie sandbox dostawcy: pełna ścieżka, zwrot, nieudana autoryzacja. Kurierzy — generowanie etykiety, pobranie, numer tracking w mailu. ERP — dwukierunkową synchronizację stanów i statusów zamówień. Każda z tych rzeczy to osobny scenariusz testowy, nie „jedno kliknięcie”.
| Etap | Czas | Efekt |
|---|---|---|
| Audyt, dostępy, inwentaryzacja danych | tydzień 1 | Lista produktów, modułów, integracji i ryzyk |
| Środowisko staging, instalacja, szablon | tydzień 2–3 | Sklep działa na subdomenie testowej z noindex |
| Migracja danych i mapowanie | tydzień 4–5 | Produkty, kategorie, klienci, zamówienia w nowej bazie |
| Integracje: płatności, kurierzy, ERP | tydzień 6–7 | Testy sandbox i poprawki błędów |
| Testy akceptacyjne i przekierowania 301 | tydzień 8 | Zamknięta lista błędów, mapa URL-i |
| Uruchomienie i monitoring | tydzień 9–10 | Stary sklep w trybie tylko do odczytu |
Nie wyceniamy projektu „od sklepu”, tylko w godzinach pracy dewelopera. Widełki to 150–250 zł netto za godzinę — dolna granica dotyczy prac standardowych (konfiguracja, import CSV, szablon z marketplace), górna specjalistycznych (moduł pod API ERP, migracja z nietypowej bazy, wielojęzyczność z tłumaczeniami). Stawka rośnie razem z odpowiedzialnością za integrację, która ma działać bez nadzoru.
Trzy typowe pakiety godzinowe:
Koszty podnoszą: moduły niestandardowe (20–60 h każdy), integracja ERP (40–120 h zależnie od jakości API), wielojęzyczność, migracja danych o nieznanej jakości, nietypowe reguły cenowe i ceny klientów B2B. Obniżyć koszt bez utraty jakości możesz po swojej stronie: przygotuj produkty w jednym CSV (jedna kolumna na kategorię, jedna nazwa pliku na zdjęcie), wskaż jednego decydenta do akceptacji, dostarcz dostępy do domeny, bazy i paneli w pierwszym dniu projektu i nie zmieniaj zakresu w trakcie prac. Gotowe opisy i zdjęcia przed startem to często 10–20 godzin mniej na etapie treści.
Wycena przed audytem jest szacunkowa, bo nikt nie zna stanu bazy, liczby modułów z licencjami i jakości danych. Doprecyzowanie zajmuje 3–5 dni: eksport i przegląd bazy, lista modułów, test wydajności, mapowanie integracji. Wynik to zakres w godzinach z buforem 10–15% i podziałem na etapy. Podobny model stosujemy w projektach z Lublina i Bełżca.
| Pakiet | Liczba godzin | Widełki netto | Typowy zakres |
|---|---|---|---|
| Start | 80–120 h | 12 000–30 000 zł | Nowy sklep, 1 język, płatności i 2 kurierów, do ~500 produktów |
| Rozwój | 140–220 h | 21 000–55 000 zł | Szablon custom, import, wielojęzyczność, dodatkowe moduły |
| Migracja z integracjami | 200–350 h | 30 000–87 500 zł | Dane i historia, ERP/magazyn, przekierowania 301, testy |
Plan projektu sprowadza się do siedmiu kroków. Każdy kończy się plikiem albo decyzją, nie „etapem do omówienia”.
Pułapki, które zatrzymują projekty. Zamówienia przenosisz jako archiwum do wglądu — po migracji do PrestaShop 8 nie odtworzysz w nich pełnej edycji (historia statusów, podatki sprzed zmiany stawek). Numeracja faktur w ps_order_invoice musi startować powyżej ostatniego numeru ze starego sklepu, inaczej księgowość dostanie dwa dokumenty z tym samym numerem. Hasła klientów: sprawdź, jakim algorytmem są zahashowane w źródle — jeśli to stary md5, wymuś reset hasła przy pierwszym logowaniu. Override'y z katalogu /override/ i modyfikacje rdzenia przenosi się pojedynczo, z kontrolą, czy nie dublują funkcji wbudowanej już w nową wersję.
Testy przed startem. Minimum: ścieżka zakupu (gość, zalogowany, z kodem rabatowym), płatność zakończona sukcesem i odrzucona, wysyłka do dwóch stref, faktura, e-mail potwierdzający, formularz zwrotu. Do tego test wydajności przy 50 równoczesnych użytkownikach i skan bezpieczeństwa — najczęściej wychodzi nieaktualny moduł i panel administracyjny pod domyślną nazwą katalogu.
Start i odbiór. W dniu wdrożenia: przekierowania 301, sitemap.xml, monitoring błędów 404 i czasów odpowiedzi. Potem 2–3 godziny szkolenia z zespołem i dokumentacja: gdzie zmienić stawkę wysyłki, jak dodać produkt, gdzie sprawdzić nieudaną płatność. Kolejność kroków dla sklepu w Zamościu opisujemy w artykule o organizacji wdrożenia i migracji PrestaShop w Zamościu; jeśli działasz w Chełmie, zobacz organizację projektu dla sklepu w Chełmie.
| Etap | Czas | Efekt |
|---|---|---|
| Audyt | 1–3 dni | lista modułów, override'ów, integracji i wolumenów danych |
| Backup i staging | 1 dzień | odtworzona kopia działająca na subdomenie |
| Mapowanie danych | 2–5 dni | tabela stare ID → nowe ID, ustalona numeracja faktur |
| Konfiguracja | 2–4 dni | płatności, kurierzy, strefy wysyłki, podatki, regulaminy |
| Testy | 2–3 dni | raport błędów i lista poprawek przed startem |
| Start | 1 dzień | 301, sitemap.xml, monitoring 404 i czasów odpowiedzi |
| Odbiór | 1 dzień | szkolenie zespołu i przekazana dokumentacja |
Integracje to najczęstsze miejsce, w którym sklep startuje, ale nie sprzedaje. Kolejność planowania jest zawsze ta sama: ERP, płatności, kurierzy — każda z osobnym okienkiem na testy. Podobny układ pracy stosujemy przy projektach w mniejszych miastach regionu, np. w organizacji wdrożenia PrestaShop w Hrubieszowie.
ERP. Kluczem jest SKU albo EAN, nigdy nazwa produktu. Stany i ceny płyną z ERP do sklepu (cron co 5–15 minut), zamówienia w drugą stronę — webhookiem po zmianie statusu albo cronem co 5 minut. Faktury wystawia ERP; jeśli PrestaShop generuje własne, masz dwa obiegi dokumentów. Przy 300–600 zamówieniach miesięcznie synchronizacja co 10 minut wystarcza. Przy wyprzedaży ze 200 zamówieniami na godzinę potrzebna jest kolejka i idempotencja, żeby to samo zamówienie nie wciągnęło się do ERP dwa razy.
Płatności. Przelewy24, PayU, tpay — osobne klucze testowe i produkcyjne, poprawny URL powrotu i webhook notyfikacji. Apple Pay i Google Pay wymagają HTTPS oraz weryfikacji domeny w panelu operatora. W sandboxie przetestuj cztery scenariusze: sukces, odrzucenie, brak powrotu klienta z bramki (zamówienie zostaje w „oczekuje na płatność”) i podwójną notyfikację tego samego zamówienia.
Kurierzy. InPost Paczkomaty, DPD, DHL — nie chodzi tylko o etykietę. Potrzebujesz wyboru punktu odbioru na stronie zamówienia i zapisania jego kodu, mapowania metod dostawy na usługi w API (gabaryt, przesyłka pobraniowa), numeru tracking w e-mailu i obsługi zwrotu z panelu.
Kiedy własny moduł. Gdy wtyczka nie wspiera twojej wersji PrestaShop, gdy kod jest zakodowany (np. ionCube) i nie da się dopisać logiki, albo gdy proces jest nietypowy (stawki zależne od nośnika, mapowanie kilkunastu statusów). Własny moduł to zwykle 40–120 godzin. Bazę techniczną znajdziesz w dokumentacji dla deweloperów PrestaShop.
Przypadki brzegowe, które trzeba mieć zaplanowane:
Migracja bez mapowania adresów to najszybszy sposób na utratę ruchu. Pracę zaczynasz przed startem: crawlujesz stary sklep (Screaming Frog lub eksport adresów URL z Google Search Console), wyciągasz listę wszystkich adresów ze statusem 200 i przypisujesz każdemu nowy adres. Reguły 301 wrzucasz do .htaccess albo do modułu przekierowań. Dwie zasady: żadnych łańcuchów (ma być A → C, nie A → B → C) i żadnych 301 prowadzących do 404. 5% starych adresów bez przekierowania to realnie kilka procent ruchu organicznego.
Podstawy techniczne. Canonical self-referencing na produkcie i kategorii, jeden adres na produkt bez parametrów sortowania i ?id_lang. sitemap.xml generowana automatycznie i podlinkowana w robots.txt, który nie blokuje /modules/ ani /themes/. Meta title i opisy kategorii pisz od nowa — kopiowanie ich z 1.7 do 8.x to najczęstsza duplikacja treści, jaką widzimy po migracjach. Sprawdź też, czy na produkcji nie został robots.txt ze stagingu z wpisem Disallow: /.
Wydajność. Najwięcej daje cache (Smarty, cache stron, Redis lub APCu), CDN dla plików statycznych, obrazy w WebP w rozmiarach generowanych przez sklep i lazy loading — ale nie na obrazie LCP, bo go opóźni. W bazie: indeksy na tabelach produktów i kategorii, eliminacja zapytań w pętli, wyłączenie nieużywanych modułów, które doładowują własne skrypty na każdej stronie.
Monitoring. Po starcie 4–8 tygodni obserwacji w Google Search Console: raport 404, wydajność, statystyki adresów URL i tygodniowe porównanie kliknięć. W tym okresie nie zmieniaj struktury adresów drugi raz — nie odróżnisz wtedy efektu migracji od efektu przebudowy. Definicje i progi metryk opisuje Web Vitals w web.dev. Jeśli projekt dotyczy większego sklepu, zobacz organizację wdrożenia i migracji PrestaShop w Lublinie.
| Metryka | Próg | Co najczęściej go psuje |
|---|---|---|
| LCP | poniżej 2,5 s | duży obraz baneru bez WebP i bez lazy loadingu poza LCP |
| INP | poniżej 200 ms | ciężkie skrypty zewnętrzne: czat, piksele, dodatkowe wtyczki |
| CLS | poniżej 0,1 | brak wymiarów obrazów i brak miejsca zarezerwowanego na komunikaty |
| TTFB | poniżej 600 ms | brak cache i CDN oraz wolne, niezaindeksowane zapytania do bazy |
Dzień startu to nie koniec projektu, a początek eksploatacji. Sklep, który przez pierwszy miesiąc działa bez opieki technicznej, zwykle psuje się po cichu: rosną logi, wycieka pamięć w PHP-FPM, a moduł płatności przestaje odpowiadać po zmianie API po stronie operatora.
Hosting. Dla sklepu do ok. 2000 SKU i kilkuset zamówień miesięcznie wystarcza VPS 4 vCPU / 8 GB RAM z dyskiem NVMe. Powyżej 5000 SKU albo z integracją ERP schodzimy na 8 vCPU / 16 GB lub serwer dedykowany. Na serwerze: PHP 8.1/8.2 z OPcache i PHP-FPM, MySQL 8 lub MariaDB 10.6+, wymuszony HTTPS, memory_limit 512M, max_execution_time 300 s. Parametry PHP sprawdzisz w panelu i w Zaawansowane → Informacje w back office.
Aktualizacje bez przestoju. Każdą aktualizację PrestaShop, PHP albo modułu robimy najpierw na stagingu, potem w oknie serwisowym (np. sobota 22:00), z kopią sprzed zmiany i planem wycofania. Wersje PHP i PrestaShop mają daty końca wsparcia — pracę po tej dacie traktujemy jak otwarte drzwi. Warto pilnować tego po stronie dokumentacji dla deweloperów PrestaShop.
Kopie 3-2-1. Trzy kopie, dwa nośniki, jedna poza serwerem. Backup obejmuje bazę, /img, /themes, /modules oraz pliki konfiguracyjne. Retencja: 7 kopii dziennych, 4 tygodniowe, 12 miesięcznych. Raz na kwartał robimy test odtworzenia na stagingu — bez testu nie wiesz, czy backup w ogóle się nadaje.
Monitoring i SLA. Uptime co minutę, błędy PHP do Sentry, wydajność mierzona Core Web Vitals, bezpieczeństwo przez WAF i fail2ban. SLA opisujemy liczbami, nie hasłami „szybko”.
| Poziom zgłoszenia | Przykład | Czas reakcji | Kanał |
|---|---|---|---|
| Krytyczny | Sklep nie działa, płatności odrzucane | 1 h w godzinach 8–16 | Telefon + e-mail |
| Wysoki | Błędne etykiety, błąd koszyka | 4 h | E-mail lub tracker |
| Normalny | Zmiana treści, nowy moduł | 1 dzień roboczy | Tracker |
Pracujemy z firmami z Zamościa, Lublina, Chełma, Hrubieszowa, Narola i Bełżca. Model domyślny to praca zdalna, ale gdy trzeba usiąść nad tematem — przyjeżdżamy. Spotkanie w Zamościu albo w promieniu ok. 60 km ustalamy zwykle w ciągu 3–5 dni roboczych, bez osobnej opłaty za dojazd w tej strefie.
Kontakt z deweloperem, nie z pośrednikiem. Rozmawiasz z osobą, która pisze kod i odpowiada za wdrożenie. Bez handlowca przekazującego ustalenia „do zespołu” i bez zmiany opiekuna w połowie projektu. Ten sam człowiek prowadzi audyt, migrację i poprawki po starcie.
Rytm komunikacji. W każdy piątek dostajesz krótki raport: co zamknięte, co w toku, co blokuje i czego potrzebujemy od Ciebie. Zgłoszenia trafiają do jednego miejsca — skrzynki e-mail albo trackera (GitLab Issues, Linear) — więc nic nie ginie w wątkach na WhatsAppie. Każda zmiana idzie najpierw na staging, do którego masz dostęp z hasłem o każdej porze. Produkcję dotykamy dopiero po Twojej akceptacji na stagingu.
Organizację projektu po stronie miasta opisujemy osobno, bo zakresy bywają różne:
Różnice wynikają z liczby SKU, magazynu, integracji z kurierami i tego, czy migrujesz z 1.6/1.7, czy z innego systemu.
Ta lista działa w dwie strony: porządkuje pracę wykonawcy i daje Ci gotowe pytania na spotkanie.
Przed startem (punkty obowiązkowe):
meta noindex, blokada w robots.txt) i hasłem.Po starcie (pierwsze 30 dni):
Kryteria odbioru ustal przed podpisaniem umowy, nie po. Pytaj wprost: jaki jest czas reakcji i w jakich godzinach, gdzie trzymane są kopie i jak często testujecie odtworzenie, kto ma dostęp do serwera i bazy, czy kod trafia do repozytorium na moim koncie, czy licencje płatnych modułów są przypisane do mojej domeny i czy po zakończeniu współpracy zostaje mi dokumentacja. Jeśli wykonawca nie umie odpowiedzieć liczbami — to sygnał ostrzegawczy.
| Kryterium odbioru | Jak sprawdzić | Kto akceptuje |
|---|---|---|
| Etykiety kurierskie | Wygenerować 3 przesyłki testowe (InPost, DPD, DHL) i sprawdzić dane nadawcy/odbiorcy | Klient |
| Faktury | Numeracja ciągła, stawki VAT, faktura korygująca, wysyłka e-mail | Księgowość klienta |
| Stany magazynowe | Porównać losowe 20 SKU po synchronizacji z ERP lub Subiektem | Magazyn |
| Zamówienia | Brak duplikatów po odświeżeniu strony i po nieudanej płatności | Klient |
Migracja bez kopii zapasowej i bez testu odtworzenia na stagingu
Jak wykryć: Brak udokumentowanego backupu z datą albo brak środowiska testowego przed pierwszymi zmianami w bazie i plikach.
Jak naprawić: Zrób pełny backup bazy i plików, odtwórz go na stagingu i sprawdź, czy sklep startuje z danymi. Dopiero potem przenoś zmiany na produkcję.
Brak przekierowań 301 ze starych adresów URL
Jak wykryć: Po migracji w Search Console rośnie liczba błędów 404, a widoczność spada w pierwszych dniach od startu.
Jak naprawić: Przygotuj mapę stary adres → nowy adres przed startem i wdroż przekierowania 301 na poziomie serwera, a nie tylko modułu. Wygeneruj nową sitemapę i zgłoś ją w Search Console.
Migracja 1:1 bez decyzji o UX i bez pomiaru efektu
Jak wykryć: Nowy sklep wygląda jak stary, a klienci porzucają koszyk dokładnie na tym samym etapie co wcześniej.
Jak naprawić: Jeśli dane pokazują porzucenia na koszyku lub płatności, zaplanuj przebudowę tych kroków zamiast kopiowania 1:1. Zmiany UX mierz przed i po (konwersja, porzucenia koszyka).
Testy płatności i kurierów dopiero po starcie
Jak wykryć: Pierwsze zamówienie testowe robisz na produkcji z prawdziwą kartą albo po udostępnieniu sklepu klientom.
Jak naprawić: Przetestuj całą ścieżkę w sandboxie (Przelewy24, PayU, tpay), a potem wykonaj jedno zamówienie produkcyjne na symboliczną kwotę i je zwróć. To samo dotyczy generowania etykiet InPost, DPD i DHL.
Brak mapowania numeracji zamówień i faktur
Jak wykryć: Po starcie numeracja zaczyna się od 1 albo w księgowości pojawiają się duplikaty numerów dokumentów.
Jak naprawić: Ustal z biurem rachunkowym, jak numerować dokumenty po migracji, i przenieś historię zamówień bez łamania ciągłości. Przetestuj wystawienie faktury do starego i nowego zamówienia.
Równoległe działanie dwóch sklepów z tą samą treścią
Jak wykryć: Oba adresy są publicznie dostępne i indeksowane, te same opisy produktów pojawiają się w Google pod dwoma linkami.
Jak naprawić: Ustaw na starym sklepie przekierowania 301 lub przynajmniej noindex i wyłącz możliwość zakupu, zanim Google zacznie traktować treści jako duplikaty.
Wdrożenie i migracja PrestaShop w Zamościu różnią się zakresem, terminem i ryzykiem, ale mają wspólny mianownik: porządek po stronie danych i integracji. Przy prostym sklepie mówimy o 2–4 tygodniach, przy migracji MŚP o 4–10 tygodniach, a z ERP o 8–16 tygodniach i budżecie liczącym 200–350 godzin pracy. Największe ryzyko to brak backupu, brak przekierowań 301 i testy płatności dopiero po starcie. Zacznij od audytu, a decyzję o zakresie podejmij na liczbach, nie na wrażeniach — ogólne zasady organizacji takich projektów opisujemy tutaj: https://dropdigital.pl/wdrozenia-i-migracje-prestashop-zamosc-organizacja
Proste wdrożenie z gotowym szablonem to 2–4 tygodnie. Migracja w firmie MŚP, z przeniesieniem produktów, klientów i zamówień, zajmuje zwykle 4–10 tygodni. Projekt z integracją ERP i wieloma językami trzeba zaplanować na 8–16 tygodni, bo najdłuższy etap to testy integracji, a nie samo przenoszenie danych.
Rozliczamy projekt godzinowo, w widełkach 150–250 zł netto za godzinę pracy dewelopera — stawka zależy od specjalizacji (frontend, backend, integracje, DevOps). Typowe pakiety to 80–120 h dla prostego wdrożenia, 140–220 h dla rozbudowy sklepu i 200–350 h dla migracji z integracjami. Konkretną liczbę godzin podajemy po audycie, bo to liczba produktów, kombinacji i integracji zmienia zakres pracy.
Tak, pod warunkiem że przekierowania 301 powstaną równolegle ze startem nowej wersji. Trzeba też przenieść metadane, opisy i strukturę kategorii oraz zgłosić nową sitemapę w Search Console. Pierwsze tygodnie po migracji warto monitorować pod kątem błędów 404 i spadków widoczności. Sam remont techniczny nie zaszkodzi, jeśli treści pozostaną wartościowe dla użytkownika — Google opisuje to w wytycznych o treściach tworzonych dla ludzi: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
Nie, jeśli pracujesz na stagingu i uruchamiasz nową wersję w oknie o najmniejszym ruchu. Stary sklep sprzedaje do momentu przełączenia domeny, a nowy jest testowany równolegle. Po starcie stary adres musi zwracać przekierowania 301, żeby nie indeksowały się dwie wersje tego samego sklepu.
Gdy sklep działa na wspieranej wersji PrestaShop, moduły nie generują błędów, a problemem jest tylko wydajność lub kilka elementów UX. Wtedy wystarczy audyt, optymalizacja serwera, cache i poprawki szablonu — to zwykle mniejszy koszt niż pełna migracja. Dokumentacja techniczna PrestaShop pomaga ocenić, czy używane moduły są zgodne z nowszymi wersjami: https://devdocs.prestashop-project.org/
Ustal jedną osobę decyzyjną po stronie firmy i harmonogram tydzień po tygodniu z jasnymi punktami kontrolnymi. Dostępy do serwera, DNS, płatności i ERP przekaż na starcie, nie w połowie prac. Sposób prowadzenia projektu w innych miastach regionu opisujemy też na przykładzie Lublina: https://dropdigital.pl/wdrozenia-i-migracje-prestashop-lublin-organizacja
Przed audytem nie wiadomo, ile modułów działa poprawnie, jak wygląda baza i czy ERP ma dokumentację API. Różnica między sklepem z 500 a 20 000 produktów to nie procent, a rząd wielkości czasu importu i testów. Dlatego podajemy widełki i doprecyzowujemy je po analizie, a nie odwrotnie.
Jeśli chcesz wiedzieć, czy w Twoim przypadku wystarczy optymalizacja, czy potrzebna jest migracja, prześlij nam adres sklepu i wersję PrestaShop. Po krótkim audycie dostaniesz zakres prac w godzinach, a nie ogólną ofertę.