Zamjena naslijeđenih sistema korak po korak: Strangler Pattern, paralelni rad i konzistentnost podataka u rolloutu

Jedna zamjena naslijeđenog sistema rijetko propadne zbog „izrade“ novog rješenja, nego zbog prijelaza: podaci moraju ostati ispravni, sučelja se ne smiju prekinuti, a rad mora tijekom prebacivanja nastaviti. U mnogim kompanijama je Big-Bang-Cutover stoga nije opcija – ovisnosti su prevelike, troškovi zastoja previsoki, a povratak presložan.

U praksi se pokazuje kao djelotvorno postupno pristupanje s Strangler Pattern (funkcionalni dijelovi se postepeno „prebacuju“), Parallelbetrieb (stari i novi sistem privremeno rade paralelno) i jasnim pravilima za Datenkonsistenz. Ovaj članak pokazuje kako te gradivne blokove kombinirati tako da budu održivi u svakodnevici IT-uprave, administracije i projektne odgovornosti – uključujući tipične pogreške, posljedice u radu i mjesta odluke u rolloutu.

Zašto je pristup korak po korak često realistična zamjena naslijeđenog sistema

Legacy-Systeme su rijetko „samo jedna aplikacija“. Obično su vezani: batch poslovi, datotečna sučelja (SFTP-Ordner, Netzlaufwerke), procesi ispisa i skeniranja, lokalni alati, BI-ekstrakti, E-Mail-Relays, specijalizirani hardver, preusmjerenja Shadow-IT-a i ručni zaobilazni postupci. Kod Big Bang-a svi ti tokovi moraju funkcionirati istog vikenda – i to uključujući prava pristupa, Stammdaten, historije i posebne slučajeve.

Pristup korak po korak smanjuje rizik, ali ga ne premješta automatski „na niži nivo“. Čini rizike vidljivijim i upravljivijim, ali zahtijeva čiste odluke o arhitekturi i operacijama: Gdje se routa? Tko je nositelj podataka? Koja dosljednost je strukturno obavezna, a gdje je vremensko kašnjenje prihvatljivo? I kako spriječiti da Parallelbetrieb postane stalno gradilište?

Strangler Pattern in der Unternehmensrealität: nicht „Microservices“, sondern klare Schnittkanten

Das Strangler Pattern znači: gradite nove funkcije pored starog sistema i postupno preusmjeravate promet dok stari dio ne postane suvišan. Važno: ovo nije arhitektonski religiozni sukob („Monolith vs. Microservices“), nego Migrationsmuster. Funkcionira i ako ciljna arhitektura i dalje ostane monolit – samo modernija, održivija i bolje integrirana.

Die wichtigste Entscheidung: Schneiden Sie nach Prozessen, nicht nach Tabellen

U mnogim zamjenama se rez vrši vođen podacima („Prvo uzimamo tabele za kupce i narudžbe“). To često vodi bolnom Parallelbetrieb, jer procesi prelaze preko tih podataka. Bolje je prozessorientisano rezanje, npr. „izrada ponude“, „prijem robe“, „obrada reklamacija“ ili „servisni tiket do fakture“.

Pravilo iz prakse: Jedna Strangler-etapa treba pokriti stručno zatvoren tok koji se u novom sistemu može upravljati i nadzirati od kraja do kraja. To obuhvata ulaze (UI, API, uvoz), obradu (poslovna pravila) i izlaze (štampa, izvoz, knjiženje, obavještenje).

Strangler treba „preusmjerivač“: Gateway, Proxy ili routing-sloj

Da korisnici i povezani sistemi ne bi svaki put morali učiti nove krajnje tačke, često se koristi routing-sloj. Ovisno o početnoj situaciji to može biti: Reverse Proxy ispred web-aplikacija, ein API-Gateway za servisne endpointe ili integracijski sloj koji objedinjuje datotečne interfejse i evente. Presudna je operativna sposobnost: centralna konfiguracija, jasni logovi, monitoring i kontrolirani rollback.

Za administratore je važno da taj sloj ne postane blackbox. Potrebni su razumljivi routing‑zapisi (koji request je otišao gdje), korelacija kroz logove (npr. Request-ID) i definisani Timeouts/Retry‑Regeln, kako se greške ne bi „zalijepile“.

Paralelni rad je operativno stanje – nije „projektni trik“

Paralelni rad znači: stare i nove komponente neko vrijeme rade istovremeno u produkciji. To je normalno, ali skupo – naročito u radu. Imaćete više aktivnih komponenti, više monitoringa, veći potencijal incidenata i složenije odgovornosti. Zato se paralelni rad mora planirati kao vremenski ograničeni režim rada, uključujući kriterije za prekid.

Tipični modeli paralelnog rada (i kada odgovaraju)

• Prebacivanje po grupama korisnika (pilotgrupa → talasi): pogodno kada su korisničke uloge jasno odvojive i procesi ne prelaze preko grupa.
• Prebacivanje po klijentima/lokacijama: dobro za strukture filijala/pogona, kada su tokovi podataka između lokacija ograničeni.
• Prebacivanje po koracima procesa: npr. „unos nov, obračun još star“ – rizično ako postoji mnogo povratnih veza, ali ponekad neizbježno.
• Prebacivanje po tipu objekata: npr. nova osnovna sredstva u novom sistemu, stare zalihe u starom – može funkcionisati ako postoje jasna pravila za historiju/izvještavanje.

Iz operativne perspektive trebate dizajnirati paralelni rad tako da domene grešaka ostanu male: kvar u novoj komponenti ne smije povući naslijeđeni sistem (npr. kroz blokirajuća sučelja ili zaključavanja baze podataka), i obrnuto, naslijeđeni sistem ne smije sabotirati sve nove tokove kroz nestabilne eksporte.

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

Feature Flags su prekidači kojima ciljano aktivirate/deaktivirate funkcije – bez novog Deployment. Za IT‑upravitelje i projektne odgovorne nije presudan tehnički detalj, već Governance: ko smije prebacivati? Kako se dokumentuje zašto je promjena urađena? Koliko brzo se može vratiti? Koje zavisnosti nastaju (npr. ako su podaci već kreirani u novom formatu)?

Smisleno je voditi mali zapisnik promjena (Decision Log) za svaku akciju prebacivanja: vrijeme, Owner, pogođena grupa korisnika, očekivani efekt, monitoring‑indikatori, uvjet za rollback. To sprječava klasično „nitko više ne zna zašto je tako rutirano“.

Konzistentnost podataka pri rolloutu: jezgra 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 teško, jer dva sistema istovremeno pišu ili barem oba tvrde da su „Wahrheit“. Tu se odlučuje hoće li zamjena legacy sistema djelovati stabilno ili ćete mjesecima izvoditi usklađivanje delta-promjena.

Prvo razjasnite: Ko je „System of Record“ za svaki podatkovni prostor?

Potrebno je za svaki podatkovni prostor (npr. dužnici, artikli, cijene, narudžbe, skladišne promjene, dokumenti) odrediti koji sistem je vodeći. To nije samo arhitektonsko pitanje, već operativno:

• Gdje se vrše ispravke u slučaju podrške?
• Gdje se odvija proces odobravanja (princip dviju osoba, SoD/odvajanje funkcija)?
• Koji audit tragovi su potrebni (tko je kada što promijenio)?
• Kako izbjeći naknadne radove pri mjesečnom zatvaranju?

U ranim Strangler-etapama često je smisleno prvo ostaviti Legacy kao nositelja podataka i novu komponentu „samo“ konzumirati. Kasnije okrenete vođenje. Ovaj prijenos vodstva je zaseban mileston i zahtijeva jasno Cutover-prozor te plan komunikacije i prihvatanja.

Obrasci sinkronizacije: Dual Write, CDC i Events – s realističnim očekivanjima

Postoji nekoliko načina da se podaci sinkronizuju između starog i novog. Nijedan nije „kostenlos“.

• Dual Write: Jedna akcija piše u oba sistema (npr. kreiranje narudžbe → Legacy i novi sistem). Prednost: brza dostupnost. Nedostatak: greške su kompleksne (što ako System A upiše, a System B ne?), osim toga nastaju ovisnosti i često rizici za performanse.
• Change Data Capture (CDC): Promjene se ekstrahiraju iz loga baze podataka ili preko triggera/replikacije kao delta. Prednost: odvaja aplikaciju i sinkronizaciju. Nedostatak: replikujete i „tehničke“ promjene i morate rekonstruirati poslovne događaje; osim toga promjene šema u Legacy mogu iznenada postati integracijski rizik.
• Integracija zasnovana na događajima: Sistem publikuje poslovne događaje (npr. „narudžba odobrena“), koje drugi sistemi konzumiraju. Prednost: jasna poslovna semantika. Nedostatak: zahtijeva čiste definicije događaja, idempotenciju (višestruka obrada bez štete) i robusan koncept operativnog upravljanja messagingom.

Za donosioce odluka ključno je: konzistentnost podataka nije binarna. Neki procesi zahtijevaju jaku konzistentnost (odmah ispravno, npr. odobrenja plaćanja), drugi podnose eventual consistency (kratko kašnjenje, npr. indeks pretrage, izvještavanje, obavijesti). Ova kategorizacija treba se rano uskladiti s poslovnim odjelom i revizijom/auditom.

Konflikti i duplikati: Planirajte eksplicitno „ružan put“

U paralelnom radu konflikti obično nastaju ovako: Dva sistema mijenjaju isti objekt, ali prema različitim pravilima. Ili se import pokreće dvaput jer je retry „zu früh“ došao. Ili korisnik ispravlja podatke u Legacy dok je novo sučelje već prebačeno.

Potrebna su vam obavezujuća pravila:

• Rješavanje konflikata: „Last write wins“ rijetko je stručno ispravno. Bolje su prioriteti (vodeći sistem pobjeđuje) ili stručna pravila spajanja (npr. osnovni podaci o kontaktu naspram uvjeta).
• Idempotencija: Svaka integracija treba podnijeti višestruku obradu bez duplikata (npr. isti broj dokumenta, ista vanjska referenca).
• Dead-Letter/Karantena: Neobradive delte moraju biti uočljive, s jasnom odgovornošću i mogućnošću ponovnog pokretanja.

Bez ovih pravila konzistentnost podataka sklizne u „Excel-Abgleich“ i ručni naknadni rad – sa odgovarajućim frustracijama i teško mjerljivim naknadnim troškovima.

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

Dobar rollout je više od „Deployment + obuka“. U paralelnom radu morate povezati rollout i operativu: Tko radi First-Level pri greškama? Koji logovi su odmah dostupni? Kako se vrši eskalacija? Koji procesi se u jednom valu ne smiju mijenjati (npr. mjesečno zatvaranje, inventura, promjena cijena)?

Planiranje valova sa strogim kriterijima

Ispostavilo se da je učinkovit plan valova s jasnim ulaznim kriterijima, a ne samo datumima. Primjeri strogih kriterija:

• Monitoring-Dashboards i alerting za novu komponentu su u produkciji i testirani (uključujući smanjenu „Alarm-Rauschen“).
• Runbooks za tipične incidente postoje (Timeouts, Queue-Stau, neispravni Imports, Berechtigungsfehler).
• Delta-Abgleich je automatiziran i daje razumljive reports (razlike po tipu objekta, vremenskom prozoru, klasi uzroka).
• Rollback-Mechanismus je uvježban (najmanje u Staging/Pre-Prod realistički odrađen).

Posebno se podcjenjuje posljednja točka: Rollback nije „mi schalten wieder zurück“. Ako je novi sistem već generirao podatke, morate znati kako će ti podaci biti vidljivi u Legacy ili kako ćete generirane podatke ispravno migrirati/neutralizirati.

Mini-Cutovers umjesto Big Bang-a

Čak i kod Strangler Pattern postoje cutoveri – samo manji. Tipično su mini-cutoveri pri promjeni koraka procesa ili pri promjeni vođenja podataka. Svaki mini-cutover treba:

• Zamrzavanje podataka (kratko, ali obavezno): Tko smije što mijenjati tijekom tog perioda?
• Usklađivanje: Šta je promijenjeno od posljednje sinhronizacije?
• Prebacivanje: Routing/Feature Flags, jobovi, rasporedi, dozvole.
• Verifikacija: Stručni smoke-testovi (npr. kreiranje naloga → otpremnica → faktura), plus tehničke provjere (Queues, Fehlerraten, DB-Last).

Za IT-upravu je važno da su ovi koraci dokumentirani kao ponovljiv proces i kadrovski osigurani. Inače uspjeh projekta ovisi o pojedincima koji „wissen, wie es geht“.

Prvo stabilizirati sučelja: potcijenjeni temelj zamjene Legacy sistema

Mnogi Legacy sistemi komuniciraju preko naraslih sučelja: CSV-Exporte u mape, noćni Jobs, direktni pristupi bazi podataka kroz alate trećih strana, e‑mail‑bazirani Workflows. Postepena zamjena postaje znatno lakša ako prvo inventarisirate krajolik sučelja i konsolidirate ga na nekoliko tačaka.

Praktično to znači: Identifikujte sistemski kritične tačke integracije (npr. Finanzbuchhaltung, Versand, Produktionsrückmeldungen, Identitäten/Berechtigungen) i uspostavite tamo jasne ugovore. „Ugovor“ ovdje ne znači pravno, već tehničku stabilnost: verzionisanje, nedvosmislena polja, stabilni IDs, dokumentirana obrada grešaka, definirani SLAs za isporuku podataka.

Ako uz to uspostavite interni API-/Integrations-Governance-model (Owner, Deprecation-Regeln, Test-/Staging-Pfade), smanjuje se rizik da neka legacy-izmjena iznenada onesposobi vašu novu komponentu. Primjer odgovarajuće tematske poveznice za internu linkanju bio bi, npr., doprinos o API-Governance i Deprecation-Strategien.

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

U paralelnom radu često postoje dupli modeli korisnika i uloga. To dovodi do sjenovitih prava: korisnik je u novom sistemu ispravno ograničen, ali u Legacyju i dalje ima široka prava – i na kraju koristi „lakši put“. Tu su i tehnička konta (Service Accounts) za sinhronizaciju, importe, queue-e i batch poslove.

Konkretne tačke koje biste trebali rano razjasniti:

• Izvor identiteta: Odakle dolaze korisnici i grupe? AD/Entra ID? Ein eigenes IAM? Važno je da je provisioniranje pratljivo.
• Mapiranje uloga: Ako uloge ne odgovaraju 1:1, potrebne su tranzicijske uloge koje su vremenski ograničene i koje se recertificiraju.
• Service Accounts: Minimalna prava, rotacija tajni, uredno evidentiranje. Posebno sinhronizacioni nalozi inače predstavljaju ulaznu tačku za napad i teško ih je auditovati.
• Audit-Trails: Ako se mijenja vodstvo podataka, mora biti jasno gdje se nalazi dokaz o promjenama i kako se on kroz oba sistema može provjeriti.

Važno za donosioce odluka: Security ovdje nije „dodatni Scope“, već utiče na izvodljivost rollouts. Naknadno usklađivanje ovlaštenja u paralelnom radu obično je skuplje nego rana, pragmatična podjela uloga i servisnih naloga.

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

U paralelnom radu obrasci grešaka su često indirektni: delta zapne, retry se izvršava beskonačno, red se zaguši, ili vremenski kritičan job sukobljava se sa zaključavanjem baze podataka. Ako to vidite samo preko korisničkih tiketa, kasnite. Zato od početka trebate minimum observability: Monitoring (stanje), Logging (događaji) i – gdje ima smisla – Tracing (lanac kroz sisteme).

Praktični, lako održivi signali su, na primjer:

• Synchronisations-Backlog (koliko izmjena „čekaju“), plus starost najstarijeg unosa.
• Stopa grešaka po Schnittstelle i klasi greške (Validierung, Timeout, Auth, Datenkonflikt).

Für die Betriebsübergabe zählt weniger, welches Tool genutzt wird, sondern ob Verantwortlichkeiten und Runbooks klar sind. Wenn Sie On-Call oder Bereitschaft haben, muss der Betrieb bei typischen Störungen ohne Entwickler-Detektivarbeit handlungsfähig bleiben.

Wann Strangler Pattern nicht passt (oder nur mit klaren Einschränkungen)

Es gibt Situationen, in denen schrittweise Ablösung nur eingeschränkt funktioniert:

• Extrem enge Transaktionskopplung: Wenn nahezu jeder Vorgang quer über alle Module geht und harte Konsistenz erfordert, wird Parallelbetrieb schnell unbeherrschbar.
• Direkte DB-Zugriffe durch Drittsysteme: Wenn mehrere Tools direkt auf Legacy-Tabellen schreiben/lesen, muss zuerst dieser Wildwuchs beendet oder kontrolliert werden.
• Unklare Datenhoheit: Wenn nicht festgelegt werden kann, wer Daten führt, sind Konflikte garantiert – und die Ablösung wird politisch statt technisch.
• Fehlende Betriebsdisziplin: Ohne saubere Umgebungen, reproduzierbare Deployments und Monitoring wird jeder Zwischenschritt zum Risiko.

Das heißt nicht, dass Sie zum Big Bang gezwungen sind. Aber Sie müssen dann die Reihenfolge ändern: Erst Integrationspunkte stabilisieren, Datenzugriffe zentralisieren, Rollen und Ownership klären – und erst dann stranglen.

Ein praxistauglicher Ablaufplan für die Legacy-Ablösung in Etappen

Als Orientierung für Projektverantwortliche hat sich ein Ablauf in klaren Etappen bewährt. Die genaue Ausprägung hängt von System und Branche ab, aber die Logik ist robust:

1. Inventar & Abhängigkeiten: Schnittstellen, Jobs, Datenflüsse, Nutzergruppen, kritische Zeitfenster (Abschluss, Inventur).
2. Schnittkanten definieren: Prozessmodule, Datenführerschaft je Bereich, Integrationsverträge.
3. Routing & Schalter bauen: Gateway/Proxy, Feature Flags, zentrale Protokollierung.
4. Datenpfad festlegen: CDC/Event/Dual Write, Konfliktregeln, Quarantäne, Abgleichberichte.
5. Pilot mit echter Last: nicht nur Demo, sondern mit realen Fällen, inklusive Ausnahmen.
6. Wellenrollout: Eintrittskriterien, Cutover-Checklisten, Rollback-Übungen.
7. Abschalten & Aufräumen: Altpfade deaktivieren, Jobs entfernen, Rechte entziehen, Dokumentation aktualisieren.

Der letzte Punkt ist essenziell: Viele Organisationen lassen Legacy-Komponenten „zur Sicherheit“ weiterlaufen. Ergebnis: doppelte Kosten, unklares Risiko, niemand traut sich ans Abschalten. Planen Sie das Decommissioning als Teilprojekt mit Termin, Verantwortlichen und Nachweisen (z. B. „keine Zugriffe seit X Wochen“, „alle Exporte umgestellt“, „Audit-Anforderungen erfüllt“).

Fazit: Schrittweise ablösen heißt, Konsistenz und Betrieb als Produkt zu behandeln

Eine Legacy-Ablösung Schritt für Schritt ist nicht automatisch einfacher – aber sie ist in vielen Unternehmen die einzige realistische Option. Das Strangler Pattern funktioniert, wenn Sie pro Etappe klare Prozessschnittkanten definieren, den Parallelbetrieb als echten Betriebszustand planen und Datenkonsistenz nicht dem Zufall überlassen. Entscheidend sind frühe Festlegungen zur Datenführerschaft, robuste Synchronisationsmuster mit Konfliktregeln sowie ein Rollout-Design mit Wellen, Abnahmen und geübtem Rückfall.

Ako planirate zamjenu i želite strukturirano razgovarati o integracionim tačkama, paralelnom radu ili konceptu dosljednosti podataka, možete nas kontaktirati putem .

Razgovarajte o projektu ili planu modernizacije sa Net-Base.