Migracja do chmury

Co zwykle jest powodem migracji

Rzadko jest nim moda na chmurę. Najczęściej kończy się gwarancja na serwer, firma otwiera drugą lokalizację, część zespołu zostaje przy pracy zdalnej albo ktoś policzył, ile kosztuje utrzymanie serwerowni razem z prądem, klimatyzacją i wymianą sprzętu co pięć lat.

Drugi powód pojawia się po incydencie: firma odzyskiwała dane z kopii i okazało się, że wszystko, co ma, stoi w jednym pomieszczeniu.

Czego nie przenosimy

Chmura nie jest odpowiedzią na wszystko i mówimy to przed wyceną. Zostają lokalnie systemy przywiązane do sprzętu produkcyjnego, aplikacje, których producent nie wspiera poza własnym serwerem, oraz duże zasoby, na których pracuje się codziennie z biura, bo przy nich koszt transferu i opóźnienie przewyższają zysk.

Firma, która przeniesie do chmury wszystko bez wyjątku, zwykle wraca po roku z pytaniem, dlaczego rachunek urósł trzykrotnie.

Przebieg projektu

1. Inwentaryzacja. Skrzynki i ich rozmiary, zasoby plikowe, uprawnienia, systemy branżowe, kto z czego korzysta i skąd. Na tym etapie powstaje lista tego, co idzie do chmury, i tego, co zostaje.
2. Tożsamość. Konta, grupy, synchronizacja z domeną, logowanie wieloskładnikowe. To fundament, bo od niego zależy dostęp do wszystkiego, co przeniesiemy później.
3. Poczta. Pierwsze kopiowanie w tle, potem przełączenie wpisów DNS poza godzinami pracy i synchronizacja różnicowa, żeby nie zgubić wiadomości z ostatnich godzin.
4. Pliki. Przeniesienie zasobów z serwera do SharePoint i OneDrive z zachowaniem struktury i uprawnień, zwykle działami, nie wszystko naraz.
5. Serwery. Maszyny, które mają sens w chmurze, przenosimy osobno, w oknach serwisowych, po sprawdzeniu zależności.
6. Odbiór. Szkolenie zespołu, dokumentacja i dopiero po Waszej akceptacji wyłączenie starego środowiska.

Trzy rzeczy, które psują migracje

Brak planu na pocztę wychodzącą. Bez poprawnych wpisów SPF, DKIM i DMARC wiadomości z nowego środowiska lądują w spamie u kontrahentów. Ustawiamy je przed przełączeniem, nie po pierwszej reklamacji.

Uprawnienia przeniesione jeden do jednego. Jeśli na starym serwerze wszyscy mieli dostęp do wszystkiego, przeniesienie tego bałaganu do chmury robi z niego problem widoczny z internetu. Migracja to najlepszy moment na uporządkowanie dostępów.

Brak kopii zapasowej po migracji. Microsoft odpowiada za dostępność usługi, nie za to, że ktoś skasował folder w marcu. Kopia zapasowa danych w chmurze to osobna usługa i mówimy o niej przy projekcie, a nie po roku.

Ile to kosztuje w praktyce

Rynkowe wyceny migracji do Microsoft 365 mieszczą się zwykle w przedziale od 5 000 do 15 000 zł, a przy większych projektach z serwerami rosną znacznie wyżej. Nasza kotwica, 4 900 zł netto za biuro do dwudziestu osób, to dolna granica tego przedziału, bo liczymy samą pracę: dwa i pół dnia inżyniera bez licencji i bez zasobów, które kupujecie u Microsoftu na siebie.

Serwery i aplikacje wyceniamy osobno, po inwentaryzacji. Utrzymanie środowiska po migracji opisaliśmy przy administracji chmurą.

Dokąd migrujemy i czym to opisujemy

Poczta i pliki idą zwykle do Microsoft 365, bo tam jest pakiet biurowy, z którego firma i tak korzysta. Serwery i aplikacje najczęściej lądują na AWS albo Google Cloud: przy nich automatyzacja i przewidywanie rachunku wychodzą nam najlepiej. Azure bierzemy tam, gdzie tożsamość stoi na Active Directory i przewaga wspólnego logowania przeważa nad resztą.

Nowe środowisko od pierwszego dnia opisujemy w Terraformie, żeby dało się je odtworzyć poleceniem, a nie z pamięci. Szczegóły przy infrastrukturze jako kodzie.

Treść sprawdzona i zaktualizowana: 30 lipca 2026