De første 90 dage efter en flytning skal bruges til at måle det, der først viser sig over tid: ydelsen i travle perioder, den første rigtige gendannelse, de første regninger og den måde, ansvaret fungerer på, når noget går galt. Omstillingen viser, at systemet kører. De næste uger viser, om det kan drives.
Tallet 90 er vores eget valg. Det giver plads til tre månedsafslutninger, tre regninger og nok supportsager til at se et mønster. Har jeres forretning en travl sæson, skal den med, også selv om den ligger senere.
Uge 1: driften kører
Den første uge handler om fejl, der kun ses under rigtig brug. Følg svartider, fejl i logfilerne og henvendelser fra brugerne dagligt. Hold øje med trafik til de gamle adresser. Den fortæller, hvem der stadig ikke har fået de nye. Det gamle miljø står klar til tilbagefald i hele perioden. Læs omstillingen.
Kontrollér, at alle planlagte job er kørt: backup, rapporter, overførsler til samarbejdspartnere, rydning af logfiler. Et job, der ikke kørte, giver ingen fejl. Det mangler bare.
Uge 2 til 4: første gendannelse og første regning
Gendannelse. Gendan et helt system fra backup i det nye miljø, og mål tiden mod det, forretningen har sagt, den kan undvære det. En backup, der kører uden fejl, er ikke bevis for, at gendannelsen virker. Læs hvor hurtigt data kommer tilbage fra cloud.
Regningen. Den første regning viser, om prismodellen er forstået. Sammenlign hver post med det, I regnede med i business casen. Poster, der ikke var med, er det vigtigste at finde: lager til snapshots, udgående trafik, ekstra IP-adresser, support som tillæg. Læs fast aftale eller forbrug.
Supporten. Gå jeres supportsager igennem, og se for hver sag på to tidspunkter: kvitteringen og løsningen. Kommissionens retningslinjer for serviceaftaler i cloud skelner mellem svartid, altså tiden til at kvittere, og løsningstid. En hurtig kvittering siger intet om, hvornår sagen er løst.
Uge 5 til 12: drift i travle perioder
Ydelse under belastning. Månedsafslutning, lønkørsel, kampagner og andre perioder med høj belastning viser, om miljøet er dimensioneret rigtigt. Sammenlign med målinger fra det gamle miljø i samme slags periode.
Oppetid. Opgør oppetiden selv og sammenlign med udbyderens. Kommissionens retningslinjer beskriver oppetid som den tid, tjenesten var tilgængelig, over den samlede mulige tid, og det er almindeligt, at planlagt vedligehold trækkes fra, før oppetiden opgøres. Læs jeres egen aftale for at se, hvad der tæller. En tjeneste kan også være oppe og så langsom, at den ikke kan bruges. Det skal aftalen helst sige noget om. Læs serviceaftalen.
Ansvar. Har der været en hændelse, hvor det var uklart, om det var jeres eller udbyderens opgave? Skriv det ned, og ret ansvarsfordelingen. Det er i de første måneder, hullerne viser sig. Læs ansvarsdeling.
Kapacitet. Hvor meget lager og regnekraft bruger I nu, og hvor hurtigt vokser det? Det er grundlaget for at vælge mellem forbrug og fast aftale, når I kender belastningen.
Hvornår det gamle må lukkes
Det gamle miljø lukkes, når fire ting er på plads: der har ikke været trafik til de gamle adresser i en aftalt periode, en gendannelse i det nye miljø er bestået, de data, der skal opbevares, er flyttet eller arkiveret, og den ansvarlige for systemet har skrevet under. Indtil da koster det gamle miljø penge, og det skal stadig opdateres og overvåges.
Ved afslutningen af en aftale om en cloudtjeneste har I efter Data Act (dataforordningen) en periode til at hente data efter overgangen. Tjek i aftalen, hvor lang den er, og hvornår data bliver slettet.
Afslutningen efter 90 dage
Saml målingerne i et kort notat: hvad der virker som forventet, hvad der afviger, og hvad der er rettet. Sammenlign med kriterierne fra piloten og med posterne i business casen. Notatet er grundlaget for at afslutte projektet og for den næste vurdering af placeringen. Det er også det, I viser en kunde eller en revisor, der spørger, hvordan skiftet gik.
Hvad det kræver, og hvad det koster at lade være
De 90 dage kræver en ansvarlig, der samler målingerne, tid hos driftsfolkene til gendannelse og opfølgning og en fra økonomi til at læse regningerne. Det er mindre arbejde end selve flytningen, men det skal planlægges, for projektgruppen kan allerede være i gang med det næste.
Uden opfølgning opdages fejlene, når de rammer: en gendannelse, der ikke virker, en regning, der vokser, eller et ansvar, ingen tog. Det gamle miljø bliver stående i månedsvis, fordi ingen har besluttet at lukke det, og så betaler I for to miljøer længere end planlagt.
Det skal I lade være med
- At afslutte projektet ved omstillingen · de vigtigste målinger kommer i ugerne efter.
- At regne en backup uden fejl som en bestået gendannelse · kun en gendannelse viser, at det virker.
- At lade det gamle miljø stå uden en dato · det koster og skal stadig vedligeholdes.
Det skal valget kunne vise
- ☐ En gendannelse af et helt system, målt mod forretningens krav.
- ☐ De første regninger sammenholdt med business casen, post for post.
- ☐ Supportsager med både svartid og løsningstid.
- ☐ En dato og fire kriterier for at lukke det gamle miljø.
Kilder
- Europa-Kommissionen, Cloud Service Level Agreement Standardisation Guidelines, 2014: afsnit 3.1 og 3.5.
- Forordning (EU) 2023/2854 (Data Act): art. 25, stk. 2, litra g.
Senest gennemgået: november 2026.
Næste skridt
Skriv målepunkterne ind i projektplanen nu, med navne og datoer. Så slutter projektet med et notat, alle kan læse.
Læs også: Pilot hos en ny udbyder · FinOps på flere platforme
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
