Data og ejerskab
Dataeksport og exit-plan: kan appen flyttes, hvis I får brug for det?
En downloadknap eller en databasefil er ikke nødvendigvis en brugbar vej ud. Virksomheden skal kunne få kode, forretningsdata, filer, relationer, brugere og nødvendig konfiguration med videre – og bevise, at materialet kan læses og genopbygges uden den nuværende leverandør.
Exit-testen har et andet formål end backup
Backup skal normalt få den eksisterende løsning tilbage efter en fejl. En exit-test skal vise, at virksomheden kan forstå og genbruge sine aktiver på en anden konto, i et andet projekt eller på en anden platform. De to kontroller kan dele eksportværktøjer, men et leverandørstyret snapshot er ikke automatisk en flytbar exit-pakke.
Kortlæg det, appen består af
Tag udgangspunkt i appens faktiske dataflow. Hvis én del mangler, kan den nye løsning måske åbne data uden at kunne drive den samme arbejdsproces.
| Aktiv | Det skal med | Typisk skjult hul |
|---|---|---|
| Kode | Repository, branches, tags og nødvendig historik | Kun seneste ZIP-fil, ingen byggevejledning |
| Database | Skema, data, relationer, regler og migrationshistorik | CSV-filer uden id'er, datatyper eller relationer |
| Filer | Selve filerne, mappestruktur, metadata og kobling til poster | Links peger fortsat på den gamle leverandør |
| Brugere | Stabile bruger-id'er, roller og relevant identitetsdata | Loginudbyder, MFA eller adgangsregler kan ikke kopieres direkte |
| Drift | Miljøvariablernes navne, jobs, DNS, integrationer og runtime | Secrets eksporteres usikkert eller er kun kendt af én person |
Lav en exit-pakke, som en anden kan forstå
Pakken skal ikke kun indeholde bytes. Den skal forklare, hvordan delene hænger sammen, og hvad der bevidst ikke er med. Brug formater, som kan læses uden leverandørens egen brugerflade, hvor det er praktisk muligt.
- Manifest: Dato, kildeprojekt, eksportmetode, ansvarlig, filoversigt og kendte begrænsninger.
- Databeskrivelse: Tabeller eller collections, felter, datatyper, tidszoner, enheder, statusværdier og relationer.
- Stabile nøgler: Bevar id'er og forbindelser mellem kunder, ordrer, filer og brugere. Navne alene er sjældent nok.
- Kode og opskrift: Repository, låste afhængigheder, migrationsfiler og dokumenterede build- og deploymentkrav.
- Konfigurationsskabelon: Navne og formål for nødvendige værdier – uden at lægge aktive secrets i dokumentationen.
Et regneark kan være fint til en enkel tabel, mens relationelle data ofte kræver SQL, flere CSV-filer med nøgler eller et dokumenteret JSON-format. En visuel PDF kan supplere dokumentationen, men den er normalt dårlig som eneste format, når data skal genbruges.
Kontrollér platformens reelle eksportgrænser
Eksportkommandoer har forskelligt omfang. Brug dokumentationen til den konkrete stack, og antag ikke at ordet export betyder hele løsningen.
GitHub
Et mirror-clone kan medtage Git-repositoryets filer og revisionshistorik. GitHubs dokumentation gør samtidig opmærksom på, at andre arkivtyper ikke nødvendigvis indeholder alle tilknyttede data. Kontrollér derfor også eksempelvis LFS-objekter, pakker og projektmetadata efter jeres brug.
PostgreSQL og Supabase
PostgreSQLs pg_dump eksporterer én database konsistent, mens globale objekter som roller og tablespaces kræver særskilt håndtering. Supabasesdb dump er desuden som standard en skemaeksport uden data og brugerdefinerede roller; data og roller vælges eksplicit, og platformens administrerede auth- og storage-dele skal vurderes særskilt.
Firebase
Firestores administrerede eksport kan flytte dokumenter mellem projekter, men er ikke et præcist snapshot fra starttidspunktet. Hvis eksporten skal repræsentere en konsistent tilstand, beskriver Firebase en flytning, hvor skrivninger standses under eksporten. Brugerkonti eksporteres med en anden CLI-funktion til JSON eller CSV, og adgang til password-hashparametre skal behandles som følsom.
Bevis flytbarheden i et isoleret miljø
En fil, der kan downloades, er kun et løfte. Lav en afgrænset prøve, hvor materialet åbnes eller indlæses uden adgang til produktion. Testen behøver ikke være et fuldt leverandørskifte, men den skal ramme de aktiver, virksomheden ikke kan undvære.
- Sammenlign antal poster og filer pr. vigtig type før og efter eksporten.
- Slå konkrete kunder, ordrer og bilag op gennem deres stabile id'er og relationer.
- Kontrollér danske tegn, tomme værdier, beløb, datoer, tidszoner og store filer.
- Byg eller kør koden fra en frisk kopi med dokumenterede, nye testværdier.
- Afprøv hvem der kan læse eksporten, og slet testkopier sikkert efter den aftalte periode.
- Notér mangler, manuel efterbehandling, tidsforbrug og den person, som ejer næste test.
Beskyt eksporten som en følsom produktionskopi
En samlet exit-pakke kan være mere attraktiv end appens normale skærmbilleder, fordi den samler mange kunder og felter ét sted. Begræns derfor adgangen, brug en godkendt placering, registrér udlevering, og aftal hvornår midlertidige kopier slettes. Send ikke databasefiler, aktive nøgler eller passwordmateriale i almindelig email eller chat.
Dataportabilitet efter GDPR er en særskilt rettighed med bestemte betingelser. Den gælder ikke automatisk alle virksomhedens data, men EU-Kommissionen beskriver, at omfattede persondata skal kunne modtages i et struktureret, maskinlæsbart format. Brug derfor ikke den tekniske exit-plan som erstatning for en konkret juridisk vurdering.
Typiske fejl
- “Vi kan eksportere CSV”: Ingen har kontrolleret relationer, datatyper, filer eller skjulte platformstabeller.
- Backup kaldes en exit-plan: Kopien kan kun gendannes på samme leverandørkonto.
- Kun databasen flyttes: Kode, storage, auth, jobs, DNS og integrationsopsætning bliver glemt.
- Eksporten er ikke prøvet: Manglende felter og ødelagte tegn opdages først, når aftalen er opsagt.
- Secrets følger med i ZIP-filen: Flytningen skaber et nyt sikkerhedsbrud.
- Ingen ejer processen: Leverandør, systemejer og virksomhed antager hver især, at en anden har den nødvendige adgang.
Tjekliste til en brugbar exit-plan
- ☐ Kode, database, filer, brugere, konfiguration og drift er med i inventaret.
- ☐ Virksomheden ved, hvilke konti og projekter der ejer hvert aktiv.
- ☐ Eksportformat, metode, hyppighed og kendte begrænsninger er dokumenteret.
- ☐ Stabile id'er, relationer, datatyper, tidszoner og filkoblinger bevares.
- ☐ Kode kan hentes med nødvendig historik og bygges fra en frisk kopi.
- ☐ Auth, storage, roller og platformsspecifikke dele er kontrolleret særskilt.
- ☐ Aktive secrets ligger ikke i exit-pakken eller dens dokumentation.
- ☐ En isoleret test har bekræftet antal, stikprøver, relationer og kritiske brugerforløb.
- ☐ Adgang, sikker opbevaring, udlevering og sletning af eksportkopier er aftalt.
- ☐ Ansvarlig, seneste testdato, mangler og udløsende situationer står i runbooken.
Relaterede guides
Officielle kilder
Den præcise eksport afhænger af platform, datamodel, abonnement og den valgte målløsning. Kontrollér den aktuelle dokumentation, og test altid på jeres egen stack.