Fra .NET Framework til moderne .NET: Hvornår giver det mening?

Mange virksomheder har stabile og forretningskritiske løsninger bygget på .NET Framework. De virker hver dag og kan have gjort det i ti eller femten år. Derfor er "det er gammel teknologi" ikke i sig selv et argument for at skrive dem om.

Men der kommer et tidspunkt, hvor teknisk gæld begynder at koste: nye integrationer bliver sværere, deployment er tungt, biblioteker kan ikke opgraderes, eller udviklerne bruger stadig mere tid på at arbejde rundt om platformen. Her kan en modernisering være en god investering – hvis den angribes trinvis.

Modernisér af en forretningsmæssig grund

En migration bør have et tydeligt mål. Det kan være hurtigere releases, lettere rekruttering, lavere driftsrisiko, bedre understøttelse af cloud og containere eller muligheden for at bruge nyere biblioteker og integrationer.

Hvis systemet derimod er stabilt, sjældent ændres og ikke står i vejen for forretningen, kan målrettet vedligeholdelse være en bedre investering end en stor teknisk modernisering.

Hvor sidder de reelle bindinger?

Ældre .NET-løsninger er ofte tæt koblet til mere end selve frameworket. IIS, Windows Services, Web Forms, WCF, COM-komponenter, gamle NuGet-pakker, filshares eller særlige databasebiblioteker kan være de dele, der bestemmer migrationsvejen.

Derfor starter vi med et dependency map: Hvilke applikationer findes? Hvad kalder de? Hvem kalder dem? Hvilke komponenter kan flyttes isoleret, og hvilke er bundet tæt sammen?

Få build og deployment under kontrol først

Hvis kun én bestemt udviklermaskine kan bygge løsningen, er det et større problem end versionsnummeret på .NET. Før en migration bør build kunne reproduceres, kildekoden være komplet, og deployment være forstået.

Det samme gælder databaser, konfiguration og secrets. En modernisering bliver langt mere forudsigelig, når teamet først kan bygge og deploye den eksisterende løsning sikkert.

Tests er sikkerhedsnettet under migrationen

Man behøver ikke 90 procent testdækning før man går i gang. Men de vigtigste forretningsflows bør være beskyttet. Det kan være ordreoprettelse, prisberegning, login, fakturering eller kritiske integrationer.

Karakteriseringstests er særligt nyttige på legacy-systemer: De dokumenterer, hvordan løsningen faktisk opfører sig i dag, også når adfærden ikke er elegant. Dermed kan man ændre implementationen uden uforvarende at ændre forretningen.

Undgå den store rewrite, hvis I kan

Det fristende projekt er ofte: Vi bygger hele systemet på ny og skifter på én bestemt dato. Risikoen er, at teamet skal genopdage mange års små forretningsregler, samtidig med at den gamle løsning stadig skal vedligeholdes.

En trinvis strategi er ofte stærkere. Nye API'er, services, baggrundsjobs eller afgrænsede moduler kan flyttes til moderne .NET ét ad gangen. Den gamle og nye verden kan leve side om side, mens risikoen reduceres.

Modernisering betyder ikke automatisk microservices

At gå fra .NET Framework til moderne .NET kræver ikke, at en monolit samtidig bliver splittet i 30 services. Det introducerer nye driftsmæssige omkostninger og kan gøre en ellers enkel migration væsentligt større.

En velstruktureret modulær monolit på moderne .NET er for mange løsninger et glimrende mål. Arkitekturen bør vælges efter systemets reelle behov – ikke efter hvad der er moderne.

Cloud er en mulighed, ikke målet

Moderne .NET gør Linux, containere og cloud-platforme lettere at bruge. Det kan give mere fleksibel drift og bedre automatisering. Men on-premise eller klassisk hosting kan stadig være det rigtige valg afhængigt af compliance, netværk og integrationer.

En realistisk moderniseringsplan

Vi deler typisk arbejdet i tre spor: først stabilitet og overblik, derefter tekniske forudsætninger som tests og CI/CD, og til sidst den trinvise flytning af komponenter. Hvert skridt bør efterlade systemet i en bedre og fortsat driftbar tilstand.

Hvornår ville vi lade systemet være?

Hvis løsningen er stabil, sikker, billig at drive og næsten ikke ændres, kan den godt få lov at leve videre. Modernisering er mest værdifuld dér, hvor gammel teknologi faktisk begrænser ændringshastighed, sikkerhed eller forretning.

Uptime arbejder både med nye .NET-løsninger og med overtagelse og modernisering af eksisterende systemer. Det gør det muligt at forbedre løsningen uden at gøre en teknisk opgradering til et mål i sig selv.

Modernisering behøver ikke være en total rewrite. Start dér, hvor gammel .NET reelt begrænser sikkerhed, drift eller videreudvikling, og modernisér i kontrollerede trin.