Digital suverænitet

Trin 9 i exit‑planen: et skifte, der er afprøvet, før det gælder

Trin 9 i exit-planen: et skifte, der er afprøvet, før det gælder

En exit-plan på papir siger, hvad organisationen vil gøre. Først når data er gendannet hos en anden leverandør, og brugerne har arbejdet i den nye løsning, ved I, om planen holder. Trinnet hviler på tre elementer: parallel drift, test af gendannelse et andet sted og en tilbagefaldsvej.

Kontrakten fra → Trin 8 giver retten til data, varsel og overgangsperiode. Dette trin handler om at bruge den ret i praksis, uanset om skiftet er planlagt eller fremtvunget.

Planen bliver først til viden, når den er afprøvet

Fire tyske organisationer med ansvar for pension, arbejdsformidling og sygesikring afprøvede i 2026 netop det. Ifølge Deutsche Rentenversicherungs pressemeddelelse af 21. juli 2026 byggede projektet CKKI fire selvstændige installationer af kontorpakken openDesk. De blev drevet hos IONOS, STACKIT og T-Systems.

Filer, chat, mail og videomøder blev testet i realistiske scenarier for driftskontinuitet. Projektet flyttede også installationer mellem to forskellige cloudplatforme, og ifølge pressemeddelelsen lykkedes det.

Pointen for andre organisationer ligger i metoden. Flytningen blev afprøvet, mens der var ro, og resultatet blev skrevet ned. Forløbet gennemgås i → Tyske myndigheder øvede scenariet.

Fremgangsmåden

  1. Vælg form for overgang · Afgør for hvert system, om skiftet sker med parallel drift, i etaper eller på én gang.
  2. Fastlæg succeskriterier · Beskriv på forhånd, hvad der skal virke, før det gamle system lukkes.
  3. Gendan data hos den nye leverandør · Brug en reel eksport fra den nuværende leverandør og kontrollér, at data er komplette og læsbare.
  4. Kør parallelt med en afgrænset gruppe · Lad rigtige brugere arbejde i den nye løsning, mens den gamle stadig kører.
  5. Beskriv tilbagefaldsvejen · Skriv, hvordan I vender tilbage, hvis noget går galt, og hvem der beslutter det.
  6. Gennemfør skiftet i overgangsperioden · Planlæg, så skiftet ligger inden for den periode, kontrakten giver.
  7. Bekræft lukning og sletning · Luk det gamle system først, når succeskriterierne er opfyldt, og bed om skriftlig bekræftelse på sletning.

Trinnene gælder både et planlagt leverandørskifte og den situation, hvor en tjeneste uventet forsvinder. I det sidste tilfælde er punkt 3 og 5 de vigtigste, og de skal være øvet på forhånd.

Succeskriterierne afgør, hvornår det gamle system må lukkes. De skal være skrevet ned, før skiftet begynder, så beslutningen ikke træffes under tidspres.

Gode kriterier kan kontrolleres af andre end dem, der har gennemført skiftet. Det kan være, at alle brugere kan logge ind, og at et bestemt antal dokumenter åbner korrekt. Det kan også være, at mail kommer frem begge veje, og at integrationerne til de vigtigste fagsystemer virker.

Notér også, hvor lang tid gendannelsen tog. Tallet viser, hvor længe organisationen vil være uden systemet i et fremtvunget skifte.

Resultatet gemmes med dato som en del af exit-planen. Det er det dokument, ledelse, revision og tilsyn kan bede om.

Tre måder at gennemføre skiftet på

Parallel drift betyder, at gammel og ny løsning kører samtidig i en periode. Det er den sikreste form, fordi brugerne kan falde tilbage, men den kræver to sæt licenser og to driftsmiljøer i perioden.

Etapevis overgang flytter én funktion eller én gruppe ad gangen. Mail kan flyttes før dokumenter, og en afdeling kan gå forud for resten. Formen passer, når systemerne kan adskilles.

Skift på én gang flytter alt på en fastsat dato. Det er hurtigst, men tilbagefaldet er sværest. Det kan bruges til systemer med få integrationer og få brugere, hvor en kort afbrydelse kan accepteres.

Valget noteres i exit-planen sammen med begrundelsen. Omkostningen ved parallel drift skal med i beregningen fra trin 5.

Parallel drift med en afgrænset gruppe

Parallel drift afslører de problemer, en teknisk test ikke finder. Det kan være skabeloner, der ikke konverteres, makroer, der holder op med at virke, eller arbejdsgange, der afhænger af en bestemt integration.

Vælg en gruppe, der repræsenterer forskellige arbejdsopgaver, og fastsæt en periode på forhånd. Notér begrænsningerne skriftligt, også dem, der virker små. Afslut perioden med en kort evaluering, hvor gruppen beskriver, hvad der skal rettes, før resten af organisationen følger efter.

En nødløsning, der drives ved siden af hovedsystemet, er en variant af parallel drift. Et eksempel gennemgås i → Schweiz bygger en nødløsning.

Gendannelse et andet sted

En backup viser, at data findes. En gendannelse hos en anden leverandør viser, at de kan bruges uden den oprindelige platform. Det er to forskellige test.

NIS2-direktivets artikel 21, stk. 2, litra c, nævner driftskontinuitet, herunder backup-styring og reetablering efter en katastrofe, blandt de foranstaltninger, enhederne skal have. Finanssektorens DORA, artikel 28, stk. 8, går længere og kræver exitplaner, der er testet i tilstrækkeligt omfang og gennemgås regelmæssigt.

Tag konfiguration, brugere, rettigheder og krypteringsnøgler med i testen. Data uden nøgler eller rettigheder kan ikke tages i brug. Hvorfor kopien skal ligge hos en anden udbyder, står i → Backup hos samme udbyder. Et eksempel på en hel region, der ikke kom tilbage, findes i → Droneangreb på datacentre i Golfen.

Tilbagefaldsvejen

Tilbagefaldsvejen beskriver, hvad der sker, hvis den nye løsning svigter under eller lige efter skiftet. Den skal angive, hvem der kan træffe beslutningen, inden for hvilken tid, og hvilke data der skal synkroniseres tilbage.

Et tilbagefald forudsætter, at den gamle løsning stadig kører. Derfor må det gamle system først lukkes, når den nye løsning har kørt stabilt i en aftalt periode. Kontraktens overgangsperiode sætter grænsen.

Ved et fremtvunget skifte findes den gamle løsning måske ikke længere. Her består tilbagefaldet i en nødløsning, der kan bære de mest kritiske opgaver. Den hollandske stats krav om exitplaner for begge situationer er gennemgået i → Holland kræver exitplaner.

Brugerne i overgangen

Tekniske test viser, om data kan flyttes. Brugerne afgør, om skiftet lykkes. Genveje, menuer og vaner følger ikke med, og modstanden handler oftest om arbejdsgange frem for funktioner.

Planlæg uddannelse før skiftet, en kontaktperson i hver afdeling og en kanal til at melde problemer. Giv også brugerne en tilbagefaldsvej, fx adgang til det gamle system i en periode til opslag. Erfaringer fra skift af kontorpakke findes i → Brugerne i skiftet.

Typiske fejl

  • Backup forveksles med exit · en kopi hos samme udbyder hjælper ikke, når adgangen til udbyderen forsvinder.
  • Gendannelsen testes uden nøgler og konfiguration · data kommer ud, men kan ikke tages i brug.
  • Det gamle system lukkes for tidligt · tilbagefaldsvejen forsvinder, før den nye løsning er stabil.
  • Kun IT tester · brugernes arbejdsgange afprøves først efter skiftet.
  • Overgangsperioden passer ikke til planen · skiftet tager længere tid, end kontrakten giver.

Hvad trinnet kan og ikke kan vise

Trinnet kan vise, om data, konfiguration og arbejdsgange kan flyttes til en anden leverandør, og hvor lang tid det tager. Det giver et dokumenteret grundlag for at vurdere exit-planen over for ledelse, revision og tilsyn.

Trinnet kan ikke garantere, at et fremtidigt, fremtvunget skifte forløber som testen. En øvelse med god tid og fuld adgang til den gamle leverandør er lettere end et skifte uden varsel. Resultatet gælder desuden kun den version og den opsætning, der blev testet.

Tjekliste

  • ☐ Form for overgang er valgt og begrundet for hvert system.
  • ☐ Succeskriterier er skrevet ned, før skiftet begynder.
  • ☐ Data er gendannet hos en anden leverandør med konfiguration, rettigheder og nøgler.
  • ☐ En afgrænset gruppe har arbejdet i den nye løsning, og begrænsningerne er noteret.
  • ☐ Tilbagefaldsvejen er beskrevet med ansvar og tidsgrænse.
  • ☐ Der er en nødløsning for de mest kritiske opgaver, hvis tjenesten forsvinder uden varsel.
  • ☐ Skiftet ligger inden for kontraktens overgangsperiode.
  • ☐ Lukning og sletning hos den gamle leverandør er bekræftet skriftligt.

Næste trin

Et gennemført skifte ændrer leverandørbilledet, og en øvelse bliver forældet, når systemerne ændrer sig. Planen holdes ajour i → Trin 10: Hold exit-planen opdateret. Et dansk eksempel på et gennemført skifte findes i → STAR flyttede fra Microsoft til europæisk cloud.

Skal organisationen afgøre, hvilke systemer der er kritiske nok til en afprøvet exit eller en nødløsning, kan en uvildig vurdering give overblik. Nielco IT’s rådgivning om exit-planen omfatter en overgangsplan med parallel drift, test og en vej tilbage for hvert kritisk system.

Kilder

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal afhængigheden kortlægges?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad anledningen er. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ikke indgået forhandleraftaler med leverandører.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.