Migracja sklepu internetowego: przeniesienie sklepu na inny hosting, migracja PrestaShop i WooCommerce

Czym migracja sklepu różni się od przeniesienia zwykłej strony

Stronę wizytówkową można przenieść w dowolny wtorek i nikt tego nie zauważy. Sklep pracuje w sposób ciągły: w czasie, gdy kopiujesz bazę danych, klient może złożyć zamówienie i zapłacić. Jeśli przełączysz domenę na nowy serwer po godzinie, to zamówienie zostaje na starym serwerze i nigdy nie trafi do nowego. Dlatego przy sklepie liczy się nie szybkość kopiowania, tylko moment domknięcia danych.

Druga różnica to liczba rzeczy podpiętych z zewnątrz. Sklep rozmawia z bramką płatniczą, kurierem, systemem księgowym, hurtownią i porównywarką cen. Każda z tych integracji ma zapisany adres albo klucz i część z nich trzeba autoryzować ponownie po zmianie serwera. Sklep potrafi wyglądać poprawnie i jednocześnie nie wysyłać zamówień do systemu księgowego przez tydzień, zanim ktoś to zauważy.

Migracja WooCommerce: gdzie naprawdę leżą zamówienia

To jest najczęstszy sposób na zgubienie zamówień przy samodzielnej migracji i jednocześnie najsłabiej opisany. Przez lata WooCommerce trzymał zamówienia w tabelach posts i postmeta, czyli tam, gdzie WordPress trzyma wpisy i strony. Wtyczki do migracji i poradniki z tamtych czasów kopiowały właśnie te tabele i to wystarczało.

Od WooCommerce 8.2, wydanego w październiku 2023 roku, domyślnym magazynem zamówień w nowych instalacjach jest High-Performance Order Storage. Dane zamówień leżą w czterech osobnych tabelach: wc_orders, wc_order_addresses, wc_order_operational_data oraz wc_orders_meta. Kopia ograniczona do klasycznych tabel WordPressa odtworzy produkty, strony i wpisy, a zamówień w panelu nie będzie. Sklep wygląda wtedy na sprawny, więc błąd wychodzi dopiero przy pierwszym rozliczeniu.

Praktyczny wniosek jest prosty: przy sklepie na WooCommerce przenosi się całą bazę danych, a nie wybrane tabele. Przed przełączeniem domeny warto policzyć zamówienia w panelu starego i nowego sklepu i porównać obie liczby. To jedno sprawdzenie wyłapuje ten błąd w całości.

• Zrzut całej bazy, nie eksport z wtyczki ograniczonej do treści WordPressa.
• Porównanie liczby zamówień na starym i nowym serwerze przed przełączeniem domeny.
• Sprawdzenie ostatniego zamówienia co do numeru, kwoty i statusu płatności.
• Kopia kontrolna tuż przed zmianą DNS, żeby domknąć zamówienia z okresu testów.

Migracja PrestaShop: pułapka wersji PHP

Przy PrestaShop najczęstszy problem nie dotyczy danych, tylko środowiska. Sklep przenosi się poprawnie, a potem nie startuje, bo nowy serwer ma nowszą wersję PHP niż ta, którą obsługuje dana wersja sklepu. Zakresy są wąskie i łatwo o pomyłkę, więc zestawiliśmy je w tabeli niżej na podstawie oficjalnej dokumentacji PrestaShop i WooCommerce, sprawdzonej 30 sierpnia 2026 roku.

Z tego zestawienia wynika rzecz, która zaskakuje właścicieli dwóch sklepów na jednym koncie hostingowym: sklep na PrestaShop 8 i sklep na WooCommerce nie zmieszczą się na wspólnej wersji PHP. PrestaShop 8 kończy się na PHP 8.1, a WooCommerce wymaga co najmniej 8.3. Potrzebne są wtedy dwa katalogi z osobno ustawioną wersją PHP, co u nas jest standardem, albo aktualizacja PrestaShop do wersji 9. PrestaShop 9 obsługuje PHP od 8.1 do 8.4, więc dopiero on spotyka się z WooCommerce na wspólnym gruncie.

Druga różnica dotyczy pamięci. WooCommerce prosi o limit pamięci 256 MB, a dokumentacja PrestaShop 9 rekomenduje 512 MB na skrypt. Jeśli sklep po migracji wyświetla białą stronę przy imporcie produktów albo w panelu, to zwykle właśnie ten limit, a nie brak mocy serwera.

Jak wygląda migracja sklepu krok po kroku

Prowadzimy migrację tak, żeby stary sklep sprzedawał do ostatniej minuty. Nowy serwer przygotowujemy równolegle, w tle, a kupujący cały czas trafiają na działającą wersję. Przełączenie jest ostatnią czynnością, nie pierwszą.

• 1. Inwentaryzacja: spisujemy wersję sklepu, wersję PHP, wtyczki płatnicze, integracje kurierskie i skrzynki pocztowe.
• 2. Kopia: pobieramy pliki i pełny zrzut bazy danych od dotychczasowego dostawcy.
• 3. Odtworzenie: stawiamy sklep na naszym serwerze na adresie roboczym, ustawiamy właściwą wersję PHP i limit pamięci, wystawiamy certyfikat SSL.
• 4. Testy sprzedaży: przechodzimy pełną ścieżkę zakupową, od dodania do koszyka po płatność testową i wysyłkę potwierdzenia.
• 5. Obniżenie TTL wpisów DNS do 300 do 600 sekund na 24 do 48 godzin przed przełączeniem.
• 6. Domknięcie danych: kopia kontrolna zamówień z okresu testów, tuż przed zmianą serwerów nazw.
• 7. Przełączenie w ustalonym oknie, zwykle rano w dzień roboczy, gdy sprzedaż jest najniższa.
• 8. Obserwacja: stary serwer zostaje włączony jeszcze przez kilka dni jako zabezpieczenie.

Kiedy przełączyć sklep, żeby nie stracić zamówień

Zerowy przestój nie bierze się z tempa pracy, tylko z kolejności i z czasu życia wpisów DNS. Standardowy TTL to 86400 sekund, czyli doba. Jeśli zmienisz serwery nazw bez wcześniejszego obniżenia TTL, przez kolejne 24 godziny część kupujących nadal trafi na stary sklep, a Ty będziesz mieć zamówienia w dwóch bazach naraz. Rozjazd zamówień jest gorszy niż krótka przerwa, bo wychodzi na jaw dopiero przy wysyłce i rozliczeniu.

Dlatego TTL obniżamy z wyprzedzeniem, a samo przełączenie planujemy na porę najniższej sprzedaży. Dla większości polskich sklepów jest to wczesny ranek w dzień roboczy. Odradzamy migrację w listopadzie i grudniu oraz w tygodniu poprzedzającym własną kampanię promocyjną. Jeśli sklep przenosi się przed sezonem, najlepszy moment to styczeń albo luty.

• Zamrożenie zmian w panelu na czas migracji: bez nowych produktów, cen i wysyłek.
• Okno poza szczytem, ustalone z Tobą, a nie narzucone przez dostawcę.
• Krótki TTL przygotowany dobę wcześniej, żeby przełączenie liczyło się w minutach.
• Stary serwer w gotowości przez kilka dni po przełączeniu.

Co sprawdzić w sklepie zaraz po migracji

Sklep, który się wyświetla, to nie jest sklep, który sprzedaje. Po przełączeniu domeny przechodzimy listę kontrolną, bo część usterek nie widać z poziomu strony głównej. Najbardziej podstępne są powiadomienia od bramki płatniczej: klient płaci, pieniądze wpływają, a zamówienie w panelu zostaje ze statusem oczekującym, bo powiadomienie idzie pod stary adres.

Osobno pilnujemy poczty. Po zmianie serwera zmienia się adres wysyłający, więc bez poprawnych rekordów SPF i DKIM potwierdzenia zamówień zaczynają lądować w spamie. Dla sklepu to realna strata, bo kupujący nie dostaje numeru przesyłki i pisze do obsługi zamiast czekać.

• Płatność testowa zakończona zamówieniem o statusie opłacone.
• Liczba zamówień zgodna ze starym panelem, łącznie z ostatnim numerem.
• Wiadomości transakcyjne docierające do skrzynki, a nie do folderu ze spamem.
• Etykieta kurierska wygenerowana na próbnym zamówieniu.
• Certyfikat SSL ważny na domenie głównej i na wersji z przedrostkiem www.
• Mapa witryny i przekierowania działające tak jak przed migracją.

Na jakim planie postawić sklep po migracji

Sklep zachowuje się inaczej niż strona firmowa, bo prawie każde żądanie jest dynamiczne i uderza w bazę danych. Dlatego przy sklepach nie polecamy planu Startowego. Mówimy to wprost, mimo że jest najtańszy: nie ma w nim LiteSpeed ani Redisa, a to właśnie te dwa elementy odciążają bazę przy koszyku i wyszukiwarce produktów. Startowy jest dobrym wyborem dla strony wizytówkowej, nie dla sprzedaży.

Dla typowego sklepu z kilkuset produktami sensownym minimum jest plan Biznes, a przy większym katalogu, ruchu z kampanii i wymaganiach na monitoring plan Zarządzany Pro. Cena odnowienia jest u nas taka sama jak startowa, więc rachunek za drugi rok nie skacze. Szczegóły wydajności opisaliśmy na stronie szybki hosting NVMe, a pełne zestawienie planów znajdziesz w cenniku.