At bevise, at intet blev ændret under en migrering

Før eller siden i en migrering spørger nogen: hvordan ved vi, at intet er blevet ændret undervejs? I en reguleret virksomhed er det ikke et høfligt spørgsmål. Det er et krav, der skal kunne dokumenteres over for en revisor.

Det oplagte svar er en kontrolsum. Beregn en SHA-256 for hver fil før migreringen, beregn den igen bagefter, og sammenlign. Er de ens, er filen ens. For en PDF eller et billede holder det. For Word, Excel og PowerPoint i SharePoint gør det ikke.

SharePoint ændrer Office-filerne#

Når en Office-fil lægges i et dokumentbibliotek, skriver SharePoint bibliotekets metadata ind i filen: indholdstypen og kolonnerne ender i filens customXml-dele. Det hedder property promotion og demotion, og det er det, der gør, at kolonnerne kan ses og redigeres inde fra Word. Brødteksten og selve dokumentet er uændret, men pakken er en anden, og kontrolsummen er en anden. Filen er typisk et par kB større.

Det er beskrevet af flere i Microsoft Q&A. Svaret i den ene tråd er, at det er forventet, og at det ikke kan slås fra i SharePoint Online. I en anden nævnes det samme for e-mails (.eml og .msg) og TIFF-filer.

Den naive kontrol melder altså fejl på stort set hver eneste Office-fil. Enten bliver kontrollen droppet, fordi den “altid fejler”, eller også bliver afvigelserne godkendt i bunke uden at blive forklaret. Begge dele er værre end ingen kontrol, fordi de ligner en kontrol.

Hvad kravet faktisk siger#

EU’s GMP-vejledning, Annex 11, punkt 4.8: når data overføres til et andet format eller system, skal valideringen omfatte kontroller af, at data ikke ændres “in value and/or meaning”. GDPR artikel 5, stk. 1, litra f, kalder det integritet: beskyttelse mod uautoriseret behandling og mod hændeligt tab, tilintetgørelse eller beskadigelse.

Ingen af dem kræver identiske bytes. De kræver, at indholdet og betydningen er den samme, og at det kan vises. Det er en anden og bedre opgave, men den kræver, at nogen beslutter, hvad “uændret” betyder for hver slags fil, før migreringen går i gang.

Hvad der kan bevises#

At alt kom med. En liste over alle filer i kilden med sti og størrelse, og den samme liste fra SharePoint bagefter. Mangler der noget, eller er der kommet noget til, skal det kunne forklares. Her dukker filnavne med tegn, SharePoint ikke tillader, for lange stier og låste filer op.

At indholdet er det samme. For filer, SharePoint ikke rører, fx PDF, er kontrolsummen stadig beviset. SharePoint og OneDrive giver selv en kontrolsum gennem Microsoft Graph, file.hashes.quickXorHash på filen, og Microsoft har koden, der beregner den samme værdi lokalt. SHA-256 findes ikke dér (feltet er ifølge Graph “not supported”), så skal det være SHA-256, må filen hentes ned igen. For Office-filerne må sammenligningen gå på indholdet i pakken og lade customXml være ude. Den metode skal beskrives og begrundes, før den bruges, ikke findes på, når den første fil fejler.

At metadata fulgte med. Oprettet, Ændret, Oprettet af og Ændret af. SharePoint Migration Tool tager dem med fra et fildrev, når brugerne kan findes i Entra ID. Gamle versioner af filerne fra fildrevet kommer ikke med.

Beviset skrives før#

Listen over filer og kontrolsummer fra kilden skal laves, før migreringen, og gemmes et sted, migreringen ikke kan røre. Bagefter er beviset ikke en grøn bjælke med “100 %”. Det er en liste over de afvigelser, der blev fundet, og en forklaring på hver af dem: at Word-filerne har fået metadata skrevet ind af SharePoint, brødteksten er kontrolleret og uændret, eller at de her tolv filer blev omdøbt, fordi navnet indeholdt tegn, SharePoint ikke tillader.

“Intet blev ændret” er sjældent sandt for Office-filer i SharePoint. “Intet blev ændret i værdi eller betydning, og her er de ændringer, vi kender og kan forklare” kan bevises.