Przenoszę sklepy WooCommerce i PrestaShop z hostingu współdzielonego na dedykowany VPS. Bez przestojów w sprzedaży, bez utraty pozycji SEO i bez niespodzianek po przełączeniu DNS.
Środowisko docelowe
Nie narzucam jednego dostawcy VPS ani jednej dystrybucji. Dobieram środowisko docelowe pod specyfikę Twojej platformy i budżet — od ekonomicznych instancji Hetzner po wydajne maszyny OVH czy AWS.
Czyste środowisko pod produkcyjne instalacje WooCommerce i PrestaShop. Stabilne repozytoria LTS, natywne wsparcie dla OpenLiteSpeed i szybkich systemów cache.
Dostrojone środowisko klasy Enterprise pod rygorystyczne polityki bezpieczeństwa. Pełne wsparcie dla reguł SELinux, izolacji procesów PHP-FPM i systemowego firewalld.
Przenosiny nie tylko między serwerami, ale też między platformami (np. Magento → WooCommerce). Zachowuję integralność danych produktowych.
Ryzyko
Widziałem setki migracji wykonanych „na szybko" przez web developerów bez doświadczenia w administracji serwerami. Najczęstszy scenariusz: sklep zostaje skopiowany przez FTP, baza zaimportowana z phpMyAdmin, DNS przekierowany — i przez kolejne 48h support odbiera telefony od wściekłych klientów, którzy nie mogą sfinalizować zamówień.
Migracja e-commerce to nie kopiowanie plików. To synchronizacja stanu aplikacji w ruchu — z aktywnymi sesjami użytkowników, oczekującymi płatnościami i webhookami zwrotnymi z bramek. Każda minuta desynchronizacji między starym a nowym serwerem to ryzyko utraty zamówienia.
Bez odpowiedniej procedury — synchronizacji przyrostowej bazy danych, przygotowania certyfikatów SSL przed przełączeniem DNS i whitelistowania nowych endpointów w bramkach płatności — migracja kończy się utratą danych, spadkiem SEO i frustracją klientów.
Pożary
Klient składa zamówienie na starym serwerze, podczas gdy baza została już wyeksportowana. Po migracji zamówienie znika z panelu administracyjnego, a płatność została już pobrana z konta kupującego.
Rozwiązanie: Przełączenie starego serwera w tryb Read-Only na czas finalnego dumpu i natychmiastowa synchronizacja różnicowa przed zmianą rekordów DNS.
Certyfikat SSL nie został poprawnie skonfigurowany na nowym serwerze lub został wystawiony na tymczasową domenę stagingową. Google widzi błąd bezpieczeństwa i w ciągu 24–48h obniża pozycje sklepu.
Rozwiązanie: Certyfikat Let's Encrypt lub komercyjny generowany na nowym serwerze przed przełączeniem DNS, testowany przez plik hosts lub subdomenę stagingową.
Przelewy24, Stripe, PayPal nie komunikują się z nowym adresem IP serwera. Bramki zwracają timeout, zamówienia wiszą w statusie „oczekuje na płatność", a klienci dzwonią z pretensjami.
Rozwiązanie: Whitelistowanie nowych endpointów w panelach operatorów płatności i test każdej bramki przed ogłoszeniem migracji za zakończoną.
Część klientów widzi stary serwer, część nowy (propagacja DNS 24–48h). Bez odpowiedniego zabezpieczenia sesji, dane rozjeżdżają się między dwoma środowiskami.
Rozwiązanie: Ustawienie TTL rekordów A na 300s na 24h przed migracją + proxy bazy danych lub wymuszenie Read-Only na starym hoście z przekierowaniem na nowy IP.
Procedura
Każda migracja, którą wykonuję, przechodzi przez tę samą, sprawdzoną procedurę. Żadnych skrótów, żadnego „na pewno się uda".
Sprawdzam obecną konfigurację serwera źródłowego, wersje PHP/MySQL, rozmiar bazy danych, ilość plików statycznych i obciążenie obecnego hostingu.
Stawiam czyste środowisko: system operacyjny, serwer WWW, PHP w odpowiedniej wersji, MariaDB, Redis. Konfiguruję firewall, fail2ban i automatyczne backupy.
Kopiuję wszystkie pliki sklepu na nowy serwer przez rsync z flagą archive. Transfer odbywa się w tle, bez wpływu na działanie produkcji.
Eksportuję strukturę i dane. W oknie migracyjnym blokuję zapis na starym serwerze, wykonuję zrzut różnicowy (delta) i aplikuję go na nowej instancji MariaDB, eliminując ryzyko rozbieżności.
Przed przełączeniem DNS testuję: checkout, webhooki płatności, certyfikat SSL, wysyłkę maili SMTP, działanie wtyczek cache. Wszystko na tymczasowej domenie stagingowej.
Ustawiam TTL rekordów A na 300 sekund na 24h przed migracją. Finalne przełączenie wykonuję w godzinach 2:00–4:00 w nocy, gdy ruch w sklepie jest minimalny.
Po migracji monitoruję logi serwera, błędy PHP, kolejki mailowe i webhooki przez 72 godziny. Stary serwer pozostaje online jako awaryjny fallback.
Platformy
Każda platforma e-commerce ma swoją specyfikę migracyjną. Poniżej dedykowane strony z opisem konkretnych rozwiązań i stackiem technologicznym.
Migracja sklepu WooCommerce z hostingu współdzielonego na VPS. Optymalizacja
wp_options,
Redis Object Cache i konfiguracja OpenLiteSpeed.
Migracja PrestaShop 1.7 / 8.x z uwzględnieniem silnika Symfony. Tuning PHP-FPM, Redis + APCu i optymalizacja zapytań Doctrine ORM.
$ cd /administracja-serwerami-prestashop →Case studies
Rzeczywiste logi z wykonanych migracji sklepów e-commerce.
FAQ
Cały proces — od audytu środowiska do pełnego przełączenia — trwa od 48 do 72 godzin. Sam moment zmiany rekordów DNS wykonuję w nocy (między 2:00 a 4:00), przy minimalnym ruchu. Dzięki tymczasowemu zablokowaniu transakcji na starym serwerze i natychmiastowej migracji przyrostowej, żadne zamówienie nie ma prawa zginąć.
Nie, jeśli zostanie wykonana poprawnie. Kluczowe elementy: certyfikat SSL działa od pierwszej minuty po przełączeniu DNS, adresy URL pozostają identyczne, serwer WWW zwraca te same kody odpowiedzi (200/301/404) co poprzednik. Dodatkowo, nowy VPS jest szybszy — niższe TTFB pozytywnie wpływa na Core Web Vitals i może poprawić pozycje.
To najczęściej pomijany element migracji. Po przełączeniu DNS, bramki płatności muszą komunikować się z nowym adresem IP serwera. W checkliście migracyjnej uwzględniam whitelistowanie nowych endpointów w panelach operatorów płatności i test każdej bramki przed ogłoszeniem migracji za zakończoną.
$ rsync -ahP — Twoja migracja bez ryzyka
Zleć audyt infrastruktury