Data, der bruges sammen, skal som regel ligge samme sted, og jo mere data der er, jo stærkere trækker den de programmer, der bruger den. Det kaldes datatyngde, og det forklarer, hvorfor et system, der teknisk kan flytte alene, kan høre sammen med andre.
Spørgsmålet melder sig, når en flytning skal ske i dele. Hvert system kan vurderes alene, men systemerne taler sammen. Flyttes det ene, og bliver det andet, går hver forespørgsel mellem dem over nettet mellem to steder. Det mærkes i svartid, i udgående datatrafik og i drift.
Hvad datatyngde betyder i praksis
Tre ting gør data tung:
Mængden. Store datamængder er langsomme at flytte og dyre at sende frem og tilbage. Et datalager, en filserver med mange års arkiv eller en database med lang historik flytter ikke på en weekend, og den kopi, der flyttes, skal holdes ajour, til omstillingen er sket.
Hyppigheden. Et program, der læser lidt data mange gange i sekundet, er følsomt over for afstand, selv om mængden er lille. Hver tur over nettet lægger tid til.
Bindingerne. Data bliver brugt af flere systemer: rapporter, integrationer, backup og analyse. Flyttes data, skal alle dem, der bruger den, enten flytte med eller vente længere på svar.
Vi giver ingen tal for, hvor meget svartiden stiger med afstand. Tallet hænger på jeres egne linjer og programmer, så det må måles i jeres miljø.
Tegn på, at to systemer skal ligge sammen
- Programmet laver mange små forespørgsler til databasen i stedet for få store.
- Brugerne mærker ventetid i dag, selv om alt ligger samme sted.
- Systemerne deler et filområde, som begge skriver til.
- En natlig kørsel flytter store mængder mellem dem.
- Rapporterne læser direkte i produktionsdatabasen.
Når et eller flere af tegnene passer, skal de to systemer behandles som én enhed i planen. De flytter samtidig, eller ingen af dem flytter.
Grænser, der følger med platformen
Platformene har deres egne grænser, der påvirker, hvordan data kan deles. En dataplatform, vi har læst dokumentationen for, kræver en konto pr. region, så data i to regioner betyder to konti, der skal holdes sammen. Et objektlager hos en stor udbyder opgiver grænser for antallet af forespørgsler pr. præfiks og øger ydelsen ved at dele data ud over flere præfikser. Den slags grænser afgør, om en arkitektur, der virker samlet, også virker delt. De skal læses i dokumentationen for den platform, I flytter til.
Udgående data, før og efter 2027
Data, der sendes ud af en udbyders net, koster ofte noget. En delt arkitektur sender data ud hver dag, så posten vokser med, hvor tæt systemerne taler sammen.
Data Act (dataforordningen) ændrer en del af det. Fra 12. januar 2027 må en udbyder ikke tage gebyr for selve skiftet til en anden udbyder, herunder udgående data i forbindelse med skiftet. Bruger I flere udbydere parallelt, kan udbyderen stadig kræve betaling for trafikken ud, dog højst til egen kostpris. Det er vores forenkling af art. 29 og art. 34, stk. 2. Den løbende trafik i en delt arkitektur er altså stadig en post efter 2027. Hvad reglen betyder i detaljer, står i udgående data.
Hvornår delt arkitektur bliver dyrere og langsommere
En delt arkitektur kan ende med at være værre end begge yderpunkter. Det sker, når de systemer, der flytter, taler meget med dem, der bliver. Så betaler I for to miljøer, for trafikken imellem dem og for driften af forbindelsen, og brugerne får længere svartid end før. Gevinsten ved flytningen skal være stor nok til at bære det.
Det modsatte findes også. Systemer, der kun udveksler data en gang i døgnet, kan sagtens ligge hvert sit sted. Delvis flytning virker bedst, når snittet lægges, hvor der i forvejen er lidt trafik. Læs delvis flytning.
Sådan finder I snittet
Tegn systemerne og forbindelserne mellem dem. Sæt for hver forbindelse et mærke for mængde og hyppighed: lille eller stor, sjælden eller hyppig. Mål, hvor I kan, ved at se på netværkstrafik og databaselogs over en almindelig uge og en månedsafslutning.
Snittet lægges dér, hvor forbindelserne er få og små. Systemer, der hænger sammen med store og hyppige forbindelser, samles i én gruppe, og gruppen flytter samlet eller bliver samlet.
Hvad det kræver, og hvad det koster at lade være
Tegningen kræver en arkitekt eller IT-chef og adgang til netværks- og databasemålinger. Med et begrænset antal systemer tager selve tegningen få dage, og dertil kommer den uge, hvor målingerne løber. Resultatet er grupperne og et snit, der kan forklares.
Uden tegningen opdages tyngden efter flytningen. Brugerne klager over et system, der før var hurtigt, regningen for udgående data stiger, og det første system må flyttes tilbage eller vente på, at resten følger efter. Det koster to omstillinger og den tid, de to miljøer skal leve side om side.
Det skal I lade være med
- At vurdere systemer, som om de stod alene · forbindelserne mellem dem afgør, om de kan skilles.
- At regne udgående data for løst i 2027 · gebyrforbuddet gælder skiftet og ikke den løbende trafik ved parallel brug.
- At gætte svartider · mål dem i jeres eget miljø, før snittet lægges.
Det skal valget kunne vise
- ☐ En tegning af systemer og forbindelser med mængde og hyppighed.
- ☐ Grupper af systemer, der flytter eller bliver samlet.
- ☐ Målinger fra en almindelig uge og en travl periode.
- ☐ Udgående data i ord for den delte periode og efter flytningen.
Kilder
- Snowflake Documentation, Supported cloud regions, https://docs.snowflake.com/en/user-guide/intro-regions, læst 8. november 2026.
- AWS, Best practices design patterns: optimizing Amazon S3 performance, https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html, læst 8. november 2026.
- Forordning (EU) 2023/2854 (Data Act), art. 29 og art. 34, stk. 2, https://eur-lex.europa.eu/eli/reg/2023/2854/oj, gengivet forenklet, november 2026.
Senest gennemgået: november 2026.
Næste skridt
Tegn de ti vigtigste systemer og forbindelserne mellem dem. Det viser, hvor et snit kan lægges.
Læs også: Data og lagring til AI · Hybrid cloud
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
