Modernisér det system, ingen tør røre, én funktion ad gangen.
Årtiers forretningsregler ligger i COBOL, PL/I, Oracle Forms og tidlig Java og .NET. Vi genfinder reglerne, bygger et sikkerhedsnet af test og flytter funktion for funktion bag en facade, med parallelkørsel og afstemning, før noget bliver slukket.
For organisationer med kritiske systemer, hvor nedetid og tabte forretningsregler ikke kan accepteres.
Porteføljen vurderes, og målet aftales. Forretningsreglerne genfindes i koden med hjælp fra AI og kontrolleres af mennesker. Karakteriseringstest danner et sikkerhedsnet. Hver funktion genopbygges bag en facade og kører parallelt med det gamle system; forskelle vurderes og rettes, før forretningsejeren godkender skiftet, og den gamle del udfases.
Før og efter
Det ændrer sig i arbejdet
I dag
Med systemet
I dag
I dag: Hver ændring er en risiko
Små lovændringer tager måneder, fordi ingen kan forudsige, hvad en ændring ellers påvirker.
Med systemet
Med systemet: Ændringer med test bag sig
Karakteriseringstest fastholder, hvad systemet gør i dag, så hver ændring viser sin virkning før frigivelse.
I dag
I dag: Viden går på pension
De folk, der forstår koden, nærmer sig pensionsalderen, og dokumentationen holdt for længst op med at passe til systemet.
Med systemet
Med systemet: Regler skrevet ned og bekræftet
Forretningsregler, der genfindes i koden, dokumenteres i et klart sprog og bekræftes af fageksperter.
I dag
I dag: Big bang-planer går i stå
Store udskiftningsprogrammer lover én dato for overgangen, som bliver ved med at flytte sig, mens omkostningerne vokser.
Med systemet
Med systemet: Værdi i bidder
Funktionerne flytter én ad gangen bag en facade. Hver bid går i drift for sig og kan rulles tilbage.
I dag
I dag: Data låst i gamle strukturer
Nye tjenester og AI-anvendelser kan ikke nå dataene uden skrøbelige udtræk og natlige batchkørsler.
Med systemet
Med systemet: Data tilgængelige via API’er
Migrerede områder stiller deres data til rådighed via dokumenterede API’er, afstemt med det gamle system, indtil det udfases.
Forløb
Sådan kører forløbet
En strangler fig-tilgang: det nye system vokser frem omkring det gamle, funktion for funktion. Sløjfen mellem parallelkørsel og genopbygning er der, hvor det meste af det egentlige arbejde sker.
Eksempel på et forløb
7 trin · 3 menneskelige kontroller
Signaturforklaring
System
AI-agent
Person
Menneskelig kontrol
Undtagelsesforløb
Modernisering af legacy: eksempel på et forløb med afstemningssløjfe
Læs diagrammet som tekst
Hovedforløbet går fra vurdering af porteføljen og genfinding af forretningsreglerne, over et sikkerhedsnet af karakteriseringstest og genopbygning af én funktion bag en facade, til parallelkørsel af gammelt og nyt og til sidst skift og udfasning af den gamle del.
Mennesker godkender målarkitekturen, kontrollerer hver genfunden regel og godkender hvert skift: det er de menneskelige kontroller.
Når parallelkørslen viser forskelle i output, forlader bidden hovedforløbet og vurderes af udviklere og fageksperter. Den går tilbage til genopbygningen, indtil gammelt og nyt stemmer overens.
01
Trin 1: Vurdér porteføljenPerson
Oversigt over applikationer, kortlægning af afhængigheder og dataflow og en beslutning pr. applikation: udfase, beholde, flytte uændret, flytte til ny platform, genopbygge eller udskifte. Domænerne kortlægges for at finde de snitflader, hvor systemet kan deles op.
Menneskelig kontrol
Dit arkitekturråd godkender målarkitekturen og rækkefølgen af bidderne.
02
Trin 2: Genfind forretningsreglerneAI-agent
AI-assisteret kodeforståelse læser COBOL, PL/I, JCL, Oracle Forms og ældre Java eller .NET og skriver udkast til dokumentation, kaldgrafer og et katalog over forretningsregler.
Menneskelig kontrol
Udviklere og fageksperter kontrollerer hver udtrukket regel, før den bruges som specifikation. Regler, der ikke er kontrolleret, markeres som sådan.
03
Trin 3: Byg sikkerhedsnettetSystem
Karakteriseringstest genereres ud fra anonymiserede input og output fra produktionen, så den nuværende adfærd, med alle dens særheder, er fastholdt, før noget ændres.
04
Trin 4: Genopbyg en bid bag en facadeSystem
En routingfacade eller et API-lag placeres foran det gamle system. Én funktion genopbygges som en ny tjeneste, og dens data migreres og holdes synkroniseret.
05
Trin 5: Kør parallelt og afstemSystem
Det gamle og det nye system behandler de samme transaktioner. Output og data sammenlignes automatisk, og hver forskel rapporteres pr. regel og pr. post.
06
Trin 6: Vurdér forskellenePerson
Udviklere og fageksperter afgør, om hver forskel er en fejl i den nye tjeneste, en fejl i den gamle eller en tilsigtet ændring, og sender bidden tilbage til genopbygning.
Undtagelsesforløb: Output er forskelligt· Fortsætter ved trin 4
07
Trin 7: Skift over og udfasPerson
Trafikken for funktionen flyttes til den nye tjeneste via facaden. Efter en stabil periode udfases den gamle kodevej og dens data, og de arkiveres.
Menneskelig kontrol
Forretningsejeren godkender hvert skift på grundlag af afstemningsresultaterne. Tilbagerulning via facaden er mulig, indtil den gamle del er udfaset.
Komponenter
Det ville vi bygge
01
Kort over portefølje og afhængigheder
Oversigt, kortlægning af snitflader og dataflow og en domænemodel, der viser, hvor systemet kan deles op i bidder.
Kodeanalysen kører i et miljø, du kontrollerer, og ingen kildekode sendes til tjenester, du ikke har godkendt. Produktionsdata til test anonymiseres, før de forlader produktionsmiljøet.
Menneskelig gennemgang
Genfundne regler kontrolleres af udviklere og fageksperter, før de bliver til specifikationer. Hvert skift godkendes af forretningsejeren på grundlag af afstemningsresultaterne, og tilbagerulning er mulig.
Sporbarhed
Hver regel i kataloget kan spores tilbage til den kode, den kom fra, og til den person, der kontrollerede den. Afstemningsrapporter gemmes som dokumentation for hvert skift.
Databeskyttelse
Datamigreringen følger en dokumenteret mapping med antal poster og kontrolsummer, og personoplysninger minimeres i testsæt. Reglerne for opbevaring følger med dataene.
Gennemsigtighed om AI
Hvor AI skriver udkast til dokumentation eller kode, bliver resultatet markeret, gennemgået og versioneret som ethvert andet udviklingsprodukt.
Målepunkter
Det ville vi måle
Målepunkterne aftaler vi med dig under vurderingen og følger dem pr. bid, ikke kun for programmet som helhed.
Det ville vi måle
Målepunkt
Hvorfor det er vigtigt
Sådan ville vi måle det
01Gennemløbstid for ændringer
Hvorfor det er vigtigtDet tydeligste tegn på, at systemet bliver lettere at ændre.
Sådan ville vi måle detTid fra godkendt ændringsønske til produktion, for de gamle og de moderniserede dele.
02Afstemningsstatus
Hvorfor det er vigtigtViser, om den nye tjeneste virkelig opfører sig som den gamle, hvor den skal.
Sådan ville vi måle detAndelen af transaktioner og poster, der stemmer under parallelkørslen, med åbne forskelle fordelt på årsag.
03Regeldækning
Hvorfor det er vigtigtUkendte regler er den største risiko ved enhver udskiftning.
Sådan ville vi måle detAndelen af genfundne forretningsregler, der er kontrolleret af fageksperter og dækket af test.
04Tilbageværende legacy
Hvorfor det er vigtigtModernisering betaler sig, når gamle komponenter faktisk bliver slukket.
Sådan ville vi måle detUdfasede funktioner, kodeveje, batchjob og licenser, fulgt pr. bid.
Vi sætter ingen mål, før der er en baseline.
Udrulning
Sådan ville vi rulle det ud
Fase 01
Vurdering
Portefølje, afhængigheder, domæner og risici. Vi vælger en første bid, der betyder noget for forretningen, men som kan rulles tilbage.
Kriterier for at gå videre
Målarkitektur godkendt
Rækkefølge af bidder aftalt
Adgang til test og data på plads
Fase 02
Første bid
Genfinding af regler, sikkerhedsnet, facade og én genopbygget funktion, kørt parallelt med det gamle system.
Kriterier for at gå videre
Afstemning inden for den aftalte tolerance
Forretningsejeren godkender skiftet
Tilbagerulning testet
Fase 03
Bid for bid
Flere funktioner følger samme vej, hver med sin egen parallelkørsel og beslutning om skift.
Kriterier for at gå videre
Hver bid afstemt og skiftet
Viden overført til dit team
Fase 04
Udfasning
Gamle kodeveje, batchjob og datalagre arkiveres og slukkes.
Ydelses-, opkrævnings- og registreringssystemer i kommuner og styrelser, hvor lovgivning er kodet ind i årtier gammel kode, og ændringerne bliver ved med at komme.
Egenudviklede ERP-udvidelser og produktionssystemer, der flyttes sammen med en migrering til SAP S/4HANA.
Eksempel
Policesystemet i et forsikringsselskab
Situation
Et forsikringsselskab beregner præmier og administrerer policer i et årtier gammelt mainframesystem. Nye produktregler venter i kø, og to af de udviklere, der kender koden, går snart på pension.
System
Reglerne genfindes og kontrolleres pr. produkt. En facade sender først præmieberegningen for ét produkt til en ny tjeneste, der kører parallelt med mainframen, indtil resultaterne stemmer.
Menneskelig kontrol
Fageksperter for hvert produkt kontrollerer deres regler. Forretningsejeren godkender skiftet, og tilbagerulning via facaden er fortsat mulig.
Det ville vi måle
Afstemningsstatus pr. produkt, regeldækning og gennemløbstid for den næste ændring af produktreglerne.
Danmark
Modernisering med NIS 2-loven i tankerne
Mange organisationer kører en ældre kerne, som lovændringer og nye krav hele tiden skal bygges ind i. Vi lægger moderniseringen i en rækkefølge, så hver bid flyttes for sig, og gammelt og nyt er afstemt, før noget bliver slukket.
NIS 2-loven har været i kraft siden 1. juli 2025 med Styrelsen for Samfundssikkerhed (SAMSIK) som kompetent myndighed og sektormyndigheder for de enkelte sektorer. De nye tjenester lander derfor på platforme, der er designet efter lovens krav til sikkerhed, og dataforordningens regler om skift af udbyder er en grund til at holde data flytbare fra første bid. Hvor posterne indeholder personoplysninger, følger mapping og testdata GDPR, og for banker, pensionskasser og forsikringsselskaber gælder også DORA.
Fordi én samlet overgang lægger hele risikoen på én dato, og forretningen venter i årevis på en gevinst. Når du flytter funktion for funktion, kan hver bid bevise sig i en parallelkørsel, gå i drift for sig og rulles tilbage, hvis det bliver nødvendigt.
02Kan AI oversætte vores COBOL til Java?
Oversættelse linje for linje giver som regel kode, der er lige så svær at ændre som originalen. Vi bruger AI til at læse og dokumentere den gamle kode og til at skrive udkast til regler og test, og derefter designer vi de nye tjenester ordentligt. Hver genfunden regel kontrolleres af mennesker, før den bruges.
03Vores eksperter går på pension. Hvordan fanger I det, de ved?
Gennem strukturerede sessioner, hvor eksperterne gennemgår de genfundne regler og karakteriseringstestene. Deres viden ender i dokumentation og test, der bliver hos dit team, ikke i vores hoveder.
04Gælder det også SAP ECC?
Ja. De samme principper gælder for oprydning i egenudviklet kode og en migrering til SAP S/4HANA: vurdér, hvad der stadig bruges, genfind og test det, der betyder noget, og flyt i kontrollerede trin.
05Hvor længe kører gammelt og nyt side om side?
Indtil afstemningsresultaterne ligger inden for den tolerance, der er aftalt med forretningsejeren, og længe nok til at dække periodiske kørsler som månedsafslutning eller årlige kørsler.