Przejście do chmury bez działania na ślepo.

Aplikacja może zależeć od komponentów, które nie występują na pierwszej liście systemów: usług katalogowych, zaplanowanych zadań w tle, udziałów plikowych albo interfejsu zewnętrznego partnera. Takie powiązania są ustalane wspólnie z osobami odpowiedzialnymi. W ten sposób powstają grupy migracyjne, których komponenty są przenoszone razem albo celowo łączone ze sobą na okres przejściowy. Na kolejność wpływają wolumen danych, okna serwisowe i dostępność osób kontaktowych z działów biznesowych. Plan fal migracji odwzorowuje więc rzeczywiste procesy, a nie tylko listę systemów, które można technicznie przenieść.

Dla każdej grupy określa się odpowiedni sposób migracji. Część aplikacji można początkowo przenieść w dużej mierze bez zmian, inne wymagają dostosowania do środowiska docelowego. Dalsza modernizacja może mieć sens jako osobny krok, jeśli niepotrzebnie zwiększyłaby zakres przeniesienia. Decyzja uwzględnia ryzyko przejścia, późniejszą eksploatację i dostępne zasoby. Przed przeniesieniem sprawdza się środowisko docelowe, dostępy i wymagane połączenia, aby znanych warunków wstępnych nie trzeba było spełniać dopiero w przewidzianym oknie przełączenia.

W dniu przełączenia muszą być ze sobą zgodne stan danych, zmiany dostępów i testy biznesowe. Uzgodniony przebieg opisuje więc, kiedy kończy się praca w starym systemie, jakie dane są przenoszone i jakie testy odbywają się potem. Należą do tego również osoby kontaktowe i sposoby komunikacji. Uczestnicy muszą wiedzieć, kto ocenia problem i kto decyduje o dalszym postępowaniu. Techniczna dostępność jest przy tym tylko jednym z etapów sprawdzania. Aplikacja musi także móc realizować operacje istotne dla Państwa działalności biznesowej.

Wcześniej ustala się również, w jakich warunkach przełączenie należy przerwać albo wycofać. Powrót do starego systemu nie jest dla każdej aplikacji równie prosty, w szczególności jeśli w systemie docelowym powstały już nowe dane. Dlatego planowanie określa warunki i granice przewidzianej procedury. Pilotaż i testy służą do sprawdzenia założeń i usprawnienia przebiegu. Dopiero na podstawie tych wyników można wspólnie ocenić, czy kolejna fala migracji jest przygotowana, czy potrzebna jest jeszcze dodatkowa praca.

Po uruchomieniu produkcyjnym mogą wyjść na jaw nowe kwestie: zmienione obciążenie, brakujące uprawnienia albo procesy, które w testach nie były w pełni widoczne. Takie kwestie są w uzgodnionej fazie stabilizacji rejestrowane, oceniane i rozwiązywane. Przekazanie do eksploatacji obejmuje konfigurację, dostępy, monitorowanie i znane zadania pozostałe do wykonania. Osoby odpowiedzialne za Państwa aplikację potwierdzają, że nadaje się ona do użytku biznesowego. Obowiązki techniczne i organizacyjne są dokumentowane w taki sposób, aby po zakończeniu projektu było jasne, kto reaguje na kolejne zgłoszenia.

Stare systemy nie powinny potem działać dalej bez kontroli. Jednocześnie wycofanie z eksploatacji nie może usunąć żadnej wciąż potrzebnej zależności. Dlatego po odbiorze wspólnie ustala się, które zasoby trzeba wyłączyć, które dane zachować i które umowy dostosować. Plan wycofania z eksploatacji określa kolejność działań i zatwierdzenia. Dzięki temu podwójne koszty i otwarte zadania pozostają widoczne. Migracja kończy się uporządkowanym przekazaniem i uzgodnionymi dalszymi działaniami, a nie samym stwierdzeniem, że dane znajdują się teraz w innym miejscu.