Przeniesienie WordPressa nie polega tylko na skopiowaniu katalogu public_html. Strona zależy od bazy, wersji PHP, rozszerzeń, crona, poczty, DNS, certyfikatu i konfiguracji serwera. Dobra migracja przygotowuje nowy serwer przed zmianą DNS, testuje stronę na docelowym środowisku i ma plan na dane, które powstaną między pierwszą kopią a przełączeniem.
Szybka odpowiedź
Zrób pełny backup plików i bazy, zinwentaryzuj wersję PHP, zadania cron, rekordy DNS, skrzynki i integracje. Uruchom stronę na nowym serwerze bez zmiany publicznego DNS — na przykład przez plik hosts lub tymczasowy adres testowy. Dopiero po testach wykonaj końcową synchronizację danych, ustaw SSL, przełącz DNS i obserwuj oba środowiska przez okres propagacji.
Inwentaryzacja przed kopiowaniem
Sprawdź rozmiar uploads, bazę, wersję PHP, wymagane rozszerzenia, limity uploadu, crony, reguły serwera i sposób wysyłki poczty. Jeżeli domena korzysta z zewnętrznych rekordów MX albo API opartych o allowlistę IP, migracja serwera WWW może mieć skutki poza samą stroną.
Test bez publicznej zmiany DNS
Nową instalację można sprawdzić, kierując własny komputer na docelowe IP przez plik hosts. Dzięki temu publiczni użytkownicy nadal korzystają ze starego serwera, a Ty testujesz realną domenę i HTTPS. Jeśli używasz CDN, test originu wymaga dodatkowej uwagi, aby nie pomylić odpowiedzi cache z nowym serwerem.
Synchronizacja danych dynamicznych
Na stronie firmowej krótka różnica w bazie może być mało istotna, ale w sklepie w kilka minut powstają zamówienia i konta. Zaplanuj okno przełączenia, czasowy maintenance albo końcową synchronizację. Nie uruchamiaj równolegle dwóch niezależnych aktywnych sklepów zapisujących do osobnych baz.
DNS, TTL i certyfikat
Obniżenie TTL przed migracją może skrócić okres, w którym część użytkowników trafia na stary serwer. Certyfikat powinien być gotowy na nowym środowisku lub wydany natychmiast po przełączeniu, zależnie od metody walidacji. Nie kasuj starego serwera, dopóki nie masz pewności, że ruch i wszystkie funkcje działają poprawnie.
Kontrola po przełączeniu
Sprawdź logi 404/5xx, formularze, SMTP, cron, REST API, panel, cache, media i wydajność. Porównaj liczbę plików oraz rozmiar bazy. Monitoruj stary serwer — pojedyncze żądania po propagacji DNS mogą pokazać, że część resolverów nadal korzysta ze starego adresu.
Jak potwierdzić, że naprawa naprawdę działa?
Po przełączeniu DNS porównaj odpowiedzi starego i nowego serwera przez kilka resolverów oraz bezpośrednio po IP/hosts. Sprawdź formularze, SMTP, cron, upload, cache i certyfikat. Jeśli baza jest dynamiczna, potwierdź, że nowe rekordy trafiają już tylko do nowego środowiska. Stary serwer powinien pozostać dostępny do rollbacku, ale nie powinien przyjmować niezależnych danych przez długi czas.
Co obserwować po zmianie?
Przejrzyj logi 404/5xx i różnice wydajności w pierwszej dobie. Migracja może ujawnić brak rozszerzenia PHP, inny limit uploadu albo odmienną konfigurację rewrite dopiero przy konkretnej funkcji. Zapisz również finalne rekordy DNS i TTL, aby kolejna osoba wiedziała, które wartości są produkcyjne.
Kiedy przekazać temat dalej?
Eskaluj migrację, gdy serwis ma aktywną sprzedaż, duże pliki, pocztę na tej samej infrastrukturze lub kilka subdomen. Wtedy potrzebny jest plan synchronizacji i kolejności DNS, a nie prosty „backup → restore → zmień A record”.
Praktyczny scenariusz diagnostyczny
Przy migracji bez przestoju najbezpieczniej przygotować nowy serwer wcześniej, zsynchronizować pliki i bazę, przetestować witrynę przez lokalny wpis hosts albo techniczną domenę i dopiero potem przełączyć DNS. Dla dynamicznego sklepu trzeba zaplanować finalną synchronizację, aby żadne zamówienie nie zostało między starą a nową bazą. Przed zmianą obniż TTL, jeśli infrastruktura na to pozwala. Po przełączeniu obserwuj logi obu serwerów: część użytkowników może jeszcze trafiać na stary adres z cache DNS. Gdy ruch się przeniesie, sprawdź SSL, e-maile, cron, uploady i integracje wychodzące. Migracja zakończona kodem 200 na homepage to za mało — trzeba potwierdzić cały przepływ biznesowy i dopiero potem wyłączyć stare środowisko.
Bezpieczna kolejność działań
- Zrób inwentaryzację i pełny backup.
- Przygotuj zgodne środowisko PHP/bazy na nowym hostingu.
- Skopiuj pliki i bazę oraz przetestuj nowy serwer przed DNS.
- Zaplanować końcową synchronizację danych dynamicznych.
- Przełącz DNS i SSL, pozostawiając stary serwer online.
- Wykonaj checklistę po migracji i obserwuj logi przez co najmniej pełny cykl zadań.
Czego nie robić
Nie kasuj starego hostingu w tej samej chwili, w której zmieniasz DNS. Nie wykonuj prostego search-replace w bazie, jeśli domena się nie zmienia. I nie zakładaj, że poczta „przeniesie się razem ze stroną” — rekordy MX mogą prowadzić do całkiem innego systemu.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
HeatLogic może przeprowadzić migrację WordPressa z testem przed zmianą DNS, końcową synchronizacją danych, konfiguracją SSL i monitoringiem po przełączeniu.
Źródła techniczne
Najczęściej zadawane pytania
Czy WordPress trzeba instalować od nowa na nowym hostingu?
Nie. Oficjalny poradnik WordPressa opisuje przeniesienie przez skopiowanie plików i bazy oraz dostosowanie konfiguracji.
Czy domena musi się zmienić?
Nie. Możesz przenieść serwer, zachowując ten sam adres strony.
Jak uniknąć utraty zamówień WooCommerce?
Trzeba zaplanować końcową synchronizację lub krótkie okno maintenance, aby nie mieć dwóch rozjechanych baz.
Kiedy wyłączyć stary hosting?
Dopiero po potwierdzeniu propagacji DNS, działania strony i wszystkich usług zależnych.