Zamjena naslijeđenih sustava korak po korak: Strangler Pattern, paralelni rad i dosljednost podataka pri uvođenju

Zamjena Legacy-Ablösung rijetko ne uspije zbog „izgradnje“ novog rješenja, već zbog prijelaza: podaci moraju ostati ispravni, sučelja se ne smiju prekinuti, a rad sustava mora se nastaviti tijekom promjene. U mnogim tvrtkama Big-Bang-Cutover stoga nije opcija – ovisnosti su prevelike, troškovi zastoja su previsoki, a povratak je prerizičan.

U praksi se pokazuje učinkovitim postupno pristupanje s Strangler Pattern (funkcionalni dijelovi se postupno „preusmjeravaju“), Parallelbetrieb (stari i novi sustav neko vrijeme rade paralelno) i jasnim pravilima za Datenkonsistenz. Ovaj članak pokazuje kako te građevne blokove kombinirati tako da budu održivi u svakodnevnom radu IT‑vodstva, administracije i odgovornih za projekte – uključujući tipične pogreške, operativne posljedice i točke odlučivanja u rolloutu.

Zašto je pristup korak‑po‑korak često jedina realistična Legacy‑Ablösung

Legacy‑sustavi rijetko su „samo jedna aplikacija“. Najčešće su povezani: batch‑pokretanja, datotečni interfacei (SFTP mape, mrežni diskovi), procesi ispisa i skeniranja, lokalni alati, BI‑ekstrakti, e‑mail‑relayi, specijalizirana hardvera, Shadow‑IT izlazi i ručna zaobilazna rješenja. Kod Big‑Banga sve ove staze moraju raditi istog vikenda – i to uključujući prava pristupa, master‑podatke, povijest i iznimne slučajeve.

Pristup korak‑po‑korak smanjuje rizik, no ne premješta ga automatski „dolje“. Čini rizike vidljivijima i upravljivima, ali zahtijeva čvrste arhitekturne i operativne odluke: gdje se radi routing? Tko je vlasnik podataka? Koja konzistentnost je poslovno obvezna, a gdje je vremensko kašnjenje prihvatljivo? I kako spriječiti da paralelni rad postane trajna gradilišna situacija?

Strangler Pattern u korporativnoj stvarnosti: ne „Microservices“, već jasne rezne točke

Strangler Pattern znači: razvijate nove funkcije pored postojećeg sustava i postupno preusmjeravate promet dok stari dio ne postane suvišan. Važno: ovo nije arhitekturni ideološki sukob („Monolith vs. Microservices“), već migrationsmuster. Djeluje i ako ciljana arhitektura i dalje bude monolit – samo moderniziran, održiviji i bolje integriran.

Najvažnija odluka: rezati po procesima, ne po tablicama

U mnogim zamjenama rezanje se radi prema podacima („Prvo ćemo uzeti tablice za kupce i narudžbe“). To često vodi bolnom paralelnom radu, jer procesi prelaze preko tih podataka. Bolje je rezanje usmjereno na procese, npr. „izrada ponude“, „prijem robe“, „obrada reklamacije“ ili „servisni ticket do fakture“.

Pravilo iz prakse: Strangler-etapa trebala bi pokriti stručno zatvoren proces koji se u novom sustavu može upravljati i nadzirati kraja do kraja. To uključuje ulaze (UI, API, uvoz), obradu (poslovna pravila) i izlaze (ispis, izvoz, knjiženje, obavijest).

Strangler braucht einen „Umlenker“: Gateway, Proxy oder Routing-Schicht

Kako bi korisnici i povezani sustavi svaki put ne morali učiti nove krajnje točke, često se koristi sloj rutiranja. Ovisno o početnoj situaciji to može biti: ein Reverse Proxy ispred web-aplikacija, ein API-Gateway za service-krajnje točke ili integracijski sloj koji objedinjava datotečna sučelja i događaje. Ključno je operabilnost: centralna konfiguracija, jasni logovi, monitoring i kontrolirani rollback.

Za administratore je važno da taj sloj ne postane blackbox. Trebaju im razumljiva routiranja (koji je Request otišao kamo), korelacija kroz logove (npr. Request-ID) i definirani timeoutovi/pravila ponovnog pokušaja, kako se pogreške ne bi „verklebt“.

Parallelbetrieb ist ein Betriebszustand – kein „Projekttrick“

Paralelni rad znači: stare i nove komponente neko vrijeme rade istovremeno u produkciji. To je normalno, ali skupo – osobito u radu. Imate više pokretnih dijelova, više nadzora, veći potencijal incidenata i složenije odgovornosti. Stoga se paralelni rad mora planirati kao operativni režim ograničenog trajanja, uključujući kriterije za prekid.

Typische Parallelbetriebs-Modelle (und wann sie passen)

• Prebacivanje prema skupinama korisnika (Pilotgruppe → Wellen): pogodno kada su korisničke uloge jasno razdvojive i procesi ne prelaze preko skupina.
• Prebacivanje prema mandantima/lokacijama: dobro kod struktura s filijalama/pogonima, kada su tokovi podataka između lokacija ograničeni.
• Prebacivanje prema koracima procesa: npr. „unos novi, obračun još stari“ – rizično ako postoji mnogo povratnih veza, ali ponekad neizbježno.
• Prebacivanje prema tipovima objekata: npr. nova dugotrajna imovina u novom sustavu, stare zalihe u starom – može funkcionirati ako postoje jasna pravila za historiju/izvještavanje.

Iz operativnog pogleda trebali biste paralelni rad osmisliti tako da domene pogrešaka ostanu male: kvar u novoj komponenti ne smije povući legacy sustav za sobom (npr. kroz blokirajuća sučelja ili zaključavanja u bazi podataka), i obrnuto, legacy ne smije sabotirati sve nove tokove kroz nestabilne izvozne procese.

Feature Flags und Routing-Regeln: Kontrolle statt „wir rollen aus und hoffen“

Feature flagovi su prekidači kojima ciljno uključujete/isključujete funkcije – bez novog deploya. Za IT-upravu i odgovorne za projekt nije presudan tehnički detalj, nego Governance: tko smije prebacivati? Kako se dokumentira zašto je napravljena promjena? Koliko brzo se možete vratiti? Koje ovisnosti nastaju (npr. ako su podaci već stvoreni u novom formatu)?

Praktična praksa je mali zapisnik promjena (Decision Log) za svaku akciju prebacivanja: vrijeme, Owner, pogođena skupina korisnika, očekivani efekt, pokazatelji za monitoring, uvjet za rollback. To sprječava klasično „Nitko više ne zna, zašto je tako rutirano“.

Konzistentnost podataka pri uvođenju: srž, o kojoj ovise mnoge zamjene

Konzistentnost podataka znači da su podaci stručno ispravni, potpuni i dostupni u očekivanom redoslijedu. U paralelnom radu to postaje izazov, jer dva sustava istovremeno pišu ili se barem oba smatraju „istinom“. Ovdje se odlučuje hoće li zamjena legacy sustava djelovati stabilno ili ćete mjesecima izvoditi usklađivanja delta-podataka.

Erst klären: Wer ist „System of Record“ je Datenbereich?

Za svako područje podataka (npr. kupci (Debitoren), artikli, cijene, narudžbe, kretanja zaliha, dokumenti) trebate odrediti koji sustav je vodeći. To nije puko arhitektonsko pitanje, već operativno:

• Gdje se izvršavaju ispravke u slučaju podrške?
• Gdje se odvija proces odobrenja (Vier-Augen, SoD/odvajanje funkcija)?
• Koje audit-trake su potrebne (tko je kada što promijenio)?
• Kako izbjeći naknadne ispravke pri mjesečnom zatvaranju?

U ranim fazama Strangler pristupa često je smisleno prvo ostaviti legacy kao vodeći izvor podataka, a novu komponentu „samo“ konzumerom. Kasnije okrenete vođenje. Ta promjena vođenja je zaseban ključni korak i zahtijeva jasno Cutover-Fenster te plan komunikacije i prihvata.

Synchronisationsmuster: Dual Write, CDC und Events – mit realistischen Erwartungen

Postoji nekoliko načina sinkronizacije podataka između stare i nove komponente. Nijedan nije „besplatan“.

• Dual Write: Jedna akcija upisuje u oba sustava (npr. kreiranje narudžbe → Legacy i novi sustav). Prednost: brza dostupnost. Nedostatak: u slučaju pogreške složeno je (što ako sustav A upiše, a sustav B ne?), dodatno nastaju ovisnosti i često rizici za performanse.
• Change Data Capture (CDC): Promjene se ekstrahiraju iz loga baze podataka ili preko triggera/replikacije kao delte. Prednost: odvojenost aplikacije i sinkronizacije. Nedostatak: replicirate i „tehničke“ promjene i morate rekonstruirati poslovne događaje; osim toga, promjene sheme u legacyju iznenada postaju rizik za integraciju.
• Integracija temeljena na događajima: Sustav publikuje poslovne događaje (npr. „narudžba odobrena“), koje drugi sustavi konzumiraju. Prednost: jasna poslovna semantika. Nedostatak: zahtijeva čiste definicije događaja, idempotenciju (ponovna obrada bez štete) i pouzdan operativni koncept za messaging.

Za donositelje odluka ključno je: konzistentnost podataka nije binarna. Neki procesi zahtijevaju jaku konzistentnost (odmah ispravno, npr. odobrenja plaćanja), drugi toleriraju eventualnu konzistentnost (kratko kašnjenje, npr. indeks pretraživanja, izvještavanje, obavijesti). Ovu klasifikaciju treba rano uskladiti s poslovnim odjelom i revizijom/auditom.

Konflikte und Dubletten: Planen Sie den „hässlichen Pfad“ explizit

U paralelnom radu sukobi obično nastaju ovako: dva sustava mijenjaju isti objekt, ali prema različitim pravilima. Ili se import izvrši dvaput jer je retry došao preuranjeno. Ili korisnik ispravlja podatke u Legacyju dok je novo sučelje već prebačeno.

Za to su vam potrebna obvezujuća pravila:

• Rješavanje konflikata: „Last write wins“ rijetko je stručno ispravno. Bolje su prioritete (vodeći sustav pobjeđuje) ili stručna pravila spajanja (npr. osnovni podaci kontakta vs. uvjeti).
• Idempotencija: Svaka integracija treba podnijeti višestruku obradu bez duplikata (npr. isti broj dokumenta, ista vanjska referenca).
• Dead-Letter/Quarantäne: Neobrađeni zapisi delta moraju se moći pronaći, s jasno definiranim odgovornostima i mogućnošću ponovnog pokretanja.

Bez tih pravila dosljednost podataka sklizne u „Excel-abgleich“ i ručni naknadni rad – uz odgovarajuću frustraciju i teško mjerljive posljedične troškove.

Dizajn roll-outa: valovi, prihvati i povratak, bez preopterećenja operativnog rada

Dobar roll-out je više od „Deployment + Schulung“. U paralelnom radu morate povezati roll-out i operativni rad: tko radi First-Level kad nastane greška? Koji logovi su odmah dostupni? Kako se eskalira? Koji procesi se u valu ne smiju prebacivati (npr. mjesečno zatvaranje, inventura, promjena cijena)?

Planiranje valova sa strogi(m) kriterijima

Pokazalo se učinkovitima planiranje valova s jasnim ulaznim kriterijima, ne samo datumima. Primjeri strogih kriterija:

• Monitoring-Dashboards i alerting za novu komponentu su u produkciji i testirani (uključujući smanjenje „alarm-rauschen“).
• Runbookovi za tipične incidente postoje (timeouti, zagušenje redova, neispravni importi, problemi s dopuštenjima).
• Usklađivanje delta je automatizirano i daje razumljive izvještaje (razlike po tipu objekta, vremenskom prozoru, klasi uzroka).
• Mehanizam rollbacka je uvježban (barem realistično odigran u Staging/Pre-Prod).

Posebno se potcjenjuje zadnja točka: rollback nije „mi samo uključimo natrag“. Ako je novi sustav već generirao podatke, morate znati kako će ti podaci biti vidljivi u Legacyju ili kako ćete generirane podatke ispravno migrirati/neutralizirati.

Cutover — mini-cutoveri umjesto Big Bang

Čak i kod Strangler Pattern postoje cutoveri – samo manji. Tipično su mini-cutoveri pri promjeni koraka procesa ili pri preuzimanju vodstva nad podacima. Svaki mini-cutover treba:

• Zamrzavanje podataka (kratko, ali obvezujuće): Tko smije što mijenjati tijekom toga?
• Usklađivanje: Što je promijenjeno od zadnje sinkronizacije?
• Prebacivanje: Routing/Feature Flags, jobovi, rasporedi, dopuštenja.
• Verifikacija: Stručni smoke-testovi (npr. kreiranje narudžbe → otpremnica → račun), plus tehničke provjere (redovi, stope grešaka, opterećenje DB-a).

Za IT‑vodstvo je važno da su ti koraci dokumentirani kao ponovljiv proces i osobno osigurani. Inače uspjeh projekta ovisi o pojedincima koji „znaju kako se to radi“.

Prvo stabilizirati sučelja: potcijenjena osnova zamjene Legacy sustava

Mnogi Legacy-sustavi komuniciraju preko razvijenih sučelja: CSV-izvozi u mape, noćni jobovi, direktni pristupi bazi podataka od strane alata trećih strana, e-mail bazirani workflowi. Postupna zamjena bit će znatno lakša ako prvo inventarizirate krajolik sučelja i konsolidirate ga na nekoliko mjesta.

U praksi to znači: identificirajte integracijske točke kritične za sustav (npr. Finanzbuchhaltung, Versand, Produktionsrückmeldungen, Identitäten/Berechtigungen) i uspostavite tamo jasne ugovore. „Ugovor“ ovdje ne znači pravno, nego tehničku stabilnost: versioniranje, jednoznačna polja, stabilni IDs, dokumentirano rukovanje greškama, definirani SLAs za isporuku podataka.

Ako uz to uspostavite interni API-/integracijski model upravljanja (vlasnik, Deprecation-Regeln, Test-/Staging-Pfade), smanjuje se rizik da će izmjena u legacy sustavu iznenada onesposobiti vašu novu komponentu. Pogodna tema za internu poveznicu bila bi, npr., objava o API-Governance i strategijama deprecacije.

Security, Berechtigungen und Audit: Parallelbetrieb verschärft das Thema

U paralelnom radu često postoje dvostruki modeli korisnika i uloga. To vodi do sjena‑priviligija: korisnik je u novom sustavu ispravno ograničen, ali u legacyju još ima široka prava – i na kraju koristi „einfacheren Weg“. Uz to dolaze tehnički računi (Service Accounts) za sinkronizaciju, importe, Queues i Batchjobs.

Konkretne točke koje biste trebali razjasniti rano:

• Izvor identiteta: Odakle dolaze korisnici i grupe? AD/Entra ID? Ein eigenes IAM? Važno je da je provisioniranje pratljivo.
• Mapiranje uloga: Ako uloge nisu 1:1, trebaju prijelazne uloge koje su vremenski ograničene i koje se redovito rezertificiraju.
• Servisni računi: Minimalna prava, rotacija Secrets, detaljno evidentiranje. Posebno sinkronizacijski računi su inače ulazna točka i teško ih je auditirati.
• Audit-Trails: Ako se vlasništvo nad podacima promijeni, mora biti jasno gdje se nalazi dokaz o promjenama i kako se on može istražiti preko oba sustava.

Važno za donositelje odluka: Security ovdje nije „zusätzlicher Scope“, nego utječe na izvedivost puštanja u rad. Kasnije usklađivanje ovlasti u paralelnom radu obično je skuplje od ranog, pragmatičnog definiranja opsega uloga i servisnih računa.

Monitoring, Logging und Betriebsübergabe: Ohne Observability wird Parallelbetrieb blind

U paralelnom radu slike grešaka često su indirektne: delta zapne, retry se izvršava beskonačno, Queue se zaguši, ili vremenski kritičan posao kolidira s zaključavanjem baze podataka. Ako to vidite samo preko korisničkih tiketa, kasnite. Zato trebate od početka minimum observabilnosti: Monitoring (stanje), Logging (događaji) i – gdje je smisleno – Tracing (lanac kroz sustave).

Praktični, dobro upravljivi signali su, na primjer:

• Synchronisations-Backlog (koliko promjena „čeka“), plus starost najstarijeg unosa.
• Stope pogrešaka po Schnittstelle i klasi pogrešaka (Validierung, Timeout, Auth, Datenkonflikt).

Za predaju u operativu manje je važno koji je alat korišten, a važnije je jesu li odgovornosti i Runbooks jasni. Ako imate On-Call ili dežurstvo, operativ mora biti sposoban reagirati na tipične kvarove bez detektivskog rada developera.

Kada Strangler Pattern ne odgovara (ili samo uz jasna ograničenja)

Postoje situacije u kojima postupna zamjena djeluje samo ograničeno:

• Izuzetno usko povezivanje transakcija: Ako gotovo svaki postupak obuhvaća sve module i zahtijeva strogu konzistenciju, paralelni rad ubrzo postaje neobvladiv.
• Izravni DB-pristupi od trećih sustava: Ako više alata izravno čita/pisuje u legacy tablice, taj razmještaj treba prvo zaustaviti ili staviti pod kontrolu.
• Nejasno vlasništvo nad podacima: Ako se ne može jasno odrediti tko vodi podatke, konflikti su zajamčeni – i zamjena postaje političko umjesto tehničko pitanje.
• Nedostatak operativne discipline: Bez urednih okruženja, reproducibilnih deploymenta i nadzora svaki međukorak postaje rizik.

To ne znači da ste prisiljeni na Big Bang. Ali tada morate promijeniti redoslijed: prvo stabilizirati integracijske točke, centralizirati pristupe podacima, razjasniti uloge i vlasništvo – i tek onda primijeniti Strangler Pattern.

Praktičan plan tijeka za etapnu zamjenu legacy sustava

Kao smjernica za voditelje projekata pokazao se tijek rada podijeljen u jasne etape. Točna provedba ovisi o sustavu i industriji, ali je logika robusna:

1. Inventar & ovisnosti: sučelja, zadaci, tokovi podataka, skupine korisnika, kritični vremenski okviri (zaključenje, inventura).
2. Definiranje granica integracije: procesni moduli, vlasništvo nad podacima po području, integracijski ugovori.
3. Izgraditi rutiranje & sklopke: Gateway/Proxy, Feature Flags, centralizirano protokoliranje.
4. Odrediti put podataka: CDC/Event/Dual Write, pravila za rješavanje konflikata, karantena, izvještaji o usklađivanju.
5. Pilot s pravim opterećenjem: ne samo demo, nego s realnim slučajevima, uključujući iznimke.
6. Rollout u valovima: kriteriji ulaska, kontrolne liste za cutover, rollback vježbe.
7. Onemogućavanje & čišćenje: deaktivirati stare putanje, ukloniti zadatke, oduzeti prava, ažurirati dokumentaciju.

Zadnja točka je esencijalna: Mnoge organizacije ostave legacy komponente „za sigurnost“ da rade. Rezultat: dvojni troškovi, nejasan rizik, nitko se ne usuđuje isključiti ih. Planirajte dekomisioniranje kao podprojekt s rokom, odgovornima i dokazima (npr. „nema pristupa zadnjih X tjedana“, „svi eksporti preusmjereni“, „ispunjeni zahtjevi audita“).

Zaključak: Postupna zamjena znači tretirati konzistenciju i operacije kao proizvod

Postupna zamjena legacy sustava po koracima nije automatski jednostavnija – ali je u mnogim tvrtkama jedina realna opcija. Strangler Pattern funkcionira ako za svaku etapu definirate jasne procesne rezne točke, planirate paralelni rad kao stvarno operativno stanje i ne prepuštate konzistentnost podataka slučaju. Presudno su rane odluke o vlasništvu podataka, robusni obrasci sinkronizacije s pravilima za konflikte te dizajn roll-outa s valovima, odobrenjima i uvježbanim povratkom.

Ako planirate zamjenu i želite strukturirano razmotriti integracijske točke, paralelni rad ili koncept dosljednosti podataka, kontaktirajte nas putem .

Razgovarajte o projektu ili modernizacijskom pothvatu s Net-Base.