Pillar stranica
Modernizacija naslijeđenih sustava
Inkrementalni refaktoring monolita u mikroservise, migracija sa zastarjelih tehnologija na moderne stackove, prijenos u oblak — bez poslovnog prekida, s planom rollbacka i potpunim revizijskim tragom.
Svaka tvrtka ima neki naslijeđeni sustav. Neke ih imaju nekoliko. Računovodstvena aplikacija iz 2008. godine koja nekako radi. CRM koji su napisali konzultanti kojih se nitko više ne sjeća. Skladište u Accessu. Svaki od njih jednom će morati biti zamijenjen — pitanje nije hoće li, nego kada i kako.
Modernizacija naslijeđenih sustava jedan je od najtežih tipova IT projekata. Zahtijeva uravnoteženje tri sile: održavanje poslovnog kontinuiteta (sustav mora raditi cijelo vrijeme), uvođenje modernih tehnologija (mikroservisi, oblak, AI) i kontrolu rizika (svaki refaktoring može pokvariti nešto što je radilo godinama).
Zašto „pisanje ispočetka" nije dovoljno?
Iz našeg iskustva 9 od 10 uspješnih modernizacija je inkrementalni refaktoring, a ne rewrite. Rewriteovi su konceptualno primamljivi („počet ćemo s čistom pločom"), ali u praksi imaju tri fundamentalna problema:
- Nevidljiva poslovna logika. Stari sustav sadrži godine poslovnih pravila — posebne uvjete za najveće klijente, porezna oslobođenja za konkretne industrije, zaobilaženja za regulative iz 2015. godine. Većina nije dokumentirana. Rewrite ih mora sve rekreirati iz sjećanja ljudi ili analize koda.
- Dupliciranje rada. Tijekom pisanja novog sustava, biznis i dalje zahtijeva promjene u starom (regulative, novi klijenti, sitni bugovi). Tim ili duplicira rad (promjena na dva mjesta) ili zamrzava stari sustav (poslovni rizik).
- Big bang deployment. Nakon godine rada, novi sustav je „skoro gotov". Prebacivanje svih korisnika u jednoj noći generira monumentalan rizik. Svaki neočekivan problem znači povratak na stari sustav, gubitak morala tima, podrivanje povjerenja biznisa.
Inkrementalni refaktoring (najčešće prema Strangler Fig obrascu) rješava sva tri: poslovna logika otkriva se postupno, jedan izvor istine za svaki entitet, deployment u fazama s feature flagovima.
Šest obrazaca modernizacije
Svaki od njih rješava konkretan rizik. U većini projekata kombiniramo nekoliko, birajući obrazac za konkretan modul.
Strangler Fig
Postupno „omotavanje" starog sustava novim komponentama. Stari kod i dalje radi, ali svaka nova funkcionalnost ide u novi mikroservis, a postojeći moduli zamjenjuju se jedan po jedan. Nakon 12-24 mjeseca stari monolit se gasi.
Anti-corruption layer
Adapter koji štiti novi kod od posebnosti starog sustava (nečitljiva imena polja, čudni formati datuma, nedosljedni tipovi). Sva „ružna" logika izolirana je na jednom mjestu — novi kod operira na čistom modelu domene.
Database refactoring
Obrasci iz knjige Refactoring Databases (Ambler/Sadalage): expand-and-contract za migracije sheme, validacija podataka prije brisanja starih stupaca, paralelno održavanje obje sheme tijekom migracije aplikacije.
Branch by abstraction
Uvođenje sloja apstrakcije oko stare komponente, paralelna implementacija nove komponente, postupno prebacivanje s 0% na 100% prometa (feature flag). Bez „big bang" deploya.
Shadow mode
Novi kod pokreće se paralelno sa starim — oba obrađuju iste zahtjeve, ali samo rezultati starog dolaze do korisnika. Rezultati se uspoređuju offline. Nakon potvrde sukladnosti (obično 2-4 tjedna) prebacujemo promet na novi kod.
Event sourcing za migraciju
Snimamo tok poslovnih događaja iz starog sustava i reproduciramo ga u novom. Omogućuje preliminarnu validaciju nove arhitekture bez produkcijskog rizika te povratak na bilo koje povijesno stanje.
Tipičan harmonogram modernizacije
Za srednji sustav (monolit ~200 tis. linija koda, 5-10 poslovnih modula):
- Mjesec 1: Discovery i dokumentacija. Reverse engineering arhitekture, mapiranje ovisnosti, identifikacija tokova podataka, dokumentacija poslovnih procesa uz pomoć poslovnih ljudi.
- Mjesec 2: Ciljna arhitektura i pilot. Projekt nove arhitekture, odabir tehnologija, pilot na najjednostavnijem modulu (proof of concept). Prva validacija pristupa.
- Mjeseci 3-4: Izdvajanje prvog produkcijskog modula. Strangler Fig obrazac, shadow mode kroz 2-3 tjedna, prebacivanje prometa, hypercare. Prva stvarna poslovna vrijednost.
- Mjeseci 5-12: Iterativno izdvajanje sljedećih modula. Svaki u ciklusu 4-6 tjedana: refaktoring → testovi → shadow → produkcija → hypercare. Kontinuirano unaprjeđenje procesa, smanjenje vremena za sljedeće module.
- Mjeseci 12-18: Migracija podataka i povlačenje monolita. Kada su svi kritični moduli izdvojeni, finaliziramo migraciju povijesnih podataka, gasimo stari sustav, arhiviramo. Slavimo.
Stari sustav vs. modernizirani
| Aspekt | Naslijeđeni sustav (obično) | Nakon modernizacije |
|---|---|---|
| Vrijeme implementacije nove funkcije | 4-8 tjedana (visok rizik regresije) | 3-7 dana (automatski testovi minimiziraju rizik) |
| Pokrivenost testovima | 5-15% (ili ništa) | >80%, u CI/CD pipelineu |
| Dostupnost programera | Niska (zastarjela tehnologija) | Visoka (popularni, moderni stackovi) |
| Sigurnost | Stare biblioteke s CVE rupama | Skeniranje OWASP, gitleaks, automatska ažuriranja |
| Skaliranje | Vertikalno (više resursa za monolit) | Horizontalno (skaliranje konkretnih mikroservisa) |
| Observabilnost | Logovi u datotekama, bez metrika | Prometheus + Grafana + Sentry + SIEM |
| Compliance (GDPR, EU AI Act, ISO 27001) | Zahtjevno, skupo za dokazivanje | Ugrađeno u arhitekturu, spremno za reviziju |
Šest tipičnih rizika — i kako ih adresiramo
Rizik: Nedostatak testova u naslijeđenom sustavu
Mitigacija: Prvo gradimo karakterizacijske testove (capture testove) — snimamo trenutno ponašanje sustava na temelju produkcijskih logova i snimki prometa. Tek onda počinjemo refaktoring, s testovima kao sigurnosnom mrežom.
Rizik: Znanje koncentrirano u jednoj osobi („truck factor 1")
Mitigacija: Prijenos znanja započinje u prvom tjednu projekta. Svi sastanci s osobom koja poznaje sustav se snimaju i transkribiraju, ključni procesi dokumentiraju, arhitektonske odluke obrazlažu. Nakon projekta cijeli tim razumije sustav.
Rizik: Privremeno usporavanje tima
Mitigacija: U prvih 2-3 mjeseca tim održava stari sustav + gradi novi. Prirodno usporavanje tempa promjena. Mitigiramo ga: prioritet za promjene koje idu samo u novi sustav, freeze za niskoprioritetne promjene u starom kodu.
Rizik: Migracija podataka
Mitigacija: Svaka migracija podataka ima tri faze: dry-run (na produkcijskoj kopiji), staging (na testnom okruženju sa stvarnom razmjerom podataka), produkcija (u servisnom prozoru ili inkrementalno). Plan rollbacka gotov prije starta.
Rizik: Organizacijski otpor
Mitigacija: Komunikacija s biznisom od prvog dana: zašto modernizacija, što se mijenja za korisnika, kakav je raspored, kako mjerimo uspjeh. Prva iteracija odabrana je tako da brzo pokaže opipljivu vrijednost (npr. novi UI ili brži izvještaj).
Rizik: Podcjenjivanje troška
Mitigacija: Discovery (1-2 tjedna) prije procjene projekta. Iteracije od 2-3 tjedna s konkretnim isporukama — lakše je korigirati kurs nego u dugom projektu tipa „sve odjednom". Budžet s rezervom 20-30% za nepredviđeno.
Najčešća pitanja
Što je naslijeđeni (legacy) sustav?
Zašto modernizirati ako sustav radi?
Nije li lakše napisati sve iznova?
Zahtijeva li modernizacija poslovni prekid?
Koliko traje tipična modernizacija?
S kojih tehnologija najčešće migriramo?
Što s postojećim integracijama s drugim sustavima?
Kako ograničavate poslovni rizik?
Što s dokumentacijom sustava koja ne postoji?
Kakvi su troškovi modernizacije u usporedbi s održavanjem starog sustava?
Započnimo revizijom
Tjedna tehnička revizija: mapiranje trenutnog stanja, identifikacija najhitnijih područja modernizacije, fazni plan s konkretnim poslovnim učincima u prvoj iteraciji.