Migracja strony bez zgadywania: checklista przed, w trakcie i po zmianie
Migracja to kontrolowana zmiana wielu zależności, nie tylko kopiowanie plików. Checklista prowadzi od rozpoznania stanu po testy i decyzję o zamknięciu wdrożenia.
Najbardziej zdradliwe migracje to te, które wydają się zbyt proste na plan. Strona główna może otworzyć się poprawnie, podczas gdy formularz wysyła wiadomości w próżnię, zadanie cykliczne nie działa, część plików wskazuje stare adresy albo nowa baza nie przyjmuje zapisów. Checklista nie usuwa wszystkich niespodzianek, ale ogranicza liczbę decyzji podejmowanych pod presją.
Traktuj migrację jak zmianę usługi, a nie operację na katalogu. Jej zakres obejmuje dane, konfigurację, domenę, certyfikat, integracje, monitoring i osoby odpowiedzialne za reakcję.
Przed migracją: opisz stan, który przenosisz
Zacznij od mapy zależności. Wymień aplikację i jej wersję, bazę, pliki użytkowników, zadania cykliczne, pocztę, zewnętrzne API, magazyny danych, rekordy DNS i certyfikaty. Zapisz, gdzie znajdują się sekrety oraz kto ma dostęp do panelu domeny i obecnego środowiska. Nie kopiuj haseł do zwykłego dokumentu; odnotuj chronione miejsce ich przechowywania.
Sprawdź, które dane zmieniają się stale. Dla strony informacyjnej może to być tylko formularz lub licznik, a dla sklepu — zamówienia, stany, konta i zdarzenia płatnicze. Ta wiedza określa, czy podczas końcowej synchronizacji potrzebne jest ograniczenie zapisów, tryb konserwacji lub osobny sposób uzgodnienia zmian.
Ustal kryteria sukcesu. „Strona działa” zastąp listą konkretnych prób: otwarcie przez HTTPS, logowanie, wyszukanie treści, kontrolowany zapis, formularz do wskazanego odbiorcy, zadanie w tle i integracja, bez której proces nie ma sensu. Dopisz warunki wycofania oraz osobę, która podejmuje tę decyzję.
Kopia przed zmianą musi mieć instrukcję odtworzenia
Wykonaj kopię plików, danych i konfiguracji potrzebnych do uruchomienia. Zapisz czas jej wykonania oraz wersję aplikacji, z którą jest zgodna. Następnie odtwórz ją w miejscu odseparowanym od obecnej usługi. Otwórz reprezentatywne dane i wykonaj operację potwierdzającą, że aplikacja potrafi z nich skorzystać.
Jeśli nie można przeprowadzić pełnej próby, opisz dokładnie, co sprawdzono, czego nie sprawdzono i kto akceptuje pozostałe ryzyko. Sam rozmiar archiwum ani zielony status zadania nie dowodzą kompletności. NIST i CISA w zaleceniach dotyczących odporności podkreślają testowanie możliwości przywrócenia oraz oddzielenie części kopii od środowiska, które może zostać naruszone.
Próba na nowym środowisku
Zbuduj nowe środowisko, nie kierując jeszcze publicznego ruchu. Zainstaluj tylko potrzebne usługi, zastosuj aktualizacje z oficjalnych źródeł, ogranicz konta i uprawnienia, włącz logi oraz monitoring. Uruchom aplikację na adresie testowym albo sprawdzaj właściwą domenę przez kontrolowane lokalne mapowanie.
Przejdź przez kryteria sukcesu. Zwróć uwagę na ścieżki zapisu, kodowanie znaków, strefę czasową, limity przesyłania, zadania cykliczne, przekierowania, generowanie adresów oraz komunikację z zewnętrznymi usługami. W logach szukaj nie tylko błędów krytycznych, lecz także ostrzeżeń świadczących o brakującej konfiguracji.
DNS i HTTPS przygotuj przed oknem zmiany
Nazwa domeny jest tłumaczona przez DNS na informacje potrzebne do odnalezienia usługi. Odpowiedzi mogą być przechowywane w pamięci podręcznej, dlatego po zmianie część odbiorców może jeszcze trafiać według wcześniejszych danych. Zapisz istniejące rekordy i potwierdź dostęp do ich edycji. Nie zmieniaj kilku niezależnych rzeczy naraz, jeśli nie jest to konieczne — prostsza sekwencja ułatwia rozpoznanie źródła błędu.
Przygotuj certyfikat TLS dla wszystkich nazw używanych przez stronę. Sprawdź automatyczne odnowienie, przekierowanie z HTTP do HTTPS i ładowanie zasobów. Dokumentacja Let’s Encrypt zaleca automatyczny przepływ odnowień zamiast ręcznego procesu, który łatwo przeoczyć. Niezależnie od wystawcy certyfikatu potrzebny jest monitoring jego ważności i błędów odnowienia.
W oknie migracji prowadź jeden zapis działań
Potwierdź aktualną kopię i gotowość osób odpowiedzialnych. Ogranicz nowe zapisy albo rozpocznij uzgodnioną końcową synchronizację. Zanotuj czas, przenieś brakujące dane, wykonaj kontrolę spójności i zmień kierowanie ruchu. Każdy krok oraz jego wynik wpisuj do wspólnej osi czasu.
Po przełączeniu wykonaj test z zewnętrznej perspektywy. Użyj publicznego adresu, przejdź najważniejszą ścieżkę i sprawdź, czy zapis pojawił się w nowym miejscu. Obserwuj odpowiedzi HTTP, błędy aplikacji, czas wykonania, kolejki i miejsce na dane. Równocześnie sprawdź, czy stare środowisko nie przyjmuje nowych zmian, które pozostaną poza synchronizacją.
Kiedy wrócić
Nie czekaj bez końca tylko dlatego, że przełączenie już się wydarzyło. Jeżeli nie działa funkcja uznana za krytyczną, dane rozchodzą się między środowiskami albo brakuje diagnostyki pozwalającej bezpiecznie kontynuować, zastosuj wcześniej zapisane kryterium. Przywróć poprzednie kierowanie, zatrzymaj zapisy w niewłaściwym miejscu i udokumentuj dane wymagające późniejszego scalenia.
Plan powrotu powinien uwzględniać pamięć podręczną DNS: użytkownicy mogą przez pewien czas trafiać różnymi drogami. Dlatego oba środowiska muszą mieć zrozumiały stan, a komunikacja o przerwie lub ograniczeniu powinna być przygotowana wcześniej, jeśli konsekwencje są istotne.
Po udanej migracji
Zaktualizuj inwentarz, instrukcję dostępu, odbiorców alertów i procedurę odtwarzania. Wykonaj pierwszą kopię już w nowym środowisku i zaplanuj jej test. Stare zasoby wyłącz dopiero po uzgodnionym okresie obserwacji, usunięciu sekretów i potwierdzeniu, że nie są potrzebne do rozliczenia danych.
Pełny plan wdrożenia znajdziesz w osobnym przewodniku. Jeśli na etapie próby okazuje się, że wybrany model wymaga zbyt wielu ręcznych działań, wróć do mapy wyboru serwera — migracja jest dobrym testem realnego kosztu utrzymania.