Før en cloudaftale fornyes, skal tre ting være klar fra driftens side: et billede af forbruget pr. system, et kort over de tjenester, arkitekturen er bygget på, og en prøve på, om mindst ét system kan køre et andet sted. Med det i hånden ved ledelsen, hvad den faktisk forlænger, og hvilke muligheder der findes.
Forhandlingen selv og prisen hører ikke til her. Det samme gælder beslutningen om en exit-plan. Denne artikel handler om det arbejde, driftsfolkene skal have gjort, før nogen sætter sig ved bordet.
Forbruget, som det faktisk ser ud
Fornyelsen bygger på et forventet forbrug. Er det skønnet ud fra sidste års faktura, er det et dårligt grundlag. Træk forbrugsdata for mindst et år, og del dem op pr. system, pr. miljø og pr. type ressource.
Kig efter tre ting. Ressourcer, ingen ejer: servere, diske og kopier, der blev oprettet til et projekt og aldrig slettet. Ressourcer, der er større end nødvendigt: servere, der kører med lav udnyttelse hele døgnet. Og udviklingen: vokser forbruget jævnt, i spring eller slet ikke?
Oprydningen er værd at lave før fornyelsen, uanset hvad I beslutter. Den gør tallene, aftalen bygger på, mindre og mere retvisende. Mangler I mærkning af ressourcer, så systemerne ikke kan skilles ad på fakturaen, er det første opgave.
Bindingerne, der allerede løber
Store cloududbydere har flere former for binding ud over selve aftalen. Reserveret kapacitet for et eller flere år, en fast timeforpligtelse i penge og aftaler om et samlet forbrug i aftaleperioden. De kan løbe på andre datoer end hovedaftalen.
Lav en liste med hver binding, hvad den dækker, og hvornår den udløber. Den liste afgør, hvornår et system rent praktisk kan flytte uden at efterlade betaling for kapacitet, der ikke bruges. Hvordan bindingerne virker hos de største udbydere, står på vendor-lock-in.dk. Tidspunktet for flytningen står i Bindinger og rabataftaler.
Kortet over arkitekturen
Det andet stykke arbejde er at se, hvad systemerne er bygget af. For hvert system skrives de tjenester ned, det bruger fra udbyderen: virtuelle servere, lager, administrerede databaser, funktioner, køer, identitet, overvågning, nøgler og netværk.
Sortér dem i to bunker. Den første er byggesten, der findes hos mange udbydere i en sammenlignelig form, som virtuelle servere og blokdiske. Den anden er udbyderens egne tjenester, der skal erstattes eller bygges op igen, hvis systemet flytter. Jo mere der ligger i den anden bunke, jo større er bindingen i arkitekturen, uanset hvad aftalen siger. Se Applikationer bygget på udbyderens egne tjenester.
Kortet er også det, der viser, om de alternative tilbud I indhenter, sammenligner det samme.
Prøveflytningen
En prøve viser mere end et tilbud om, hvorvidt et alternativ er reelt. Vælg ét system, der er typisk for miljøet og ikke for kritisk, og sæt det op hos en anden udbyder eller i colocation. Mål svartider, gendannelse fra backup, overvågning og den tid, det tog.
Efter art. 31, stk. 2, i Data Act (dataforordningen) falder versioner, der ikke bruges i produktion og kun afprøves i en tidsbegrænset periode, uden for kapitlet om skift. En prøve hos en ny udbyder kan altså ligge uden for forordningens skifteregler. Grænsen for, hvornår en prøve er ikke-produktion, har vi ingen kilde til. Brug kopier af data, hvor det kan lade sig gøre, og skriv rammerne ned.
Planlæg prøven, så den er færdig mindst et par måneder før fornyelsen. Ellers kommer resultatet for sent til at kunne bruges.
Tidsplan
Bagud fra fornyelsesdatoen giver det et forløb i fire dele. Forbrug og oprydning først, fordi det tager tid at få data ud og ejere til at svare. Bindinger og arkitekturkort derefter. Så prøveflytningen. Og til sidst et kort notat til dem, der skal forhandle og beslutte. For et mellemstort miljø skal arbejdet begynde seks til tolv måneder før datoen. Planlægningen set fra exit-planens side står på exit-plan.dk.
Hvad det kræver, og hvad det koster at lade være
Forbruget og oprydningen tager en driftsperson nogle uger ved siden af den daglige drift. Arkitekturkortet tager en til tre dage pr. system, afhængigt af hvor mange tjenester det bruger. Prøveflytningen er et lille projekt med en tekniker i et par uger og en åben konto hos den udbyder, I prøver.
Lader I være, fornyer I på leverandørens tal og uden kendskab til jeres egne muligheder. Det kan betyde en ny binding på et forbrug, der indeholder ressourcer, ingen bruger, og en arkitektur, der gror fastere for hvert år. Næste mulighed for at gøre det anderledes kommer først ved næste fornyelse.
Det skal I lade være med
- At forny på sidste års faktura · ryd op først, og byg på det faktiske forbrug.
- At starte prøveflytningen for sent · et resultat efter fornyelsen kan ikke bruges.
- At glemme bindinger med andre datoer · de afgør, hvornår noget reelt kan flytte.
Det skal valget kunne vise
- ☐ Forbrug pr. system for mindst et år, efter oprydning.
- ☐ Alle bindinger med udløbsdato.
- ☐ Arkitekturkort med byggesten og udbyderens egne tjenester adskilt.
- ☐ Resultatet af en prøveflytning af mindst ét system.
Kilder
- Forordning (EU) 2023/2854 (Data Act): art. 31, stk. 2.
Senest gennemgået: november 2026.
Næste skridt
Find fornyelsesdatoen og bindingernes datoer, og læg dem i samme kalender. Så kan I se, hvor meget tid I har.
Læs også: Fast aftale eller forbrug på servere og lager · FinOps, når regningen ikke længere kommer ét sted fra
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
