Pillar stran

Modernizacija zapuščinskih sistemov

Inkrementalen refaktoring monolita v mikrostoritve, migracija s zastarelih tehnologij na sodobne stacke, prenos v oblak — brez poslovnega izpada, z načrtom rollback in popolno revizijsko sledjo.

Revizija zapuščinskega sistema Vse storitve

Vsako podjetje ima kakšen zapuščinski sistem. Nekatera jih imajo več. Računovodska aplikacija iz leta 2008, ki nekako deluje. CRM, ki so ga napisali svetovalci, ki se jih nihče več ne spomni. Skladišče v Accessu. Vsakega od njih bo nekoč treba zamenjati — vprašanje ni ali, ampak kdaj in kako.

Modernizacija zapuščinskih sistemov je ena najtežjih vrst IT projektov. Zahteva uravnoteženje treh sil: ohranjanja poslovne kontinuitete (sistem mora delovati ves čas), uvajanja sodobnih tehnologij (mikrostoritve, oblak, AI) in nadzora tveganj (vsak refaktoring lahko pokvari nekaj, kar je delovalo leta).

Zakaj ne zadostuje „napisati znova od začetka"?

Iz naših izkušenj je 9 od 10 uspešnih modernizacij inkrementalen refaktoring, ne rewrite. Rewrite vabi s konceptualno preprostostjo („začeli bomo s čistim listom"), vendar v praksi ima tri temeljne težave:

  • Nevidna poslovna logika. Stari sistem vsebuje leta poslovnih pravil — posebni pogoji za največje stranke, davčne oprostitve za določene panoge, obvodi za regulative iz leta 2015. Večina ni dokumentirana. Rewrite jih mora vse obnoviti iz spomina ljudi ali analize kode.
  • Podvajanje dela. Med pisanjem novega sistema posel še naprej zahteva spremembe v starem (regulative, nove stranke, drobne napake). Ekipa bodisi podvaja delo (sprememba na dveh mestih) bodisi zamrzne stari sistem (poslovno tveganje).
  • Big bang deployment. Po letu dela je nov sistem „skoraj pripravljen". Preklop vseh uporabnikov v eni noči generira ogromno tveganje. Vsaka nepričakovana težava pomeni vrnitev na stari sistem, izgubo morale ekipe, izpodbijanje zaupanja posla.

Inkrementalen refaktoring (najpogosteje po vzorcu Strangler Fig) rešuje vse tri težave: poslovna logika se odkriva postopoma, en vir resnice za vsako entiteto, deployment po fazah s feature flagi.

Šest vzorcev modernizacije

Vsak od njih rešuje konkretno tveganje. V večini projektov združujemo več njih in izbiramo vzorec glede na konkretni modul.

Strangler Fig

Postopno „ovijanje" starega sistema z novimi komponentami. Stara koda še deluje, vendar vsaka nova funkcionalnost gre v novo mikrostoritev, obstoječe module pa zamenjujemo enega za drugim. Po 12-24 mesecih se stari monolit izklopi.

Anti-corruption layer

Adapter, ki ščiti novo kodo pred posebnostmi starega sistema (nečitljiva imena polj, čudni formati datumov, neskladni tipi). Vsa „grda" logika izolirana na enem mestu — nova koda dela na čistem domenskem modelu.

Database refactoring

Vzorci iz knjige Refactoring Databases (Ambler/Sadalage): expand-and-contract za migracijo sheme, validacija podatkov pred izbrisom starih stolpcev, vzporedno vzdrževanje obeh shem med migracijo aplikacije.

Branch by abstraction

Uvedba abstrakcijske plasti okrog stare komponente, vzporedna implementacija nove komponente, postopen preklop z 0% na 100% prometa (feature flag). Brez „big bang" uvedbe.

Shadow mode

Nova koda se izvaja vzporedno s staro — obe obdelujeta iste zahteve, vendar le rezultati stare gredo k uporabniku. Rezultati se primerjajo offline. Po potrditvi skladnosti (običajno 2-4 tedne) promet preklopimo na novo kodo.

Event sourcing za migracijo

Snemamo tok poslovnih dogodkov iz starega sistema in ga predvajamo v novem. Omogoča predhodno validacijo nove arhitekture brez produkcijskega tveganja in vrnitev v poljubno preteklo stanje.

Tipičen časovni razpored modernizacije

Za povprečni sistem (monolit ~200 tisoč vrstic kode, 5-10 poslovnih modulov):

  1. Mesec 1: Discovery in dokumentacija. Reverse engineering arhitekture, preslikava odvisnosti, identifikacija tokov podatkov, dokumentacija poslovnih procesov s pomočjo poslovnih oseb.
  2. Mesec 2: Ciljna arhitektura in pilot. Načrt nove arhitekture, izbira tehnologije, pilot na najpreprostejšem modulu (proof of concept). Prva validacija pristopa.
  3. Meseca 3-4: Izločitev prvega produkcijskega modula. Strangler Fig pattern, shadow mode 2-3 tedne, preklop prometa, hypercare. Prva realna poslovna vrednost.
  4. Meseci 5-12: Iterativno izločanje naslednjih modulov. Vsak v ciklu 4-6 tednov: refaktoring → testi → shadow → produkcija → hypercare. Nenehno izboljševanje procesa, krajšanje časa za naslednje module.
  5. Meseci 12-18: Migracija podatkov in izklop monolita. Ko so vsi kritični moduli izločeni, dokončamo migracijo zgodovinskih podatkov, izklopimo stari sistem, arhiviramo. Praznujemo.

Stari sistem vs. moderniziran

VidikZapuščinski sistem (običajno)Po modernizaciji
Čas uvajanja nove funkcije4-8 tednov (visoko tveganje regresije)3-7 dni (samodejni testi minimizirajo tveganje)
Pokritost s testi5-15% (ali brez)>80%, v CI/CD cevovodu
Razpoložljivost razvijalcevMajhna (zastarela tehnologija)Velika (priljubljeni, sodobni stacki)
VarnostStare knjižnice z CVE luknjamiSkeniranje OWASP, gitleaks, samodejne posodobitve
SkaliranjeVertikalno (več virov za monolit)Horizontalno (skaliranje konkretnih mikrostoritev)
OpazljivostLogi v datotekah, brez metrikPrometheus + Grafana + Sentry + SIEM
Compliance (GDPR, EU AI Act, ISO 27001)Zahtevno, drago za dokazovanjeVgrajeno v arhitekturo, pripravljeno za revizijo

Šest tipičnih tveganj — in kako jih obravnavamo

Tveganje: Brez testov v zapuščinskem sistemu

Mitigacija: Najprej gradimo karakterizacijske teste (capture tests) — snemamo obstoječe vedenje sistema na podlagi produkcijskih logov in posnetkov prometa. Šele nato začnemo refaktoring, s testi kot varovalom.

Tveganje: Znanje skoncentrirano v eni osebi („truck factor 1")

Mitigacija: Prenos znanja se začne v prvem tednu projekta. Vsi sestanki z osebo, ki pozna sistem, se snemajo in transkribirajo, ključni procesi dokumentirajo, arhitekturne odločitve utemeljijo. Po projektu celotna ekipa razume sistem.

Tveganje: Začasna upočasnitev ekipe

Mitigacija: V prvih 2-3 mesecih ekipa vzdržuje stari sistem + gradi nov. Naravna upočasnitev tempa sprememb. To ublažimo: prednost za spremembe, ki gredo le v nov sistem, freeze za nizko prioritetne spremembe v stari kodi.

Tveganje: Migracija podatkov

Mitigacija: Vsaka migracija podatkov ima tri faze: dry-run (na produkcijski kopiji), staging (na testnem okolju s pravim obsegom podatkov), produkcija (v servisnem oknu ali inkrementalno). Načrt rollback pripravljen pred začetkom.

Tveganje: Organizacijski odpor

Mitigacija: Komunikacija s poslom od prvega dne: zakaj modernizacija, kaj se bo spremenilo za uporabnika, kakšen časovni razpored, kako merimo uspeh. Prva iteracija izbrana tako, da hitro pokaže oprijemljivo vrednost (npr. nov UI ali hitrejše poročilo).

Tveganje: Podcenitev stroškov

Mitigacija: Discovery (1-2 tedna) pred ocenitvijo projekta. Iteracije 2-3 tedne s konkretnimi dostavljivimi učinki — lažje popraviti smer kot v dolgem projektu tipa „vse naenkrat". Proračun z buffer 20-30% za nepredvideno.

Pogosta vprašanja

Kaj je zapuščinski sistem?
Zapuščinski sistem je programska oprema, ki še deluje v organizaciji, vendar temelji na zastarelih tehnologijah, ima velik tehnični dolg, manjka mu testov, dokumentacije ali razvijalca, ki ga je napisal. Klasični primeri: monolitna aplikacija v PHP 5.x ali .NET Framework 4.0, podatkovna baza brez migracij, frontend v jQuery, deploy prek FTP. Deluje, vendar je vsaka sprememba visoko tveganje in strošek.
Zakaj modernizirati, če sistem deluje?
Trije glavni razlogi. Prvič: strošek vzdrževanja narašča eksponentno s starostjo sistema — vse manj razvijalcev pozna tehnologijo, vsaka sprememba traja dlje, vsaka napaka ima večji obseg. Drugič: varnostno tveganje — stari frameworki imajo nezakrpane luknje, brez podpore proizvajalca, neskladnost z GDPR/ISO 27001. Tretjič: zaviranje razvoja posla — nove zahteve (mobile, API, integracije, AI) so težke ali nemogoče za dodajanje.
Ali ni lažje vse napisati znova?
Klasična dilema „rewrite vs refactor". Rewrite vabi s konceptualno preprostostjo, vendar v praksi: trajajo 2-3-krat dlje od načrtovanega, projekt utone pod težo obnavljanja nevidne poslovne logike, vmes je stari sistem še naprej treba razvijati (podvajanje dela). Iz naših izkušenj: 9 od 10 uspešnih modernizacij je inkrementalen refaktoring (Strangler Fig pattern) — postopna zamenjava elementov starega sistema z ohranitvijo poslovne kontinuitete. Rewrite ima smisel le za zelo majhne sisteme.
Ali modernizacija zahteva poslovni izpad?
V veliki večini projektov ne. Uporabljamo vzorce, ki omogočajo zamenjavo komponent „v živo": blue-green deployment, feature flags, dark launches, vzporedni zagon stare in nove kode s primerjavo rezultatov (shadow mode). Kratka servisna okna so lahko potrebna pri migraciji podatkovne baze z bistveno spremembo sheme, vendar jih načrtujemo vnaprej (običajno ponoči, ob koncu tedna) in s polnim načrtom rollback.
Kako dolgo traja tipična modernizacija?
Odvisno od obsega. Posamezen modul monolita, izločen kot mikrostoritev: 1-2 meseca. Večja modernizacija (5-10 modulov, nova podatkovna baza, nov API): 6-12 mesecev v iteracijah 2-3 tedne. Popolna preobrazba podjetniškega monolita: 18-36 mesecev, vendar se poslovna vrednost pojavi že po prvi iteraciji — vsak izločen modul takoj prinese koristi (hitrejše spremembe, nižje tveganje, boljša opazljivost).
S katerih tehnologij najpogosteje migriramo?
Najpogostejše poti: PHP 5/7 → PHP 8 ali Python (FastAPI) ali Node.js (Express/Fastify). .NET Framework 4.x → .NET 8 ali Java/Spring Boot. Java EE (JBoss/WebSphere) → Spring Boot ali Quarkus. jQuery + monolithic templates → React/Vue/Astro. Oracle DB → PostgreSQL (znaten prihranek pri licencah). On-premise → oblak (AWS, Azure, GCP, lokalni privatni oblak).
Kaj z obstoječimi integracijami z drugimi sistemi?
Vsaka obstoječa integracija je preslikana v discovery fazi. Načrt migracije zajema: ohranitev obstoječih pogodb (interne in zunanje stranke ne opazijo spremembe), uvedba verzioniranja (v1 stara pogodba, v2 nova), postopno migriranje porabnikov na v2, šele nato izklop v1. Popolna povratna združljivost med migracijo.
Kako omejujete poslovno tveganje?
Pet plasti: 1) inkrementalnost — menjavamo po enem modulu, ne vsega naenkrat; 2) karakterizacijski testi — pred refaktoringom posnamemo obstoječe vedenje sistema (capture tests), ki potem preverjajo, da nič ni pokvarjeno; 3) feature flags — nova funkcionalnost zaganjana postopno (1% uporabnikov → 10% → 50% → 100%); 4) načrt rollback za vsako uvedbo (<5 min); 5) hypercare po uvedbi (intenziven monitoring 2-4 tedne).
Kaj z dokumentacijo sistema, ki je ni?
Pogosta težava pri zapuščinskih sistemih. Prva faza projekta: reverse engineering dokumentacije. Agenti AI analizirajo kodo, shemo podatkovne baze, produkcijske loge in generirajo: shemo arhitekture, seznam končnih točk, zemljevid odvisnosti, opis poslovnih procesov. Ta dokumentacija je nato preverjena z osebami iz posla (ali proces izgleda tako, kot ga razumemo iz kode). Učinek: popolna dokumentacija pred začetkom refaktoringa, uporabna ne le za projekt modernizacije, ampak tudi za produktno ekipo.
Kakšni so stroški modernizacije v primerjavi z vzdrževanjem starega sistema?
Kratkoročno je modernizacija dražja od vzdrževanja (naložba v refaktoring + vzporedno vzdrževanje starega sistema). Točka break-even (kjer nov sistem postane cenejši za vzdrževanje od starega) običajno nastopi po 12-18 mesecih. Po tem času: nov sistem stane manj za vzdrževanje (manj razvijalcev, več avtomatizacije), omogoča hitrejše uvajanje sprememb (krajši time-to-market), zmanjšuje tveganje (boljša opazljivost, več testov, izolacija odpovedi).

Začnimo z revizijo

Enotedenska tehnična revizija: preslikava trenutnega stanja, identifikacija najnujnejših področij modernizacije, fazni načrt s konkretnimi poslovnimi učinki v prvi iteraciji.

Dogovori revizijo sistema Proces razvoja