Kort svar: Exit-planen er dokumentet, du skriver FØR du behøver det: for hvert kritisk system – hvordan får vi vores data ud (format, værktøj, hvem gør det), hvad er alternativet, hvor lang tid tager et skifte, og hvad koster det? Fire linjer pr. system. Testen er lige så vigtig som planen: eksportér én gang årligt og VERIFICÉR, at dataene faktisk kan bruges. En leverandør, du kan forlade, behøver du sjældent forlade – men forhandlingspositionen og roen følger med planen.
Lock-in opstår sjældent ved kontraktunderskrift – den vokser stille: data i proprietære formater, processer bygget om ét værktøj, viden der kun findes hos leverandøren. Exit-planen er modgiften, og den koster en eftermiddag. Her er skabelonen, testrutinen – og de kontraktpunkter, der afgør, om exit er en øvelse eller en gidselsituation.
Tag de kritiske systemer fra kortlægningen (site, mail, regnskab, CRM, nyhedsbrev, fragt/betaling) og skriv pr. system: (1) Data ud: eksportfunktion/API, format (standard? proprietært?), hvem hos jer kan gøre det. (2) Alternativ: ét-to navngivne alternativer, gerne testet overfladisk. (3) Skiftetid: realistisk kalendertid inkl. omlæring. (4) Bindinger: opsigelsesvarsel, forudbetaling, tekniske låse (fx betalings-tokens – webshoppens klassiske gidsel). Mere behøver planen ikke være – den skal være SAND, ikke smuk.
Før du skriver under (eller ved næste fornyelse): tjek at aftalen indeholder udleveringspligt ved ophør (dine data, i et brugbart format, inden for en frist), bistand ved migrering (og til hvilken timepris), sletning efter udlevering med bekræftelse (jf. DPA’ens exit-tjek) – og rimelige opsigelsesvilkår. Punkterne findes typisk allerede hos seriøse leverandører; de mangler hos dem, der planlægger at holde på dig. Spørgsmålet „hvordan kommer vores data ud, den dag vi opsiger?“ hører til i leverandørspørgsmålene – og svaret fortæller dig alt.
En plan, der aldrig er testet, er en hypotese. Én gang årligt (læg det i årshjulet sammen med subprocessor-gennemgangen): vælg ÉT kritisk system, kør den fulde eksport – og VERIFICÉR indholdet: kan filen åbnes, er alle data med, kan et alternativ importere den? Mange opdager først her, at „eksport“ betyder en PDF-rapport eller et proprietært format uden importmulighed – og DEN opdagelse vil du gøre i fredstid. Notér resultatet i planen med dato; næste år tager du det næste system.
Udløserne er velkendte: prisstigning, opkøb/retningsændring hos leverandøren, gentagne driftsproblemer – eller et suverænitetskrav fra en stor kunde. Med planen i hånden er processen rolig: eksportér FØRST (mens adgangen er venlig), sæt det nye system op parallelt, flyt i etaper med faldbæk-punkter (som ved migreringsplanens tunge etape), og opsig først, når alt er verificeret – samme logik som ved gatewayskiftet. Og husk exit-planens stille sidegevinst: leverandører forhandler anderledes med kunder, der beviseligt KAN gå. På Hostious er holdningen enkel: dine data er dine – fuld eksport og åbne standarder er en del af produktet, ikke en forhandling.
Den dag, planen skal bruges – leverandøren lukker, hæver prisen vildt eller skærer i vilkårene – er rækkefølgen: træk dine data UD først (eksporten fra planens punkt 2), FØR du opsiger eller diskuterer; en konto i god stånd eksporterer uden dramatik, en opsagt konto kan være spærret. Opsæt derefter det nye system i parallel, flyt, og luk først det gamle, når det nye har kørt en periode – præcis som ved en hostingflytning.
Og lær af hver exit: hvorfor blev den nødvendig, og kunne planen have fanget det tidligere? Ofte var advarslerne der – opkøb, forringede vilkår, længere svartider – og næste års test kan få et punkt mere: „er der tegn på, at leverandøren er på vej væk fra os?“. Exit-planer handler i sidste ende ikke om mistillid, men om forhandlingsposition: den, der KAN gå, bliver behandlet bedst – og betaler mindst.
Og gør øvelsen synlig internt: når årets exit-test er kørt, så del resultatet i én kort besked – hvilke systemer består, hvor er vi låst, og hvad gør vi ved det. Det holder både ledelse og kolleger investerede i, at skiftbarhed er en værdi – og gør næste års test til rutine i stedet for et særprojekt, der skal forklares forfra.
De kritiske: site/webshop, mail, regnskab, CRM, nyhedsbrev og betalings-/fragtplatforme. Fire linjer pr. system rækker – sandt slår smukt.
Test ét systems fulde eksport årligt – med verifikation af, at dataene kan bruges. Rotér, så alle kritiske systemer testes over en årrække.
Eksporten, der viser sig ubrugelig (PDF eller proprietært format) – og betalings-tokens, der ikke kan migreres. Begge opdages bedst i fredstid.
