Modernisera systemet som ingen vågar röra, en förmåga i taget.
Årtionden av verksamhetsregler finns i COBOL, PL/I, Oracle Forms och tidig Java och .NET. Vi tar fram reglerna, bygger ett skyddsnät av tester och flyttar en förmåga i taget bakom en fasad, med parallellkörning och avstämning innan något stängs av.
För statliga myndigheter, försäkringsbolag och industriföretag i Sverige med verksamhetskritiska system där driftstopp och förlorade regler inte är ett alternativ.
Systemportföljen bedöms och målbilden fastställs. Verksamhetsreglerna tas fram ur koden med stöd av AI och verifieras av människor. Karakteriseringstester bildar ett skyddsnät. Varje förmåga byggs om bakom en fasad och körs parallellt med det gamla systemet; avvikelser utreds och åtgärdas innan verksamhetsägaren godkänner bytet och den gamla delen avvecklas.
Före och efter
Vad som ändras i arbetssättet
I dag
Med systemet
I dag
I dag: Varje ändring är en risk
Små ändringar i regelverket tar månader, eftersom ingen kan förutse vad mer en ändring påverkar.
Med systemet
Med systemet: Ändringar med tester i ryggen
Karakteriseringstester fångar vad systemet gör i dag, så att varje ändring visar sin effekt före driftsättning.
I dag
I dag: Kunskapen går i pension
De som förstår koden närmar sig pensionen, och dokumentationen slutade stämma med systemet för länge sedan.
Med systemet
Med systemet: Regler som är nedskrivna och verifierade
Verksamhetsregler som har tagits fram ur koden dokumenteras så att verksamheten kan läsa dem, och bekräftas av verksamhetsexperter.
I dag
I dag: Planer på ett enda stort byte fastnar
Program för att ersätta allt på en gång lovar ett enda datum för bytet, som hela tiden flyttas medan kostnaderna växer.
Med systemet
Med systemet: Nytta i etapper
Förmågorna flyttas en i taget bakom en fasad. Varje etapp tas i drift för sig och kan backas.
I dag
I dag: Data inlåsta i gamla strukturer
Nya tjänster och användningsfall för AI når inte data utan sköra uttag och nattliga batchkörningar.
Med systemet
Med systemet: Data tillgängliga via API:er
Migrerade områden gör sina data tillgängliga via dokumenterade API:er och stäms av mot det gamla systemet tills det avvecklas.
Arbetsflöde
Så fungerar arbetsflödet
Vi följer strypfikonmönstret (strangler fig): det nya systemet växer fram runt det gamla, en förmåga i taget. Loopen mellan parallellkörning och ombyggnad är där det mesta av det verkliga arbetet sker.
Exempel på arbetsflöde
7 steg · 3 mänskliga kontrollpunkter
Teckenförklaring
System
AI-agent
Människa
Mänsklig kontrollpunkt
Undantagsflöde
Modernisering av äldre system: exempel på arbetsflöde med avstämningsloop
Läs diagrammet som text
Huvudflödet går från bedömningen av portföljen och framtagningen av verksamhetsreglerna, via ett skyddsnät av karakteriseringstester och ombyggnaden av en förmåga bakom en fasad, till parallellkörning av gammalt och nytt och slutligen bytet och avvecklingen av den gamla delen.
Människor godkänner målarkitekturen, verifierar varje framtagen regel och godkänner varje byte: det är de mänskliga kontrollpunkterna.
När parallellkörningen visar att utdata skiljer sig åt lämnar etappen huvudflödet för utredning av utvecklare och verksamhetsexperter, och går tillbaka till ombyggnadssteget tills gammalt och nytt stämmer överens.
01
Steg 1: Bedöm portföljenMänniska
Förteckning över applikationer, kartläggning av beroenden och dataflöden och ett beslut per applikation: avveckla, behålla, flytta, anpassa, bygga om eller ersätta. Områdena kartläggs för att hitta de skarvar där systemet kan delas upp.
Mänsklig kontrollpunkt
Din arkitekturgrupp godkänner målarkitekturen och ordningen för etapperna.
02
Steg 2: Ta fram verksamhetsreglernaAI-agent
AI-stödd kodförståelse läser COBOL, PL/I, JCL, Oracle Forms och äldre Java eller .NET och tar fram utkast till dokumentation, anropsgrafer och en katalog över verksamhetsregler.
Mänsklig kontrollpunkt
Utvecklare och verksamhetsexperter verifierar varje framtagen regel innan den används som specifikation. Overifierade regler markeras som sådana.
03
Steg 3: Bygg skyddsnätetSystem
Karakteriseringstester tas fram ur avidentifierade indata och utdata från produktion, så att dagens beteende, inklusive egenheterna, fångas innan något ändras.
04
Steg 4: Bygg om en del bakom en fasadSystem
En fasad som styr trafiken, eller ett API-lager, placeras framför det gamla systemet. En förmåga byggs om som en ny tjänst, och dess data migreras och hålls synkroniserade.
05
Steg 5: Kör parallellt och stäm avSystem
Gammalt och nytt behandlar samma transaktioner. Utdata och data jämförs automatiskt, och varje skillnad rapporteras per regel och per post.
06
Steg 6: Utred avvikelserMänniska
Utvecklare och verksamhetsexperter avgör om varje skillnad är ett fel i den nya tjänsten, ett fel i den gamla eller en avsiktlig ändring, och skickar tillbaka etappen för omarbetning.
Undantagsflöde: Utdata skiljer sig åt· Återgår till steg 4
07
Steg 7: Byt och avvecklaMänniska
Trafiken för förmågan flyttas till den nya tjänsten via fasaden. Efter en stabil period avvecklas och arkiveras den gamla kodvägen och dess data.
Mänsklig kontrollpunkt
Verksamhetsägaren godkänner varje byte utifrån avstämningsresultaten. Det går att backa via fasaden fram till avvecklingen.
Komponenter
Det här skulle vi bygga
01
Karta över portfölj och beroenden
Förteckning, kartläggning av gränssnitt och dataflöden och en domänmodell som visar var systemet kan delas upp.
Salesforce som nytt kundgränssnittPlattformSalesforce
Integrationsplattform och API-gateway
Målmiljö i moln eller datacenter
Kontroller
Inbyggda kontroller
Åtkomstgränser
Kodanalysen körs i en miljö som du kontrollerar, och ingen källkod skickas till tjänster som du inte har godkänt. Produktionsdata som används för tester avidentifieras innan de lämnar produktionsmiljön.
Mänsklig granskning
Framtagna regler verifieras av utvecklare och verksamhetsexperter innan de blir specifikationer. Varje byte godkänns av verksamhetsägaren utifrån avstämningsresultaten, och det går att backa.
Spårbarhet
Varje regel i katalogen kan spåras till den kod den kommer från och till den som verifierade den. Avstämningsrapporterna sparas som underlag för varje byte.
Dataskydd
Datamigreringen följer en dokumenterad mappning med antal poster och kontrollsummor, och personuppgifter minimeras i testdata. Gallringsreglerna följer med data, så att din informationshanteringsplan gäller även i det nya systemet.
Transparens kring AI
Där AI tar fram utkast till dokumentation eller kod märks resultatet, granskas och versionshanteras som allt annat i utvecklingsarbetet.
Mått
Det här skulle vi mäta
Vi kommer överens med dig om måtten under bedömningen och följer dem per etapp, inte bara för programmet som helhet.
Det här skulle vi mäta
Mått
Varför det är viktigt
Så skulle vi mäta det
01Ledtid för ändringar
Varför det är viktigtDet tydligaste tecknet på att systemet blir lättare att ändra.
Så skulle vi mäta detTid från godkänd ändringsbegäran till produktion, för de gamla och de moderniserade delarna.
02Avstämningsstatus
Varför det är viktigtVisar om den nya tjänsten verkligen beter sig som den gamla där den ska.
Så skulle vi mäta detAndel transaktioner och poster som stämmer under parallellkörningen, med öppna skillnader per orsak.
03Täckning av regler
Varför det är viktigtOkända regler är den största risken när ett system ersätts.
Så skulle vi mäta detAndel framtagna verksamhetsregler som har verifierats av verksamhetsexperter och täcks av tester.
04Kvarvarande gamla delar
Varför det är viktigtModerniseringen lönar sig först när gamla komponenter faktiskt stängs av.
Så skulle vi mäta detFörmågor, kodvägar, batchjobb och licenser som har avvecklats, följda per etapp.
Vi sätter inga mål förrän utgångsläget har mätts.
Införande
Så skulle vi införa det
Fas 01
Bedömning
Portfölj, beroenden, områden och risker. Vi väljer en första etapp som betyder något för verksamheten men som går att backa.
Kriterier för att gå vidare
Målarkitekturen godkänd
Ordningen för etapperna överenskommen
Åtkomst till testmiljö och data ordnad
Fas 02
Första etappen
Framtagning av regler, skyddsnät, fasad och en ombyggd förmåga som körs parallellt med det gamla systemet.
Kriterier för att gå vidare
Avstämning inom överenskommen tolerans
Verksamhetsägaren godkänner bytet
Återgång testad
Fas 03
Etapp för etapp
Fler förmågor följer samma väg, var och en med egen parallellkörning och eget beslut om byte.
Kriterier för att gå vidare
Varje etapp avstämd och bytt
Kunskapen överförd till ditt team
Fas 04
Avveckling
Gamla kodvägar, batchjobb och datalager arkiveras och stängs av.
Tillstånds-, bidrags- och registersystem på statliga myndigheter, där lagstiftning finns inbyggd i årtionden gammal kod och nya ändringar fortsätter att komma.
Egenutvecklade tillägg till affärssystemet och fabrikssystem, som flyttas i samband med en migrering till SAP S/4HANA.
Illustrativt exempel
Ett tillståndssystem på en statlig myndighet
Utgångsläge
En statlig myndighet handlägger tillstånd i ett egenutvecklat system från 1990-talet. Flera regeländringar väntar, och två av de utvecklare som känner koden ska snart gå i pension.
System
Reglerna tas fram och verifieras per tillståndstyp. En fasad leder först en tillståndstyp till en ny tjänst som körs parallellt med det gamla systemet tills resultaten stämmer, medan e-tjänsten med e-legitimation förblir densamma för de sökande.
Mänsklig kontroll
Verksamhetsexperter verifierar reglerna för varje tillståndstyp. Systemägaren godkänner varje byte, och det går att backa via fasaden.
Det här skulle vi mäta
Avstämningsstatus per tillståndstyp, täckning av regler och ledtid för nästa regeländring.
Sverige
Modernisera under svenska och europeiska regler
När en statlig myndighet eller ett försäkringsbolag har ett verksamhetskritiskt system där decennier av lagändringar finns inbyggda i koden, väntar ofta nästa ändring redan. Vi lägger upp moderniseringen så att en etapp i taget flyttas och stäms av mot det gamla systemet innan något stängs av. När arbetet upphandlas enligt lagen om offentlig upphandling (LOU) besvarar vi upphandlingsdokumentet punkt för punkt.
De nya tjänsterna hamnar på plattformar som utformas med cybersäkerhetslagen (2025:1506) i åtanke, med krav på säkerhetsåtgärder sedan den 1 oktober 2026, och dataförordningens regler om byte av tjänst är ett skäl att hålla data flyttbara från första etappen. För banker och försäkringsbolag är Finansinspektionen behörig myndighet enligt Dora. Där registren innehåller personuppgifter följer mappningar och testdata dataskyddsförordningen.
Därför att ett enda byte samlar hela risken till ett datum, och verksamheten får vänta i åratal på nyttan. När en förmåga i taget flyttas kan varje etapp visa att den fungerar i en parallellkörning, tas i drift för sig och backas vid behov.
02Kan AI översätta vår COBOL till Java?
Översättning rad för rad ger ofta kod som är lika svår att ändra som originalet. Vi använder AI för att läsa och dokumentera den gamla koden och för att ta fram utkast till regler och tester, och utformar sedan de nya tjänsterna ordentligt. Varje framtagen regel verifieras av människor innan den används.
03Våra experter går snart i pension. Hur fångar ni det de vet?
Genom strukturerade genomgångar där experterna granskar de framtagna reglerna och karakteriseringstesterna. Deras kunskap hamnar i dokumentation och tester som stannar hos ditt team, inte i våra huvuden.
04Gäller det här även SAP ECC?
Ja. Samma principer gäller för sanering av egenutvecklad kod och en migrering till SAP S/4HANA: bedöm vad som fortfarande används, ta fram och testa det som är viktigt och flytta i kontrollerade steg.
05Hur länge körs gammalt och nytt parallellt?
Tills avstämningsresultaten når den tolerans som verksamhetsägaren har godkänt, och tillräckligt länge för att täcka återkommande körningar som månadsbokslut, årsbokslut eller den årliga omräkningen av avgifter.
06Hur börjar vi?
Med en bedömning av portföljen och en kandidat till första etapp. Om arbetet upphandlas enligt LOU besvarar vi upphandlingsdokumentet punkt för punkt. Läs mer om arkitektur och rådgivning. Vårt arbetssätt beskriver hur vi levererar.
Berätta om dina äldre system
Berätta vilket system som håller tillbaka verksamheten och vad som är beroende av det. Vi föreslår en första etapp och hur den kan prövas säkert, med avstämning mot det gamla systemet.