Migracja WordPress: dane, przełączenie serwera i odbiór

Najpierw zapisz, co nowy serwer ma rozwiązać: ograniczenie zasobów, potrzebę innej konfiguracji, wymagania utrzymania albo zakończenie umowy. Wolna strona nie zawsze wymaga przeprowadzki. Problem może wynikać z zapytania, skryptu lub zewnętrznej integracji. Przy takiej diagnozie zacznij od wydajności hostingu WordPressa, a nie od uniwersalnego progu ruchu czy czasu odpowiedzi.

Rozdziel zmianę hostingu od zmiany domeny. Możesz przenieść aplikację i zachować wszystkie publiczne adresy. Google opisuje przeprowadzkę bez zmiany URL jako osobny scenariusz. Nie trzeba przy tej okazji przebudowywać struktury strony ani tworzyć nowych adresów ofert.

Uzgodnij zakres poczty, DNS, kopii i integracji. Przeniesienie strony nie oznacza automatycznie migracji skrzynek. Jeśli obsługą zajmuje się nowy hosting, potwierdź, co obejmuje jego usługa i kto odbiera wynik. Nie zakładaj określonej ceny, terminu ani gwarancji dostępności bez warunków dotyczących konkretnej instalacji.

Na końcu tego etapu powinny być jasne trzy rzeczy: powód zmiany, elementy objęte migracją i osoba decydująca o przełączeniu. Pozwala to uniknąć rozszerzania prac podczas awarii, kiedy trudno już odróżnić skutki przenosin od nowych modyfikacji.

Dokumentacja migracji WordPressa rozdziela pliki, bazę i ustawienia adresów. Własna instalacja może mieć niestandardowy układ, dlatego spisz katalogi mediów, motyw, dodatki, mu-plugins, konfigurację i pliki poza typowym wp-content. Zanotuj także zadania systemowe oraz ustawienia niewchodzące do paczki wtyczki.

Ustal właściwą bazę, prefiks i tabele rozszerzeń. Nie zakładaj, że wszędzie użyto wp_ albo że zamówienia znajdują się w jednym, zawsze takim samym zestawie tabel. WooCommerce może korzystać z różnych konfiguracji przechowywania danych. Właściciel aplikacji powinien potwierdzić, które źródło jest autorytatywne.

Zachowaj informacje o charset i collation oraz sprawdź tekst po imporcie. Nie zmieniaj przy okazji wszystkich ustawień kodowania bez uzasadnienia. Weryfikacja powinna objąć polskie znaki, nazwy produktów i przykładowe treści, a nie tylko fakt zakończenia importu.

Dokumentuj potrzebne parametry bez publikowania sekretów. Dostęp do archiwum i poświadczeń powinien mieć uzgodniony zakres. Konfiguracji .htaccess nie kopiuj ślepo jako rozwiązania dla Nginx: docelowy serwer musi dostać reguły właściwe dla swojego sposobu działania.

Zabezpiecz stan wyjściowy, zanim rozpoczniesz zmianę. Kopia powinna obejmować ustalony zakres oraz mieć dowód kompletności. Eksport bazy przechowuj poza publicznym katalogiem serwisu. Do transferu plików używaj chronionego połączenia, na przykład SFTP lub SSH, z uprawnieniami ograniczonymi do potrzebnego zadania.

Sprawdź próbne odtworzenie poza produkcją. Sam plik archiwum nie potwierdza, że można z niego odzyskać stronę. Pełniejszą procedurę opisujemy przy problemach z kopią WordPressa. Zanotuj datę danych oraz komponenty zestawu, aby nie pomylić różnych wersji podczas końcowej synchronizacji.

Ustal, co będzie się działo z nowymi zamówieniami, kontami, formularzami i mediami do czasu przełączenia. Stara kopia bazy nie zawiera zapisów powstałych później. Nie planuj powrotu przez bezwarunkowe nadpisanie świeżego stanu archiwum sprzed migracji.

Plan wycofania powinien wskazywać moment decyzji, miejsce aktualnych danych i sposób obsługi zdarzeń przyjętych po przełączeniu. W sklepie płatność może mieć nowszy stan u operatora niż w przywracanej bazie. Samo cofnięcie DNS nie synchronizuje tych informacji. Tę zależność trzeba uwzględnić przed rozpoczęciem prac.

Wtyczka migracyjna, ręczny transfer i usługa operatora to sposoby wykonania tego samego zakresu. Porównaj obsługiwany format, wymagania wersji, możliwość wznowienia i kontrolę błędów. Nie wybieraj narzędzia wyłącznie według dawnego limitu wielkości lub nieaktualnej ceny licencji.

Na nowym serwerze przygotuj właściwą bazę i użytkownika, konfigurację PHP oraz reguły routingu. Sprawdź wymagane rozszerzenia, miejsce robocze i prawa zapisu. Importuj do jasno wskazanego środowiska, oddzielonego od produkcyjnych danych. Nie uruchamiaj od razu prawdziwych wysyłek, płatności, webhooków ani powielonego harmonogramu.

Adresy i ścieżki zmieniaj tylko tam, gdzie migracja tego wymaga. WP-CLI search-replace obsługuje dane serializowane i tryb dry-run. Najpierw ustal zakres tabel oraz kolumn i obejrzyj wynik próby bez zapisu. Opcja all-tables może objąć również obce tabele w tej samej bazie, więc nie jest uniwersalnym wyborem.

Zwykłe zastąpienie tekstu może uszkodzić serializację. Jeżeli taka szkoda już wystąpiła, ponowne uruchomienie poprawnego narzędzia nie gwarantuje naprawy. Potrzebny jest sprawdzony stan źródłowy i diagnoza. Przy zmianie domeny przygotuj osobny plan adresów zgodnie z wytycznymi Google dla zmiany URL. Change of Address nie służy każdej zmianie pojedynczej ścieżki.

Odbierz nowe środowisko, zanim skierujesz do niego wszystkich odwiedzających. Użyj uzgodnionego podglądu, lokalnego mapowania hosta lub innego sposobu pozwalającego sprawdzić właściwy serwer. Potwierdź, że przeglądarka rzeczywiście korzysta z nowej instancji. Widok starej strony z cache może stworzyć pozór udanego testu.

Sprawdź certyfikat, nazwę hosta oraz połączenie między proxy a serwerem origin. FORCE_SSL_ADMIN steruje zachowaniem WordPressa, ale nie instaluje certyfikatu. Potwierdź także przekierowania, media, logowanie i adresy podstron. Sam zapis permalinków nie odtwarza automatycznie konfiguracji każdego serwera WWW.

Formularze testuj z przechwytywaniem wiadomości i bez zapisu do produkcyjnego CRM. Płatności sprawdzaj w sandboxie, bez prawdziwych zamówień oraz sztucznych konwersji. Odbiór powinien obejmować zarówno poprawny przebieg, jak i błąd lub ponowienie, jeśli dotyczy integracji.

Gdy pojawi się biały ekran, użyj diagnostyki WordPressa i chronionego logu. Nie pokazuj błędów oraz sekretów odwiedzającym. Przyczyną może być konfiguracja, kod lub dane; nie cofaj dowolnie PHP na podstawie samego wyglądu ekranu. Dla lokalnej kopii pomocny będzie poradnik o diagnozie localhost.

Dwie kopie z osobnymi bazami nie mogą bez planu równolegle przyjmować zamówień i zgłoszeń. Podczas zmiany DNS część odbiorców lub integracji może nadal docierać do starego miejsca. Dostępność obu ekranów nie oznacza spójności danych. Ustal jedno aktywne miejsce zapisu oraz sposób obsługi ruchu trafiającego do drugiego.

W zależności od aplikacji potrzebne może być kontrolowane okno wstrzymania zapisów, końcowa synchronizacja albo sprawdzony mechanizm kierowania operacji do właściwego środowiska. Wybór musi uwzględniać funkcje strony i możliwość wycofania. Nie wdrażaj improwizowanej synchronizacji kilku tabel sklepu podczas samego przełączenia.

Uwzględnij spóźnione callbacki, czyli powiadomienia operatorów, oraz kolejki zadań. Zamówienie rozpoczęte przed zmianą może zostać opłacone później. Zapisz sposób powiązania takiego zdarzenia z aktualnym stanem i obsługi ponowienia bez duplikatu. Uruchomienie cronów na obu kopiach może podwoić działania integracji, nawet jeśli ruch przeglądarkowy trafia już wyłącznie na nowy serwer.

Zmianę DNS przygotuj z osobą utrzymującą domenę. Sprawdź A i AAAA, proxy, certyfikat origin oraz zakres MX i TXT związany z pocztą. Obniżony wcześniej TTL może pomóc, ale nie gwarantuje jednego czasu zakończenia propagacji u wszystkich odbiorców. Po zmianie obserwuj oba środowiska i rzeczywiste zapisy, zamiast zakładać, że samo upłynięcie ustalonej liczby godzin kończy proces.

Po przełączeniu porównaj aktualne dane i kluczowe ścieżki. Ustal, czy ostatnie zamówienia, konta oraz pliki są we właściwym środowisku i czy nie zostały osierocone powiadomienia operatorów. Rozdziel potwierdzenie działania strony od potwierdzenia każdego procesu sprzedażowego.

Usuń wyłącznie niezamierzone blokady odziedziczone ze stagingu. Zaplanowane noindex pozostają częścią polityki witryny. Sprawdź mapę strony i dostępność wymaganych URL, ale nie wysyłaj jej ponownie do Search Console bez potrzeby wynikającej ze zmiany. Zachowanie adresów nie jest gwarancją niezmiennych pozycji: liczy się również prawidłowa obsługa, treść i dostępność.

Zapisuj czas oraz zakres obserwacji błędów. Dla obsługi WordPressa użyteczny raport pokazuje, co rzeczywiście sprawdzono i co pozostaje do obserwacji. Nie zastępuj go obietnicą braku przestoju albo arbitralnym przewidywaniem wahań rankingu.

Stare środowisko wyłącz dopiero po potwierdzeniu, że nie przyjmuje już potrzebnych zapisów i nie obsługuje zależności pozostawionych poza zakresem migracji. Sprawdź logi, kolejki, ruch operatorów oraz pocztę. Stały termin, na przykład dwie doby, nie jest samodzielnym dowodem bezpiecznego zamknięcia.

Zachowaj archiwum zgodnie z ustaloną retencją i kontrolą dostępu. Uporządkuj tymczasowe konta oraz dostęp migracyjny, potwierdź harmonogram kopii na nowym serwerze i właściciela alertów. Nie zostawiaj publicznego instalatora ani eksportu bazy jako pamiątki po przeprowadzce.

Jeżeli odbiór wykazał problem wymagający powrotu, najpierw zastosuj uzgodniony plan zachowania aktualnych danych. Cofnięcie ruchu do starej bazy bez ich rozliczenia może pogłębić usterkę. Po zakończeniu zapisz przyczynę odstępstwa i wynik ponownego sprawdzenia.

Skontaktuj się z KC Mobile, podając zakres strony, model zapisów i ważne integracje. Przy tworzeniu oraz rozwoju stron internetowych możemy ustalić także sposób migracji i dalszego wsparcia. Koszt oraz termin wynikają z inwentaryzacji, próby i odbioru, a nie z samej wielkości katalogu WordPressa.