Datamigrering: systemskiftets mest undervurderede del

Når et gammelt system skal erstattes af et nyt, går opmærksomheden næsten altid til det nye: funktionerne, brugerfladen, mulighederne. Men det der oftest sprænger tidsplanen, er noget helt andet, nemlig at få de eksisterende data med. Datamigreringen bliver behandlet som en teknisk detalje i slutningen af projektet og viser sig gang på gang at være det sværeste af det hele. Her kan du læse hvorfor den bliver undervurderet og hvordan du planlægger den som det selvstændige delprojekt den fortjener at være.

Derfor sprænger migreringen tidsplaner

Forklaringen ligger ikke i selve flytningen, som er teknisk rutine, men i dataenes tilstand. Gamle data har næsten altid samlet problemer op gennem årene: dubletter af den samme kunde, tomme felter der burde være udfyldt, den samme oplysning i forskellige formater forskellige steder og begreber der betyder én ting i én afdeling og noget andet i den næste.

At flytte rene, velordnede data er enkelt. Det der trækker tiden ud, er først at rydde op, fortolke og gøre rodet forståeligt, og den del kan ikke ses i den oprindelige plan fordi ingen vidste hvor slemt det stod til før de begyndte at kigge. Undervurderingen er altså indbygget: Man budgetterer med flytningen, men ikke med oprydningen, og det er oprydningen der er det tunge arbejde.

Datarensning og dubletter er forretningens beslutning

Den mest almindelige og dyreste fejl er at gøre datamigreringen til et rent teknisk spørgsmål. Men de afgørende beslutninger kan teknikken ikke træffe.

Er de her to kundeposter den samme person eller to forskellige? Hvis en kunde har to modstridende adresser, hvilken gælder så? Skal en gammel kategori lægges sammen med en ny? Den slags spørgsmål kan kun besvares af nogen der kender forretningen. Udviklerne kan udføre arbejdet (lægge sammen, omforme, flytte), men de kan ikke afgøre hvad dataene betyder.

Lad derfor forretningssiden eje beslutningerne om rensning og dubletter, med teknikken som værktøj. I praksis betyder det at afsætte tid fra folk der kender forretningen, ikke kun fra udviklerne. Den tid er let at glemme i planlægningen og umulig at undvære i gennemførelsen.

Testmigreringer med verifikation

Ingen endelig datamigrering bør ske uden at forløbet først er kørt i et testmiljø og resultatet gennemgået. En testmigrering afslører det der ellers først opdages i drift, hvor det er dyrest at rette.

Verifikationen er mindst lige så vigtig som kørslen. At migreringen “gik igennem”, betyder ikke at dataene blev rigtige: Poster kan ubemærket være gået tabt eller blevet forvansket. Tag derfor stikprøver mod kildedataene, og lad forretningen se på resultatet før go-live. At opdage en fejl i en testkørsel er billigt. At opdage den når kunderne allerede bruger det nye system, kan være en krise.

Historikkens omfang: Ikke alt skal med

En stiltiende antagelse er at alle gamle data skal med. Det gør migreringen unødigt tung og tager gammelt rod med ind i det nye system.

Meget historik er der sjældent aktivt brug for. Ordrer fra ti år tilbage, afsluttede sager, inaktive kunder: Den slags kan ofte arkiveres separat i stedet for at blive flyttet ind i det nye system, hvor det bare ville ligge og tynge. Beslut bevidst hvilket omfang der faktisk er brug for fremover: Hvad skal brugerne have adgang til dagligt, hvad er det nok at kunne finde frem ved behov, og hvad kan gemmes i et arkiv uden for systemet?

Et snævrere, renset datasæt der flytter ind, gør både migreringen hurtigere og det nye system lettere at leve med.

Et scenarie: projektet der planlagde for dataene

En virksomhed der skiftede kundesystem, gjorde det modsatte af det sædvanlige: De behandlede datamigreringen som et selvstændigt delprojekt fra starten. Forretningen fik til opgave at gennemgå og træffe beslutning om dubletterne, de kørte tre testmigreringer med verifikation, og de besluttede at kun de seneste års aktive data skulle flyttes ind mens ældre data blev arkiveret.

Migreringen blev projektets mindst dramatiske del, netop fordi den havde fået den opmærksomhed den normalt ikke får. En sammenlignelig virksomhed der lod dataene vente til sidste uge, måtte i stedet udskyde lanceringen to gange da rodet kom for dagen. Forskellen var ikke held, men planlægning.

Skal I skifte system og vil undgå at dataene bliver det der vælter tidsplanen, hjælper vi i Weapp gerne med at planlægge migreringen som den selvstændige opgave den bør være. Kontakt os med en beskrivelse af hvad I skal flytte.