Migrering af data ved systemskifte: plan, kvalitet og kontrol

Forstå systemskiftet: formål, omfang og hvad datamigrering indebærer

Datamigrering er flytning af data fra et system eller format til et andet. Det sker typisk ved systemopgradering, fusion, opkøb eller for at samle data ét nyt sted.

Den enkleste form er overførsel fra én placering til en anden, fx når filer flyttes til nyt lager. I praksis er opgaven ofte mere sammensat: data konverteres til nye formater, fejl og dubletter ryddes op, og data fra flere kilder integreres.

Før I går i gang, skal målet med systemskiftet være klart. Skal ydeevnen forbedres, skal data konsolideres for at blive lettere at administrere, eller skal de forberedes til analyse og rapportering?

Målet styrer, hvilke data der skal migreres, og hvordan de behandles undervejs. Et uklart mål fører let til, at man flytter for meget, for lidt eller de forkerte data.

Datamigrering dækker flere typer flytning med forskellige krav. Lagringsmigrering flytter data fra ét lagerformat til et andet, fx digitalisering af papirarkiver til onlinelagring. Applikationsmigrering er skift af applikation, fx fra et ældre økonomiprogram til et nyt.

Databasemigrering flytter en hel database til en ny placering, fx fra lokale pc'er til en cloudbaseret database. Cloud-migrering er en særlig variant: flytning fra lokal filserver til skyen eller fra én skyløsning til en anden.

Skyen er ikke én ensartet størrelse. Adgangen til data afhænger af den valgte tjeneste; adgang til én udbyders lager giver ikke automatisk adgang til en andens. Flytning mellem to skyløsninger er derfor i sig selv en migreringsopgave, der skal planlægges.

Typer af datamigrering – krav og eksempler

Kortlæg data: grunddata, stamdata og transaktionsdata

Når målet er fastlagt, skal I identificere, hvilke data der reelt skal oprettes eller flyttes i det nye system. En praktisk opdeling er grunddata, stamdata og transaktionsdata, fordi de stiller forskellige krav til rækkefølge, kvalitet og tidsfølsomhed.

Grunddata er opsætninger og værdilister, som de efterfølgende data bruger – fx varegrupper eller momskoder. De skal som regel være på plads først, fordi stamdata og transaktionsdata refererer til dem. Mangler grunddata, opdager man det ofte først, når indlæsningen fejler.

Stamdata kommer typisk fra et eksisterende system og har så mange poster, at manuel indtastning ikke kan betale sig – fx kunder, leverandører og varer. Antallet af skærmbilleder, faner og felter kan være stort, og rækkefølgen, data indlæses i, kan være afgørende for, om det lykkes.

Transaktionsdata er levende og ofte meget tidsfølsomme. De bør deles op i historiske data og åbne poster. Historiske data er typisk ældre, lukkede forhold, som primært har værdi for dokumentation og analyse.

Åbne poster er sager, ordrer eller mellemværender, der stadig er i spil, og som derfor skal være korrekte fra dag ét i det nye system. Opdelingen gør prioriteringen lettere: Hvad skal med i første bølge, hvad kan vente, og hvad skal måske slet ikke flyttes?

Prioritering af data typer efter kritikalitet og tidsfølsomhed

Plan og roller før første flytning

Afgør tidligt, om organisationen selv skal stå for migreringen, om opgaven skal løses eksternt, eller om I vælger en hybridmodel. Fordel ansvaret for udtræk fra de gamle systemer, klargøring af data og indlæsning i det nye system, så ingen opgave falder mellem to stole.

Brug en enkel RACI-model til at beskrive, hvem der er ansvarlig for arbejdet, hvem der godkender beslutninger, hvem der skal høres, og hvem der skal orienteres. Udpeg en dataejer, en teknisk migreringsansvarlig, forretningsansvarlige for mapninger og testere fra de berørte brugergrupper.

Fastlæg også et beslutningsforum med mandat til at afgøre tvivl om data, mapninger og kvalitet. Beskriv, hvem der kan eskalere en fejl, hvem der kan stoppe en indlæsning, og hvem der godkender, at I går videre til næste fase.

Byg planen op om foranalyse, dataprofilering, dokumenteret mapning, testmigrering eller dry run, cutover-plan, go-live og hypercare. For hvert trin beskrives leverancen, den ansvarlige og det beslutningspunkt, der skal være godkendt, før næste trin begynder.

I foranalysen afgrænses datakilder, dataomfang og afhængigheder. Dataprofileringen afdækker fejl, dubletter og manglende værdier; derefter dokumenteres mapninger og rensningsregler. Brug fundene til at udarbejde en tids- og ressourceplan, og revidér estimatet, hvis omfanget ændres.

Mapning mellem gammelt og nyt system

Strukturen og kravene til data er sjældent ens fra ét system til et andet. Når systemerne udvider deres funktionalitet, udvides kravene til data også. Derfor kræver det et solidt stykke arbejde at lægge en strategi, mappe og overføre data, så de bliver retvisende og værdiskabende i det nye system.

Mapningen af data fra gammelt til nyt system er ofte den største del af arbejdet. Her er tæt dialog mellem konsulent og forretning afgørende, så man ved, hvordan forretningsprocesserne skal se ud i det nye system. Forretningsprocesserne påvirker datakravene – og datakravene kan omvendt påvirke, hvordan processerne kan indrettes. De to beslutninger bør derfor ikke træffes adskilt.

Dokumentér mapningen skriftligt, så den kan testes, godkendes og genbruges ved gentagelser eller flere forretningsområder. Beskriv for hvert felt kildedata, målfelt, transformation, værdiliste, obligatoriskhed og eventuelle undtagelser. Notér også data, der ikke skal flyttes, og begrund beslutningen.

Rens og forbered data før flytning

En vellykket migrering forudsætter planlægning, datasikkerhed, oprydning og validering – og en klar plan for at flytte data uden tab eller driftsforstyrrelser. Rensning skal sikre, at det nye system starter med et troværdigt datagrundlag.

Rensningen omfatter typisk fejl og dubletter i de eksisterende data. Data, der skal overføres, bør gennemgås for manglende obligatoriske felter, inkonsistente værdier, forældede poster og dubletter, før de forsøges indlæst automatisk. Det er nemmere og billigere at rette fejlen i kilden end at opdage den i det nye system efter ibrugtagning.

Opret først et repræsentativt datasæt manuelt i det nye system, så I kan kontrollere obligatoriske felter, grunddata og rækkefølge. Gennemfør derefter en testmigrering eller dry run med automatiseret udtræk og indlæsning. Den manuelle afprøvning afdækker krav; dry run viser, om den samlede migreringsproces fungerer.

Planlæg arbejdet, så der er tid til at oprette manglende grunddata, inden stamdata og transaktionsdata skal indlæses. Ellers risikerer man, at hele indlæsningen fejler på grund af få manglende opsætninger, som kunne være håndteret tidligt.

Sikkerhed, persondata, backup og tilbagerulning

Datamigrering indebærer ofte, at følsomme oplysninger flyttes – fx kundeoplysninger eller finansielle data – og de skal beskyttes gennem hele processen. Det kan betyde kryptering under overførslen, brug af sikre forbindelser og sikring af, at det nye system har passende sikkerhedsforanstaltninger på plads, før data lander der.

Sikkerheden bør være en del af planen, ikke noget der tilføjes til sidst. Det gælder både tekniske tiltag og de adgangsrettigheder, der gives til personer og leverandører, som deltager i migreringen. Færrest mulige rettigheder og tydelig logning af, hvad der flyttes hvornår, gør det lettere at efterprøve forløbet bagefter.

Ved behandling af personoplysninger skal den dataansvarlige gennemføre passende tekniske og organisatoriske foranstaltninger for at sikre og kunne påvise, at behandlingen er i overensstemmelse med databeskyttelsesforordningen (Datatilsynet). En konsekvensanalyse vedrørende databeskyttelse er navnlig påkrævet ved systematisk og omfattende vurdering af personlige forhold baseret på automatisk behandling, behandling af følsomme oplysninger i stort omfang eller systematisk overvågning af et offentligt tilgængeligt område i stort omfang (Datatilsynet).

Hav en backup-plan, hvis noget går galt under migreringen. Det kan indebære en kopi af de originale data gemt sikkert og en plan for, hvordan systemet hurtigt kan gendannes til sin oprindelige tilstand, hvis det bliver nødvendigt. Uden en sikkerhedskopi og en gendannelsesplan har man ingen reel mulighed for at rulle tilbage, hvis valideringen viser problemer.

Hvis planlægningen svigter, kan det koste datatab. Det kan også give langvarig nedetid, som organisationen ikke kan undvære.

Validering: kontrol før, under og efter ibrugtagning

Datavalidering indebærer at kontrollere, at migrerede data er nøjagtige og komplette, og at de fungerer korrekt i det nye system. Valideringen bør dække både dataindholdet og den måde, data bruges på i de nye arbejdsgange.

I praksis kan det gøres ved at sammenligne data i det gamle og det nye system, teste systemets funktioner med de migrerede data og sikre, at brugerne kan få adgang til og bruge dataene, som det er forventet. Involvér de kommende brugere tidligt i testen, fordi de ofte opdager manglende felter eller forkerte sammenhænge, som en rent teknisk kontrol ikke fanger.

Kontrollér efter hver indlæsningsbølge, før fejl spredes til resten af datasættet. Registrér antal poster i kilden, antal indlæste og afviste poster, og afstem relevante totaler mellem systemerne. Fastlæg acceptkriterier før testen: kritiske poster må ikke afvises, obligatoriske felter skal være udfyldt, og eventuelle afvigelser skal være forklaret og godkendt.

Kontrolpunkter før go-live

Datakvalitet som styringsparameter efter systemskiftet

Datakvalitet bør være en løbende disciplin. Organisationen bør udpege de dataelementer, der er kritiske for driften og for beslutninger på baggrund af systemet. De kritiske dataelementer bør have de strammeste forretningsgange og metoder til styring af datakvalitet.

Finanstilsynets notat om god praksis for kreditinstitutters styring af datakvalitet peger på, at forretningsgange og metoder specifikt gælder kritiske dataelementer, mens der er færre krav til ikke-kritiske. Samme prioritering kan bruges bredere: Identificér først, hvad der er kritisk, og byg styringen op omkring det.

Arbejdet om god praksis med at sikre datakvalitet i forsyningskæderne (Stentoft, 2025) peger på, at datakvalitet fremover bør understøtte virksomhedens overordnede mål, og på hvilke forbedringsområder der kan tages fat på. Datakvalitet er ikke et projekt med en slutdato, men et forbedringsområde, der bør kobles til organisationens øvrige mål.

Praktisk kan det betyde faste kontroller af de kritiske felter og en defineret ejer for hvert centralt dataområde. Det kan også betyde en vane med at rette fejl ved kilden frem for i rapporterne.

Genudtræk og kontrol over data efter systemskiftet

Planlæg også, hvordan organisationen bevarer adgang til data under flytningen og kan hente dem ud igen senere. Gør udtræksmulighed, ejerskab og ansvar til konkrete punkter i migreringsplanen, ikke kun til spørgsmål, der opstår, når en leverandør eller løsning skiftes.

Afhængighed af en enkelt løsning kan gøre et senere systemskifte vanskeligere. Undersøg derfor tidligt, hvilke data der kan trækkes ud, hvilke relationer eller vedhæftninger der følger med, og hvilke oplysninger der kræver særskilt håndtering.

Indhent en prøve på et udtræk, og kontrollér, at det kan læses og forbindes med den tilhørende dokumentation. Sammenhold prøveudtrækket med data i kildesystemet, og få forretningen til at bekræfte, at felter, relationer og betydning er bevaret.

Beskriv udtrækkets struktur, felter, værdier og relationer i en dataordbog, og aftal, hvordan ændringer i strukturen meddeles. Aftal også, om udtrækket skal kunne gentages, hvordan fejl i det håndteres, og hvem der godkender, at det er komplet.

Medtag både fulde udtræk og ændringer siden seneste udtræk i afprøvningen, hvis løsningen understøtter begge dele. Kontrollér, at gentagne udtræk kan afstemmes, og at poster, der er ændret eller slettet undervejs, ikke bliver overset.

Aftal på forhånd, hvem der leverer udtrækket, hvem der kontrollerer det, og hvor længe det opbevares. Begræns adgangen til arbejdsfiler, og sørg for, at testkopier håndteres efter samme sikkerhedsplan som de øvrige migreringsdata.

Afprøv genudtræk som en del af testmigreringen, ikke først når organisationen står over for et nyt skifte. Dokumentér resultatet, kendte begrænsninger og de trin, der kræves for at få data ind i et andet system.

Stil krav om dokumenterede, maskinlæsbare udtræk og en beskrivelse af formatets felter, værdier og relationer. Bed også om en vejledning til genudtræk, så data kan kontrolleres og flyttes igen uden at være afhængig af udokumenteret specialviden.

Indarbejd udtræksprøven, dokumentationen og ansvarsfordelingen i projektets godkendelsespunkter. Hvis et krav ikke kan opfyldes, skal konsekvensen for kvalitet, kontrol og en senere flytning være synlig, før organisationen godkender go-live.

Migreringsplanen skal derfor både sikre, at data lander korrekt, og at de kan kontrolleres og hentes ud igen. Knyt genudtrækket til den øvrige test, og sørg for en aftale om rettigheder, ansvar og håndtering, hvis leverandøren skifter kurs, eller løsningen skal udskiftes.