Інструмент

Migracja do chmury: checklista dla firmy

Praktyczna checklista migracji aplikacji, strony, poczty i DNS do chmury: backup, TTL, SSL, testy, monitoring i rollback.

Hub

Migracja do chmury nie powinna zaczynać się od kopiowania plików. Najpierw trzeba wiedzieć, co przenosimy: aplikację, stronę WWW, pocztę, bazę danych, DNS, certyfikaty, backupy, zadania cykliczne i dostępy administracyjne. Ten hub zbiera praktyczną checklistę dla firm, które chcą przenieść serwer albo aplikację do chmury bez nieplanowanej przerwy.

Dobór serwera cloud VPS, cloud server, dedyk albo model hybrydowy. Kontenery po migracji Docker, Kubernetes i środowiska aplikacyjne. Audyt DNS Delegacja, DNSSEC, HTTPS i mixed content po zmianie. SSL/TLS po przełączeniu Certyfikat, łańcuch zaufania i zgodność nazw. Poczta firmowa MX, SPF, DMARC i stare rekordy po migracji. Test HTTP Status, czas odpowiedzi, cache i kompresja.

Migracja aplikacji do chmury: kolejność prac

Dobra migracja do chmury ma dwa cele: uruchomić usługę w nowym środowisku i zachować możliwość szybkiego powrotu, jeśli testy pokażą problem. Dlatego przed zmianą DNS warto przygotować kopie danych, konfigurację aplikacji, listę zależności, dostęp do poprzedniego serwera i plan weryfikacji po przełączeniu ruchu.

Checklista przed migracją

Inwentaryzacja usług. Spisz domeny, subdomeny, aplikacje, bazy danych, konta pocztowe, zadania cron, integracje API i pliki użytkowników.
Backup i test odtworzenia. Zrób kopię plików, baz, konfiguracji, certyfikatów i sekretów, a potem sprawdź, czy da się je odtworzyć.
DNS i TTL. Obniż TTL przed przełączeniem, przygotuj rekordy A/AAAA, CNAME, MX, SPF, DKIM, DMARC i plan ich przywrócenia.
Środowisko docelowe. Przygotuj VPS, cloud server albo serwer dedykowany, firewall, konta administracyjne, monitoring i backup.
Testy przed ruchem produkcyjnym. Sprawdź aplikację po adresie technicznym albo wpisie hosts, zanim publiczny DNS zacznie kierować użytkowników do chmury.

Co migrować razem, a co osobno?

Strona i aplikacja

Aplikację można zwykle przenieść etapami: kod, pliki, konfiguracja, baza danych, certyfikat i dopiero potem publiczne DNS. To ogranicza czas niedostępności.

Baza danych

Przy bazie trzeba zaplanować okno synchronizacji, blokadę zapisów albo replikację. Najważniejsze jest to, żeby po przełączeniu aplikacja nie pisała danych w dwóch miejscach.

Poczta firmowa

Migracja poczty wymaga osobnego planu: MX, SPF, DKIM, DMARC, webmail, IMAP, konta użytkowników i stare systemy wysyłające wiadomości w imieniu domeny.

DNS i certyfikaty

DNS i SSL/TLS są widoczne dla użytkownika od razu. Po przełączeniu trzeba sprawdzić certyfikat, przekierowania, mixed content, rekordy DNS i stare wpisy po poprzednim hostingu.

Testy po przełączeniu do chmury

Strona lub aplikacja odpowiada poprawnym statusem HTTP i nie pokazuje błędów backendu.
Certyfikat SSL/TLS pasuje do domeny, ma poprawny łańcuch i działa dla wszystkich hostów.
Nie ma mixed content, starych linków HTTP ani zasobów ładowanych z poprzedniego środowiska.
DNS wskazuje na nowe adresy, a stare rekordy nie kierują części ruchu do poprzedniego hostingu.
Poczta ma poprawne MX, SPF, DKIM i DMARC, a systemy mailingowe nadal są uwzględnione w DNS.
Backup działa w nowym miejscu, monitoring zgłasza alerty, a logi aplikacji są dostępne administratorom.

Plan rollbacku, czyli powrót po nieudanej migracji

Plan powrotu powinien istnieć przed migracją. W praktyce oznacza to zachowanie starego środowiska przez ustalony czas, niski TTL DNS, aktualny backup, listę zmian wykonanych w nowym środowisku i jasną decyzję, kiedy przerywamy migrację zamiast naprawiać ją w środku ruchu produkcyjnego.

Minimalny rollback

Dla prostej strony wystarczy często przywrócenie rekordów DNS, wyłączenie zapisów w nowym miejscu i powrót do poprzedniego serwera z aktualnym backupem.

Rollback aplikacji z bazą

Przy bazie danych trzeba wiedzieć, co stało się z zapisami po przełączeniu. Bez tego powrót może oznaczać utratę zamówień, formularzy albo danych użytkowników.