Sådan kontrollerer du migreret data efter systemskiftet

Afklar kontrollens omfang: data, applikationer og integrationer

Evidis teknologiordbog beskriver flere migreringstyper ved et systemskifte: datamigrering (strukturerede og ustrukturerede data), applikationsmigrering (systemer og software), platforms- og miljømigrering (operativsystem, infrastruktur eller cloud) og versionsmigrering (opgradering til nyere systemversioner).

Migreringen kan være teknisk, funktionel eller organisatorisk og spænde fra databaser og integrationer til brugerkonti og forretningsprocesser.

Kontrollen skal følge, hvad der faktisk er flyttet: strukturerede data i tabeller og felter, ustrukturerede data i filer og dokumenter, integrationer mellem systemer samt brugerkonti og rettigheder.

Udelades et område, kan fejl først vise sig i driften efter go-live.

Brug migreringsplanen som kontrolfacit

Evidi beskriver, at migrering ofte kræver planlægning af kompatibilitet, sikkerhed, identitet og datakvalitet for at sikre en kontrolleret overgang.

Planen for de fire områder bør derfor være kontrollens facit: Hvilke data skulle med? Hvilke felter skulle mappes? Hvilke integrationer skulle virke? Hvilke roller og rettigheder skulle videreføres?

Derfor tager kontrollen udgangspunkt i de dokumenter, der allerede findes: migreringsplan, feltmapping, integrationsbeskrivelser, rollematrix og aftalte datakvalitetskrav.

I stedet for at opfinde nye kriterier bagefter sammenlignes de faktiske resultater med de aftalte krav.

Hvert krav bør have en observerbar test – fx en afstemning, en stikprøve eller en funktionel test.

Kontrollér datastrukturer, mængder og relationer

Kontrollér først, at alle aftalte datamængder er kommet med.

Sammenlign antal poster og felter før og efter migreringen for centrale tabeller, og lav kontroltotaler på beløb, datoer og nøglefelter.

Tjek, at der ikke findes tomme felter eller afkortede tekster, hvor der ikke skal være det.

Tjek også, at tegnsæt, datoformater og decimaler er ens i kilde og mål.

Kontrollér relationerne: Fremmednøgler skal pege på poster i målsystemet, og der må ikke opstå orphan-poster, hvor en post mister sin overordnede.

Gennemgå dubletter og sammenkædninger, hvis to kildesystemer er slået sammen.

For ustrukturerede data tælles filer, mapper og versioner, og du kontrollerer, at metadata, filnavne og adgangsrettigheder følger med.

Tjek integrationer og dataflows på tværs af systemer

Jitterbit kalder en integrationsplatform det centrale nervesystem, der forbinder, synkroniserer og orkestrerer dataflows på tværs af teknologistakken.

Efter et systemskifte bør du kontrollere, at hver aftalt integration forbinder de rigtige systemer, synkroniserer de rigtige data og orkestrerer rækkefølgen korrekt – ikke bare at den kører uden fejl.

Jitterbit angiver, at 67 % af virksomhederne bruger over 500 applikationer, mens 71 % mangler en samlet platform til effektiv integration.

Jitterbit peger også på, at svigtende integration kan skabe datasiloer, og at punkt-til-punkt-integrationer multipliceres eksponentielt, når nye applikationer tilføjes.

Kontrollen bør derfor gennemgå, om der er opstået nye, skjulte punkt-til-punkt-forbindelser efter skiftet, og om data ligger låst i enkelte systemer i stedet for at flyde som aftalt.

Test både normal drift og fejlsituationer: Hvad sker der, når et system er nede? Gensendes data uden dubletter? Logges fejl og sendes videre til en ansvarlig?

Gennemgå logfiler og overvågning for de første dataflows, så afvigelser opdages, mens de stadig er små.

Verificér identitet, adgang og sikkerhed

Kontrollér brugerkonti, roller og rettigheder mod den planlagte rolle- og rettighedsstruktur.

Sammenlign brugere, grupper og servicekonti før og efter skiftet.

Verificér, at ingen konti er efterladt med for høje rettigheder, og at ingen legitime brugere har mistet adgang.

Gennemgå også tekniske adgangsmekanismer som API-nøgler, certifikater og integrationskonti, fordi integrationer ofte bruger dem, og de derfor skal matche de nye endepunkter.

Tjek særligt konti, der ikke længere bruges, og om rettigheder er kopieret ukritisk fra et gammelt system, så følsomme data er blevet bredere tilgængelige end planlagt.

Validér forretningskritiske data i praksis

Lad forretningsbrugere kontrollere udvalgte nøgledata og processer i det nye system.

Det kan være centrale transaktioner, stamdata som kunder, leverandører, varer og priser samt arbejdsgange, der bruger dataene dagligt.

Formålet er at vurdere kvaliteten i den daglige drift – ikke kun via tekniske tællinger.

Vælg et antal representative sager, og før dem gennem processen fra start til slut: opret, ret, godkend og rapportér.

Sammenlign resultatet med det gamle system eller den aftalte facitliste.

Fejl, som forretningen finder her, opdages ellers ofte for sent, fordi de handler om betydning og sammenhæng, ikke om antal poster.

Dokumentér afvigelser og beslut om go-live

Saml alle fund i én liste med entydig id, kort beskrivelse, alvorlighed, ansvarlig person og deadline.

Skel mellem blokerende fejl, der skal løses før go-live, og fejl der kan håndteres efter.

Listen bør også vise, hvilke data eller integrationer der mangler, og hvem der skal levere dem.

Brug listen til go/no-go: Er alle krav fra migreringsplanen enten opfyldt eller bevidst accepteret med en plan? Er de blokerende afvigelser lukket?

Hvis ikke, bør beslutningen udskydes, eller der skal laves en midlertidig kompenserende kontrol i driften.

Dokumentér beslutning og begrundelse, så den kan følges op senere.

Følg op efter go-live

Efter go-live fortsætter dataflows og ændringer.

Derfor bør afstemning og datakvalitetskontrol planlægges som en fast opgave i en periode.

Aftal, hvor ofte der afstemmes – fx dagligt i den første tid og derefter sjældnere – og hvem der reagerer, når en afstemning ikke stemmer.

Følg de samme målinger som under kontrollen: postantal, kontroltotaler, integrationslogfiler og fejlrater.

Gennemgå afvigelserne med jævne mellemrum, og luk først overvågningen, når tallene har været stabile gennem flere perioder.