Migracja PrestaShop: 6 kroków zmiany serwera
Materiał reklamowy — linki partnerskie: LH.pl, dhosting.pl.
Migracja PrestaShop na inny serwer polega na przeniesieniu tej samej instalacji wraz z plikami, bazą i konfiguracją. Najtrudniejszy moment to ustalenie, gdzie zapisują się zamówienia i potwierdzenia płatności podczas przełączenia. Sama działająca strona główna nie dowodzi, że sklep został przeniesiony poprawnie.
Porównaj usługi
Poniższa ścieżka dotyczy zachowania obecnej domeny i wersji sklepu. Dużą aktualizację PrestaShop, zmianę motywu lub przejście na inny CMS zaplanuj osobno. Potrzebujesz dostępu do panelu sklepu, plików, bazy, DNS, nowego hostingu i operatorów integracji. Jeśli nie potrafisz odtworzyć bazy na kopii, zleć wykonanie administratorowi i użyj tej instrukcji do odbioru prac.
W tym poradniku
- Migracja PrestaShop: najpierw sprawdź zgodność
- Przygotuj pełną kopię i środowisko docelowe
- Zmień połączenie z bazą i sprawdź pamięć podręczną
- Przetestuj kopię bez uruchamiania prawdziwej sprzedaży
- Ustal ostatnią synchronizację i płatności w toku
- Przełącz ruch, SSL i zadania cron
- Sprawdź sprzedaż i przygotuj powrót z nowymi danymi
- Jaki pakiet kupić do takiej migracji?
Migracja PrestaShop: najpierw sprawdź zgodność
Zapisz dokładną wersję PrestaShop, PHP, silnika bazy, motywu i wszystkich modułów. Dołącz rozmiar plików i bazy, ustawienia poczty, listę zadań cron oraz zewnętrznych połączeń. Odczytaj bieżące limity pamięci, czasu wykonania i wielkości importu. Nowy serwer powinien obsługiwać ten zestaw; sama etykieta „hosting PrestaShop” tego nie rozstrzyga.
Dokumentacja PrestaShop 9 rozróżnia wersje 9.0 i 9.1. Dla 9.0 rekomenduje PHP 8.4, a dla 9.1 PHP 8.5. Nie wybieraj PHP 8.5 do 9.0 tylko dlatego, że jest nowsze. Dla starszej instalacji sprawdź właściwą tabelę zgodności i wsparcie bezpieczeństwa. Nie przenoś długo nieaktualizowanego sklepu na przypadkową starą wersję PHP jako trwałe rozwiązanie.
Ustal też odpowiedzialność: kto przygotowuje kopię, kto testuje płatności i kto zezwala na otwarcie sklepu. Operator może kopiować dane, a nie znać logiki Twojej integracji magazynowej. Zapisana lista odbioru oszczędza szukanie odpowiedzialnej osoby dopiero w chwili awarii.
1. Przygotuj pełną kopię i środowisko docelowe
Jeszcze przed kopiowaniem danych poproś administratora o zamknięcie publicznego dostępu do środowiska docelowego i blokadę wychodzących wiadomości oraz produkcyjnych wywołań do ERP i płatności. Nie uruchamiaj tam cron. Blokady mają działać poza konfiguracją kopiowanego sklepu, aby import bazy nie włączył ich ponownie. Nie otwieraj panelu ani nie wykonuj PHP przeniesionej kopii, dopóki nie ustawisz jej połączenia z osobną bazą docelową w kroku 2.
- Wykonaj kopię wszystkich plików sklepu przez SFTP lub narzędzie kopii operatora, z zachowaniem plików ukrytych, zdjęć, modułów i zmienionej nazwy katalogu administracyjnego.
- Wyeksportuj całą bazę z jej strukturą i danymi. Eksport produktów do CSV nie zastępuje kopii bazy. W panelu bazy, np. phpMyAdmin, wybierz właściwą bazę i eksport SQL wszystkich należących do niej tabel.
- Zapisz kopię poza publicznym katalogiem WWW. Zachowaj czas wykonania i zabezpiecz dostęp, bo baza zawiera dane klientów oraz zamówień.
- Na nowym hostingu utwórz osobną pustą bazę i użytkownika z uprawnieniami do niej. Ustaw zgodne PHP, rozszerzenia i limity, następnie skopiuj pliki i zaimportuj SQL.
- Sprawdź komunikat zakończenia importu, liczbę tabel i rozmiar danych. Timeout przeglądarki nie oznacza ukończonego importu; przy dużej bazie poproś operatora o import serwerowy zamiast dzielenia pliku przypadkowo w edytorze.
Kopia wykonana podczas pracy sklepu służy przede wszystkim próbie. Zamówienia zapisane później trzeba zsynchronizować przed przełączeniem. Dla końcowego przeniesienia potrzebujesz spójnego punktu danych albo kontrolowanej metody synchronizacji; oddzielne eksporty wykonane w różnych chwilach mogą się ze sobą nie zgadzać.
Przed pracą sprawdź retencję kopii i sposób ich przywracania. Informacja „backup codziennie” nie dowodzi, że odtworzysz aktualne zamówienia ani że kopia obejmuje pliki, bazę i konfigurację integracji.
2. Zmień połączenie z bazą i sprawdź pamięć podręczną
W nowoczesnych instalacjach PrestaShop ustawienia połączenia z bazą znajdują się w app/config/parameters.php. Zrób kopię tego pliku, a następnie dostosuj host, nazwę bazy, użytkownika, hasło i ewentualny port do nowego środowiska. Zachowaj właściwy prefiks tabel. Nie zamieniaj całego pliku na przykład znaleziony w internecie i nie regeneruj przy okazji kluczy sklepu.
W starszych wydaniach ścieżka i format konfiguracji mogą być inne. Korzystaj z dokumentacji swojej wersji, zamiast dopisywać nowy plik obok faktycznie używanego. Po zmianie danych połączenia wyczyść cache zgodnie z dokumentacją: obszary var/cache/prod i, jeśli używany, var/cache/dev. Dotyczy to pamięci podręcznej przenoszonej kopii, nie katalogów produktów, modułów lub całego sklepu.
Gdy możesz już wejść do panelu, kontrolę cache znajdziesz także w parametrach zaawansowanych na stronie wydajności. Błąd dostępu do bazy najpierw porównaj z danymi z panelu nowego hostingu. Błąd zapisu cache wymaga właściwego właściciela plików i uprawnień dla serwera; nie rozwiązuj go nadaniem wszystkim plikom praw 777.
3. Przetestuj kopię bez uruchamiania prawdziwej sprzedaży
Poproś operatora o bezpieczny podgląd nowej instalacji. Przy lokalnym wskazaniu obecnej domeny na nowy adres, np. przez plik hosts komputera testera, tylko ten komputer zobaczy nowy serwer. Domena musi mieć poprawny certyfikat również na nowym hoście. Nie akceptuj ostrzeżenia TLS jako zakończonego testu SSL.
Odizoluj kopię od rzeczywistych działań: wyłącz produkcyjne wysyłki do magazynu, masowe wiadomości i zadania cykliczne. Dla płatności wykorzystaj środowisko testowe operatora. Ochrona dostępu hasłem zabezpiecza kopię lepiej niż samo noindex; nie udostępniaj swobodnie danych klientów pod adresem testowym.
Sprawdź kategorię, wyszukiwanie, produkt z wariantami, koszyk, rabat, dostawę, rejestrację i logowanie. Wykonaj zamówienie testowe i sprawdź jego kwoty, status oraz wiadomość w kontrolowanej skrzynce. Porównaj wybrane stare zamówienia z ich sumami, pozycjami i powiązaniami.
Lokalny plik hosts nie zmienia adresu widzianego przez operatora płatności. Zewnętrzne powiadomienie może nadal trafiać na stary serwer. Pełny test takiego połączenia wymaga uzgodnionego publicznego adresu testowego lub ponownej kontroli po przełączeniu. Nie oznaczaj samodzielnego otwarcia koszyka jako potwierdzenia wszystkich płatności.
4. Ustal ostatnią synchronizację i płatności w toku
Wybierz termin o małym ruchu i zapowiedz przerwę. Zatrzymaj przyjmowanie nowych zamówień oraz operacje zmieniające katalog i magazyn. Uzgodnij zatrzymanie importów, cron i integracji po obu stronach. Sam tryb konserwacji strony nie musi zatrzymać wszystkich połączeń API.
Zanotuj ostatnie zamówienie i wyeksportuj listę transakcji oczekujących z panelu płatności. Potwierdzenia wpłat mogą nadejść po wykonaniu kopii. Ustal z integratorem, czy będą przekazane na nowy serwer, ponowione według mechanizmu operatora czy ręcznie uzgodnione. Nie zakładaj, że każda bramka automatycznie ponowi każde odrzucone powiadomienie.
Po zatrzymaniu zapisów wykonaj końcową kopię danych i zsynchronizuj zmienione pliki. Pełny końcowy eksport SQL zaimportuj do nowej, pustej bazy na serwerze docelowym, a nie do bazy zawierającej zamówienia z próby. Sprawdź zakończenie importu, następnie wskaż tę końcową bazę w parameters.php i wyczyść cache. Zachowaj blokady środowiska z kroku 1: końcowy import może przywrócić produkcyjne ustawienia modułów. Jeżeli ponownie kopiujesz pliki konfiguracji, przed kolejnym uruchomieniem PHP przywróć w kopii docelowej nowe dane połączenia z bazą; stary plik nie może skierować nowej strony z powrotem do starej bazy.
Przykład: o 21:00 zatrzymujesz nowe zakupy, a o 21:04 klient kończy płatność za zamówienie utworzone o 20:58. Ta wpłata musi zostać skojarzona z tym samym zamówieniem po migracji, nawet jeśli eksport bazy wykonano o 21:02. Porównanie listy płatności i zamówień zamyka tę lukę; same godziny wykonania plików nie wystarczą.
5. Przełącz ruch, SSL i zadania cron
Gdy końcowa kontrola danych się zgadza, zmień właściwe rekordy kierujące WWW na nowy serwer. Sprawdź zarówno IPv4, jak i istniejące IPv6 oraz ewentualne pośrednictwo CDN. Rekordów MX i ustawień poczty nie zmieniaj automatycznie, jeśli skrzynki pozostają u dotychczasowego dostawcy. Mechanizm i znaczenie TTL opisuje poradnik o DNS.
Pod obecną domeną sprawdź certyfikat, przekierowanie HTTP do HTTPS, adresy obrazów i wszystkie ważne podstrony. Przy zachowaniu domeny i ścieżek nie jest potrzebna masowa zmiana URL-i sklepu. Jeśli widzisz przekierowanie na adres testowy, wróć do ustawień domeny w kopii i konfiguracji serwera; nie zmieniaj na ślepo całej bazy operacją wyszukaj–zamień.
Odtwórz zadania cron na nowym hostingu z prawidłową ścieżką PHP, ścieżkami plików i harmonogramem. Włącz produkcyjne integracje tylko w jednym aktywnym środowisku. Stary sklep pozostaw niedostępny dla nowych zakupów tak długo, jak część klientów może trafiać na jego adres z pamięci DNS. Nie odłączaj starej usługi przed uzgodnieniem transakcji i ukończeniem obserwacji.
6. Sprawdź sprzedaż i przygotuj powrót z nowymi danymi
Po przełączeniu DNS, nadal przed otwarciem sklepu klientom, dopuść kontrolowany test na nowym hoście. W uzgodniony sposób włącz tylko potrzebne połączenia produkcyjne, złóż kontrolowane zamówienie i sprawdź rzeczywiste potwierdzenie płatności, status w nowej bazie, wiadomość oraz przekazanie do integracji. Jeśli bramka nie pozwala wykonać takiego testu bez obciążenia, ustal wcześniej kwotę i sposób zwrotu z właścicielem. Nie przyjmuj pierwszego zamówienia przypadkowego klienta jako próby technicznej. Dopiero po zgodnym wyniku i uzgodnieniu wcześniejszych transakcji usuń ograniczenie zakupów.
| Kontrola | Oczekiwany rezultat |
|---|---|
| Dane | Uzgodnione liczby i sumy zamówień, poprawne warianty oraz stany |
| Płatność | Właściwy status zamówienia po potwierdzeniu; brak podwójnego przetwarzania |
| Poczta i integracje | Wiadomość trafia do odbiorcy, a zamówienie do właściwego systemu |
| SSL i URL-e | Poprawna domena, certyfikat i ścieżki bez adresu testowego |
| Logi i cron | Brak nowych błędów krytycznych; zadania działają tylko na nowym serwerze |
| Kopie | Nowy backup plików i bazy oraz potwierdzona możliwość odtworzenia |
Prosty powrót do niezmienionego źródła jest możliwy tylko wtedy, gdy na celu nie powstały nowe zapisy ani transakcje. Nawet kontrolowany zakup przed otwarciem sklepu klientom wymaga zachowania jego danych i uzgodnienia płatności lub zwrotu. Jeśli nowe dane już powstały, zatrzymaj zapisy, zachowaj aktualną bazę, transakcje i zmienione stany, a dopiero potem uzgodnij przeniesienie ich do środowiska, na które wracasz. Samo cofnięcie DNS do starej kopii grozi utratą historii opłaconych zamówień.
Jaki pakiet kupić do takiej migracji?
Dla sklepu z 8 GB plików, 1 GB bazy i 1 GB poczty nowa produkcja potrzebuje około 10 GB. Druga kopia WWW i bazy to kolejne 9 GB; dolicz zapas na aktualizacje oraz wzrost. LH.pl Mango 30 GB jest kandydatem do sprawdzenia dla takiej pojemności, po potwierdzeniu stosu i limitów. Pierwszy rok: 37,50 zł netto i źródłowe 46,12 zł brutto; odnowienie: 399 zł netto / 490,77 zł brutto rocznie. Trzy lata przy obecnych cenach: 1027,66 zł brutto.
Gdy potrzebujesz 50 GB i dodatkowych zasobów podczas importów, sprawdź dhosting EWH: 99 zł netto / 121,77 zł brutto na pierwszy rok, potem 399 zł netto / 490,77 zł brutto. Bazowe trzy lata kosztują 1103,31 zł brutto; skalowanie jest osobno płatne. Kwoty uwzględniają VAT 23%, nie obejmują pracy migracyjnej i nie są testem wydajności.
Wybierz ofertę dopiero po potwierdzeniu wymagań danej wersji PrestaShop i próbie na kopii. Porównanie hostingu z warunkami migracji i odnowienia pomaga zawęzić wybór; plan ostatniej synchronizacji oraz odbiór zamówień pozostają częścią konkretnego zlecenia.
