Redde eldre systemer — uten en full omskriving

Et sted i Europa sitter en CIO akkurat nå og signerer på en systemomskriving til 2 millioner euro – for et problem som kunne vært løst med en patch til 200 000 euro og seks ukers arbeid.

Dette er ikke et tenkt eksempel. Det skjer hver uke i enterprise-IT. Det er nesten blitt et ritual: et prosjekt stopper opp, systemet begynner å oppføre seg rart, og noen sier de magiske ordene — «Vi må bygge alt på nytt.»
Tre måneder, et dusin PowerPoint-presentasjoner og en hær av konsulenter senere, står selskapet igjen med et halvferdig system – og en helt ny haug med teknisk gjeld.

Et innlegg på Reddit beskrev det perfekt:

«Etter at vi installerte en ny hyperkonvergert infrastruktur… kontaktet vi leverandørens supportteam, og etter tre uker med frem og tilbake… gjenopprettet en ingeniør clusteret vårt på omtrent to timer.»

To timer. Etter tre uker med panikk.
Det er forskjellen mellom å vente på kavaleriet – og å ha én erfaren ingeniør med riktig verktøy.

Når “nytt” ikke betyr “bedre”

Vi i Kaunas High Tech Cluster har sett denne filmen før.
En stor detaljkjede kom til oss med et e-handels­system som deres forrige leverandør hadde stemplet som “for gammelt til å redde”. Planen deres: en full omskriving til 1,2 millioner euro, over ni måneder.

Vi foreslo noe annet.
Et moderne API-lag over det eksisterende systemet. Målrettet refaktorering av de verste flaskehalsene. 90 % av koden ble beholdt.
Seks uker senere håndterte selskapet rekordmange ordre — uten å sprenge budsjettet.

Den ubehagelige sannheten?
De fleste “legacy”-systemer er ikke døde. De er bare misforstått.

Hvorfor selskaper havner i omskrivingsfellen

Store leverandører selger trygghet. En total omskriving ser ryddig ut, scope er lett å definere, og fakturaene er store og fine.
Men under den blanke overflaten av “strategisk transformasjon” skjuler det seg det Gartner kaller information overload paralysis — team som drukner i dokumentasjon, presentasjoner og prosesser, mens lite faktisk beveger seg fremover.

Forskning viser at 86 % av B2B-kjøpere allerede har en “dag én-liste” over foretrukne leverandører, og 92 % kjøper fra denne listen.
Når du først er der, er det lett å selge inn en omskriving. For hvem vil være konsulenten som sier: «Egentlig kan vi bare fikse dette.»

Kjøperne slipper heller ikke unna. Et gjennomsnittlig IT-prosjekt involverer 17 beslutningstakere – fra IT og drift til finans. Ingen vil ta den politiske risikoen ved å foreslå en “billig” løsning. Dermed velger man den dyre – og farligere – veien.

Den smartere moderniseringsstrategien

Når vi hjelper bedrifter med å redde gamle systemer, starter vi ikke med koden. Vi starter med spørsmålene.

1. Hva er faktisk ødelagt?
De fleste problemer handler om integrasjoner, ikke arkitektur. En enkel avhengighetsanalyse avslører ofte at 80 % fungerer fint – det er de siste 20 % som skaper bråk.

2. Kan vi “pakke inn og utvide” i stedet for å rive og bygge nytt?
Ved å bygge et API-lag, modernisere dataflyten eller gjøre frontenden modulær kan du fornye uten å starte på nytt. Evolusjon, ikke revolusjon.

3. Hvem tjener mest på en full omskriving?
Hvis svaret er leverandøren og ikke virksomheten, vet du allerede nok.

Hva som faktisk fungerer

Hos Kaunas High Tech Cluster jobber vi med selskaper som vil ha resultater, ikke rapporter.
Fra e-handelsplattformer til produksjonssystemer har vi hjulpet team med å forlenge levetiden på sine systemer — ikke ved å skrive alt om, men ved å gjøre det som finnes smartere.

Den sannheten få tør å si høyt:
Det mest moderne du kan gjøre, er ofte å redde det du allerede har.

Slutt å stole på de store navnene.
Begynn å løse virkelige problemer.