Hvis du er en grunnlegger, CTO eller forretningsleder ansvarlig for et produkt bygget på eldre teknologi, har du sannsynligvis stilt deg selv spørsmålet: bør vi fortsette å fikse det vi har — eller starte på nytt?
Kanskje koden er skjør. Kanskje de opprinnelige arkitektene er lenge borte. Kanskje teamet ditt er frustrert, veikartet ditt er blokkert, og moderne rekruttering er en utfordring. Du er ikke alene — og du tar ikke feil ved å stille spørsmålet.
Men svaret er ikke enkelt. En omskrivning kan bringe muligheter — eller introdusere risiko som påvirker hele selskapet ditt. Det du trenger er ikke bare en mening — det er et rammeverk for å ta det riktige valget.
Den guiden er for deg. Enten du blir presset mot en stor teknisk overhaling eller bare prøver å forstå alternativene dine, vil vi gå gjennom:
- Hvorfor team føler seg tvunget til å omskrive
- Når det gir mening (og når det ikke gjør)
- Hvordan modernisere eldre systemer trygt og strategisk
Vi vil også dele advarende historier, praktiske taktikker, og ett viktig råd: ikke ta denne beslutningen i vakuum. En annen mening — fra noen utenfor din daglige drift — kan spare deg for måneder med bortkastet innsats og millioner i mulighetskostnader. Den tar for seg begge sider av debatten, utforsker hvorfor selskaper vurderer omskrivninger, skisserer de reelle risikoene, og introduserer et mer strategisk alternativ: inkrementell modernisering. Viktigst av alt, før du forplikter deg til noen storskala endringer, er det verdt å få en annen mening — ideelt sett fra noen utenfor det umiddelbare teamet, som en digital konsulent, betrodd rådgiver, eller et annet erfarent blikk. Noen ganger går en liten ekstern perspektiv langt.
Hvorfor omskrivninger er så fristende
Programvarelandskapet utvikler seg raskt. Nye verktøy, rammeverk og arkitektoniske paradigmer lover bedre ytelse, jevnere utvikleropplevelse, raskere distribusjon og lavere vedlikeholdskostnader.
Fra et forretningsperspektiv:
- Konkurrenter som bruker moderne stakker ser ut til å bevege seg raskere
- Å ansette utviklere for utdaterte teknologier (som Java 6, AngularJS eller PHP 5) er vanskeligere
- Ledelsen hører "legacy" og antar "forpliktelse"
Fra et utviklerperspektiv:
- Å vedlikeholde gammel kode føles demoraliserende
- Verktøyene kan være klønete, dokumentasjonen utdatert, og tester ikke-eksisterende
- Ingeniører ønsker å jobbe med spennende, markedsrelevante teknologier
Dette skaper en oppfatningskløft:
Legacy = dårlig | Refactor/Rewrite = bra
Men dette er en overforenkling. Legacy-systemer driver ofte de mest kritiske delene av en virksomhet — og stabilitet, ikke glans, er det som betaler regningene.
Hvorfor selskaper omskriver kodebasene sine
Omskrivninger skjer av en rekke grunner. Her er de vanligste drivkreftene:
- Ytelse & Skaleringsgrenser: Et system bygget for 10 000 brukere kan svikte under 1 million. Noen ganger er omskrivning med en annen arkitektur (f.eks. å gå fra monolittisk til mikrotjenester) den eneste måten å skalere på.
- Overholdelse & Sikkerhet: Utdaterte teknologier kan introdusere uopprettelige sårbarheter eller ikke oppfylle oppdaterte standarder som PCI DSS 4.0 eller OWASP.
- Flaskehalser i funksjonsutvikling: Arvde systemer kan være så skjøre at det blir risikabelt eller tidkrevende å legge til funksjoner.
- Talentbevaring & Rekruttering: Ingeniører forlater ofte team som sitter fast på utdaterte stakker. Omskrivning kan være en talentstrategi, selv om det er en risikabel en.
- M&A eller Forretningstransformasjon: Fusjoner, oppkjøp eller store omstillinger krever ofte systemer som er mer fleksible eller bedre integrerte. Omskrivninger kan fungere — men bare under veldig spesifikke forhold. De fleste mislykkes ikke på grunn av dårlige intensjoner, men på grunn av undervurdert kompleksitet og overvurdert kapasitet.
Omskrivninger kan fungere — men bare under veldig spesifikke forhold. De fleste mislykkes ikke på grunn av dårlige intensjoner, men på grunn av undervurdert kompleksitet og overvurdert kapasitet.
Når en omskrivning føles nødvendig (og hva du bør vurdere først)
Noen ganger føles en omskrivning som det eneste levedyktige alternativet. Systemet er farlig utdaterte. Forretningsbehovene har endret seg. Overholdelse er i fare. Dette er legitime presspunkter som kan (og ofte gjør) utløse krav om en total ombygging.
Men her er hva vi har sett gang på gang: selv om smerten er reell, er en full omskrivning ofte ikke den smarteste eller raskeste måten å lindre den på. I mange tilfeller kan du adressere det underliggende problemet — ytelse, sikkerhet, fleksibilitet — med et mye mindre, tryggere tiltak.
Nedenfor er vanlige scenarier som ofte får team til å vurdere en omskrivning — og hva som faktisk fungerte i stedet.
1. Din Stack Er Aktivt Farlig
- Ingen tester
- Sikkerhetshull i produksjon
- Utdaterte avhengigheter
- Ingen igjen som forstår koden
Dette er alvorlige risikoer — og i noen tilfeller må kritiske moduler skrives om. Men det betyr ikke at hele kodebasen må fjernes.
Eksempel: En klient kom til oss med en Rails 3 monolitt. Ingen test suite, ødelagt autentiseringsflyt, forlatte gems. I stedet for å bygge alt på nytt, skar vi ut betalingsmodulen (den mest volatile delen), skrev den om som en selvstendig tjeneste, og la til tester og observabilitet.
→ De reduserte kritisk risiko, gjenopprettet tillit, og fortsatte å levere — uten å fryse produktarbeidet.
2. Du pivotere virksomheten
Hvis produktstrategien din endrer seg fundamentalt — ikke bare ved å legge til nye funksjoner, men ved å endre hele verdiforslaget — så ja, kan noen deler av kodebasen din ikke lenger være til nytte.
Men en pivot krever ikke alltid et nytt fundament.
Eksempel: Et SaaS-selskap vi rådgav planla en omskrivning for å støtte et stort produktift. Etter å ha gjennomgått arkitekturen deres, fant vi ut at backend i stor grad kunne forbli på plass. Ved å bygge nye tjenester oppå og avkoble eldre logikk der det var nødvendig, sparte de 6–9 måneder med arbeid og unngikk å re-onboarde hele brukerbasen sin.
→ Det de virkelig trengte var ikke en omskrivning — det var klarhet, modularitet, og en pragmatisk leveringsplan.
3. Du kan ikke skalere eller overholde
Noen ganger blokkerer gamle systemer virkelig for vekst — enten på grunn av skjøre integrasjoner, mangel på observabilitet, eller sikkerhetskrav som SSO, MFA, eller revisjonslogger.
Selv da er det sjelden at omskrivning av alt er den eneste veien videre.
Eksempel: En B2B SaaS-plattform hadde autentiseringslogikk spredt over fem tjenester, ingen MFA, og ingen klar eierskap. I stedet for å gjenoppbygge hele autentiseringssystemet, designet vi et moderne tilgangslag som kunne sitte ved siden av den eksisterende stakken.
→ De oppnådde overholdelse og UX-gevinster med minimal forstyrrelse, ingen fakturadødtid, og raskere enn forventet utrulling.
Hva mener vi med "Legacy"?
"Legacy" er ikke et skittent ord — det er en beskrivelse. Det refererer generelt til programvare som:
- Bruker utdaterte språk, biblioteker eller paradigmer
- Har dårlig dokumentasjon eller testdekning
- Ble bygget under betingelser som ikke lenger eksisterer
- Har overlevd flere produkt- eller teamiterasjoner
Men legacy-systemer er også:
- Slagkraftige: De har vist seg å fungere under reelle forhold
- Stabile: Mange håndterer sensitive operasjoner (betalinger, logistikk, samsvar)
- Lønnsomme: De støtter forretningskritiske funksjoner
Fra et kulturelt perspektiv er det en psykologisk tiltrekning mot det nye og skinnende. Men å erstatte noe bare fordi det "føles gammelt" er som å bytte inn en fungerende bil fordi dashbordet ikke er digitalt.
De reelle risikoene ved fullstendige omskrivninger
Å starte på nytt med en ren tavle kan høres tiltalende ut, men i virkeligheten medfører fullstendige systemomskrivninger betydelige risikoer—spesielt i sektorer som fintech og helsevesen. Her er hva dataene viser:
- Budjettoverskridelser: Omtrent 70% av omskrivninger av eldre systemer overskrider budsjettet, og kostnadene kan nå ~$30 per kode linje, noe som betyr at selv mellomstore systemer kan koste millioner. (CAST Software / Mobilize.net)
- Forsinkede frister: Ifølge Standish Groups CHAOS-rapport, er det kun 16% av programvareomskrivningsprosjektene som blir fullført i tide og innen budsjett, mens over 50% er betydelig forsinket eller forblir ufullstendige. (CHAOS Rapport 2020 – Henny Portman oppsummering)
- Tapt forretningslogikk: Fullstendige omskrivninger risikerer å miste kritiske forretningsregler som er innebygd i udokumentert eldre logikk. (Gartner 2022 Prediksjoner)
- Teamomsetning: Langvarige omskrivningsinnsatser (ofte 2–3 år) fører til utbrenthet og høyere omsetning, ettersom utviklere jonglerer med doble systemer og langvarig usikkerhet. (Infosys omsetningstrender – Economic Times)
- Frosne veikart: Under fullstendige omskrivninger kan team gå 12–18 måneder uten å levere nye funksjoner, noe som stanser produktvekst og innovasjon. (Accenture Life Trends 2023)
- Prosjektfeil: Alarmerende, 31% av omskrivningsprosjektene mislykkes helt, og mange andre er tvunget til å gå tilbake til skjøre eldre systemer. (CHAOS Rapport 2020 – Henny Portman oppsummering)
Omskrivning er ikke iboende dårlig—men det er iboende risikabelt. Det bør aldri være standardvalget. I stedet må det være en kalkulert forretningsbeslutning, basert på reelle tekniske, organisatoriske og ROI-innsikter.
Dette er grunnen til at det er sterkt anbefalt å involvere en nøytral tredjepart—som et digitalt konsulentfirma eller ekspertbyrå. De kan:
- Revidere den faktiske helsen til dine eldre systemer
- Identifisere om hindringene dine er tekniske, team- eller prosessbaserte
- Foreslå fasede, lavere risiko modernisering strategier som låser opp innovasjon uten å ofre stabilitet
Den strategiske alternativet: Inkrementell modernisering
Du trenger ikke å velge mellom stagnasjon og en risikabel omskrivning. Det finnes et tredje — ofte oversett — alternativ: strategisk, trinnvis modernisering.
I stedet for å bygge alt på nytt, moderniserer du systemet bit for bit, begynner med områdene som faktisk blokkerer fremdrift. Denne tilnærmingen respekterer den eksisterende forretningsverdien samtidig som den reduserer teknisk risiko og nedetid ved levering.
Hvorfor det fungerer
Systemet ditt kan være ufullkomment, men det gjør allerede jobben: håndterer produksjonstrafikk, lagrer forretningslogikk, holder brukerne fornøyde (eller i det minste funksjonelle). Det er ikke noe å kaste bort lett.
Inkrementell modernisering anerkjenner den virkeligheten. Det handler ikke om å klamre seg til fortiden — det handler om å gjøre smarte, lavrisiko fremskritt mot en bedre fremtid.
Virkelighetsnært eksempel: Hvordan HRTech arvbedrift moderniserte uten å forstyrre brukerne
En av våre kunder, en plattform for avanserte psykometriske vurderinger, kom til oss med et stort, høyt tilpasset system. Det støttet tusenvis av brukere, men hadde blitt stadig mer skjør over årene — vanskelig å skalere, vanskelig å teste, og tett knyttet til utdaterte logikker.
I stedet for å starte fra bunnen av, jobbet vi sammen for å:
- Skille ut nøkkelmomenter — som testgenerering og resultatberegning — til frittstående komponenter
- Pakke inn arvlogikk i moderne API-er, som tillot frontend-teamene å levere forbedringer uavhengig
- Introdusere observabilitet og CI/CD-pipelines gradvis, og redusere utviklingsfriksjon uten en fullstendig stakksmigrasjon
Resultatet?
Ny funksjonalitet ble levert 2x raskere innen første kvartal, null brukerforstyrrelser, og en veikart som ikke lenger var avhengig av en omskrivning for å komme videre.
Hvordan inkrementell modernisering fungerer
Kvelde Monolitten, Forsiktig
Begynn med å identifisere selvstendige deler av systemet — som brukerautentisering, fakturagenerering eller e-postvarsler — og trekk dem ut til fristående tjenester. Dette er Strangler Fig Pattern, popularisert av Martin Fowler, hvor ny funksjonalitet omslutter og gradvis erstatter den gamle uten å stenge den ned.
Eksempel: Et fintech-selskap vi jobbet med erstattet sin fakturamodul med en fristående tjeneste, uten å berøre resten av monolitten. I løpet av 6 måneder isolerte de flere funksjoner, og etterlot til slutt bare en lettvekts kjerne.
Bygg adaptere, ikke brytere
Introduser abstraksjonslag for å frikoble eldre interne systemer fra brukeropplevelsen. Dette lar deg modernisere bak kulissene uten å bryte API-er, brukerflyter eller integrasjoner. Tenk på det som å bygge stillas før du renoverer en bygning.
Tips: Dette gjør det også lettere å bytte ut delsystemer senere. I dag er det betalinger, i morgen kan det være analysepipen din.
Start Where the Pain Is
Ikke sikte mot arkitektonisk renhet — sikte mot innvirkning. Fokuser innsatsen din på områdene som forårsaker mest smerte for brukerne eller som bremser teamets evne til å levere. Er produktkatalogen umulig å oppdatere? Er rapporteringen skjør og upålitelig? Start der.
Tommelfingerregel: Moderniser 20% av koden som leverer 80% av verdien. Resten kan vente.
Legg igjen smuler
Dokumenter merkelige kanttilfeller og ikke-opplagt logikk. En enkelt udokumentert regel — som en MVA-beregning fra 2017 — kan bryte en kritisk arbeidsflyt hvis den ved et uhell fjernes.
Tips: Legg igjen kommentarer som # Påkrevd på grunn av MVA-regel fra 2017 slik at fremtidige team forstår hva de ikke skal fjerne.
Mål, Refaktorer, Gjenta
Behandle modernisering som en kontinuerlig prosess, ikke en engangshendelse. Introduser målinger: byggetid, distribusjonsfrekvens, antall hendelser, tid til gjenoppretting. Bruk deretter disse til å rettferdiggjøre og prioritere fremtidige forbedringer.
Pro Tips: En kultur for små, trygge endringer støttet av telemetri fører ofte til bedre langsiktige resultater enn et enkelt, stort omskrivingsprosjekt.
Spørsmål å stille før du skriver om
Før du tar steget, samle interessenter fra produkt, ingeniørfag og forretning — og svar på disse spørsmålene sammen:
- Kan vi fortsatt levere funksjoner (selv om det går sakte)?
- Er mer enn 50% av de opprinnelige utviklerne fortsatt til stede?
- Er den nåværende stakken en sikkerhets- eller samsvarsrisiko?
- Er smerten hovedsakelig teknisk, eller prosessrelatert?
- Bryr brukerne seg om problemene vi løser?
- Har vi detaljert vurdert og priset datamigrasjon?
- Hva ville vi miste som ikke er dokumentert?
Hvis de fleste av svarene dine er usikre eller blandede — ta en pause. Ta inn et eksternt perspektiv. Ikke fly blindt inn i det mest komplekse tekniske prosjektet selskapet ditt noen gang kan gjennomføre.
Oppsummering: Ikke skriv om alene
Legacy-systemer er ufullkomne, men de er ofte motstandsdyktige, pålitelige og dypt integrert i virksomheten din.
Omskrivninger kan være transformative — men de kan også være sløsende, destabilisere og unødvendige. Inkrementell modernisering tilbyr en smartere, tryggere vei videre.
Det viktigste av alt: konsulter med erfarne fagfolk før du forplikter deg. Eksterne byråer og digitale konsulentfirmaer bringer mønstergjenkjenning, hardt opptjent erfaring og objektiv innsikt. Du får bare én sjanse til en omskrivning — sørg for at det er det riktige trekket.
