Modernisera ett äldre system när det kostar mer att behålla än att förändra: ändringar som borde ta dagar tar veckor, plattformen får inga säkerhetsuppdateringar längre eller bara en person vågar röra koden. För de flesta företag är det säkrast att gå stegvis och refaktorera eller byta ut en del i taget medan det gamla systemet är i drift. Den här guiden är för CTO:er, IT-chefer och ägare av verksamhetskritiska system, och den beskriver hur vi arbetar med modernisering av äldre system. Arbetet börjar med en kodgenomlysning från 1 900 € (ca 21 000 kr).
Med äldre system (legacy-system) menar vi ett system som verksamheten fortfarande är beroende av men som har blivit svårt och riskabelt att ändra. Åldern avgör inte. Ett 15 år gammalt system med tester och uppdaterade beroenden kan vara i bättre skick än ett treårigt som ingen förstår.
Vilka tecken visar att det är dags att modernisera?
Ett av tecknen är skäl att börja planera. Två eller fler betyder oftast att systemet redan kostar mer än det ger.
| Tecken | Det ni märker | Vad det oftast betyder |
|---|---|---|
| Ändringar tar veckor i stället för dagar | Små önskemål blir liggande och uppskattningarna växer | Rörig kod utan tester, så varje ändring måste kontrolleras manuellt |
| Inga säkerhetsuppdateringar | Beroendeanalysen flaggar problem som ingen kan åtgärda utan en stor uppgradering | Plattformen eller ramverket har nått end of life |
| Integrationer kräver specialhack | Att koppla in Fortnox, Visma, en betaltjänst eller ett AI-API tar veckor | Inget rent API-lager, och datan är låst i den gamla strukturen |
| Fler driftstörningar | Fler avbrott, och varje avbrott tar längre tid att felsöka | Bristande övervakning och ackumulerad komplexitet |
| Bara en person förstår systemet | Semester och sjukfrånvaro blir en affärsrisk | Kunskapen finns i någons huvud, inte i dokumentation och tester |
| Svårt att rekrytera | Kandidater och konsulter tackar nej när de ser tekniken | Få utvecklare vill eller kan arbeta i den |
| Skalning betyder mer hårdvara | Varje prestandaproblem löses med en större server | Begränsningar i arkitekturen, inte i kapaciteten |
Den andra raden är den som har ett slutdatum. Ramverk och plattformar slutar få säkerhetsrättningar på ett publicerat datum: PHP 7.4 nådde end of life i november 2022, AngularJS i slutet av 2021 och Python 2 i januari 2020. Om ert system kör på något sådant förblir varje ny sårbarhet öppen. När NIS2 och kundernas säkerhetsfrågeformulär frågar hur ni hanterar uppdateringar är det lika mycket en affärsfråga som en teknisk.
När är modernisering inte värt det?
Låt systemet vara om det är stabilt, fortfarande får uppdateringar, sällan behöver ändras och ingen väntar på nya funktioner i det. Modernisering lönar sig genom snabbare förändring och lägre risk, och ett system som inte behöver förändras får lite av båda. Håll det uppdaterat och övervakat, dokumentera det så att det inte hänger på en person, och lägg budgeten där den gör skillnad.
Vilken moderniseringsstrategi passar ert system?
Det finns fem realistiska alternativ. De utesluter inte varandra: många projekt kombinerar två, till exempel att först omplattformera och sedan byta ut de sämsta modulerna en i taget.
| Alternativ | Vad som ändras | Välj det när | Största risk |
|---|---|---|---|
| Refaktorering | Kodens struktur, inte dess beteende | Plattformen stöds fortfarande och affärslogiken håller, men koden är svår att arbeta i | Ändlös städning utan synligt resultat om den inte kopplas till funktioner |
| Omplattformering | Drift, plattform eller ramverksversion, med små kodändringar | Koden är godtagbar men kör på programvara utan support eller på sköra, dyra servrar | Dolda beroenden till den gamla miljön |
| Stegvis omskrivning (strangler fig) | Moduler byggs om en i taget bakom ett routinglager | Systemet är stort och verksamhetskritiskt, och delar av det behöver fungera annorlunda | Två system körs parallellt ett tag; det krävs disciplin för att bli klar |
| Byta till ett standardsystem | Systemet ersätts av en SaaS-tjänst eller standardprodukt | Det systemet gör är inte längre unikt för er, till exempel fakturering, HR eller ett vanligt CRM | Ändrade arbetssätt, datamigrering och begränsade anpassningar |
| Total omskrivning | Allt på en gång, med byte ett visst datum | Sällan: ett litet system med lite återanvändbar logik | Värdet kommer först i slutet, och specialfall som det gamla systemet hanterade försvinner |
Strangler fig-mönstret har fått sitt namn efter ett fikonträd som växer runt sitt värdträd tills värdträdet är borta (Martin Fowlers ursprungliga beskrivning). Man lägger ett routinglager framför det gamla systemet, bygger en ny modul bakom det, flyttar trafiken för den funktionen till den nya modulen och stänger av den gamla koden. Sedan upprepar man tills inget av det gamla systemet finns kvar.
Att byta till ett standardsystem underskattas ofta. Om ert egenutvecklade system i dag gör det som Fortnox, Visma, HubSpot eller en vanlig e-handelsplattform gör bra, kan den billigaste moderniseringen vara att avveckla det och behålla en liten integration för det som verkligen är ert eget. Vi jämför alternativen i skräddarsydd mjukvara eller standardsystem.
Hur moderniserar man utan att skriva om allt på en gång?
Så här går vi tillväga. Ordningen spelar större roll än verktygen.
- Gå igenom och kartlägg systemet. Läs koden, lista beroenden och deras supportstatus, kartlägg integrationer och dataflöden och ta reda på vem som använder vad. Resultatet är en skriftlig rapport med prioriterade risker och en färdplan i faser.
- Bygg ett skyddsnät. Sätt upp CI, övervakning, testade backuper och karakteriseringstester, alltså tester som fångar vad systemet gör i dag så att ni märker när en ändring påverkar det. Utan detta blir varje senare steg ett vågspel.
- Åtgärda akuta säkerhetsproblem först. Föråldrade beroenden, lösenord och nycklar i koden och delade administratörskonton kan inte vänta på färdplanen.
- Välj den första delen. Ta en modul som ändras ofta, har tydliga gränser och skaver i verksamheten i dag, till exempel fakturering, en kundportal eller en rapportexport. Börja inte med kärnan som allt annat hänger på.
- Routa, bygg, jämför, byt. Lägg in routinglagret, bygg den nya modulen, kör den parallellt och jämför resultaten med den gamla, migrera dess data och flytta sedan över trafiken, gärna stegvis.
- Stäng av den gamla koden. Ta bort det som den nya modulen har ersatt. Ett strangler fig-projekt som aldrig tar bort något har bara gjort systemet större.
- Fortsätt leverera funktioner. Frys inte utvecklingen i månader. Bygg nya funktioner i de nya delarna av systemet, så ser resten av verksamheten också vad arbetet är till för.
Ett exempel: att byta ut ett ordersystem bit för bit
Det här är ett sammansatt exempel, inte en specifik kund. Ett företag har ett 12 år gammalt ordersystem i PHP som används av sälj, lager och ekonomi. Det kör på en PHP-version utan support, skickar en CSV-fil till ekonomisystemet varje natt och bara en utvecklare vet hur prisreglerna fungerar.
- Vecka 1–2: genomlysning och färdplan. De största riskerna visar sig vara PHP-versionen och nattexporten, som ibland misslyckas utan att någon märker det.
- Första fasen: uppgradera till en PHP-version med support, lägg karakteriseringstester runt prissättning och orderläggning, flytta ut hemligheter ur koden och sätt upp övervakning. Användarna märker ingen skillnad, men systemet är uppdaterat och den mest riskfyllda logiken är testad.
- Andra fasen: en ny faktureringsmodul bakom ett routinglager som pratar med ekonomisystemet via dess API i stället för en CSV-fil. Gammal och ny fakturering körs parallellt tills siffrorna stämmer, sedan stängs den gamla vägen av.
- Tredje fasen: en kundportal som läser orderstatus via ett nytt API, så att kunderna slutar mejla och fråga.
- Senare faser: de interna administrationsvyerna, modul för modul, tills den gamla applikationen kan avvecklas.
Varje fas slutar i produktion. Om budgeten dras ner efter andra fasen har företaget ändå ett uppdaterat system och en fungerande integration mot ekonomisystemet, inte en halv omskrivning.
Vad kostar det att modernisera ett äldre system, och hur lång tid tar det?
Kostnaden beror mindre på antalet kodrader än på hur mycket odokumenterad affärslogik de innehåller, hur många integrationer som finns, hur rörig datan är och hur mycket som redan täcks av tester. Det här är våra publicerade priser, exklusive moms:
| Steg | Pris | Normal tid |
|---|---|---|
| Kodgenomlysning med skriftlig färdplan i faser | Från 1 900 € (ca 21 000 kr), fast pris | 1–2 veckor |
| Moderniseringsprojekt, fast pris per fas | Oftast inom 30 000–150 000 € (ca 330 000–1 650 000 kr) | 3–6 månader |
| Hålla det gamla systemet uppdaterat under tiden (Care Lite) | 46 000 kr/mån | Löpande per månad |
| Fortsatt modernisering parallellt med nya funktioner (Start eller Scale Pod) | 90 000 eller 160 000 kr/mån | Löpande per månad efter första månaden |
En Delivery Pod är ett team till fast månadspris som leds av en senior utvecklare. Care Lite omfattar underhåll, säkerhetsuppdateringar, övervakning och mindre rättningar, men inga nya funktioner, och passar därför bra för det gamla systemet medan de nya delarna byggs.
Utvecklingen görs av vårt team i Ukraina, med en senior utvecklare som ansvarar för arkitektur och kodkvalitet och en grundare som ansvarar för projektet. Ni skriver avtal med Smoother Development AB enligt svensk lag. De flesta genomlysningar kräver bara läsbehörighet till koden; om arbetet kräver åtkomst till personuppgifter skriver vi först ett personuppgiftsbiträdesavtal med EU:s standardavtalsklausuler. Hur projektpriser fungerar mer generellt går vi igenom i vad kostar systemutveckling.
Hur får man verksamheten med sig?
Det svåraste är ofta inte tekniskt. Systemet fungerar, någorlunda, och kostnaden för att behålla det är utspridd över många små förseningar. Gör den kostnaden synlig innan ni ber om budget:
- Mät under en månad hur utvecklingstimmarna fördelas mellan underhåll och nyutveckling.
- Lista förra årets driftstörningar och vad var och en kostade i arbetstid eller förlorade order.
- Lista initiativ som skjutits upp eller strukits för att systemet inte klarade dem.
- Skriv ner vad som händer om den enda person som kan systemet slutar.
Jämför sedan två planer över två till tre år: att behålla systemet som det är, och en modernisering i faser där varje fas levererar något. Planen i faser är också lättare att få godkänd, eftersom verksamheten kan stanna efter vilken fas som helst och ändå behålla det den har betalat för.
Och om det äldre systemet är en ny app byggd med AI-verktyg?
Alla system som är svåra att ändra är inte gamla. Appar som byggts snabbt med Lovable, Bolt, Replit, v0 eller Cursor slår ofta i samma väggar inom några månader: inga tester, öppna databasregler, skör inloggning och att varje ändring förstör något annat. Det är oftast en stabilisering snarare än ett moderniseringsprojekt. Vår räddning av AI-byggda appar börjar med en kod- och säkerhetsgenomlysning från 1 900 € (ca 21 000 kr, 3–5 arbetsdagar för en typisk app), följd av en stabilisering till fast pris från 6 000 € (ca 66 000 kr), oftast 2–4 veckor.
Vad ni kan göra härnäst
Om två eller fler av tecknen ovan känns igen, börja med kodgenomlysningen. Inom 1–2 veckor får ni en skriftlig bild av riskerna, de alternativ som passar ert system och en plan i faser med fast pris för den första fasen, och sedan bestämmer ni hur ni vill gå vidare. Ni bokar den via sidan om modernisering av äldre system.
