Przy okazji rozmów dotyczących wdrożenia intranetu pojawia się pytanie odnośnie migracji aplikacji, które klienci już mają w poprzedniej wersji SharePoint – czy możemy taką migrację przeprowadzić w ramach projektu oraz w jaki sposób do tego podejść.
Ogólna odpowiedź brzmi oczywiście „TAK”, ale wiadomo, że diabeł tkwi w szczegółach. Klienci mówiąc o migracji aplikacji SharePoint’owej mają na myśli przeniesienie logiki aplikacji, jej struktur danych oraz samych danych z istniejącego środowiska operacyjnego do nowego środowiska, zazwyczaj modyfikując „przy okazji” niektóre funkcjonalności. To, jaką pracę trzeba przy tej migracji wykonać, zależy od samej aplikacji oraz różnic pomiędzy środowiskami. Najczęstsze przypadki migracji to:
- Zmiana technologii, np. z SharePoint 2007/2010 do 2013
- Zmiana technologii oraz środowiska, np. z SharePoint 2010 do SharePoint Online 2013
W obu powyższych przypadkach zazwyczaj niezbędne jest przepisanie aplikacji, aby uwzględnić zmiany funkcjonalne pomiędzy wersją SharePoint 2010 a 2013, zaś jeszcze większe różnice w funkcjonalnościach platformy widać pomiędzy SharePoint 2013 (on-premise) a SharePoint Online 2013 (cloud). Złożoność aplikacji wytwarzanych na platformę SharePoint może się ogromnie różnić – można je podzielić na kilka podstawowych klas:
- Rozwiązania wykorzystujące elementy bazowe SharePoint „z pudełka” – przeważnie listy i biblioteki dokumentów oraz wbudowane składniki Webpart i elementy programistyczne javascript. Takie rozwiązania dość dobrze można przenieść do SharePoint 2013, ewentualne prace programistyczne dotyczą modyfikacji javascript w zakresie dostępu do obiektów SharePoint oraz elementów strony.
- Aplikacje osadzane w SharePoint, ale nie wykorzystujące funkcjonalności i usług SharePoint. Przeważnie są to aplikacje napisane w technologii .NET odwołujące się do własnych baz danych, osadzone w interfejsie portalu. Takie rozwiązania są najłatwiejsze do migracji, ponieważ większość aplikacji jest od Sharepoint’a niezależna i nie trzeba jej przepisywać.
- Aplikacje zawierające dostosowania programistyczne i komponenty firm trzecich. Jest to najbardziej złożony i ryzykowny przypadek, ponieważ każdy z komponentów programistycznych wymaga przeniesienia do nowej wersji SharePoint aby zapewnić równoważne działanie. W przypadku wykorzystywania komponentów firm trzecich należy uzyskać informację czy jest dostępna wersja komponentu dla SharePoint 2013 oraz w jaki sposób może przebiegać migracja.
Kiedy migrować
Dla kogoś, kto nie zna aplikacji, procesu jaki wspiera oraz szczegółowych wymagań, jakie miała spełniać, taka migracja nie różni się niczym od wytworzenia nowej aplikacji oraz przeniesienia danych do nowego środowiska. Pojawia się więc pytanie – po co to robić? Przecież migracja aplikacji w dosłownym tego słowa znaczeniu (z zachowaniem dotychczasowej funkcjonalności) nie tworzy nowej wartości biznesowej, a kosztuje konkretne pieniądze, zatem sama w sobie nie ma uzasadnienia biznesowego (pomijam oczywiste kryterium konsolidacji farm, czyli zmniejszenia liczby używanych licencji, okoliczności wynikające z zawartych umów z kontrahentami oraz nieoczywiste uzasadnienia „propagandowe” czy wizerunkowe).
Argumentacja ZA migracją mają uzasadnienie biznesowe wyłącznie w przypadku planowanego wdrożenia nowych rozwiązań w nowej wersji lub nowym środowisku (cloud) SharePoint, a co za tym idzie:
- Wykorzystania dotychczasowej infrastruktury IT na cele nowej wersji SharePoint – utrzymywanie środowiska ze „starymi aplikacjami” i dodanie środowiska w nowej wersji jest kosztowne i podnosi złożoność infrastruktury informacyjnej, zatem logicznym krokiem jest dążenie do posiadania jednego środowiska;
- Wykorzystania możliwości dawanych przez nową wersję platformy w „starych” aplikacjach.
Jest jeszcze argument za migracją aplikacji SharePoint, który ma sens także wtedy, gdy nie planujemy wdrożenia nowych rozwiązań. Jest to chęć zlikwidowania części dotychczasowej infrastruktury IT w celu redukcji kosztów związanej z jej utrzymaniem. W takim przypadku można planować decyzję o migracji do SharePoint Online 2013 dla samych oszczędności związanych z utrzymaniem infrastruktury IT oraz możliwości oferowanych przez Office 365. Jednak tego rodzaju migracja w przypadku posiadania rozbudowanych programistycznie rozwiązań jest najtrudniejsza z powodu istotnych różnic w podejściu do tworzenia aplikacji w poprzednich wersjach SharePoint a podejściu wymaganym przez SharePoint Online 2013.
Natomiast argumentacja PRZECIW migracji dotyczy przede wszystkim niekorzystnej relacji korzyści do ceny. Przenoszenie aplikacji do nowej technologii, aby uzyskać tą samą funkcjonalność, może mieć sens wyłącznie w przypadku, gdy koszt takiej operacji jest niski.
Podejście do migracji
Dla Zamawiającego migrację aplikacji podejściem idealnym jest projekt fixed-price, w którym całą odpowiedzialność za powodzenie przedsięwzięcia bierze wykonawca i daje na to stałą cenę. Ta cena nie powinna być zbyt wysoka, bo jak wspominałem wcześniej migracja daje niewiele wartości dodanej. Dodatkowo wykonawca powinien sobie samodzielnie zinwentaryzować aplikację, żeby zobaczyć co ona robi i ile zajmie jej migracja. Tego rodzaju projekty mają szansę realizacji tylko przy prostych aplikacjach (Klasa 1 – funkcjonalności z pudełka, minimalna liczba dostosowań programistycznych) przy jednocześnie dużej skali całej migracji. Tylko wtedy wartość projektu jest na tyle duża, a ryzyko na tyle ograniczone, że Wykonawca może sobie pozwolić na jego podjęcie, zaś relacja wartości do ceny może być akceptowalna dla Zamawiającego. W praktyce sytuacja taka występuje rzadko, dlatego migracja takich aplikacji jest realizowana głównie na podstawie specyfikacji/wizji rozwiązania w ramach większego projektu wdrożeniowego dającego odpowiednie „zaplecze” nowej wartości biznesowej będące uzasadnieniem całego projektu. Tą nową wartością nie zawsze musi być wsparcie nowych obszarów biznesowych – czasami jest nim podporządkowanie istniejących aplikacji nowej architekturze informacyjnej w celu poprawienia zarządzalności.
Dla Wykonawcy podejściem idealnym jest projekt time-and-material, w którym całą odpowiedzialność za powodzenie przedsięwzięcia bierze Zamawiający, zaś Wykonawca daje specjalistów, którzy mogą opracować możliwe kierunki działań i oszacować koszty (ale nie odpowiadać za możliwe komplikacje wynikające z braku pełnej wiedzy o szczegółach działania migrowanej aplikacji czy o problemach z jej funkcjonowaniem). Takie podejście spotykane jest znacznie częściej, ponieważ stawki za pracę specjalistów w modelu time-and-material nie zawierają premii za ryzyko ponoszone przez Wykonawcę a także nie musi on zakładać żadnych rezerw na poczet niespodzianek, które mogą wyniknąć w trakcie migracji. To także pozwala uzyskać rozsądna relację korzyści do ceny.
Wniosek jest taki, że migracja złożonych i kluczowych rozwiązań powinna być realizowana w podejściu fixed-price przy okazji ich przebudowy lub rozbudowy funkcjonalnej, ponieważ to podejście jest bezpieczniejsze dla Zamawiającego i daje odpowiednią relację wartości do ceny. Analogicznie migracja niekluczowych i prostych rozwiązań powinna być realizowana w podejściu time-and-material, ponieważ ryzyko przyjmowane na siebie przez Zamawiającego jest niewielkie, a redukcja ceny wynikająca z braku ryzyka Wykonawcy jest istotna. Przypadki przeciwne mogą skończyć się boleśnie zarówno dla Zamawiającego jak i Wykonawcy, dlatego zdarzają się rzadko – zwykle wtedy, gdy migracja jest realizowana przez firmy-kamikaze z dużą tolerancją ryzyka po to by zdobyć nowego klienta jednocześnie mając niewiele do stracenia (np. firma krótko istnieje na rynku, ma podwykonawców na których przenosi ryzyko itp.), albo przez autora migrowanej aplikacji, który ma pełną wiedzę o zasadach jej działania i jego ryzyko jest istotnie mniejsze.
[:]