MIGRACJA · STRONA, POCZTA I PLAN WYCOFANIA

Migracja WordPressa i poczty: 6 etapów z checklistą i planem powrotu

Migracja WordPressa zaczyna się od sprawdzonej kopii. Następnie uruchom stronę na nowym serwerze, zsynchronizuj aktualne dane i pocztę, a dopiero na końcu przełącz ruch. Stary hosting zachowaj do zakończenia kontroli. Taka kolejność ogranicza ryzyko; nie daje automatycznej gwarancji braku przerwy ani utraty danych.

Migracja WordPressa i migracja poczty to dwa odrębne zadania. Kopia plików strony i bazy nie przenosi sama skrzynek, lokalnych archiwów ani ustawień programów pocztowych. Jeśli dopiero wybierasz miejsce docelowe, sprawdź w porównaniu hostingów i warunków ofert także pojemność poczty, koszt odnowienia oraz zakres pomocy migracyjnej.

Opracowanie: WebBay · Weryfikacja źródeł: 29.10.2026. Przykład ręczny zakłada pojedynczy WordPress z niezmienioną domeną i hosting docelowy z cPanel.

Migracja WordPressa — jak przenieść WordPress na inny hosting?

1. Zakres i odpowiedzialność
2. Kopia oraz plan powrotu
3. Test nowego serwera
4. Przeniesienie skrzynek
5. Końcowa synchronizacja i DNS
6. Sprawdzenie działania i powrót do poprzednich ustawień

Przykład kolejności dla strony z trzema skrzynkami

Przenosisz wizytówkę i skrzynki biuro@, faktury@ oraz imie@ we własnej domenie. Najpierw wykonaj kopię strony i pierwszą synchronizację każdej skrzynki. Przed odtworzeniem przygotuj oddzielny katalog, nową bazę, konfigurację celu oraz blokadę zewnętrznych działań kopii. Dopiero potem uruchom i sprawdź nową witrynę bez przełączania klientów. Uzgodnij krótkie wstrzymanie zmian, skopiuj ostatnie pliki i bazę oraz dosynchronizuj pocztę. Zmień zaplanowane rekordy DNS, potem sprawdź stronę, formularz i obie strony komunikacji e-mail. Stare konto zachowaj do wygaśnięcia wcześniejszych odpowiedzi DNS i rozliczenia danych.

1. Migracja WordPressa: ustal zakres i odpowiedzialność

Zapisz domeny, subdomeny, katalogi aplikacji, bazy, wersje PHP, harmonogramy zadań i integracje. Osobno wypisz skrzynki, aliasy, przekierowania, autorespondery, limity i sposób korzystania z poczty. Ustal, gdzie zarządzasz rekordami DNS, czyli wpisami kierującymi usługi domeny do odpowiednich serwerów.

Migracja WordPressa nie wymaga przenoszenia rejestracji domeny tylko dlatego, że zmieniasz hosting. Nie łącz też bez potrzeby migracji ze zmianą adresów URL, przebudową sklepu lub aktualizacją wszystkich wtyczek. Mniej jednoczesnych zmian ułatwia znalezienie przyczyny ewentualnej awarii. Dla sklepu uzupełnij odbiór o testy koszyka, zamówień i zadań WooCommerce.

Dla pojedynczego WordPressa pod niezmienioną domeną skorzystaj z instrukcji przeniesienia hostingu z home.pl albo przeniesienia CloudHosting z nazwa.pl. Rozwijają one kroki zależne od panelu źródłowego i wskazują konkretny panel docelowy. Przed zastosowaniem wybierz wariant zgodny ze swoją usługą oraz ustal, czy przenosisz także pocztę.

Poproś wykonawcę o rozróżnienie „skopiowaliśmy dane” i „przeprowadziliśmy końcową synchronizację”. Przy aktywnym sklepie lub poczcie różnica dotyczy danych powstałych już po pierwszym kopiowaniu. Zakres bezpłatnej pomocy operatora sprawdź przed zamówieniem; nie zakładaj, że obejmuje każdą aplikację i dowolną liczbę kont.

Karta zlecenia i granice bezpłatnej pomocy

Przygotuj kartę prac z czterema polami: wykonawca, zakres, termin i oczekiwany wynik. Wpisz osobę odpowiedzialną za dostęp do domeny oraz osobę, która zna sklep i potrafi ocenić zamówienia. Jeżeli operator przenosi tylko stronę, pocztę zleć oddzielnie. Uzgodnij też, kto sprawdzi formularz i odpowie za problem ujawniony następnego dnia.

Przed wyborem oferty porównaj liczbę obsługiwanych witryn i skrzynek, rozmiar pojedynczej bazy, zgodność paneli oraz dostępność migracji ręcznej. Zapytaj, czy cena obejmuje ponowne kopiowanie po testach, podłączenie SMTP i pomoc w programach pocztowych. Szczegóły oceny zakresu rozwija poradnik o hostingu z darmową migracją; tutaj najważniejsza jest kolejność wykonania prac.

Ustal kanał alarmowy niezależny od przenoszonej domeny, termin decyzji o przełączeniu i osobę zatwierdzającą wynik. Nie przekazuj wykonawcy wszystkich uprawnień do konta hostingowego, jeżeli wystarczy ograniczony dostęp do jednej instalacji. Po odbiorze usuń dostęp tymczasowy zgodnie z uzgodnioną procedurą, zachowując właścicielowi możliwość samodzielnego zarządzania usługą.

2. Zabezpiecz pliki i bazę przed kopiowaniem

Bezpieczna migracja WordPressa zaczyna się od kompletnej kopii, która obejmuje pliki i bazę danych. Tak rozdziela je oficjalna dokumentacja backupu. Pobierz kopię poza konto hostingowe, zabezpiecz dostęp i sprawdź, czy da się odtworzyć ją w osobnym środowisku. Sam komunikat o zakończeniu archiwizacji nie jest próbą przywracania.

Dla tej ręcznej metody pobierz pliki z katalogu źródłowego szyfrowanym transferem, razem z mediami i plikami ukrytymi. Bazę wskazaną w konfiguracji źródła otwórz w cPanel → Databases → phpMyAdmin, wybierz tę konkretną bazę i zakładkę Export. Wybierz eksport SQL, uruchom go i zachowaj wynik obok plików z uzgodnionego momentu. Sprawdź, że eksport obejmuje wszystkie potrzebne tabele tej instalacji. Przed importem na cel upewnij się, że plik nie przełącza poleceniem USE na inną bazę ani nie tworzy lub usuwa innych baz. Wątpliwy eksport przekaż administratorowi do przygotowania. Nie wybieraj całego serwera ani baz sąsiednich stron.

Do planu dodaj oddzielne zabezpieczenie poczty oraz eksport aktualnych rekordów DNS. Zachowaj konfigurację aplikacji, wersje środowiska i listę integracji. Kopie mogą zawierać dane klientów, hasła i klucze dostępu: nie umieszczaj ich w publicznym katalogu ani w ogólnodostępnym repozytorium.

Zanim zaczniesz, określ warunki przerwania prac. Przykłady: niepełna kopia bazy, niedostępny panel domeny, brak miejsca na skrzynki lub niesprawdzony certyfikat. Wyznacz osobę decydującą o przełączeniu i kanał kontaktu, który nie zależy wyłącznie od przenoszonej poczty.

Co sprawdzić w archiwum plików i eksporcie SQL?

Dla kopii zanotuj godzinę wykonania, wielkość archiwów i nazwę bazy przypisanej do tej konkretnej instalacji. Otwórz archiwum lokalnie lub w bezpiecznym środowisku i potwierdź obecność katalogu przesłanych mediów, motywów, wtyczek i konfiguracji. Eksport bazy powinien dać się zaimportować na serwerze testowym bez przerwania operacji. Pusty plik SQL lub samo pobranie zdjęć nie wystarcza.

Migracja WordPressa może ujawnić pliki pomijane przez standardowy backup: własny kod poza katalogiem aplikacji, zadania serwera, ustawienia przekierowań czy klucze integracji. Nie kopiuj całego konta razem z cudzymi witrynami. Rozpoznaj zależności, a hasła i klucze dostępu odtwórz bezpiecznie tylko tam, gdzie są potrzebne. Kopię poczty przechowuj oddzielnie od kopii strony, z ograniczonym dostępem i ustalonym terminem usunięcia.

Jeżeli nie potrafisz potwierdzić odtworzenia, zatrzymaj przełączenie. Poproś wykonawcę o próbę na izolowanej kopii i krótki protokół wyniku. Ważne są działające dane, nie sam zielony komunikat narzędzia. Zakres i retencja backupu pomogą ustalić, ile wersji pozostawić na wypadek późnego wykrycia problemu.

3. Odtwórz WordPress i sprawdź nowy serwer

Najpierw przygotuj cel. Z operatorem nowego serwera ustal blokadę ruchu wychodzącego dla kopii: SMTP, API, webhooków, płatności oraz zewnętrznych zadań. Wyłącz jej harmonogram serwera i ustaw DISABLE_WP_CRON na true. Ogranicz dostęp do kopii; samo noindex nie chroni danych. Te warunki mają obowiązywać przed importem i pierwszym wywołaniem PHP. Jeśli hosting nie umożliwia wymaganej izolacji, wstrzymaj uruchomienie kopii i zleć przygotowanie środowiska administratorowi.

Ręczny wariant: nowy cPanel, ta sama domena

1. W nowym cPanel otwórz Domains, dodaj domenę przez Create a New Domain lub odczytaj jej istniejący Document Root. Wybierz własny pusty katalog, nie katalog działającej witryny. Uzgodnij zgodne PHP i poprawny certyfikat dla docelowej nazwy przed próbą HTTPS.
2. W Databases → Database Wizard utwórz nową bazę, przejdź Next Step, utwórz osobnego użytkownika z nowym hasłem i przypisz mu wymagane uprawnienia do tej jednej bazy; kreator oferuje ALL PRIVILEGES. Zapisz pełne nazwy z prefiksem i host bazy podany przez operatora. Nie twórz bazy importem w phpMyAdmin.
3. Przygotuj na komputerze kopię plików strony. W jej wp-config.php wpisz DB_NAME, DB_USER, DB_PASSWORD i DB_HOST nowej bazy oraz define('DISABLE_WP_CRON', true);, bez dublowania istniejącej stałej. Zachowaj oryginał poza katalogiem publicznym. Ten plik musi wskazywać cel zanim trafi na nowy serwer. Nie zmieniaj konfiguracji źródła.
4. Przez udostępnione przez nowy hosting szyfrowane SFTP lub FTPS prześlij pliki do potwierdzonego pustego katalogu. Zweryfikuj nazwę serwera i pełny raport transferu. Nie wyślij ponownie starego wp-config.php; reguły plików ukrytych uzgodnij z nowym operatorem, aby nie nadpisać jego ustawień.
5. W nowym cPanel wybierz Databases → phpMyAdmin. Po lewej wskaż wyłącznie nową pustą bazę, porównaj jej nazwę z konfiguracją celu, otwórz Import, wybierz eksport SQL tej strony i uruchom import. Poczekaj na pełne zakończenie. Przy błędzie lub przekroczeniu limitu pliku zatrzymaj się i poproś hosting o import tej bazy; nie kasuj tabel innej instalacji.
6. Przy niezmienionej domenie pozostaw dotychczasowe home/siteurl. Do podglądu użyj uzgodnionego lokalnego mapowania hosts opisanego niżej, z prawidłowym certyfikatem. Sprawdź odczyt oraz zapis w nowym panelu, najnowszy wpis, obraz i podstrony. SMTP i API pozostają zablokowane; funkcje wymagające łączności sprawdź dopiero z bezpiecznymi danymi i testowymi integracjami.
7. Po udanej próbie przygotuj uzgodnioną końcową synchronizację w oknie wstrzymania zapisów. Przed każdym ponownym importem potwierdź cel oraz zachowanie jego wp-config.php. Dopiero po spójnej kopii i zmianie DNS usuń własne mapowanie hosts, sprawdź nowe środowisko z normalnego połączenia i uzgodnij uruchomienie produkcyjnych integracji tylko na jednym serwerze. Przy błędzie nie przełączaj ruchu; źródło nadal działa.

Przetestuj nowe środowisko przed zmianą publicznego DNS. Utrzymuj uzgodnioną ochronę dostępu i blokadę zewnętrznych działań przez cały podgląd. Wyłączenie zadań WordPressa nie blokuje samodzielnych połączeń SMTP lub API dodatków. Odblokowanie rzeczywistych usług zaplanuj na końcowe przełączenie, aby dwie kopie nie wykonywały tych samych operacji.

• Otwórz stronę główną, kilka podstron i media; sprawdź bezpośrednie adresy, nie tylko menu.
• Sprawdź logowanie, zapis w panelu i formularz na kontrolowanym odbiorcy.
• Zweryfikuj HTTPS, przekierowania i brak odwołań do tymczasowej domeny.
• W sklepie sprawdź koszyk i płatność w trybie testowym oraz integracje.
• Porównaj błędy aplikacji i zgodność wersji, zamiast oceniać wyłącznie wygląd strony.

Pliki, baza i konfiguracja — kolejność odtworzenia

1. Na nowym koncie utwórz bazę i użytkownika z dostępem do tej bazy. Potwierdź wymaganą wersję PHP oraz potrzebne rozszerzenia; nie zmieniaj przy okazji środowiska innych usług.
2. Przenieś pliki z uzgodnionego katalogu instalacji. Uwzględnij pliki ukryte i własne reguły serwera, ale nie nadpisuj bezmyślnie konfiguracji narzuconej przez nowy hosting.
3. Przed pierwszym uruchomieniem plików ustaw w docelowym wp-config.php nową bazę, użytkownika i host. Następnie zaimportuj eksport SQL wyłącznie do tej nowej bazy. Nie publikuj danych dostępowych w zgłoszeniu lub zrzucie.
4. Odtwórz harmonogram zadań, konfigurację wysyłki i połączenia usług. W kopii testowej pozostaw zablokowane działania mogące wysłać prawdziwe powiadomienia lub powtórzyć płatność.
5. Sprawdź logi, zapis nowej treści testowej, dostęp do mediów i bezpośrednie adresy. Zanotuj, na jakim serwerze wykonano próbę, aby nie pomylić starej strony z nową.

Migracja WordPressa pod niezmienioną domeną zwykle nie wymaga zastępowania wszystkich adresów w bazie. Jeżeli zmieniasz także domenę lub katalog, to osobna operacja: kopia bazy, narzędzie obsługujące serializację, próbny raport zmian i dopiero zatwierdzona zamiana. WP-CLI udostępnia tryb --dry-run. Nie uruchamiaj globalnej zamiany w bazach innych witryn.

Jak sprawdzić nowy serwer przed zmianą DNS?

Uzgodnij z administratorem podgląd zachowujący docelową nazwę domeny, na przykład kontrolowane lokalne mapowanie hosts. To zmiana tylko na komputerze testującym; nie przełącza domeny dla klientów. Zadbaj o prawidłowy certyfikat i sprawdzenie, że odpowiedź pochodzi z nowego serwera. Podgląd po samym adresie IP może nie obsłużyć właściwej witryny w hostingu współdzielonym.

Przykład dla własnego komputera z Windows: zachowaj kopię pliku C:\Windows\System32\drivers\etc\hosts, otwórz Notatnik jako administrator i wczytaj ten plik jako „Wszystkie pliki”. Dopisz osobną linię z prawdziwym nowym IP, spacją i własną domeną; dla używanego www dodaj jego nazwę. Wzór 192.0.2.10 example.com www.example.com zawiera adres dokumentacyjny, którego nie stosuje się w prawdziwej migracji. Zapisz bez rozszerzenia .txt, zamknij przeglądarkę i otwórz domenę ponownie. Potwierdź w logu lub z operatorem, że trafiasz do nowego serwera. Po próbie usuń tylko dopisane linie; nie resetuj istniejących firmowych wpisów. Jeśli przeglądarka nadal wybiera stary serwer, przerwij próbę i wyjaśnij jej rozwiązywanie nazw.

Porównaj listę podstron, liczbę ważnych rekordów i kilka ostatnich zmian. Obejrzyj obraz z ostatnio dodanej galerii, wyślij test formularza na kontrolowany adres i sprawdź reakcję integracji. Zapisz wyniki w liście rzeczy do sprawdzenia. Migracja WordPressa nie jest jeszcze zakończona, jeśli działa tylko strona główna, ale panel nie zapisuje danych albo formularz kieruje do starego SMTP.

4. Przenieś skrzynki, a nie tylko adresy e-mail

Utwórz konta docelowe z odpowiednimi limitami. Dla poczty IMAP, przechowywanej na serwerze, uzgodnij kopiowanie folderów i wiadomości oraz późniejsze dosynchronizowanie zmian. Przykładem narzędzia obsługującego transfer przyrostowy jest imapsync; dobór i uruchomienie narzędzia zostaw osobie mającej autoryzowany dostęp do obu serwerów.

IMAP nie rozwiązuje automatycznie przeniesienia lokalnych archiwów POP, książek adresowych, kalendarzy, reguł filtrujących ani podpisów w programach pocztowych. Sprawdź te elementy oddzielnie. Haseł do skrzynek nie przekazuj w zwykłym e-mailu lub rozmowie; wykorzystaj bezpieczny kanał uzgodniony z wykonawcą.

Pierwsze kopiowanie wykonaj, gdy stary serwer nadal obsługuje pocztę. Po przełączeniu rekordów MX, określających serwer odbierający wiadomości, sprawdź oba środowiska i przeprowadź końcową synchronizację w uzgodnionym kierunku. Nie uruchamiaj bez planu kopiowania dwukierunkowego: usunięcia i przeniesienia folderów wymagają świadomej obsługi.

Kontroluj liczbę i rozmiar wiadomości, ale sprawdź też próbki: starsze e-maile, wysłane, załączniki oraz foldery z polskimi nazwami. Liczby mogą różnić się przez sposób liczenia folderów lub nowe wiadomości; różnicę wyjaśnij, zamiast od razu kasować zawartość któregokolwiek konta.

Karta migracji IMAP dla każdej skrzynki

Zapisz mapowanie adres źródłowy → konto docelowe, limity miejsca, hosty IMAP i uzgodnione foldery. Najpierw sprawdź jedną skrzynkę z reprezentatywnymi danymi, potem pozostałe. Korzystaj z szyfrowanego połączenia i weryfikacji certyfikatu. Nie obchodź ostrzeżeń TLS, aby narzędzie „wreszcie ruszyło”; wyjaśnij z operatorem prawidłową nazwę serwera.

Na czas końcowego kopiowania uzgodnij z użytkownikami ograniczenie zmian folderów i usuwania wiadomości. Sprawdź osobno katalog wysłanych, oznaczenia przeczytania i subskrypcje folderów, bo programy mogą inaczej nazywać te elementy. Po przełączeniu skonfiguruj IMAP i SMTP na komputerze oraz telefonie. Test odbioru w webmailu nie dowodzi jeszcze poprawnej wysyłki z programu pracownika.

Jeśli część poczty trafia nadal na poprzedni serwer, zachowaj do niego dostęp i wykonaj uzgodniony transfer przyrostowy. Nie usuwaj starych kont, dopóki różnice nie zostaną rozliczone. Potrzebę przenoszenia samych skrzynek rozpatruj niezależnie: migracja WordPressa może zakończyć się bez zmiany dostawcy poczty, gdy dotychczasowa usługa nadal spełnia wymagania.

5. Zsynchronizuj zmiany i przełącz właściwe rekordy DNS

W aktywnej witrynie ustal moment ostatniej kopii i końcowej synchronizacji. Przy sklepie lub częstych zapisach może być potrzebne zaplanowane okno wstrzymania zamówień lub edycji. Dopilnuj także płatności oczekujących i zewnętrznych powiadomień. Dwa serwery przyjmujące niezależnie nowe zamówienia utrudniają późniejsze uzgodnienie danych.

TTL określa czas przechowywania odpowiedzi DNS w pamięci podręcznej. Możesz zaplanować jego obniżenie wcześniej, lecz nie unieważnia to natychmiast już zapisanych odpowiedzi. Dokumentacja TTL wyjaśnia zależność od cache. Nie traktuj konkretnej liczby godzin jako uniwersalnej gwarancji zakończenia przełączenia u wszystkich użytkowników.

Zmieniaj tylko rekordy objęte planem. A i AAAA mogą kierować ruch strony, a MX — poczty. Zachowaj potrzebne rekordy TXT i sprawdź konfigurację SPF, DKIM oraz DMARC, używanych przy weryfikacji poczty. Zmiana serwerów nazw całej domeny wymaga odtworzenia kompletnej strefy; nie rób jej tylko dlatego, że przenosisz jeden serwis.

Nowy dostawca poczty powinien przekazać dokładne wartości rekordów. Nie kopiuj przykładowych kluczy ani adresów z cudzej instrukcji. Podstawowe role rekordów opisuje dokumentacja DNS dla poczty. Po zmianie wykonaj test do i z niezależnej skrzynki oraz sprawdź wynik uwierzytelniania wiadomości.

Mapa rekordów: co przełącza stronę, a co pocztę?

Przygotuj tabelę stary cel → nowy cel → właściciel zmiany → wynik kontroli. Gdy strona i poczta mają różnych dostawców, pozostaw rekordy poczty zgodnie z jej konfiguracją. Uwzględnij też formularze, system faktur i newsletter jako osobne źródła wysyłki. Migracja WordPressa nie uzasadnia usunięcia ich rekordów tylko dlatego, że nie należą do nowego hostingu.

Najpierw przygotuj usługi docelowe i uwierzytelnianie wysyłki, potem końcową synchronizację danych, następnie zatwierdzone rekordy. W czasie rozchodzenia się odpowiedzi DNS obserwuj oba serwery. Zachowaj godziny zmian i wyniki testów; bez nich trudno odróżnić błąd aplikacji od trafienia użytkownika do starszej kopii.

6. Odbierz migrację i zachowaj możliwość powrotu

Jeśli awaria wymaga powrotu, najpierw ustal, jakie dane powstały już na nowym serwerze. Samo cofnięcie DNS nie przenosi ich do starej bazy ani skrzynek. Zabezpiecz oba stany, uzgodnij zamówienia i wiadomości, a dopiero potem przełącz usługę według planu. Nie przywracaj starej kopii na działającą bazę bez oceny nowych zapisów.

Stary hosting zakończ dopiero po udokumentowanym odbiorze, rozliczeniu okresu nakładania usług i zabezpieczeniu kopii. Zaktualizuj dokumentację dostępu oraz usuń zbędne dostępy tymczasowe zgodnie z ustaleniami. Na nowym serwerze sprawdź jeszcze harmonogram kopii, ich retencję i pierwsze udane wykonanie.

Jeśli plan ujawnił brak potrzebnych funkcji u dostawcy docelowego, wróć do pytań przed zakupem hostingu WordPress i zestawienia ofert WebBay z kosztami odnowień. Wybór powinien uwzględniać utrzymanie strony i poczty po migracji, a nie samą obietnicę bezpłatnego kopiowania. Policz budżet na trzy lata, dodając okres równoległego utrzymywania obu usług.

Plan powrotu z kontrolą nowych danych

Migracja WordPressa wymaga konkretnego punktu decyzyjnego: kto może zarządzić powrót, przy jakim błędzie i do jakiej godziny. Przykładowe kryteria zatrzymania to niemożliwy zapis zamówienia, niedziałające logowanie albo nieuzgodnione braki poczty. Krótkie, zaplanowane wstrzymanie zapisów może być bezpieczniejsze niż dalsza praca na rozbieżnych bazach.

Zabezpiecz stan obu środowisk, wyznacz ostatni uzgodniony moment i porównaj późniejsze zamówienia z operatorem płatności oraz magazynem. Wykonawca powinien określić sposób przeniesienia brakujących danych bez ponownego pobrania płatności i wysłania duplikatów wiadomości. Sam import starej bazy na nową nie jest bezpiecznym planem powrotu.

• Znam zakres strony, poczty, DNS i integracji oraz osoby odpowiedzialne.
• Mam kopię poza starym kontem i dowód odtworzenia plików oraz bazy.
• Nowa instalacja i skrzynki przeszły kontrolowane testy przed przełączeniem.
• Ustalono moment ostatnich zapisów, końcową synchronizację i obsługę płatności w toku.
• Porównałem rekordy A, AAAA, MX i wymagane wpisy uwierzytelniające pocztę.
• Zachowuję stary hosting do odbioru; potrafię uzgodnić dane, jeśli trzeba wrócić.

Dopiero po zamknięciu tej listy migracja WordPressa staje się odebraną usługą. Zachowaj protokół, kopie i pierwsze wyniki backupu na nowym serwerze. Nie przyspieszaj rezygnacji z poprzedniego konta kosztem możliwości odzyskania danych.

Dziennik przełączenia i kontrola po pierwszym dniu

W dzienniku zapisz początek ostatniej synchronizacji, wynik porównania danych, godzinę zmiany rekordów i numery sprawdzanych operacji. Przy każdym teście wskaż serwer źródłowy odpowiedzi. Pozwala to wyjaśnić sytuację, w której jeden użytkownik ogląda już nową instalację, a drugi nadal trafia na poprzednią. Nie uznawaj pojedynczego zrzutu strony za dowód zakończenia przełączenia całej usługi.

Następnego dnia sprawdź nowe formularze, zadania cykliczne, wygenerowane pliki i pocztę odebraną po zmianie. Potwierdź pierwszą kopię wykonaną już na docelowym koncie, jej zakres i możliwość pobrania. Właściciel powinien mieć aktualne dane kontaktowe do pomocy, listę pozostawionych integracji oraz termin bezpiecznego zakończenia starej usługi. Jeśli pozostał niewyjaśniony błąd, nie zamykaj go samym stwierdzeniem „DNS jeszcze się propaguje”.

Źródła i aktualizacja danych

Źródła sprawdzono 29.10.2026. Kolejność kontroli i tabele są opracowaniem redakcyjnym. Szczegóły migracji trzeba dostosować do aplikacji i usług; tekst nie stanowi gwarancji zerowej przerwy ani raportu z wykonanej migracji.

• WordPress — przenoszenie instalacji
• WordPress — kopie plików i bazy
• imapsync — dokumentacja transferu IMAP
• Cloudflare — TTL
• Cloudflare — rekordy DNS dla poczty
• cPanel — kreator nowej bazy.
• phpMyAdmin — import do wskazanej bazy.
• cPanel — domena i katalog.
• Microsoft — działanie i lokalizacja hosts.
• WordPress — konfiguracja aplikacji.

• WP-CLI — bezpieczna obsługa serializacji i tryb dry-run