Migration
Cloud-migration fra legacy og on-prem
Vi flytter applikationer og data fra legacy-platforme til moderne cloud — i etaper, med klare exit-kriterier og en plan for hvad der skal med, hvad der skal genskrives og hvad der skal lægges i graven.
Migration uden big-bang
Sådan vi flytter uden at vælte forretningen
- Ét workload ad gangen, ikke alt på én weekend
- Trinvis
- Gammel og nyt sameksisterer under verificering
- Parallel
- Data-checks før hver cutover
- Validation
- Hvert skridt har en eksplicit exit-plan
- Rollback
Sådan vi flytter til cloud
Trinvis migration — uden big-bang-cutover.
Cloud-migrationer går galt på de samme måder hver gang: alt skal være færdigt på én gang, der er ikke en ærlig opgørelse over hvad der reelt skal med, og når noget ikke virker i det nye miljø, ryger man hurtigt tilbage til den gamle stack — denne gang med to systemer at vedligeholde. Vi arbejder anderledes: ét workload ad gangen, parallel-drift hvor det giver mening, og en exit-strategi for hvert skridt så ingen overraskelser kan låse os.
Vi starter altid med en kortlægning. Hvad kører der faktisk i dag, hvilke systemer afhænger af hvad, hvor er data følsom og hvor er den bare gammel? Resultatet er en ærlig liste: hvad kan løftes som det er (lift-and-shift), hvad bør re-platformes (samme funktion, ny stack), hvad bør re-skrives (gammel kode der koster mere at flytte end at genopfinde), og hvad bør lægges i graven. Den liste er det vigtigste dokument i hele projektet.
Vi flytter til den cloud der passer jer — typisk Cloudflare for edge-tunge workloads, Vercel for Next.js-applikationer, AWS for det der har brug for kerne-tjenester (RDS, S3, SQS), eller en kombination. Vi har ingen incitament til at sælge én leverandør frem for en anden — vores incitament er at I aldrig fortryder valget om to år.
Hvad I får leveret
En migration der ikke vælter forretningen.
Discovery, parallel-drift, datavalidering og en exit-plan for hvert skridt.
Discovery og workload-kortlægning
Vi starter med 1–2 ugers gennemgang af jeres nuværende setup: dependency-graf, dataejerskab, integrationer, drifts-team, compliance-krav. I går fra discovery med en konkret migrationsplan, ikke et powerpoint.
Trinvis migration med parallel-drift
Vi flytter ét workload ad gangen og kører det i parallel med det gamle system så længe der er behov for verificering. Trafikken skifter trinvist via DNS eller en API-gateway — ingen big-bang-cutover-weekender.
Data-migration med validering
Data flyttes med scripts der både migrerer og validerer (record counts, checksum, stikprøve-sammenligning). Vi kører delta-syncs så længe gammel og nyt sameksisterer, så I aldrig taber data der blev oprettet midt i migrationen.
Re-platforming hvor det giver mening
Nogle workloads bør ikke bare flyttes — de bør re-platformes til managed services. En selvhosted PostgreSQL bliver til RDS eller Supabase. En cron-server bliver til Lambda eller Vercel Cron. Vi vurderer pr. workload om indsatsen betaler sig.
Sikkerhed og adgang fra start
Identity-platformen designes inden første workload flytter. IAM-roller, secret-management (AWS Secrets Manager, Doppler), netværks-segmentering og audit-logning er på plads før vi sætter første container i drift.
Klar exit-strategi for hvert skridt
Hver migrations-etape har en defineret rollback-plan før vi går i gang. Hvis noget ikke virker i produktion, peger vi DNS'en tilbage og tager en runde til. Det skal være ufarligt at flytte — ellers bliver det aldrig gjort.
Inden vi går i gang
Det her bør I overveje først.
Lift-and-shift vs. re-platforming
Lift-and-shift er hurtigst og billigst i første omgang, men I tager også de gamle drifts-vaner med jer. Re-platforming koster mere op front, men giver jer den drift og det udviklertempo I egentlig migrerede for at opnå. Vi anbefaler typisk en blanding: lift-and-shift for tidskritiske workloads, re-platforming for det der får mest gavn af managed services.
Dependency-graf og rækkefølge
I kan ikke flytte et workload før dets afhængigheder er flyttet (eller tilgængelige fra den nye lokation). Vi bruger discovery-fasen på at lave dependency-grafen og finde rækkefølgen — typisk de mindst koblede systemer først, så de mest centrale, så det allerinderste.
Drift under migrationen
Migration er ikke et frys-perioden hvor jeres team holder pause. Forretningen kører videre, der kommer fortsat support-sager og features ind. Vi designer migrationen så den ikke blokerer for normal udvikling — typisk ved at det gamle system fortsat tager nye ændringer indtil det workload skal flyttes.
Compliance, GDPR og data-residency
Skal data forblive i EU? Er der ISAE-3402-krav på drift? Har I sundhedsdata under særlige regler? Det skal afklares i discovery — det styrer både cloud-valg, region-valg og hvilke managed services der er på listen. Vi designer efter compliance-rammen, ikke omvendt.
FAQ
Det folk plejer at spørge om.
Hvor lang tid tager en typisk migration?
Det afhænger helt af antal workloads, deres afhængigheder og jeres tolerance for parallel-drift. En enkelt monolitisk applikation kan flyttes på 4–8 uger. En portefølje på 10–20 services med dybe interne afhængigheder tager typisk 4–9 måneder fordelt over flere etaper. Vi giver et realistisk estimat efter discovery — ikke før.
Skal vi flytte alt eller kan vi gøre det gradvist?
Gradvist. Vi anbefaler stort set aldrig at flytte alt på én gang. Trinvis migration giver jer mulighed for at lære den nye platform mens den gamle stadig kører, fange overraskelser tidligt, og rulle tilbage hvis noget ikke virker — uden at hele forretningen står stille.
Hvad med vores legacy-systemer der ingen længere forstår?
Det er ofte den vanskeligste del — og den vi bruger mest tid på i discovery. Hvis kildekoden findes, læser vi den. Hvis ikke, dokumenterer vi systemets reelle adfærd via observation: hvilke API-kald laver det, hvilke data læser/skriver det, hvad er edge cases. Først når vi forstår det reelt, beslutter vi om det skal lift-and-shiftes, re-skrives eller udfases.
Kan vi kombinere flere clouds?
Ja, og det er ofte den rigtige løsning. Vi har sat opsætninger med Cloudflare-edge foran Vercel-frontend foran AWS-backend, eller med Azure for AD-integrerede tjenester og AWS for resten. Multi-cloud er kompleksitet — men det er ofte den letteste vej når en enkelt leverandør ikke dækker alle krav.
Hvordan håndterer I downtime under cutover?
Med ordentlig forberedelse er der typisk ingen mærkbar downtime. Vi sætter den nye platform op i parallel, syncer data løbende, og skifter trafikken over via DNS eller en API-gateway når den nye er verificeret. For workloads hvor en kort vedligeholdelses-window er acceptabel, planlægger vi den i god tid og kommunikerer det ud til slutbrugerne.
Relaterede ydelser
- CloudflareDNS, WAF, Workers, R2 og Pages — sat korrekt op fra start, så Cloudflare faktisk arbejder for dig.
- VercelHosting, preview-deploys og edge-functions sat op så Next.js leverer det Vercel lover.
- AWSECS, Lambda, RDS, S3 og VPC — designet, kodet i Terraform og driftet med observability fra dag ét.
Klar til at starte?
Lad os tage en uforpligtende snak.
Vi vender tilbage indenfor en arbejdsdag med konkret input — ikke et standardtilbud.