Gammal mjukvara: modernisera eller bygga om?

Du känner säkert igen läget: applikationen som företaget arbetar i varje dag skrevs för tio år sedan eller mer. Den fungerar, men ingen vågar röra den. Den ursprungliga utvecklaren försvann för länge sedan, ramverksversionen har inget stöd längre, servern behöver en uppgradering som applikationen inte klarar och varje liten ändring tar veckor.

Då hamnar frågan på bordet: laga det gamla, eller slänga det och bygga nytt?

Under de senaste åren har jag återställt flera applikationer som är över tio år gamla, både i offentlig och privat sektor. I inget av fallen var svaret "släng den". Det betyder inte att en nybyggnad alltid är fel – ibland är den faktiskt billigare. Här är kriterierna jag använder för att fatta beslutet.

Varför "vi skriver om allt" lockar så mycket

Gammal kod är tung att läsa och ny kod är roligt att skriva. Ett nytt projekt lovar ett blankt papper: modern teknik, ordnad struktur och allt det som är fel i det gamla.

Problemet är att en gammal applikation inte bara är kod. Den är tio års affärsregler. Varje konstig if-sats som ingen förstår längre lades förmodligen till av en anledning: ett specialfall för en kund, en lagändring, en begäran från ekonomiavdelningen, en bugg som dök upp en nyårsafton. Reglerna står inte nedskrivna någonstans. De finns bara i koden.

Bygger man från noll måste alla de reglerna upptäckas på nytt – oftast först när det nya systemet har tagits i drift och något går fel.

Varför stora omskrivningar så ofta misslyckas

En stor omskrivning faller nästan alltid i samma fällor:

• Ett rörligt mål. Det gamla systemet står inte stilla medan det nya byggs. Verksamheten behöver ändringar, och de måste göras på två ställen – eller inte alls i det gamla, vilket irriterar användarna.
• Lång tid utan nytta. Månader av arbete som användaren aldrig ser. Tar budgeten eller tålamodet slut före målet står man kvar med ett halvfärdigt nytt system och fortfarande det gamla.
• Datamigrering. Tio års data är alltid stökigare än någon tror: trasiga poster, dubbletter av kunder, fält som används till något annat än de var tänkta för.
• Allt eller inget. En dag byter man, och fungerar något inte finns det ingenstans att gå tillbaka.

Vad stegvis modernisering betyder

Den andra vägen är att låta applikationen vara i drift och byta ut delarna en i taget. Det är så jag har arbetat med de gamla applikationer jag har återställt:

1. Först förståelse. Applikationen startas i en separat miljö och gås igenom: versioner, beroenden, var datan finns och vad som är kritiskt.
2. Tester före ändringar. De viktigaste arbetsflödena täcks av tester som kontrollerar att applikationen beter sig exakt som förut. De är skyddsnätet för allt som följer.
3. En version i taget. Språk, ramverk, bibliotek och databas flyttas till nyare versioner komponent för komponent. Varje steg är litet, testbart och går att backa.
4. Funktionaliteten bevaras. För användaren ändras ingenting – samma arbetsflöde, samma data, bara snabbare och säkrare.
5. Sedan nya funktioner. Först när grunden är modern byggs nya funktioner. De blir rimliga i pris igen, eftersom koden är läsbar och testerna skyddar den.

Den största fördelen är att nyttan kommer direkt och risken förblir liten. Varje etapp slutar med ett fungerande system. Tar budgeten slut någon gång är applikationen ändå i bättre skick än när du började.

Ärliga kriterier: när modernisera, när bygga om

Svaret beror på fem saker.

Affärslogikens värde. Innehåller applikationen mycket logik som är unik för ert företag – beräkningsregler, specialfall, arbetsflöden – väger det tungt för modernisering. Är det i praktiken ett enkelt formulär för datainmatning finns det lite att förlora.

Kodens kvalitet. Gammal betyder inte dålig. Kod som skrevs omsorgsfullt för tio år sedan går ofta bra att uppgradera. Är den däremot rörig – databasfrågor mitt i HTML, samma logik kopierad till tio ställen – blir varje steg dyrt.

Data. Data lever nästan alltid längre än koden. Är datamodellen vettig kan man bygga vidare på den oavsett väg. Är datamodellen själv problemet måste det lösas i vilket fall som helst.

Budget och tidsplan. Stegvis modernisering kan delas upp i etapper och pausas. En nybyggnad kräver i regel hela summan innan något når användarna.

Risk. Kostar ett driftstopp pengar eller hindrar folk från att arbeta är den stegvisa vägen nästan alltid säkrare.

När en nybyggnad faktiskt är billigare

Det finns lägen där jag själv säger att modernisering inte lönar sig:

• Tekniken är så död att det inte finns någon nyare version eller några verktyg, och varje komponent ändå måste skrivas om.
• Verksamheten har förändrats så mycket att den gamla applikationen löser ett problem som inte finns längre.
• Applikationen är liten och logiken ryms på ett par sidor – då går det fortare att skriva nytt än att reda ut det gamla.
• En färdig plattform täcker behovet. För webbutik, lager och bokningar är det ofta ingen idé att bygga ett eget system när en lösning som NUNDINAE redan finns.

Även då lönar det sig att analysera det gamla systemet innan något nytt påbörjas – just för att få de dolda affärsreglerna nedskrivna.

Är det gamla systemet i själva verket en webbplats gäller samma princip: en ny webbplats går att bygga, men utan att förlora det som redan fungerar. Det skrev jag om i ett separat inlägg om ny webbplats utan att tappa SEO.

Hur jag börjar

Första steget är alltid en genomgång: jag går igenom applikationen, versionerna, datan och servern och berättar skriftligt vad jag ser. Därifrån kommer också svaret på huvudfrågan – modernisera eller bygga om – med motivering. Innehåller applikationen konfidentiell information är ett sekretessavtal (NDA) helt normalt.

Mer om vad jag gör och hur finns på sidan om modernisering av mjukvara.

Har du en applikation som ingen vågar röra? Beskriv ditt läge med ett par meningar här – vilket system det är, hur gammalt och vad som oroar just nu. Jag svarar inom en arbetsdag och säger ärligt om och hur jag kan hjälpa. Vill du hellre bara skriva finns alla uppgifter på kontaktsidan.

Måste applikationen stängas av under moderniseringen?

Oftast inte. Arbetet görs i en separat miljö och produktionsversionen byts först när den nya är testad. Bytet är kort och planerat.

Tänk om varken den ursprungliga utvecklaren eller dokumentation finns?

Det är snarare regel än undantag. Koden i sig är dokumentationen – den tar bara tid att läsa. Testerna som skrivs i början beskriver samtidigt hur applikationen verkligen beter sig.

Kan applikationen vidareutvecklas efteråt?

Ja, det är hela poängen. När grunden är modern och täckt av tester kan nya funktioner läggas till precis som i en ny applikation.