När bör du omstrukturera, ersätta eller dra tillbaka ett legacy-system?

Question

Accepted Answer

Legacy-system är obehagliga men ofta värdefulla – de driver verksamheten. Beslutet att **omstrukturera, ersätta eller dra tillbaka** måste drivas av kostnad och värde, inte av motvilja mot gammal kod. "Det är gammalt och fult" är inte en anledning; "det kostar oss" är.

## En beslutsvägledning

```text
REFACTOR (improve in place) when:
  - Core logic is sound; it's holding business value
  - Problems are localized; you can improve incrementally

REPLACE (rewrite/migrate) when:
  - It blocks important work and can't be incrementally fixed
  - Maintenance cost > rebuild cost over a sensible horizon
  - It's a growing security or reliability liability

RETIRE (remove entirely) when:
  - Its value no longer justifies any maintenance cost
  - Usage has dwindled; a simpler path exists
```

## Var försiktig med omskrivnings-fällan

Fulla omskrivningar är förföriska och ofta katastrofala – de tar längre tid än förväntat, återinför gamla buggar och det fungerade systemet förfaller i mellan tiden. Föredra inkrementell omstrukturering eller strangler-fig-ersättning. Gå för en full omskrivning endast när inkrementella vägar är verkligen stängda.

## Ett konkret exempel

En monolith är smärtsam men fungerar fint och är inte din flaskhals – omstrukturera de värsta modulerna, skriv inte om. Men ett system på en databasversion som förlorar säkerhetsstöd nästa år, utan uppgraderingsväg, det är en tvingad ersättning som du planerar medvetet.

## En fallgrop

Känslosamma beslut: att ersätta tillräckligt bra system för att de är omoderna, eller klibbar fast vid döende system på grund av tidigare investeringar. Bestäm utifrån kostnad och värde.

## Varför det spelar roll

Onödiga omskrivningar tar år och återinför lösta problem; försummat arv blir en tickande skuld.

Att fatta detta beslut rätt, på grund av bevis snarare än estetik, är ett av de högsta vadslagningsbesluten en senior TL fattar.