Datamigrering: den mest undervurderte delen av et systembytte

Når et gammelt system skal erstattes av et nytt, går oppmerksomheten nesten alltid til det nye: funksjonene, grensesnittet, mulighetene. Men det som oftest sprenger tidsplanen, er noe helt annet, nemlig å få med seg de eksisterende dataene. Datamigreringen behandles som en teknisk detalj på slutten av prosjektet og viser seg gang på gang å være det vanskeligste av alt. Her ser du hvorfor den blir undervurdert, og hvordan du planlegger den som et eget delprosjekt, slik den fortjener.

Hvorfor migreringen sprenger tidsplaner

Forklaringen ligger ikke i selve flyttingen, som er teknisk rutine, men i hvilken forfatning dataene er i. Gamle data har nesten alltid samlet på seg problemer gjennom årene: duplikater av samme kunde, tomme felt som burde ha vært fylt ut, samme opplysning i ulike formater på ulike steder og begreper som betyr én ting i én avdeling og noe annet i den neste.

Å flytte rene, velordnede data er enkelt. Det som tar tid, er å rydde, tolke og gjøre rotet forståelig først, og den delen er ikke med i den opprinnelige planen fordi ingen visste hvor ille det sto til før de begynte å se på det. Undervurderingen er altså innebygd: Man budsjetterer for flyttingen, men ikke for oppryddingen, og det er oppryddingen som er tung.

Datavask og duplikater er virksomhetens beslutning

Den vanligste og dyreste feilen er å gjøre datamigreringen til et rent teknisk spørsmål. Men de avgjørende beslutningene kan ikke IT-siden ta.

Er disse to kundeoppføringene samme person eller to forskjellige? Hvis en kunde har to motstridende adresser, hvilken gjelder? Skal en gammel kategori slås sammen med en ny? Slike spørsmål kan bare besvares av noen som kjenner virksomheten. Utviklerne kan gjennomføre (slå sammen, transformere, flytte), men de kan ikke avgjøre hva dataene betyr.

La derfor forretningssiden eie beslutningene om vask og duplikater, med teknologien som verktøy. I praksis betyr det å sette av tid fra folk som kjenner virksomheten, ikke bare fra utviklerne. Den tiden er lett å glemme i planleggingen og umulig å klare seg uten i gjennomføringen.

Testmigreringer med verifisering

Ingen endelig datamigrering bør skje uten at hele prosessen først er kjørt i et testmiljø og resultatet er kontrollert. En testmigrering avslører det som ellers først oppdages i drift, når det er som dyrest å rette.

Verifiseringen er minst like viktig som kjøringen. At migreringen «gikk gjennom», betyr ikke at dataene ble riktige. Poster kan i det stille ha forsvunnet eller blitt forvrengt. Ta derfor stikkprøver mot kildedataene og la virksomheten se på resultatet før den endelige overgangen. Å oppdage en feil i en testkjøring er billig. Å oppdage den når kundene allerede bruker det nye systemet, kan bli en krise.

Hvor mye historikk: Ikke alt trenger å flyttes

En stilltiende antakelse er at alle gamle data må følge med. Det gjør migreringen unødvendig tung og drar med seg gammelt rot inn i det nye systemet.

Mye historikk trengs sjelden aktivt. Ordrer fra ti år tilbake, avsluttede saker og inaktive kunder kan ofte arkiveres separat i stedet for å flyttes inn i det nye systemet, der de bare ville ha ligget og tynget. Bestem bevisst hvor mye som faktisk trengs fremover: Hva må brukerne ha tilgang til daglig, hva holder det å kunne finne frem ved behov, og hva kan lagres i et arkiv utenfor systemet?

Et smalere, ryddig datasett som flyttes inn, gjør migreringen raskere og det nye systemet lettere å leve med.

Et scenario: prosjektet som planla for dataene

Et selskap som byttet kundesystem, gjorde det motsatte av det vanlige: De behandlet datamigreringen som et eget delprosjekt fra start. Virksomheten fikk i oppdrag å gå gjennom og ta stilling til duplikatene, de kjørte tre testmigreringer med verifisering, og de bestemte at bare de siste årenes aktive data skulle flyttes inn, mens eldre data ble arkivert.

Migreringen ble den minst dramatiske delen av prosjektet nettopp fordi den fikk den oppmerksomheten den vanligvis ikke får. Et sammenlignbart selskap som overlot dataene til siste uke, måtte i stedet utsette lanseringen to ganger da rotet ble avdekket. Forskjellen var ikke flaks, men planlegging.

Skal dere bytte system og vil unngå at dataene blir det som velter tidsplanen, hjelper vi i Weapp gjerne til med å planlegge migreringen som et eget ledd i prosjektet, slik den fortjener. Ta kontakt med en beskrivelse av hva dere skal flytte.