Migracja na nowy hosting bez przestojów – kluczowe strategie, checklist i najlepsze praktyki cutover

Migracja hostingu bez przestoju nie polega na szybkim skopiowaniu plików i zmianie adresu IP w DNS. Największym problemem są dane zapisywane już po wykonaniu kopii: nowe zamówienia, płatności, rejestracje kont, formularze, komentarze, pliki użytkowników i zmiany w panelu administracyjnym. Jeżeli stary i nowy serwer działają równolegle bez ustalenia jednego źródła prawdy, część informacji niemal na pewno zostanie na niewłaściwej maszynie.

Dlatego migrację trzeba traktować jak kontrolowane przełączenie produkcji, czyli cutover, a nie zwykłe przenosiny. W dobrze przygotowanej operacji użytkownik nadal widzi działającą stronę, administrator potrafi wskazać moment ostatniej synchronizacji, a zespół ma ustalone warunki wycofania zmiany. Nie zawsze da się zagwarantować absolutne zero niedostępności. Można jednak ograniczyć przerwę do kilkunastu–kilkudziesięciu sekund albo ukryć ją przed większością użytkowników, jeżeli architektura pozwala prowadzić dwa środowiska równolegle.

Najpierw zgodność środowiska, dopiero potem kopiowanie danych

Pierwszy test nowego hostingu nie powinien dotyczyć wyniku z Google PageSpeed Insights. Najpierw trzeba sprawdzić, czy aplikacja w ogóle może działać na nowym środowisku bez zmiany kodu.

Deklarowane „8 GB RAM i 4 vCPU” niewiele mówi, jeżeli usługodawca ogranicza liczbę procesów PHP, operacje wejścia–wyjścia, liczbę równoczesnych połączeń albo czas wykonywania skryptu. Na hostingu współdzielonym typowym ograniczeniem bywają również limity inode, czyli liczby plików. Serwis może zajmować zaledwie 15 GB z dostępnych 100 GB, ale przekroczyć limit 500 tys. plików przez cache, miniatury, kopie zapasowe albo sesje PHP.

Przed migracją trzeba porównać co najmniej:

wersje PHP, Node.js, MySQL, MariaDB lub PostgreSQL;
wymagane rozszerzenia, np. intl, imagick, ionCube, redis, mbstring, pdo_mysql;
limity memory_limit, max_execution_time, upload_max_filesize i post_max_size;
sposób uruchamiania zadań cron, workerów kolejek i procesów działających w tle;
dostęp do SSH, Composer, WP-CLI, Git oraz logów serwera;
obsługę Redis, Memcached, OPcache i trwałego cache obiektowego;
uprawnienia katalogów oraz właścicieli plików;
konfigurację SMTP i możliwość wysyłania poczty z własnej domeny;
reguły zapory, listy dozwolonych adresów IP oraz połączenia wychodzące do zewnętrznych API;
sposób wydawania i automatycznego odnawiania certyfikatów TLS.

Szczególnie ostrożnie trzeba podchodzić do zmiany wersji bazy danych. Przeniesienie aplikacji z MySQL 5.7 do MySQL 8.x albo z jednej wersji MariaDB do innej może ujawnić różnice w sortowaniu, trybach SQL, obsłudze dat, słowach zastrzeżonych i sposobie wykonywania zapytań. Migracja hostingu nie jest dobrym momentem na jednoczesne podnoszenie wersji PHP, silnika bazy i systemu CMS. Każda dodatkowa zmiana utrudnia znalezienie przyczyny awarii.

Najważniejszym testem jest próbne odtworzenie pełnego backupu. Kopia zapasowa istniejąca wyłącznie jako archiwum .zip i plik .sql nie jest jeszcze planem awaryjnym. Trzeba ją zaimportować na nowy serwer, uruchomić aplikację i zmierzyć czas odtwarzania.

Jeżeli baza waży 20 GB, eksport wykonuje się przez 40 minut, a import trwa dwie godziny, jednogodzinne okno migracyjne jest fikcją. W takim przypadku potrzebna będzie replikacja, eksport przyrostowy, narzędzie dostawcy bazy albo dłuższy okres ograniczenia zapisów. Binlog MySQL rejestruje operacje zmieniające dane i może służyć do replikacji oraz odtworzenia transakcji wykonanych po utworzeniu kopii. Sama replikacja asynchroniczna nie gwarantuje jednak, że każda zatwierdzona transakcja zdąży dotrzeć na replikę przed awarią źródła.

Przed cutoverem należy również zinwentaryzować elementy, których często nie ma w katalogu strony:

rekordy A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC i CAA;
skrzynki pocztowe, aliasy, przekierowania oraz autorespondery;
zadania cron zapisane w panelu starego hostingu;
webhooki operatorów płatności, firm kurierskich, CRM i systemu fakturowego;
klucze API, sekrety, tokeny OAuth i zmienne środowiskowe;
reguły przekierowań, blokady adresów IP i konfigurację CDN;
katalogi z plikami przesyłanymi przez użytkowników;
zewnętrzne magazyny danych, np. Amazon S3, Cloudflare R2 lub kompatybilny storage;
kopie zapasowe wykonywane automatycznie przez poprzedniego operatora.

Najbardziej irytujące awarie po migracji zwykle nie dotyczą strony głównej. Serwis „działa”, ale formularz nie wysyła wiadomości, płatność kończy się błędem, dokument PDF nie powstaje, cron nie odnawia subskrypcji albo API odrzuca nowe IP serwera. Dlatego próba generalna musi obejmować pełne procesy biznesowe, a nie kilka odsłon w przeglądarce.

Checklista cutoveru: kolejność, odpowiedzialność i granica rollbacku

Dobra checklista nie jest luźną listą zadań. Każda pozycja powinna mieć właściciela, termin, warunek zaliczenia i procedurę cofnięcia. Podczas przełączenia nie może być wątpliwości, kto zmienia DNS, kto synchronizuje bazę, kto sprawdza płatności i kto podejmuje decyzję o rollbacku.

Na 7–14 dni przed migracją należy:

uruchomić nowe środowisko i wgrać kopię produkcji;
porównać konfigurację aplikacji oraz wersje usług;
potwierdzić miejsce na dysku z zapasem co najmniej 30–50%;
wykonać testowy import bazy i sprawdzić jego czas;
skonfigurować certyfikat TLS dla domeny oraz subdomen;
ustawić monitoring HTTP, błędów aplikacji, CPU, RAM, dysku i bazy;
spisać wszystkie integracje zewnętrzne;
wykonać testy logowania, formularzy, poczty, płatności, uploadu i panelu administratora;
określić maksymalny dopuszczalny czas niedostępności;
przygotować procedurę rollbacku.

Certyfikat trzeba uruchomić przed zmianą ruchu. W przypadku Let’s Encrypt standardowe certyfikaty są ważne przez 90 dni, więc automatyczne odnawianie powinno zostać sprawdzone, a nie tylko włączone w panelu. Serwer musi poprawnie przejść ponowną walidację domeny, również po zmianie DNS lub reguł proxy.

Na 24–48 godzin przed przełączeniem należy obniżyć TTL krytycznych rekordów DNS, najczęściej do 300 sekund. Zmiana wykonana pięć minut przed migracją niewiele daje, ponieważ resolver może nadal przechowywać poprzednią wartość przez czas wynikający ze starego TTL. Po migracji niski TTL można pozostawić przez 24–72 godziny, a następnie zwiększyć go np. do 3600 sekund. Cloudflare również rekomenduje obniżenie TTL z wyprzedzeniem odpowiadającym co najmniej poprzedniej wartości; typowym ustawieniem migracyjnym jest pięć minut.

W dniu migracji kolejność powinna wyglądać następująco:

Wstrzymanie wdrożeń, aktualizacji wtyczek i zmian konfiguracyjnych.
Wykonanie świeżego backupu plików, bazy i konfiguracji DNS.
Pierwsza synchronizacja danych na nowy serwer.
Sprawdzenie działania nowego środowiska przez lokalny plik hosts, adres techniczny albo tymczasową domenę.
Uruchomienie trybu ograniczonego zapisu lub krótkiego maintenance.
Ostatnia synchronizacja plików zmiennych, np. katalogu uploads.
Końcowy eksport bazy, zatrzymanie replikacji albo oczekiwanie na zerowy lag.
Kontrola liczby rekordów, ostatnich zamówień i czasu ostatniej transakcji.
Zmiana DNS, adresu origin w CDN albo konfiguracji load balancera.
Testy produkcyjne wykonywane już przez publiczną domenę.
Odblokowanie zapisów.
Intensywny monitoring.

W małej witrynie WordPress synchronizację plików można wykonać przez rsync, przesyłając przed cutoverem większość danych, a w ostatniej rundzie wyłącznie różnice. Kopiowanie całego katalogu od nowa tuż przed przełączeniem niepotrzebnie wydłuża operację. Trzeba jednak wykluczyć katalogi cache, stare backupy i pliki tymczasowe, chyba że aplikacja rzeczywiście ich potrzebuje.

W sklepie WooCommerce, PrestaShop lub Magento samo ponowne skopiowanie bazy jest bardziej ryzykowne. Między eksportem a importem mogą pojawić się nowe zamówienia, płatności i zmiany stanów magazynowych. Najprostsze bezpieczne rozwiązanie to krótkie zablokowanie koszyka i panelu klienta przy pozostawieniu publicznego katalogu produktów. Jeżeli biznes nie akceptuje nawet kilkuminutowego ograniczenia sprzedaży, potrzebna jest replikacja bazy albo architektura blue/green z kontrolowanym przełączeniem źródła zapisu.

Rollback trzeba zdefiniować liczbowo, zanim pojawi się problem. Przykładowe warunki cofnięcia migracji:

ponad 2–3 minuty całkowitej niedostępności bez rozpoznanej przyczyny;
brak możliwości logowania lub składania zamówień;
błędy zapisu do bazy;
seria odpowiedzi HTTP 500 przekraczająca ustalony próg, np. 2–5% żądań;
niedziałające płatności lub webhooki;
opóźnienie replikacji, którego nie można bezpiecznie wyzerować;
niezgodność liczby zamówień, użytkowników albo transakcji;
brak możliwości potwierdzenia, na którym serwerze zapisują się dane.

Granica musi uwzględniać czas potrzebny na powrót. Jeżeli odtworzenie starego środowiska trwa 90 minut, nie można podjąć decyzji o rollbacku pięć minut przed końcem dostępnego okna technicznego. Stary hosting powinien pozostać w stanie gotowości co najmniej 3–7 dni, a w systemach prowadzących sprzedaż, rezerwacje lub rozliczenia — częściej 7–14 dni.

Nie należy od razu kasować starej instancji ani zmieniać jej danych. Najbezpieczniej przełączyć ją w tryb tylko do odczytu, ograniczyć dostęp administracyjny i pozostawić logi. Trzeba też uważać na automatyczne zadania. Jeżeli cron działa jednocześnie na obu serwerach, może dwukrotnie wysłać newsletter, wystawić dwa dokumenty, pobrać tę samą opłatę cykliczną albo przetworzyć kolejkę po raz drugi.

Wybór strategii bez przestoju i testy po przełączeniu

Strategię migracji należy dobrać do liczby zapisów i kosztu utraty danych. Rozmiar serwisu ma mniejsze znaczenie niż intensywność zmian. Blog z milionem odsłon może być prostszy do przeniesienia niż niewielki system rezerwacji przyjmujący kilka transakcji na minutę.

Klasyczny eksport, import i zmiana DNS sprawdzą się przy:

stronach wizytówkowych;
blogach bez aktywnych komentarzy;
katalogach i serwisach informacyjnych;
aplikacjach, w których można czasowo zablokować zapis;
systemach akceptujących kilka minut pracy w trybie tylko do odczytu.

Zaletą jest prostota. Wadą — wyraźny punkt przełączenia i ryzyko utraty zmian dokonanych pomiędzy ostatnią kopią a blokadą zapisu.

Blue/green deployment wykorzystuje dwa kompletne środowiska: stare, czyli blue, oraz nowe, czyli green. Nowa infrastruktura jest testowana przed skierowaniem do niej użytkowników. Ruch przełącza się przez load balancer, reverse proxy, CDN lub DNS. Takie podejście upraszcza rollback, ponieważ stary system nadal działa, ale samo postawienie dwóch serwerów nie rozwiązuje problemu spójności bazy.

Jeżeli oba środowiska przyjmują zapisy, trzeba zastosować wspólną bazę, replikację, kolejkę zdarzeń albo inną kontrolę konfliktów. Próba scalania dwóch niezależnie zmienianych baz po migracji jest kosztowna i podatna na błędy. W środowisku green najlepiej pozostawić bazę w trybie tylko do odczytu aż do właściwego przełączenia. Usługi zarządzane potrafią automatycznie synchronizować środowiska i przeprowadzać switchover, ale nadal występuje krótka przerwa potrzebna na zamknięcie połączeń i przekierowanie klientów. AWS podaje, że w RDS Blue/Green typowy switchover trwa mniej niż minutę, zależnie od obciążenia.

Migracja etapowa jest uzasadniona wtedy, gdy system składa się z niezależnych komponentów. Można osobno przenieść statyczne media, frontend, API, workery, panel administracyjny i bazę. Pozwala to ograniczyć obszar potencjalnej awarii, ale zwiększa liczbę zależności. Dla zwykłej strony firmowej etapowanie jest zazwyczaj przerostem formy nad treścią.

Po przełączeniu testy trzeba wykonywać według wpływu na biznes:

rozwiązywanie domeny po IPv4 i IPv6;
certyfikat TLS, pełny łańcuch certyfikacji i przekierowanie HTTP → HTTPS;
odpowiedzi strony głównej, API i najważniejszych podstron;
logowanie, reset hasła i tworzenie kont;
zapis danych w panelu administratora;
formularze oraz dostarczanie wiadomości;
koszyk, płatność testowa, webhook i zmiana statusu zamówienia;
upload oraz odczyt nowych plików;
zadania cron, kolejki i workery;
integracje z CRM, ERP, systemem księgowym i kurierami;
nagłówki cache, przekierowania i reguły CDN.

Dopiero po potwierdzeniu zapisów warto analizować szybkość działania. Najpierw należy sprawdzić:

odsetek odpowiedzi 4xx i 5xx;
czas odpowiedzi aplikacji i bazy;
wykorzystanie CPU, RAM oraz przestrzeni dyskowej;
liczbę aktywnych procesów i połączeń;
wolne zapytania SQL;
zapełnianie kolejek;
błędy wysyłki poczty;
czas wykonywania crona;
liczbę nowych zamówień lub innych zdarzeń biznesowych w porównaniu ze zwykłym ruchem.

Monitoring przez pierwsze 30 minut powinien być ciągły. Przez następne 24 godziny trzeba sprawdzać system regularnie, także po wykonaniu zadań uruchamianych raz na godzinę lub raz na dobę. Pełny okres obserwacji powinien trwać co najmniej 3–7 dni. Część problemów wychodzi dopiero po nocnym backupie, odnowieniu cache, wygenerowaniu raportów, wysyłce newslettera albo wzroście ruchu.

Jedna niedogodność pojawia się niemal przy każdej migracji DNS: przez pewien czas użytkownicy mogą trafiać na różne serwery. Niski TTL ogranicza ten okres, ale go nie usuwa. Resolver operatora, router, przeglądarka albo aplikacja mogą zachować stary adres dłużej, niż wynikałoby to z konfiguracji. Dlatego stary serwer nie może zostać wyłączony natychmiast po zmianie rekordu.

FAQ

Czy można przenieść hosting całkowicie bez przerwy?
Tak, jeżeli ruch można przełączać przez load balancer lub CDN, a dane są współdzielone albo replikowane. Przy zwykłej zmianie DNS nie da się zagwarantować, że każdy użytkownik od razu trafi na nowy serwer.

Kiedy obniżyć TTL przed migracją?
Najbezpieczniej 24–48 godzin wcześniej, a przy dotychczasowym TTL wynoszącym dobę — co najmniej dobę przed cutoverem. Typowa wartość migracyjna to 300 sekund.

Czy trzeba włączać tryb maintenance?
Nie zawsze. Strona informacyjna może pozostać dostępna. W sklepie lub aplikacji zapisującej dane lepiej zablokować na kilka minut koszyk, panel klienta albo inne operacje zapisu niż później odtwarzać brakujące transakcje.

Jak sprawdzić nowy serwer przed zmianą DNS?
Przez lokalny wpis w pliku hosts, techniczną subdomenę, adres podglądowy operatora albo regułę kierującą wyłącznie ruch zespołu testowego. Test musi używać docelowej konfiguracji HTTPS i produkcyjnej wersji aplikacji.

Jak długo utrzymywać stary hosting?
Minimum 3–7 dni. Przy sklepie, systemie rezerwacji, subskrypcjach lub zadaniach rozliczeniowych rozsądniejszy jest okres 7–14 dni, obejmujący przynajmniej jeden pełny cykl wszystkich zadań automatycznych.

Kiedy wykonać rollback?
Gdy nie działa zapis danych, logowanie, płatność, panel administracyjny albo kluczowe API, a problemu nie da się usunąć w ustalonym limicie. Rollback nie powinien zależeć od przekonania, że „jeszcze jedna poprawka” rozwiąże sytuację.

Czy migracja hostingu wpływa na SEO?
Nie powinna, jeżeli adresy URL, kody odpowiedzi, przekierowania, certyfikat, plik robots.txt i tagi kanoniczne pozostają bez zmian. Długi przestój, masowe błędy 500, przypadkowa blokada indeksowania albo zmiana struktury adresów podczas migracji mogą już zaszkodzić.

Co sprawdzić jako pierwsze po cutoverze?
Nie wygląd strony, lecz funkcję zapisującą dane: zamówienie, formularz, rejestrację albo zmianę w panelu. Strona może wyświetlać się poprawnie z cache, mimo że połączenie z bazą, poczta lub kolejki nie działają.

Pierwszym działaniem powinno być testowe odtworzenie aktualnego backupu na nowym hostingu. Jeżeli aplikacja nie uruchamia się bez ręcznych poprawek, import trwa dłużej niż dostępne okno, brakuje rozszerzeń albo nie można potwierdzić integralności danych, termin cutoveru trzeba przesunąć. DNS, CDN i szybkie serwery nie naprawią migracji, której nie da się powtórzyć w kontrolowanych warunkach.