Niezależnie od tego, czy podejmujemy się migracji do chmury sami, czy z pomocą dostawcy tej usługi, możemy wpaść w pułapkę kilku najczęstszych błędów. Inżynierowie MAIN Data Center podpowiadają, jak ich uniknąć i na co warto zwracać uwagę podczas przenoszenia firmowych systemów, aplikacji i danych do popularnego cloud.

W skrócie dla zabieganych

·        Migracja 1:1 w większości przypadków jest błędem i uniemożliwia pełne wykorzystanie możliwości chmury.

·        Przed przeniesieniem się do chmury należy wykonać audyt – bez odpowiedniego rozpoznania możemy narazić się na wysokie koszty utrzymania nowego środowiska.

·        Najszybsza migracja to nie zawsze najlepsza migracja. Długość tego procesu należy kontrolować, ale warto też zaufać doświadczeniu firmy wykonującej migrację.

·        Podstawą dobrej migracji jest komunikacja z dostawcą chmury i stała wymiana informacji.

·        Jak w każdej sytuacji – bez kopii zapasowych ani rusz.

·        Podpisując umowę warto upewnić się co do warunków jej ewentualnego zakończenia.

Błąd 1: Jak migracja, to zawsze 1:1

Nie warto na siłę przenosić całego środowiska IT dokładnie 1:1, gdyż w wielu przypadkach będzie to błąd. Dlaczego? Przede wszystkim migracja to okazja do uporządkowania systemów IT, tak aby przenieść do chmury tylko to, z czego faktycznie firma korzysta. Jest to też idealny moment na wprowadzenie ulepszeń i aktualizacji - nawet jeśli wszystkie aktualne systemy są potrzebne, to często można je zbudować lub ułożyć w sposób, który zapewni bardziej optymalne ich funkcjonowanie, zmniejszając całkowity koszt usługi.

Ponadto, w przypadku przenosin ze środowiska fizycznego (on-premise) do chmury musimy pamiętać, że często rządzi się ona innymi prawami. Wirtualizacja zapewnia bowiem optymalne wykorzystanie sprzętu fizycznego (serwery), wysoką dostępność i łatwość uruchamiania nowych systemów. Jeśli dążymy do stworzenia wydajnego i bezpiecznego środowiska IT, to migracja do chmury stwarza ku temu doskonałą okazję.

Błąd 2: Działajmy szybko, bez audytu

Z pierwszym błędem najczęściej łączy się brak audytu środowiska przed migracją. Brakuje weryfikacji, czy wszystkie elementy, które chcemy przenieść są potrzebne i wykorzystywane. Może okazać się, że z 10 serwerów, które posiadamy, 5 jest testowych i od dawna ich nie używamy. W takim przypadku nie warto ich wszystkich migrować, a zamiast tego można postawić jedną, wydajną maszynę testową na przyszłe potrzeby.

Audyt weryfikuje nie tylko parametry migrowanych maszyn, i systemów, ale też:

·        Co jest na nich zainstalowane i jak działa od strony użytkowników wewnętrznych (pracownicy) i zewnętrznych (klienci),

·        Czy aktualne środowisko IT jest wykorzystywane w optymalny sposób (nowe rozwiązanie w chmurze może przyspieszyć i ułatwić jego działanie),

·        Jaki jest status licencji oprogramowania – czy posiadane licencje można uruchomić na środowisku chmurowym, czy potrzeba nowych (wiele firm – np. Microsoft, VMware, Veeam rozróżniają licencje na systemy fizyczne i zwirtualizowane).

Bez audytu migracja do chmury nie przyniesie firmie tylu korzyści, ile mogłaby. W niektórych przypadkach może też wręcz generować nadmierne koszty. Dlatego też przenosząc się do chmury nie należy pomijać tego etapu i zamiast tego egzekwować jego rzetelne wykonanie przez dostawcę usług cloudowych.

Błąd 3: Migracja na wczoraj

Warto pamiętać, że firma realizująca migrację może podać orientacyjny czas potrzebny na przeniesienie środowiska dopiero po audycie, gdyż dopiero wtedy posiada dane pozwalające na taką estymację. Kluczowym słowem jest tutaj „orientacyjny” - nigdy nie wiadomo, czy nie okaże się, że pojawił się problem techniczny, którego nie udało się wyłapać podczas ramach przygotowań do migracji.

Co więcej, jeśli dostawca przedstawia konkretne powody, dla których warto zwolnić tempa i przyjrzeć się czemuś bliżej, to warto go posłuchać – to profesjonaliści. Dlatego najczęściej czas migracji podawany jest jako trochę dłuższy, zakładając margines czasowy, aby projekt zakończył się zgodnie z planem nawet w przypadku nieprzewidzianych utrudnień.

Nie warto wymuszać na dostawcy chmury pośpiechu, gdy nie jesteśmy w „podbramkowej” sytuacji, np. bieżące środowisko zostanie wyłączone przez aktualnego dostawcę, jeśli nie zmigrujemy się w ciągu kilku dni.

Tutaj warto zaznaczyć, że profesjonalni dostawcy w większości przypadków są w stanie pomóc firmom nawet w takich “podbramkowych” sytuacjach. Sprawdź, jak zrobił to MAIN https://main.pl/iaas-dla-branzy-fintech-case-study-turbine-analytics/

Błąd 4: Po co rozmawiać z dostawcą?

Już poprzedni punkt pokazał nam, że bez dialogu między migrującą się firmą i dostawcą usług chmurowych rodzi się wiele błędów i problemów, których można uniknąć.

Stały kontakt pozwala nam świadomie obserwować proces migracji, nawet gdy:

·        Nie mamy osoby technicznej posiadającej wiedzę o technologiach chmurowych,

·        Nie korzystamy z usług innej firmy, która kontroluje pracę dostawcy (założenia, proces migracji i jej przebieg).

Jakich informacji powinniśmy wymagać od dostawcy:

·        Dokładny plan migracji,

·        Wnioski z audytu - co dostawca znalazł, co zaleca w migracji najważniejszych zasobów i utrzymaniu ich dostępności podczas procesu,

·        Czy wystąpią przestoje związane z migracją, a jeśli tak, to jak długie i kiedy,

·        Przewidywany termin rozpoczęcia i zakończenia migracji.

Znajomość terminu migracji jest szczególnie istotna, jeśli posiadamy już subskrypcyjną usługę chmurową – warto jest wtedy dokonać migracji w połowie miesiąca. Korzystamy wtedy z opłaconej subskrypcji i mamy czas na sprawdzenie, czy migracja zakończyła się sukcesem, a w przypadku znacznych problemów, możemy kontynuować korzystanie z poprzedniej usługi.

Jeśli od samego początku dostawca nie chce być z nami w dialogu i przedstawia nam bardzo skąpe informacje, powinna natychmiast zapalić się nam czerwona lampka. Warto wówczas rozważyć wybór innej firmy do przeprowadzenia migracji.

Błąd 5: Nie potrzebujemy kopii zapasowych

Aktualne kopie zapasowe swoich najważniejszych danych należy mieć zawsze - proces migracji do chmury nie jest tutaj wyjątkiem. Mimo, że przenosimy się z jednego środowiska na drugie - czyli jest moment, w którym nasze dane znajdują się w dwóch miejscach - warto i tak posiadać backup.

W rzadkich sytuacjach, gdy nie możemy polegać na obecnym środowisku, a nowe nie jest jeszcze gotowe, kopie zapasowe umożliwiają nam przywrócenie najważniejszych usług biznesowych w innym miejscu.

Więcej o backupie przeczytasz w Strefie Eksperta i Wiki MAIN:

·        Backup-as-a-Service, czyli dane archiwizowane w chmurze (https://main.pl/backup-danych-w-chmurze)

·        Business Continuity: Ciągłość biznesowa dzięki rozwiązaniom IT (https://main.pl/business-continuity-ciaglosc-biznesowa-dzieki-rozwiazaniom-it)

·        Backup i chmura – odpowiedź na potrzeby branży medycznej (https://main.pl/backup-i-chmura-dokumentacja-medyczna)

·        Jakie są rodzaje kopii zapasowych? (https://main.pl/wiki/kopie-zapasowe-rodzaje)

·        Zasada 3-2-1 w backupie (https://main.pl/wiki/zasada-3-2-1)

Błąd 6: Wszyscy dostawcy grają fair

Exit plan definiuje, jak wygląda rezygnacja z usługi chmurowej w przypadku zakończenia współpracy z dostawcą, decyzji o przeniesieniu się do innego dostawcy bądź własnej infrastruktury. Powinny znaleźć się w nim przede wszystkim informacje dotyczące czasu dostępnego na przeniesienie danych i systemów, warunków rezygnacji oraz potencjalnych kosztów z nią związanych.

Posiadanie exit planu pozwala uniknąć sytuacji, w których:

·        Mamy trudność z wyeksportowaniem naszych danych z chmury,

·        Ponosimy dodatkowe, wysokie koszty, np. związane z transferem,

·        Nie mamy gwarancji, że nasze dane zostaną całkowicie i bezpiecznie usunięte ze wszystkich ośrodków, w których były przetwarzane.

Już w momencie podpisywania umowy i rozpoczynania procesu migracji należy wiedzieć, co się stanie, jeśli będziemy chcieli wyjść z danej chmury, i upewnić się, że proponowane warunki są dla nas odpowiednie

Migrujesz się do chmury? Zwróć uwagę:

·        Czy firma migrująca ustaliła z nami dokładny plan, jak będzie przebiegała migracja i ile potrwa,

·        Czy poinformowała o wszystkich planowanych przerwach w dostawie usług,

·        Jakie SLA (czas reakcji na problemy) zostało zapisane w umowie,

·        Czy umowa zawiera exit plan,

·        Czy w umowie figuruje ostatni etap migracji, czyli utrzymanie - kto jest za nie odpowiedzialny, jak będzie przebiegać i ile kosztować,

·        Czy nie ma ukrytych kosztów lub niezrozumiałych zapisów (np. początkowa konfiguracja jest tania, ale może się okazać, że kolejne serwery są dwa razy droższe).

Materiał Promocyjny