Wdrożenia i migracje PrestaShop Frampol to nie jedna usługa, a dwie różne prace: budowa sklepu od zera i przeniesienie działającego sklepu na nową wersję lub z innej platformy. Mylenie ich kończy się źle oszacowanym budżetem i przestojem w sprzedaży. Poniżej znajdziesz realne widełki godzinowe, listę dostępów, które musisz przygotować, oraz sekwencję 8 etapów migracji do wydrukowania. To część organizacyjna — bez obietnic, że „przeniesiemy wszystko automatycznie” albo że wystarczy jeden klik.
Wdrożenie to budowa sklepu od zera. Dostajesz pustą instancję PrestaShop 8.x (PHP 8.1+ i MySQL 8 albo MariaDB 10.6+), konfigurację sklepu: waluty, podatki, strefy, statusy zamówień, reguły cennikowe. Do tego motyw oparty na child theme, moduły płatności (PayPal, Przelewy24, PayU), moduły kurierskie (InPost Paczkomaty, DPD, DHL), dane produktowe, strony prawne i podstawy SEO. Punktem wyjścia jest pusta baza — nie ma historii, którą można zepsuć, jest tylko to, co dopiero tworzysz. Zakres zamknięty, ryzyko skupione na konfiguracji i integracjach.
Migracja to przeniesienie działającego sklepu. Dwie odmiany: ta sama platforma w nowej wersji (PrestaShop 1.6/1.7 → 8.x) albo inna platforma → PrestaShop (WooCommerce, Shoper, autorski CMS). Zakres: produkty, kategorie, klienci, zamówienia, opinie, treści CMS, konfiguracja płatności i dostaw oraz SEO — adresy URL, znaczniki kanoniczne, przekierowania 301, mapa strony. Tu punktem wyjścia jest baza z historią, do której codziennie wracają klienci i roboty wyszukiwarek. Kompatybilność modułów i zmiany w strukturze bazy między wersjami sprawdzasz w dokumentacji dla deweloperów PrestaShop, a nie na podstawie tego, że moduł „jakoś się zainstalował”.
Kiedy NIE migrować: gdy sklep działa stabilnie, a jedyny problem to szybkość albo UX. Zmiana wersji nie naprawi ciężkiego motywu ani 40 modułów ładujących własne CSS. Taniej jest optymalizować: cache, kompresja Brotli, obrazy WebP, wyłączenie zbędnych modułów, uporządkowanie kolejności ładowania. Kolejność takich decyzji opisaliśmy w artykule o organizacji wdrożeń i migracji PrestaShop w Szczebrzeszynie.
| Kryterium | Wdrożenie od zera | Migracja |
|---|---|---|
| Liczba godzin | 40–80 h | 60–200 h (zależnie od źródła i zakresu) |
| Ryzyko przestoju | Brak — nowy sklep startuje w dniu uruchomienia | Wysokie — wymagane okno serwisowe na działającym sklepie |
| Kopia zapasowa | Kopia robocza środowiska | Obowiązkowa: baza + pliki + zdjęcia + eksport z panelu |
| Ryzyko SEO | Brak historii — indeksujesz nowe adresy | Wysokie: adresy URL, treści, przekierowania 301, mapa strony |
| Dane klientów | Brak | Przenoszone; hasła w większości przypadków do resetu |
| Ścieżka powrotu | Reinstalacja środowiska | Powrót do starej instancji w oknie serwisowym |
Trzy scenariusze, które pokrywają większość zapytań:
Co rozpycha budżet: liczba kombinacji produktów (każdy wariant to osobny wiersz w bazie), wielojęzyczność, moduły niestandardowe bez dokumentacji, integracja z ERP (Subiekt, Comarch, wFirma), zakres historii zamówień. Sam import 20 tys. zamówień z pozycjami to często 15–25 h.
Dlaczego godziny są bezpieczniejsze niż stała cena za „sklep”: wycena ryczałtowa opiera się na założeniach, które wychodzą dopiero przy eksporcie. Proś wykonawcę o rozbicie oferty na etapy z liczbą godzin i stawką. Wtedy widzisz, ile kosztuje analiza, a ile integracje — i możesz świadomie ciąć zakres.
Przekierowania przy migracji muszą zwracać właściwy kod odpowiedzi (301, nie 302), inaczej część sygnałów SEO rozmywa się — opis kodów znajdziesz w dokumentacji MDN dotyczącej HTTP. Przykład rozbicia prac z innego wdrożenia opisujemy w materiałach o migracji PrestaShop w Krasnobrodzie i wdrożeniu PrestaShop w Zwierzyńcu.
| Etap | Udział w budżecie | Co obejmuje |
|---|---|---|
| Analiza | 10% | Inwentaryzacja modułów, mapowanie danych, lista integracji |
| Przygotowanie środowiska | 15% | Hosting, staging, PHP i baza, kopie zapasowe, SSL |
| Migracja danych | 30% | Produkty, kategorie, klienci, zamówienia, treści, URL-e |
| Integracje | 25% | Płatności, kurierzy, ERP, fakturowanie, e-mail |
| Testy | 15% | Zamówienia testowe, scenariusze płatności, wydajność, SEO |
| Start i monitoring | 5% | Przełączenie DNS, tryb przerwy technicznej, obserwacja błędów |
Dobre przygotowanie skraca projekt o kilkanaście godzin, bo wykonawca nie czeka na dane i nie zgaduje zakresu. Zbierz wszystko w jednym miejscu i przekaż jednym plikiem.
config/settings.inc.php, w 1.7/8.x w app/config/parameters.php), konto administratora PrestaShop, konta u operatora płatności i u kurierów, panel domeny do zmiany DNS.Dostępy do płatności i ich tryby testowe opisujemy w tekście o organizacji wdrożenia PayPal w PrestaShop, a kolejność podłączania systemów zewnętrznych w artykule o integracjach z PrestaShop.
Migrację prowadzi się w jednej, ustalonej kolejności — skracanie jej „bo sklep jest mały” kończy się dwukrotnym importem danych i pracą na produkcji. Realny zakres to zwykle 40–80 roboczogodzin przy sklepie do 5 000 SKU i 150–250 godzin przy 20 000+ SKU z rozbudowanymi kombinacjami. Te liczby obejmują pracę techniczną, a nie czas odzyskiwania widoczności w Google (4–12 tygodni).
mysqldump --single-transaction dla bazy, archiwum plików (tar) i zrzut całego konta. Obowiązkowy test odtworzenia: kopia bez testu nie istnieje. Odtwórz bazę na stagingu i porównaj liczbę rekordów w ps_product, ps_category, ps_orders ze źródłem.robots.txt z Disallow: /, nagłówek X-Robots-Tag: noindex oraz hasło HTTP Basic Auth. Wyłącz też wysyłkę realnych maili transakcyjnych do klientów.ps_order_detail.stary_id → nowe_id i porównaj liczby rekordów przed/po dla produktów, kategorii, klientów i zamówień. Różnica rzędu 0,3% to najczęściej duplikaty SKU, nie błąd importu.Schemat tabel i kolejność operacji opisuje PrestaShop Developer Documentation. Porządek prac przy mniejszym sklepie regionalnym pokazujemy też w materiale o organizacji wdrożeń i migracji PrestaShop Krasnobród.
| Etap | Co odhaczasz | Typowy czas |
|---|---|---|
| 1. Backup | Zrzut bazy i plików + udany test odtworzenia | 2–4 h |
| 2. Staging | Subdomena, noindex, Basic Auth | 2–6 h |
| 3. Instalacja PS i modułów | Docelowa wersja + moduły na czystej bazie | 3–8 h |
| 4. Import danych | Kategorie, produkty, kombinacje, zdjęcia, klienci, zamówienia | 8–40 h |
| 5. Mapowanie ID | Tabela stary_id → nowe_id, zgodność liczb | 3–10 h |
| 6. Rekonfiguracja | Płatności, kurierzy, maile, faktury | 4–12 h |
| 7. Przekierowania i testy | Mapa 301, testy ścieżek zakupowych | 3–10 h |
| 8. Start | DNS, koniec trybu przerwy, monitoring 72 h | 2 h + 72 h obserwacji |
Największy realny koszt migracji to nie godziny programisty, a spadek widoczności. Zasada jest jedna: każdy stary URL, który miał ruch, dostaje przekierowanie 301 na najbliższy odpowiednik — produkt na produkt, kategoria na kategorię. Przekierowanie masowo na stronę główną nic nie daje: Google traktuje je jak soft 404, a użytkownik wychodzi po dwóch sekundach. W wytycznych o tworzeniu treści dla ludzi Google wprost pisze o wartości strony dla użytkownika, a nie o liczbie adresów.
Listę starych adresów zbierasz z czterech źródeł: eksport z Google Search Console (Wydajność → eksport danych), crawl narzędziem (Screaming Frog, Sitebulb), logi serwera z kodem 200 oraz sitemap.xml. Suma tych list bywa o 30–50% większa niż to, co pamięta właściciel sklepu.
Pułapka z parametrami. Adresy typu ?orderby=price, ?page=2 czy z filtrami nie powinny być indeksowane i zwykle nie wymagają przekierowania. Nie blokuj ich jednak w robots.txt przez Disallow — wtedy Google nie zobaczy ustawionego na stronie canonical ani znacznika noindex. Lepiej zostawić crawl otwarty i sterować indeksacją na poziomie strony.
Po przełączeniu: nowy sitemap.xml zgłoszony w GSC, kontrola robots.txt, sprawdzenie, czy canonical wskazuje na docelowe adresy, i ponowna weryfikacja własności domeny. Kontrole powtarzaj w 7., 30. i 90. dniu.
Nie zmieniaj jednocześnie struktury URL, treści i platformy. Jedna duża zmiana naraz uniemożliwia diagnozę: nie wiesz, czy spadek wynika z przekierowań, z nowego szablonu czy z wymiany tekstów. Jak rozłożyć te prace na etapy, opisujemy w materiale o integracjach z PrestaShop i organizacji wdrożenia oraz w planie organizacji wdrożeń i migracji PrestaShop Zamość.
| Kiedy | Co sprawdzasz | Gdzie to widzisz |
|---|---|---|
| Dzień 7 | Błędy 404, nowe 301, czy sitemap się przetworzył | GSC → Indeksowanie, logi serwera |
| Dzień 30 | Pozycje i CTR na frazach, które miały ruch przed migracją | GSC → Wydajność (porównanie 28 dni) |
| Dzień 90 | Liczba zaindeksowanych URL-i, Core Web Vitals, konwersje | GSC → Indeksowanie i Core Web Vitals, analityka |
Integracje to najczęstsze źródło opóźnień: sklep jest gotowy, ale płatności nie przechodzą testów, kurier nie generuje etykiet, a ERP nadpisuje stany magazynowe. Planuj je równolegle z importem danych, nie „po starcie”.
Zasada testu jest jedna: każda integracja przechodzi pełny cykl na stagingu — od dodania produktu do koszyka, przez płatność, etykietę i status „dostarczone”, aż po zwrot. Konfigurację jednej z nich rozpisaliśmy w materiale o PayPal w PrestaShop i organizacji wdrożenia krok po kroku.
| Integracja | Co testujesz na stagingu | Typowa pułapka |
|---|---|---|
| Płatności (P24, PayU, PayPal, BLIK) | Autoryzacja, pobranie, odmowa, zwrot pełny i częściowy | Klucze produkcyjne wpięte przed testami; brak obsługi webhooków |
| Kurierzy (InPost, DPD, DHL) | Etykieta, numer przesyłki, status zwrotny | Mapa Paczkomatów niedziałająca na mobile; numer nie zapisuje się w zamówieniu |
| ERP / księgowość | Mapowanie SKU i EAN, synchronizacja dwukierunkowa, konflikt stanów | Dwa źródła prawdy o stanie magazynowym |
| Faktury / e-paragony | Numeracja, wzór PDF, wysyłka mailem | Dane klienta w zbyt wielu systemach bez umowy powierzenia |
Decyzje hostingowe podejmuje się raz — przed startem wdrożenia. Po uruchomieniu sklepu przenosiny oznaczają przestój, ponowne testy płatności i drugie wdrożenie. Poniżej progi, którymi się posługujemy przy kwalifikacji projektu.
Nie decyduje sama liczba produktów, a liczba kombinacji. Sklep z 800 produktami i 12 000 kombinacji atrybutów obciąża bazę mocniej niż 5 000 prostych pozycji. W PrestaShop kombinacje siedzą w tabeli ps_product_attribute_combination — sprawdź tę liczbę, zanim zadzwonisz do hostingu, bo „mam 800 produktów” to za mało informacji.
PHP w wersji wspieranej i z właściwymi rozszerzeniami. Realnie wdrażamy na PHP 8.1/8.2, z włączonymi intl, mbstring, curl, zip, gd lub imagick, pdo_mysql. OPcache musi być włączony (opcache.enable=1, pamięć 128–256 MB), a validate_timestamps na produkcji ustawiony na 0 — inaczej po każdym wgraniu plików PHP sprawdza daty modyfikacji, a po deployu przez chwilę działa stary kod, dopóki nie zrestartujesz PHP-FPM. Cache obiektowy (Redis lub Memcached) włączasz w Zaawansowane → Wydajność; zdejmuje powtarzalne zapytania o kategorie, CMS i tłumaczenia. Baza: InnoDB, innodb_buffer_pool_size na poziomie 50–70% dostępnego RAM, kodowanie utf8mb4.
Moduły liczy się w zapytaniach, nie w sztukach. 30 płatnych modułów to nie 30 funkcji, a często 80–150 dodatkowych zapytań SQL, własne tabele i kilka plików JS/CSS ładowanych na każdej stronie. Trzy moduły robiące to samo (np. cross-selling) nakładają się na siebie. Jeden własny moduł bywa lżejszy i łatwiejszy do usunięcia niż trzy gotowe — i nie zostawia po sobie tabel przy odinstalowaniu.
Pomiary przed/po: TTFB, LCP, liczba zapytań SQL na stronie kategorii, liczba plików JS/CSS. Zapisz je w jednej tabelce z datą — bez punktu odniesienia każda późniejsza rozmowa o wydajności jest zgadywaniem.
Kopie zapasowe: baza i pliki codziennie, retencja 30 dni dziennych + 12 miesięcznych, jedna kopia poza serwerem produkcyjnym (inny dostawca lub storage obiektowy). Raz na kwartał odtwórz kopię na stagingu i sprawdź, czy sklep wstaje — kopia, której nikt nie testował, nie jest kopią.
| Kryterium | Hosting współdzielony | VPS / serwer dedykowany |
|---|---|---|
| Produkty proste (bez kombinacji) | do ok. 1 000 | powyżej 2 000–3 000 |
| Kombinacje atrybutów | do ok. 3 000 | powyżej 10 000 |
| Wizyty miesięcznie | do ok. 5 000 | powyżej 10 000–15 000 |
| Sytuacje dodatkowe | jeden język, brak stałej wymiany danych z systemami zewnętrznymi | wielosklep, kilka języków, importy CSV z ERP, kampanie reklamowe |
| Kontrola nad konfiguracją | brak lub ograniczona (php.ini, cron, restart usług) | pełna: PHP, OPcache, Redis, MySQL, cron, logi |
Lista jest do odhaczenia — kolejność ma znaczenie, bo błąd w punkcie 1 lub 2 blokuje sensowny test wydajności. Jeśli nie masz na to czasu przed przełączeniem, to znaczy, że przełączenie jest zaplanowane za wcześnie.
.htaccess i dodaj nagłówek X-Robots-Tag: noindex. Test obciążeniowy na produkcji generuje sztuczne zamówienia i ruch w indeksie.| Element | Jak testować | Kryterium zaliczenia |
|---|---|---|
| Płatności | pełna transakcja na niską kwotę + zwrot | zamówienie i zwrot widoczne w panelu i na bramce |
| Maile transakcyjne | 4 skrzynki: Gmail, Outlook, Onet, WP | wszystkie dotarły, SPF/DKIM/DMARC ustawione |
| Kody rabatowe | każdy typ osobno i w kombinacji | rabat nalicza się raz, zgodnie z regułą |
| Koszyk porzucony | porzuć koszyk i czekaj na mail | link wraca do tego samego koszyka |
| Rollback | odtworzenie kopii na stagingu | sklep wstaje w założonym czasie |
Co realnie powinno być w SLA. Czas reakcji liczony jako przyjęcie zgłoszenia, nie jako rozwiązanie: 4 h w dni robocze dla spraw zwykłych, 1 h dla krytycznych. Czas naprawy: krytyczny 4–8 h, zwykły 2–5 dni roboczych. Zakres godzin wsparcia 8:00–16:00, poza nimi wyłącznie krytyczne. Jeden kanał zgłoszeń — mail plus telefon, nie Messenger. Dodatkowo raport miesięczny: liczba zgłoszeń, czasy reakcji, wykonane aktualizacje, data ostatniego testu odtworzenia kopii.
Krytyczny znaczy jedno: sklep nie przyjmuje zamówień albo nie działa. Wszystko inne jest zwykłe. Bez tej definicji w umowie okaże się, że „krytyczne” jest każde zgłoszenie.
Bezpośrednio z deweloperem, nie przez łańcuch pośredników. Każde ogniwo to dodatkowe 20–40 minut na przekazanie kontekstu: co się zmieniło, gdzie leży plik, jaki był poprzedni objaw. Przy awarii w piątek po 15:00 to różnica między naprawą w godzinę a naprawą w poniedziałek.
Kontekst lokalny. Frampol leży w powiecie biłgorajskim — do Biłgoraja jest kilkanaście kilometrów, do Zamościa kilkadziesiąt, do Lublina niecałe sto. Powiemy wprost: kod pisze się zdalnie i odległość nie poprawia jakości wdrożenia. Znaczenie ma w trzech sytuacjach: awarii sprzętowej, przy przekazywaniu dostępów z podpisaniem dokumentów oraz przy pilnych sprawach, gdy ktoś musi być na miejscu tego samego dnia.
Pytania przed podpisaniem umowy: kto konkretnie koduje i kto odpowiada za wdrożenie; ile projektów prowadzi równolegle; czy prawa do kodu własnych modułów przechodzą na zamawiającego, czy zostaje tylko licencja; jak wygląda przekazanie dokumentacji (repozytorium, README, opis modułów, dostępy, schemat bazy); kto robi aktualizacje bezpieczeństwa PrestaShop i w jakim czasie od wydania poprawki.
Podobne ustalenia opisaliśmy dla Krasnobrodu, Zwierzyńca, Szczebrzeszyna i Zamościa — różnice dotyczą głównie skali sklepu, nie samej listy kontrolnej.
| Typ zgłoszenia | Czas reakcji | Czas naprawy |
|---|---|---|
| Krytyczny (sklep nie sprzedaje) | 1 h w godzinach wsparcia | 4–8 h |
| Zwykły (błąd, poprawka, konfiguracja) | 4 h w dni robocze | 2–5 dni roboczych |
| Rozwój / nowa funkcja | 1 dzień roboczy | wg wyceny i harmonogramu |
| Aktualizacja bezpieczeństwa | potwierdzenie w ciągu 24 h | wg krytyczności poprawki |
Zamawianie migracji, gdy prawdziwym problemem jest szybkość lub UX. Sklep działa stabilnie, ale wolno się ładuje, a klient i tak chce „nową platformę”.
Jak wykryć: Sprawdź Core Web Vitals w Search Console i zmierz czas ładowania katalogu oraz karty produktu na realnym hostingu. Jeśli problemem są obrazy, cache i hosting, migracja nic nie naprawi — przeniesiesz ten sam problem na nowy serwer.
Jak naprawić: Zacznij od optymalizacji: kompresja i konwersja zdjęć do WebP, włączenie cache, aktualizacja motywu, porządki w bazie i modułach. Dopiero gdy to nie pomaga, planuj migrację.
Brak testu odtworzenia kopii zapasowej przed startem prac. Kopia istnieje, ale nikt nigdy jej nie odtworzył.
Jak wykryć: Zapytaj wykonawcę, na jakim środowisku odtworzył kopię i czy liczby rekordów zgadzają się z produkcją. Jeśli nie ma takiego testu w planie, kopia jest tylko plikiem.
Jak naprawić: Odtwórz kopię na stagingu przed pierwszym importem i porównaj liczbę produktów, kategorii, klientów i zamówień. Dopisz to do zakresu prac jako punkt obowiązkowy.
Traktowanie wyceny ryczałtowej „za sklep” jako bezpieczniejszej. Przy stałej cenie każda niespodzianka wraca jako dopłata albo jakościowy kompromis.
Jak wykryć: Poproś ofertę o rozbicie na etapy (analiza, środowisko, dane, integracje, testy, start). Jeśli wykonawca nie potrafi rozbić prac, nie oszacował ich rzetelnie.
Jak naprawić: Rozliczaj projekt w godzinach z etapowym podziałem i jawnym buforem 15–20% na stare moduły, brak dostępu do bazy i nietypowe pola.
Uruchomienie środowiska staging bez blokady indeksowania. Testowy sklep pojawia się w Google i konkuruje z produkcją o te same treści.
Jak wykryć: Wejdź na staging i sprawdź nagłówki HTTP oraz plik robots.txt, a także czy strona nie została zaindeksowana (site: z adresem subdomeny w wyszukiwarce).
Jak naprawić: Ustaw noindex dla całego stagingu i zabezpiecz go hasłem. Zdjęcie blokady robisz dopiero po przekierowaniu domeny na docelową instalację.
Brak mapy przekierowań 301 przed zmianą adresów. Stare adresy produktów i kategorii zwracają 404 i wygaszają ruch organiczny.
Jak wykryć: Po migracji sprawdź w Search Console raport „Nie znaleziono (404)” oraz wyrywkowo 20–30 starych adresów URL z katalogu i z historii wyszukiwania.
Jak naprawić: Przygotuj mapę stary URL → nowy URL jeszcze przed startem, wdróż przekierowania 301 i pilnuj raportu 404 przez pierwsze 4–6 tygodni po migracji.
Ustalenie zakresu „na wyczucie”, bez decyzji, czy przenosimy historię zamówień, opinie i statystyki. W trakcie projektu wychodzi, że nikt tego nie uzgodnił.
Jak wykryć: Porównaj zakres z ofertą: czy jest tam wprost napisane, które tabele i dane są migrowane, a które zostają na starej instalacji jako archiwum tylko do odczytu.
Jak naprawić: Zrób pisemną listę zakresu przed startem i przypisz każdej pozycji decyzję: przenosimy / zostaje w archiwum / nie przenosimy. Hasła klientów i tak wymagają resetu.
Wdrożenie i migracja to dwie różne prace o różnym zakresie, ryzyku i budżecie — pierwsza startuje od 40 godzin, druga od 60, a przy zmianie platformy od 100. Największym kosztem nie jest sama instalacja PrestaShop, a dane: kombinacje produktów, historia zamówień, integracje i stare moduły. Dlatego wycena godzinowa z podziałem na etapy i buforem 15–20% jest bezpieczniejsza niż ryczałt. Zanim podpiszesz umowę, przygotuj dostępy i pisemny zakres — to skraca projekt o kilkanaście godzin.
Proste wdrożenie nowego sklepu to zwykle 40–80 godzin. Migracja PrestaShop 1.6 lub 1.7 do 8.x to 60–120 godzin, a przeniesienie sklepu z WooCommerce, Shoppera czy autorskiego CMS to 100–200 godzin. Do każdego scenariusza dolicz bufor 15–20% na stare moduły i nieprzewidziane dane.
Nie. Hasła są przechowywane w formie skrótu i nie da się ich przenieść tak, aby klient nie zauważył zmiany. Standardowe rozwiązanie to migracja kont i wymuszenie resetu hasła przy pierwszym logowaniu. Zaplanuj wtedy komunikację mailową, żeby nie zasypali Cię zgłoszeniami na infolinii.
Całkowicie bez przestoju się nie da, bo na moment przełączenia domeny dane muszą być spójne. Realnie mówimy o trybie przerwy technicznej trwającym od kilku godzin do jednego dnia w przypadku dużych katalogów. Cała praca — import, integracje i testy — dzieje się wcześniej na stagingu, więc okno serwisowe jest krótkie.
Przy poprawnej mapie przekierowań 301 ruch zwykle utrzymuje się, choć krótkotrwałe wahania są normalne. Kluczowe są: zachowanie struktury adresów, mapa 301 przygotowana przed startem i monitoring raportu 404 w Search Console. Warto też pilnować Core Web Vitals po zmianie, bo nowy hosting i motyw mogą zmienić wyniki na lepsze albo gorsze.
Nie, jeśli jedynym problemem jest szybkość albo UX. W takiej sytuacji taniej jest optymalizować: obrazy, cache, motyw, porządki w bazie i modułach. Migracja ma sens, gdy platforma nie jest już wspierana, brakuje integracji albo koszt utrzymania starych rozwiązań przewyższa koszt przeniesienia.
Godzinowo z etapowym podziałem jest bezpieczniej dla obu stron. Widzisz, na co idą pieniądze, a zakres zmian jest jawnie wyceniany. Ryczałt „za sklep” wygląda prościej, ale przy pierwszej niespodziance wraca jako dopłata albo jako cichy kompromis na jakości testów.
Praktyczny podział to: analiza 10%, przygotowanie środowiska 15%, migracja danych 30%, integracje 25%, testy 15%, start i monitoring 5%. Do tego bufor 15–20% na nieprzewidziane sytuacje, na przykład brak dostępu do bazy albo nietypowe pola w starym systemie. Taki układ łatwo przypisać do konkretnych tygodni i rozliczyć etapami.
Jeśli chcesz przejść przez wdrożenie lub migrację PrestaShop bez niespodzianek w budżecie, napisz do nas — rozbijemy prace na etapy i powiemy wprost, co da się przenieść, a co zostawić w archiwum.