Om en database er let eller svær at flytte, afhænger først og fremmest af motoren. En database på en åben motor, som I selv driver, flytter med data og konfiguration; en database på udbyderens egen motor eller som færdig tjeneste kræver, at I finder ud af, hvad der følger med ud, og det afgør ofte tidsplanen for hele flytningen.
Når ledelsen taler om at flytte, er det måske ikke databasen, den tænker på. Den er det, de andre systemer står på. Et program kan flyttes på en eftermiddag, hvis dets database er på plads. Er den ikke, venter alt andet.
Tre slags databaser, tre forskellige svar
En åben motor, I selv driver. PostgreSQL, MySQL og MariaDB på en virtuel server. Motoren findes alle steder, også på egne servere, og PostgreSQL er udgivet under en liberal open source-licens på linje med BSD og MIT. Flytningen er en kopi af data, en omstilling og en test. Arbejdet ligger i datamængden og i at holde nedetiden nede.
En administreret database med en åben motor. Udbyderen driver databasen, og I bruger den. Motoren er den samme som andre steder, så data kan flyttes. Men driften er udbyderens: sikkerhedskopier, opdateringer, overvågning og indstillinger. Alt det skal genskabes på det nye sted, enten hos en ny udbyder, der tilbyder samme motor, eller hos jer selv.
Udbyderens egen motor. En af de store udbydere har sin egen databasemotor og skriver, at den er kompatibel med MySQL og PostgreSQL, så kode, værktøjer og programmer kan bruges med den. Det er udbyderens ord. Hvad der ikke følger med den anden vej, ud af motoren, står ikke i den beskrivelse. Det kan være udvidelser, særlige funktioner til replikering eller ydelse og den måde, sikkerhedskopierne er lavet på. Det skal I teste selv.
Migreringsværktøjet ligger hos den, I forlader
En stor udbyder har et værktøj, der kan flytte data mellem forskellige databasemotorer og omskrive skemaer undervejs. Det er nyttigt. Læg mærke til, hvor værktøjet ligger. Det kører hos den udbyder, I flytter fra. Bruges det til at komme ud, er I afhængige af, at det fortsat er til rådighed og virker på den måde, I har planlagt, til flytningen er færdig.
Uanset hvilket værktøj I bruger, skal det prøves på en kopi af produktionsdata, før det bruges til omstillingen.
Det, der afgør tidsplanen
Datamængden og nettet. En stor database tager tid at kopiere, og ændringerne undervejs skal også med. Jo større databasen er, jo vigtigere er det at kunne replikere løbende, så omstillingen kun er de sidste ændringer.
Nedetiden. Hvor længe må systemet stå stille? Svaret afgør metoden. Kan det stå en weekend, er en kopi og en genstart nok. Kan det kun stå minutter, skal databasen replikeres til det nye sted og skiftes over, når de to er ens.
Afhængighederne. Hvilke programmer læser og skriver i databasen, og hvor står de? Flytter databasen før programmerne, går hver forespørgsel over nettet mellem to steder. Det kan gøre programmerne langsomme. Læs datatyngde og svartid.
Licensen. SQL Server har egne regler for licens pr. kerne og pr. virtuel maskine, for hvornår licenser må flyttes mellem serverfarme, og for brug hos en hostingleverandør. Det gennemgås i licensreglerne for SQL Server og Windows Server. Kendes licensreglerne ikke, kan flytningen være teknisk klar og stadig ikke lovlig at gennemføre.
Testen, der viser, at det virker
En database er flyttet, når programmerne giver de samme svar som før. Det kræver en test, applikationsejeren har skrevet på forhånd: hvilke rapporter skal stemme, hvilke transaktioner skal kunne gennemføres, og hvor hurtigt skal de vigtigste forespørgsler svare? Uden den test er det kun databasen, der er flyttet. Om systemet virker, ved ingen.
Gendannelse hører med. Tag en sikkerhedskopi på det nye sted, og gendan den, før den gamle database lukkes.
Hvad det kræver, og hvad det koster at lade være
For hver database skal I kende motor, størrelse, tilladt nedetid, hvem der bruger den, og hvilken licens den kører på. For en database på en åben motor er det et par timers afklaring. For en database på udbyderens egen motor skal der lægges dage til en prøveflytning og en test af det, der ikke følger med. Overslaget for selve flytningen gives i dage for en databaseadministrator og en applikationsejer, med en lav og en høj vurdering.
Springes afklaringen over, bliver databasen det, der stopper flytningen sent i forløbet. Programmerne er klar, det nye miljø kører, og så viser det sig, at databasen bruger en funktion, der ikke findes på det nye sted, eller at licensen ikke må flyttes. Så kører to miljøer side om side, mens det løses, og den tid betales to gange.
Det skal I lade være med
- At stole på en kompatibilitetserklæring uden prøve · kun en test af jeres egne data viser forskellene.
- At flytte databasen uden programmerne eller omvendt · svartiden mellem dem kan ændre sig mere end ventet.
- At lukke den gamle database før en gendannelse er prøvet · sikkerhedskopien skal virke på det nye sted.
Det skal valget kunne vise
- ☐ Motor, størrelse og tilladt nedetid for hver database.
- ☐ Funktioner og udvidelser, der bruges, og om de findes på det nye sted.
- ☐ Licensstatus for databaser med regler om flytning.
- ☐ Testen skrevet af applikationsejeren før flytningen.
- ☐ En gendannelse udført på det nye sted.
Kilder
- PostgreSQL, License, https://www.postgresql.org/about/licence/, læst 8. november 2026.
- AWS, What is Amazon Aurora?, https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html, læst 8. november 2026.
- AWS, What is AWS Database Migration Service?, https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html, læst 8. november 2026.
- Microsoft, Product Terms for SQL Server, https://www.microsoft.com/licensing/terms/productoffering/SQLServer/MCA, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Lav en liste over jeres databaser med motor, størrelse og tilladt nedetid. Den viser hurtigt, hvilke der styrer tidsplanen.
Læs også: Virtuelle servere · Omstillingen
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
