Gdy słyszymy słowo "migracja", zazwyczaj od razu odnosimy to do transferu ludzi w społeczeństwie. Niektórzy mają w pamięci znanych Polaków, którzy w czasie zaborów lub wojny znaleźli się poza granicami naszego kraju i tam działali. Innym z kolei od razu w głowie rozbrzmiewa "eeeeemiiiiigrowałeeeem" z piosenki "Jolka, Jolka pamiętasz" Budki Suflera. Jednak dzisiaj będziemy uderzać w zupełnie inne nuty, a mianowicie melodie związane z informatyką, gdyż tam migracja jak najbardziej też występuje.

To słowo w naszej dziedzinie nie jest niespotykane, a co więcej, powtarza się dość często i nie chodzi tutaj tylko o wyjazdy programistów do ciepłych krajów, aby tam uskuteczniać home office. Co więcej, za każdym razem "migracja" może wystąpić w innym kontekście. Właśnie te dzisiaj sobie omówimy, pokazując przy okazji, jaka głębia kryje się w pewnych zagadnieniach, której osoby nietechniczne nie zawsze się spodziewają.

Migracja danych

To kontekst, który najczęściej pojawia się w rozmowach software house'u ze zleceniodawcą. Wynika to z faktu, iż oprócz nowych, świeżych projektów, istnieją też takie, które mają zastąpić system używany do tej pory przez klienta. To oznacza, że użytkownicy systemu posiadają już jakieś dane i na pewno nie będą zadowoleni z ich utraty, gdyż będą im potrzebne do pracy już w nowym oprogramowaniu. A zatem te dane trzeba przenieść, czyli zmigrować.

Nie jest to takie proste zagadnienie. Każdy (lub prawie każdy) system przechowuje dane w bazie danych o schemacie, który na pewno różni się od schematu, który będzie w nowym systemie IT. Nie chodzi tutaj tylko o układ tabelek (jeśli mówimy o relacyjnych bazach danych), ale też o sposób przechowywania informacji katalogowych, oznaczenia typów i inne specyficzne dane, które są zakodowane w określony sposób. Niejednokrotnie widzieliśmy również sytuacje, w których wartości, jakie w nowym oprogramowaniu powinny być unikalne, w dotychczasowych systemach były dość swobodnie przechowywane. Oczywiście, istnieją przypadki, w których przeniesienie takich informacji zachodzi dość sprawnie, ale są to wyjątki, a wręcz "jednorożce".

O wiele częściej zachodzi potrzeba opracowania mapowania pomiędzy dwiema bazami danych, ustalenia, które dane faktycznie muszą być przeniesione, a które można pominąć (nie zawsze jest potrzeba migracji wszystkich wartości) oraz napisania skryptu, który to zrobi w powtarzalny sposób (lub skorzystania z istniejących rozwiązań). Często potrzebne są też konsultacje z konstruktorami poprzedniego systemu w celu upewnienia się, jak interpretować pewne zapisane informacje, szczególnie, jeśli są one niespójne lub przechowywane w sposób "jedyny w swoim rodzaju" (np. typy zapisane poprzez jednoliterowe skróty znane tylko osobom mającym dostęp do starego kodu). Co więcej, wbrew obiegowej opinii, migracja zwykle zachodzi więcej niż raz - ten proces często musi odbywać się kilkukrotnie lub o różnym zakresie:

• migracja pełna lub częściowa (np. tylko pewnych danych),
• migracja od początku lub tylko nowych danych - tutaj rada, aby od razu to przemyśleć, gdyż gotowość ograniczenia zakresu migracji bardzo wpływa na strukturę skryptu migrującego,
• migracja testowa, sprawdzająca "jak to będzie" po migracji właściwej,
• migracja właściwa, po której w pełni wdrażany jest nowy system,
• migracja uzupełniająca, kopiująca dane, które pojawiły się od czasu migracji właściwej.

Sam proces migracji to nie tylko przeniesienie danych - należy również pamiętać o plikach (np. zdjęciach przedmiotów w sklepie internetowym czy avatarów użytkowników), które często są zapisywane w bardzo zindywidualizowany sposób i pliki mają przeróżne nazwy, czasami wynikające ze sposobu ich wyszukiwania w systemie (np. zdjęcia przedmiotu o ID = 120 zawsze będą w folderze upload/item/120). Oczywiście, najlepiej jest przygotować system plików w nowym systemie tak, aby skopiowanie zbiorów dyskowych było bezbolesne, ale zazwyczaj nie jest to możliwe. Po pierwsze, nie zawsze stara struktura jest dobra i warto ją zachować za wszelką cenę. Po drugie, plików jest zazwyczaj tak dużo, że same przenosiny trochę trwają ze względów stricte "fizycznych". Po trzecie, zazwyczaj nikt o tym nie myśli na początku. I tutaj na chwilę się zatrzymamy.

Do pewnego stopnia zrozumiałe jest pomijanie tematu migracji na starcie, gdyż na początku wszyscy są zaaferowani powstającym nowym systemem i tym, aby prezentował się lepiej oraz umożliwiał więcej niż starsze oprogramowanie. Problem jednak w tym, że takie podejście może spowodować wiele nieporozumień - klient najczęściej myśli, że migracja danych to szybki proces, o którym nie trzeba za dużo mówić. Prosi też o wycenę tego elementu bez zaprezentowania obecnych struktur i sposobu przechowywania plików, co sprawia, że programiści najczęściej szacują taką pracę w ciemno, co w przeważającej liczbie przypadków (a właściwie prawie zawsze) oznacza niedoszacowanie zarówno budżetu, jak i czasu. A dlaczego nie ma dostępu? Bywa, że ze względów prawnych - klient jeszcze nie zdecydował się na współpracę, gdyż musi poznać wycenę i jest mniej chętny, aby na tym etapie udostępniać wrażliwe elementy swojej infrastruktury lub informacje. Oczywiście, to wszystko można załatwić i podpisać odpowiednie formalności, a programiści nie pójdą z tym na giełdę w darkwebie, natomiast ten etap jest na tyle specyficzny, że software house'owi też zależy na szybkim oszacowaniu pracochłonności, aby sam proces wyceny był efektywny. Także polecamy również nad tym tematem pochylić się na początku, a nie tylko zaznaczyć, że on jest i kiedyś nadejdzie.

Nie zawsze przenoszenie danych dotyczy migracji pomiędzy bazami danych - bywa również tak, iż informacje klienta znajdują się w:

• w innych systemach informatycznych (niebędących pod kontrolą zleceniodawcy),
• w arkuszach kalkulacyjnych (lub plikach CSV),
• w plikach tekstowych,
• w mailach.

Oczywiście, ostatni punkt to ekstremum, aczkolwiek kiedyś niemalże się z tym zetknęliśmy. Za to pierwsze dwa źródła danych (a szczególnie drugi) są bardzo częste. Klient nie zawsze przechowuje informacje w systemie - bywa, że są one zbierane poprzez współdzielone arkusze i właśnie nieefektywność takiego magazynowania sprawia, iż potrzebny staje się nowy system IT. Nierzadko również obecnie wykorzystywany system zewnętrzny traci wsparcie lub przestaje być wystarczający, co staje się impulsem do zaprojektowania swojego oprogramowania. Jednak istniejące dane trzeba wydobyć i tutaj wszystko zależy od tego, jak do tego podchodzi obecny dostawca oprogramowania. Z naszych doświadczeń wynika, że najczęściej mają do tego przygotowane procedury i eksportery. Ale trochę przygód zawsze jest.

Migracja wewnątrz aplikacji

Dawno już minęły czasy, w których zmiana schematu bazy danych wykorzystywanego przez aplikację wymagała ręcznego przygotowywania zapytań SQL i ich odtwarzania przez innych programistów. Od wielu lat frameworki posiadają funkcje migracji, która polega na wykorzystaniu wewnętrznych, zwykle wygodnych metod do np. dodania kolumny czy wprowadzenia stałych danych. Co jednak ważniejsze, tego typu podsystemy kontrolują również wprowadzanie zmian w różnych środowiskach i u różnych programistów poprzez zastosowanie tylko tych modyfikacji, które na danej maszynie jeszcze nie zostały wykonane, a także wspierając wycofywanie ich. To sprawia, że praktycznie jedną komendą w terminalu można zaktualizować swoją bazę danych i nie przejmować się szukaniem wpisów, których jeszcze nie mamy u siebie - moduł migracji w frameworku zrobi to za nas.

Tutaj warto wspomnieć, że zazwyczaj czymś innym jest migracja, a czymś innym tzw. seedowanie. W przypadku tego pierwszego mówimy właśnie o schemacie bazy danych, a więc ramach, w których ona działa. Natomiast seedy najczęściej odpowiadają za wprowadzanie stałych danych, które musi posiadać baza danych konkretnej aplikacji w każdym środowisku, aby móc normalnie działać i oferować wszystkie funkcje. Do tego dochodzi jeszcze coś, co po angielsku nazywa się fixtures (swoim zwyczajem nazywamy to "fiksturami"), a co jest pakietem danych, których obecność w bazie musi być zapewniona np. przed uruchomieniem testów automatycznych.

Migracja pomiędzy komputerami

Gdy każdy człowiek dostaje nowy komputer, zazwyczaj czuje ekscytację - znowu wszystko będzie działać szybko, sprawnie, a w dodatku do dyspozycji są lepsze podzespoły i uaktualniony system. Jednak niedługo później taki użytkownik zdaje sobie sprawę, że aby kontynuować pracę, najczęściej musi przenieść wszystkie swoje dane i - co gorsza - zainstalowane programy. A to już bywa bolesne lub przynajmniej długotrwałe. Witajcie w piekle migrowania z komputera na komputer.

Oczywiście, trochę żartuję i przesadzam, jednak faktem jest, że przenosiny na nowy sprzęt wiążą się zazwyczaj z poświęceniem trochę czasu i nerwów na dostosowanie nowinki do swoich potrzeb. Tutaj bardzo dużo zależy od środowiska - czasem kończy się na ręcznym skopiowaniu plików i instalacji oprogramowania od nowa, a niekiedy sami producenci ułatwiają ten proces. Pod tym kątem (przynajmniej pod tym...) rewelacyjne są komputery Apple'a, które mają wbudowaną opcję migracji pomiędzy maszynami. Jednak istnieją również inne sposoby ułatwiające ten proces, takie jak skorzystanie z chmury czy klonowanie dysku. Warto też zdać sobie sprawę z tego, że nie zawsze warto wszystko przenosić jeden do jednego - kto nigdy nie miał nieporządku na swoim dotychczasowym komputerze i mówił sobie "posprzątam przy okazji przenosin na nowy" niech pierwszy rzuci kamieniem. Au, ale nie w oko.

W przypadku programistów przenosiny na nowy sprzęt powinny być wyjątkowe sprawne, gdyż niemal natychmiast powinni oni zacząć pracę - w końcu klienci nie będą czekali, aż koder skończy wszystko kopiować. Tym niemniej, z obecnie dostępnymi narzędziami nie jest to aż tak problematyczne, zwłaszcza, jeśli mamy dobrze przygotowane procedury konfiguracji stosu technologicznego lub po prostu korzystamy z konteneryzacji.

Migracja użytkowników

Bardzo ciekawy i głęboki temat, związany nawet nie tyle z realizacją oprogramowania, co ludzką psychologią. Załóżmy, że użytkownicy przez długi czas korzystali z jednego oprogramowania i teraz muszą lub mogą przenieść się na drugie. Ewentualnie producent danej aplikacji przygotował nową wersję interfejsu i musi opracować procedurę przeniesienia osób. W obu przypadkach mówimy o migracji użytkowników.

Dlaczego wspomnieliśmy tutaj o psychologii? Z perspektywy użytkownika ten proces nie jest łatwy - musi poznać nowy interfejs, odmienne zasady rządzące oprogramowaniem i styl pracy. To wszystko sprawia, że przestawienie się na nowy sposób działania zajmuje trochę czasu, a to automatycznie zniechęca niektórych do zmiany, o ile nie widzą wyraźnych korzyści. Szczególnie jest to odczuwalne w firmach mających mniejsze związki z informatyką, które dodatkowo do tej pory pracowały według określonych procedur, a teraz mają przenieść się na nowe oprogramowanie i nie spełnia ono wszystkich oczekiwań. Konkretnie jednego - nie jest starym oprogramowaniem, nie wszystko jest w tym samym miejscu i nie można klikać "na pamięć". To powoduje duże problemy i zwykłą niechęć, z którą mierzyć się muszą nie tylko producenci, ale też szefostwo takiej firmy, w których interesie też jest zachęcić do korzystania z nowinki.

To wszystko oznacza, że takie przenosiny nie zachodzą tylko w sferze technicznej - one muszą zajść równiez w sferze mentalnej. Jak najbardziej pomagają tutaj różne tutoriale i dobrze przygotowany system pomocy, porównujący oba systemy, jednak zazwyczaj nie jest to wystarczające. Aby przełamać strach lub niechęć do nowego systemu, potrzebne są:

• jasno wypunkowane korzyści, ale nie w biznesowy sposób typu "będziesz pracował efektywnie" - tutaj bardzo dobrze sprawują się argumenty w stylu "tego nie można było zrobić wtedy, a teraz jest to możliwe" lub "teraz zrobisz to łatwiej",
• szkolenia - ludzki przewodnik, pomagający przejść przez trudny okres migracji, jest skuteczniejszy niż tutoriale, choć to bardzo zależy od sytuacji i charakteru współpracy,
• wideotutoriale na konkretnych przypadkach - warto poznać najczęstsze obawy użytkowników lub problemy, z którymi muszą się zmagać i zaprezentować, w jaki sposób poradzić sobie z nimi w nowym systemie, a także... wyrazić współczucie,
• dodatkowe zachęty, nie zawsze materialne - w przypadku nowych odsłon systemów dostępnych w chmurze dla wielu użytkowników, można odnieść się do potrzeby użytkownika, który chce poczuć się potrzebny i ważny i zapewnić go, że będzie w ścisłym gronie testerów nowego rozwiązania, dzięki czemu zostanie wyróżniony na tle innych.

Oczywiście, każdy taki proces jest inny i wymaga innych rozwiązań. Czasem migracja nie wiąże się z żadnymi trudnościami, a czasem jest wręcz blokowana i mimo długotrwałych starań nie dochodzi do skutku z różnych przyczyn.

Migracja technologii

Wróćmy do kwestii technicznych. Skoro "migracja" to ogólnie przeniesienie obiektu pomiędzy dwiema lokalizacjami lub obszarami, to także przejście programistów na nową technologię można określić tym mianem. Zmiana stosu technologicznego to poważna sprawa, zwłaszcza, jeśli zachodzi wewnątrz ogranizacji, w której programiści, przyzwyczajeni do jednego pakietu rozwiązań, muszą poznać i nauczyć się nowego frameworka czy języka. Wiąże się to z czasem oraz wysiłkiem, który przez pewien czas utrudnia rozwój oprogramowania, choć w dalszej perspektywie ma przynieść korzyści. Dlatego tego typu zabiegi nie powinny być przeprowadzane bez dobrego planu oraz bez wyraźnych powodów, podobnie zresztą jak to ma miejsce przy przepisywaniu konkretnego oprogramowania.

O takiej migracji mówimy również w przypadku, kiedy programista zmienia pracę i trafia do zespołu, w którym musi pisać w nieznanym sobie frameworku. Nie jest to nic rzadkiego - gdyby programiści przenosili się pomiędzy zespołami, w których cały czas korzystają z jednego technologii, to zakres takich "przeprowadzek" byłby bardzo ograniczony, a poza tym perspektywy rozwoju byłyby mniejsze. Natomiast nie zmienia to faktu, że każdy nowy element stosu technologicznego (i to tak poważny jak biblioteka, framework czy nawet język programowania) to duża zmiana i konieczność adaptacji.

Podsumowanie

Jak widać, migracja w IT niejedno ma imię. Najważniejsza jest procedura przenoszenia informacji z jednego systemu informatycznego do drugiego, jednak nie jest to jedyny kontekst, w którym to słowo jest używane (zazwyczaj nie bez dodatkowych przekleństw). Także, jeśli znajomi programiści powiedzą Wam o tym, iż mają do czynienia z migracją, to zazwyczaj nie mają na myśli czynników socjologicznych i nie jest to zaproszenie do rozmowy o polityce czy przeprowadzce.

Pozdrawiam i dziękuję - Jakub Rojek.