Når et it-system skal udskiftes, opstår behovet for migrering af data fra det eksisterende system. Den umiddelbare tanke er: ”Alt er vigtigt, og alle data skal derfor flyttes (migreres) til det nye it-system”. Det kan måske lade sig gøre, men ofte spænder virkeligheden ben. Hvordan håndterer du det?

Hvilke data skal migreres?

Der er mange afklaringer i forbindelse med anskaffelse af et nyt it-system, eksempelvis leverandørvalg, sikkerhed og brugervenlighed.

Migrering af data fra det eksisterende it-system er altid relevant. Hvis alle jeres data skal med til det nye it-system, forudsætter det:

  • At data passer til det nye system.
  • God datakvalitet. Data skal være homogene og uden overraskelser.
  • Migrering af data må ikke tage tyve timer, hvis der kun er fem til rådighed.

Med forudsætningerne på plads kan du etablere et migreringsprojekt med den målsætning, at alle data skal migreres. Men der kan dukke corner cases op, som spænder ben. Det kan være uventede udenlandske telefonnumre eller gamle danske telefonnumre med områdenumre.

Hvis data ikke passer til det nye system, må de tvinges til det. Hvis datakvaliteten er dårlig, må kvaliteten forbedres ved datavask. Tiden må planlægges, så migreringsprojektet og go-live kan holdes inden for den afsatte tid.

Hvis forudsætningerne ikke kan opnås, må du træffe beslutning om, hvilke data der ikke skal migreres til det nye it-system. Måske udelader du salgsdata ældre end fem år eller persondata for afdøde. Adressedata kan være så ringe, at de skal hentes fra andre kilder. Relevante beslutningstagere, formentlig projektets styregruppe, bør udpeges tidligt i projektet.

Få styr på datas beskaffenhed

It-systemer har forskellige datamodeller, men de migrerede data skal alligevel passe til det nye system. Hvis det nye it-system understøtter nye forretningsområder, kan den del ikke fyldes fra det eksisterende system. Der kan være felter i det eksisterende system, som ikke passer med det nye system.

En ekstern nøgle til et tidligere produktionssystem er måske ikke længere relevant, men i startfasen ønsker I adgang til den. Nøglen må ofte placeres i et kommentarfelt.

Hvis datakvaliteten er sølle, kan du overveje kun at medtage gode data. Men i et medicinsystem skal nulevende patienters ordinationer med, selvom lægemidlet er udgået. Og i et studieadministrativt system skal resultaterne med, selvom karakterskalaen er ændret, eller studieordningen ikke længere er aktiv.

Du kan indlæse historiske stamdata i det nye it-system, eventuelt fra eksterne systemer. Det spritnye system må så kende udgåede varenumre eller forældede karakterskalaer, hvis fremmednøgler i databasen kræver det. Alternativt kan gamle forretningsdata placeres i tabeller med historisk data (en slags datakirkegård), men det komplicerer ofte servicelaget eller brugergrænsefladen.

Der kan være datafejl i det eksisterende system, fx tekstfelter med ikke-printbare tegn. Hvis det eksisterende system har få forretningsregler, er der formentlig ikke-validerede data i systemet. Et telefonnummerfelt indeholder måske en e-mailadresse, og hvis det nye it-system forventer numeriske tegn, fejler indlæsningen.

Det er hårdt arbejde at forbedre datakvaliteten.

I kan vaske data i det eksisterende system eller ændre data undervejs til det nye system. Datavask i det eksisterende system er bedst, da datakvaliteten så øges her og nu. Men måske spænder eksisterende forretningsregler ben for tilstrækkelig datavask.

Ofte må I forbedre datakvaliteten på vejen til det nye system. Processen er extract, transform og load (ETL), og datakvaliteten kan forbedres i et af disse trin eller i en kombination heraf.

Forbered dig på det uforudsete

Sørg for at I har tid nok til migrering:

  • Tid til migreringsprojektet, hvor I gør jer klar til at gennemføre migreringsaktiviteterne i forbindelse med go-live, bl.a. ved at gennemføre adskillige prøvemigreringer.
  • Tid under go-live. Der skal være maskintid nok til at udføre ETL-processerne, og der skal være tid til kvalitetssikring.

Der kræves omhyggelig projektledelse og planlægning, herunder udarbejdelse af en minuttidsplan for go-live.

Vigtigst er test, test og atter test. En tommelfingerregel er syv prøvemigreringer før go-live.

For hver prøvemigrering opdager I uhensigtsmæssigheder. Måske databrud i det eksisterende system, eksempelvis skift af datoformat da systemet passerede årtusindskiftet. Eller der kan være fejl i et konverteringsværktøj, som omsætter mellem SHAK- og SOR-koder.

Den sidste prøvemigrering er generalprøven, hvor det nye system fyldes med data. Undervejs udføres relevant kvalitetssikring, og til sidst anvender rigtige brugere det nye system med de migrerede data.

Generalprøven afholdes måske 1-2 måneder før go-live, og der kan (desværre!) være tale om, at den sidste funktionalitet ikke er helt klar. Brugerne bør være forberedt på fejl og mangler, og de skal hjælpes til at skelne mellem fejl i data og manglende færdiggørelse.

I opdager først for alvor migreringsfejl, når data er læst ind og tilgås igennem det nye systems skærmbilleder, rapporter og integrationer. I kan lave mange skrivebordsøvelser med analyser af data i det eksisterende system, men med en let omskrivning af Mulles ord fra filmen Den eneste ene (”Syv år, Niels, så ved man nogle ting”), skal der syv prøvemigreringer til.

Fire gode råd på falderebet

  • Undersøg nøje relevansen af data, som udelades.
  • Vær kreativ for at finde plads til ”upassende” data i det nye it-system.
  • Undgå brug af datakirkegårde.
  • Afsæt tid til nok prøvemigreringer.