MIGRACJE / CUTOVER WITHOUT DRAMA
Migracja strony lub sklepu bez zgubionych danych, SEO i nerwowego F5.
Przenoszę strony, sklepy i ich zaplecze techniczne na nowe środowisko z planem, kopią, testami i możliwością wycofania zmiany. Pilnuję plików, baz danych, DNS, SSL, poczty, integracji, adresów URL i elementów ważnych dla widoczności w Google.
Migracja to nie „kopiuj / wklej”. Dobra migracja kończy się wtedy, kiedy nowy serwer działa, użytkownicy trafiają tam gdzie trzeba, formularze wysyłają, sklep sprzedaje, a stary system nadal może być punktem powrotu, jeśli coś wymaga korekty.
- 01Backup przed ruchemnajpierw punkt powrotu, potem zmiana
- 02Test przed przełączeniemnowe środowisko nie debiutuje na klientach
- 03SEO i DNS pod kontroląadresy, przekierowania, SSL, indeksacja
[01 / WHAT CAN GO WRONG]
Najdroższa migracja to ta, która miała być „na szybko”.
Serwis może wyglądać poprawnie, a jednocześnie gubić formularze, zamówienia, przekierowania, pliki, cron, pocztę albo ruch organiczny. Dlatego przed przełączeniem spisuję zależności i definiuję, co dokładnie musi przejść test.
Dane mają być kompletne
Pliki i baza danych muszą tworzyć spójny stan. Przy aktywnym sklepie lub serwisie z częstymi zmianami planuję też moment finalnej synchronizacji.
DATA INTEGRITY FIRSTDNS to nie przycisk „teleportuj”
Zmiana delegacji lub rekordów wymaga uwzględnienia TTL, SSL, poczty i usług, które mogą działać poza samą stroną WWW.
DNS ≠ MAGIC SWITCHSEO nie może zostać w starym serwerze
Kontroluję adresy URL, canonicale, robots, sitemapę, przekierowania i kody odpowiedzi. Replatforming bez mapy URL potrafi być kosztowniejszy niż sama migracja.
KEEP THE SIGNALSRollback jest funkcją, nie pesymizmem
Jeśli przełączenie ujawni problem, ważniejsze od heroizmu jest szybkie odzyskanie stabilnego stanu i poprawienie przyczyny poza presją produkcji.
CTRL+Z, BUT PLANNED[02 / CUTOVER LAB]
Wybierz typ migracji. Plan zmienia się razem z ryzykiem.
To nie jest automatyczna wycena ani obietnica „zero downtime”. To interaktywny model pokazujący, które punkty wymagają największej uwagi przy różnych scenariuszach.
[03 / MIGRATION SCOPE]
Co mogę przenieść i uporządkować po drodze.
Zakres zależy od technologii i celu. Czasem wystarczy przeprowadzka 1:1. Czasem migracja jest najlepszym momentem, żeby usunąć stare zależności, poprawić strukturę i nie zabierać długu technicznego do nowego środowiska.
Hosting i VPS
- WordPress, Joomla, WooCommerce i inne serwisy PHP/MySQL
- pliki, bazy danych, cron, cache i konfiguracja
- SSL, DNS i domena w zakresie potrzebnym do uruchomienia
- testy wersji PHP i zależności
Zmiana CMS lub technologii
- analiza treści i funkcji do zachowania
- mapa starych i nowych URL-i
- przeniesienie treści, mediów i danych
- kontrola indeksacji po uruchomieniu
Sklep internetowy
- produkty, kategorie i dane możliwe do migracji
- klienci, zamówienia i integracje po analizie zakresu
- płatności, dostawy, e-maile i checkout
- SEO kategorii i produktów oraz przekierowania
Poczta, DNS i domena
- rekordy DNS i usługi zależne od domeny
- skrzynki oraz migracja poczty, jeśli obejmuje to projekt
- SPF, DKIM i DMARC w zakresie konfiguracji poczty
- kontrola WWW i poczty po przełączeniu
SEO techniczne
- statusy 200 / 301 / 404
- canonical, robots i sitemap
- adresy URL i przekierowania
- analityka i tagi wymagające ponownej weryfikacji
Odbiór i stabilizacja
- test formularzy, logowania i kluczowych ścieżek
- kontrola błędów i podstawowej wydajności
- obserwacja po zmianie DNS
- decyzja kiedy bezpiecznie wyłączyć stare środowisko
[04 / RUNBOOK]
Migrację prowadzę jak zmianę produkcyjną, nie jak eksperyment na żywym serwisie.
Dokładny runbook zależy od projektu, ale kolejność jest celowa: najpierw rozpoznanie i punkt powrotu, potem kopia i test, a dopiero na końcu przełączenie ruchu.
- 01DISCOVERY
Spisuję zależności
Hosting, CMS, wersje, baza, poczta, DNS, integracje, cron, certyfikat, analityka i elementy krytyczne biznesowo.
- 02BACKUP
Tworzę punkt powrotu
Kopia plików i bazy, a gdy ryzyko tego wymaga również dodatkowy snapshot lub eksport konfiguracji.
- 03STAGE
Buduję nowe środowisko
Przenoszę serwis, konfiguruję target i rozwiązuję różnice wersji lub ustawień zanim ruszy produkcyjny ruch.
- 04VERIFY
Testuję to, co zarabia albo kontaktuje
Formularze, koszyk, checkout, logowanie, wysyłkę e-mail, przekierowania, certyfikat, błędy i kluczowe URL-e.
- 05CUTOVER
Przełączam w kontrolowanym oknie
Finalna synchronizacja danych, rekordy DNS lub delegacja i działania potrzebne do ograniczenia rozjazdu między starym a nowym systemem.
- 06WATCH
Sprawdzam stan po starcie
Monitoruję podstawowe funkcje i nie wyłączam starego środowiska tylko dlatego, że pierwsza strona główna się otworzyła.
[05 / KEEP THE SIGNAL]
Serwis może działać po migracji i jednocześnie tracić sygnały SEO.
Przy zmianie hostingu zwykle chcę zachować istniejące URL-e i zachowanie serwisu. Przy zmianie CMS lub struktury potrzebna jest mapa przekierowań i kontrola technicznego SEO. W obu przypadkach sprawdzam elementy, które roboty i użytkownicy mogą zobaczyć inaczej po zmianie.
Kluczowe strony odpowiadają poprawnie
Nie wystarczy, że otwiera się home. Sprawdzam reprezentatywne adresy i typy treści.
Stare adresy mają sensowny cel
Przy zmianie struktury unikam łańcuchów i przekierowań „wszystko na stronę główną”.
Indeksacja nie zmienia się przypadkiem
Robots, canonicale, sitemap i znaczniki noindex wymagają kontroli po migracji.
Analityka nie znika podczas przeprowadzki
Sprawdzam obecność wymaganych tagów i punktów pomiarowych w zakresie projektu.
[06 / EDGE CASES]
Nie każda migracja jest „kopią strony”. Czasem przenosimy mały ekosystem.
Im więcej usług zależy od domeny i serwera, tym ważniejsza jest kolejność. Sklep, poczta, API, płatności, integracje, ERP, zadania cron i systemy zewnętrzne mogą mieć własne adresy, whitelisty, limity albo wymagania.
Aktywny sklep
Największym problemem jest rozjazd danych w czasie. Plan musi uwzględniać zamówienia i zmiany wykonane między kopią a finalnym przełączeniem.
SYNC WINDOW MATTERSSerwis po innym wykonawcy
Najpierw ustalam, co faktycznie działa i od czego zależy. Brak dokumentacji nie może być zastąpiony zgadywaniem konfiguracji.
DISCOVER BEFORE MOVEPoczta na tej samej domenie
Zmiana DNS strony nie może przypadkiem wyciąć MX, SPF, DKIM albo innych rekordów potrzebnych do komunikacji.
WWW IS NOT THE WHOLE DNSZmiana CMS
Treść może wyglądać podobnie, ale struktura URL, metadane, schema i zachowanie komponentów potrafią zmienić się całkowicie.
REPLATFORM ≠ HOST MOVE[07 / DIRECT TO SPECIALIST]
Nie przerzucam Cię między „działem domen” i „działem strony”.
Analizuję migrację jako jeden techniczny proces. Jeżeli problem dotyczy hostingu, CMS, DNS, SSL, poczty albo integracji, patrzę na zależności między nimi. To szczególnie ważne wtedy, gdy serwis już działa i nie można sobie pozwolić na metodę prób i błędów.
Najpierw stan faktyczny
Sprawdzam, co istnieje i od czego zależy. Nie projektuję migracji z opisu „chyba wszystko jest na jednym serwerze”.
Backup przed ryzykiem
Punkt powrotu jest częścią planu, nie dodatkiem po problemie.
Test przed DNS
Jeżeli technologia na to pozwala, nowy system przechodzi test zanim użytkownicy zaczną z niego korzystać.
Nie kasuję starego serwera w euforii
Wyłączenie źródła następuje dopiero po odbiorze i stabilizacji zgodnie z ustalonym planem.
[08 / FAQ]
Pytania przed migracją strony, sklepu lub hostingu.
Nie ma jednej procedury dla każdego serwisu. Poniżej odpowiadam na pytania, które najczęściej decydują o zakresie i ryzyku.
Czy migracja może odbyć się bez przerwy w działaniu?
Często można bardzo ograniczyć przerwę, ale nie deklaruję „zero downtime” bez analizy konkretnego systemu. Wpływ mają m.in. DNS, aktywność użytkowników, częstotliwość zmian w bazie, integracje i możliwość przygotowania środowiska równoległego.
Czy podczas zmiany hostingu stracę pozycje w Google?
Sama zmiana hostingu nie powinna wymagać zmiany adresów URL. Ryzyko pojawia się wtedy, gdy po migracji serwis odpowiada inaczej, ma błędne canonicale, noindex, problemy z wydajnością, niedostępne zasoby albo zmienioną strukturę. Dlatego kontrola SEO technicznego jest częścią odbioru.
Czy przenosisz także pocztę i domenę?
Mogę objąć projektem również DNS, domenę i pocztę, jeśli jest to potrzebne. Zakres ustalam osobno, bo strona WWW i poczta mogą być utrzymywane u różnych dostawców. Nie zmieniam rekordów „hurtowo” bez sprawdzenia, do czego służą.
Czy możesz przenieść stronę, której nie tworzyłeś?
Tak. Przy cudzym serwisie najpierw robię rozpoznanie technologii, hostingu, zależności, licencji i dostępnych kopii. Jeżeli stan jest niepewny, migracja może wymagać dodatkowego etapu porządkowego przed przełączeniem produkcji.
Co jest potrzebne do wyceny migracji?
Na początek wystarczy adres serwisu, informacja skąd i dokąd ma być przeniesiony, technologia jeśli ją znasz, informacja czy w grę wchodzi poczta oraz najważniejsze funkcje biznesowe. Nie wysyłaj haseł ani tokenów w formularzu. Dostępy ustalam po kwalifikacji i przez bezpieczny kanał.
Kiedy stary hosting można wyłączyć?
Dopiero po odbiorze nowego środowiska, przejściu testów i upewnieniu się, że ruch oraz usługi zależne od DNS działają prawidłowo. Dokładny moment zależy od projektu i warunków u dostawców.
[09 / REQUEST MIGRATION]
Zanim ruszymy z danymi, ustalmy trasę.
Wyślij adres strony lub sklepu i krótko opisz, co ma się zmienić. Na tym etapie nie potrzebuję haseł do serwera, CMS, poczty ani rejestratora domeny.
Bez haseł w pierwszej wiadomości. Najpierw zakres i ryzyko. Potem bezpieczne przekazanie potrzebnych dostępów.