Działania migracyjne można podzielić na: procesowe (w tym przypadku o charakterze technicznym, bardziej standaryzowane) i projektowe (ukierunkowane organizacyjnie, bardziej unikatowe). Możemy powiedzieć, że te pierwsze zorientowane są na cele bieżące, a z uwagi na większą rutynowość i stabilniejsze relacje międzyludzkie, wiążą się z mniejszymi ryzykami i słabszym zaangażowaniem kierownictwa. W trybie projektowym (konsultingowym) mamy z kolei do czynienia ze strategicznymi celami, a zatem większym ryzykiem i częstszymi konfliktami, co wymaga zwiększonej uwagi kierownictwa.

Podane przykłady procesowe można odnieść, na przykład, do sfery bazodanowej:

- uaktualnienie wersji oprogramowania (update)

- nowa wersja oprogramowania (upgrade)

- konsolidacja (migracja bez zmian wersji oprogramowania)

- klastry (wymagają specjalnych modeli migracyjno/konsolidacyjnych).

Odrębne zagadnienia techniczne to: możliwości migrowania w trybie on-line (podczas pracy aplikacji) i off-line (z jej zatrzymaniem), budowanie środowisk testowych (dobre środowisko testowe to jedno z większych wyzwań stających przed zespołem migracyjnym) i strategie wirtualizacyjne: od typowo technicznych, jak partycjonowanie czy emulacje, aż do zorientowanych biznesowo, np. komodytyzacja (commodity, infrastruktura standaryzowana dostępowo/rozliczeniowo).

W sferze działań w typowym trybie projektowym można wyróżnić te o niższym lub wyższym stopniu niepewności. Podział jest relatywny i w każdym przypadku musimy liczyć się ze znacznym ryzykiem projektowym. Może się też zdarzyć, że bardziej standaryzowane migracje danych okażą się trudniejsze niż integrowanie podsystemów satelitarnych skojarzonych z ERP (może być ich wiele i bardzo zróżnicowanych, jeśli chodzi o cechy rzutujące na powodzenie migracji).

Zdefiniowane cele strategii migracyjnej wymagają z kolei przełożenia ich na metody (np. zwinne, agile), modele (np. COBIT, ISO, PRINCE2) i narzędzia (np. kwestionariusz Thomsetta, lista zagrożeń McConella) wdrażania ładu korporacyjnego (IT Governance). Jeśli wskażemy przy tym dodatkowo na trendy rozwojowe webowych platform programowych, to nieuchronnie nasuwają się tu skojarzenia z modelem SOA (Service Oriented Architecture). Model ten łączy w sobie dwa, pozornie sprzeczne, elementy organizacyjne: centralizację i decentralizację, czyli architekturę integrującą rozproszone usługi. Charakterystyczne dla SOA jest zdecydowane wyjście poza czysto narzędziowy wymiar inżynierii softwarowej i uwzględnienie pozatechnicznych aspektów gospodarczych aplikacji IT. W szczególności zakłada się, że ze specyfiki modelu biznesowego można wyprowadzić architekturę wspomagającego go systemu software’owego. Postulat to nienowy, ale dopiero dzisiaj mamy większe możliwości jego praktycznej realizacji.

Dla ilustracji obszerności omawianych zagadnień wystarczy tylko wskazać na problematykę wdrażania systemu zarządzania danymi referencyjnymi MDM (Master Data Management) (zobacz: Computerworld nr 32/866 z 7 września 2009, "Spójny obraz“). Wymieńmy zatem jedynie trzy powtarzające się problemy techniczno-organizacyjne podczas migracji interfejsów:

- konwersje typów danych (np. numeryczno/alfanumeryczne)

- różnice długości pól (np. za krótkie pole numeru produktu)

- różnice w ilości pól rekordów (np. brak pól rezerwowych).

Już to wystarczy do zilustrowania skali problemu.