Modernizacija legacy sistema bez Big Bang pristupa: Migracioni plan u 6 faza za aplikacije u srednjim preduzećima

Zamjena naslijeđene aplikacije često na papiru zvuči jednostavnije nego u praksi. U srednje velikim preduzećima poslovni softver je obično usko povezan sa stvarnim procesima: obrada narudžbi, skladište, proizvodnja, servis, obračun, usklađenost. Upravo zbog toga klasični „Big Bang“ često ne uspijeva: datum kada je sve novo stvara maksimalnu nesigurnost – stručnu, tehničku i organizacijsku.

Modernizacija naslijeđa bez Big Bang znači planirati modernizaciju kao kontrolisanu preinaku u radu sistema. Umjesto „sve novo“ radi se o nizu faza koje smanjuju rizike, uredno prenose podatke i sučelja i ne opterećuju rad operacija. Ključ je plan migracije koji ne uzima u obzir samo arhitekturu, već i podršku, Releases, ovlaštenja, monitoring, obuke i puteve donošenja odluka.

Slijedeći 6-etapni plan je formulisan tako da IT-rukovodstvo, administratori, tehnički odgovorni za projekte i poslovne jedinice dobiju zajedničku orijentaciju: Šta mora biti razjašnjeno kada, koja artefakte je potrebno imati i koje odluke će kasnije skupo utjecati?

Modernizacija naslijeđa bez Big Bang: Zašto Big Bang rijetko uspijeva u praksi

Promjena po principu Big Bang okuplja mnogo izmjena u jednom trenutku: novi korisnički interfejs, novi modeli podataka, nova ovlaštenja, novi interfejsi, novi operativni parametri. Čak i kada svaka pojedinačna komponenta „funkcioniše“, kombinacija pod stvarnim opterećenjem često je izvor rizika: neplanirani rubni slučajevi, nedostajući podaci, različita logika matičnih podataka, netestirani integracijski putevi.

Tipični simptomi u projektima koji su preveliki:

• Neprecizne odgovornosti: Ko odlučuje u slučaju konflikta ciljeva između poslovne jedinice i operacija? Bez jasnih uloga pitanja detalja eskaliraju u načelne rasprave.
• Praznine u testiranju zbog raznovrsnosti procesa: Osnovni procesi se testiraju, a specijalni slučajevi iz 10 godina prakse ne. Upravo ti specijalni slučajevi završavaju pri Go-live u Service Desku.
• Migracija podataka „u posljednjim metrima“: Odluke o mapiranju se odgađaju. Kasnije se pokaže da historijski podaci, reference ili duplikati blokiraju migraciju.
• Operacije se uključuju prekasno: nadzor, backupi, ponovno pokretanje, prozori održavanja, rutine za zakrpe – sve se to ne može smisleno naknadno uvesti u posljednjoj sedmici.

Postepena modernizacija nije sporiji put, već planiraniji: raspoređuje rizik kroz vrijeme, stvara mjerljive međudostave i omogućava da se stvarna saznanja o upotrebi unesu u naredne etape.

Osnovno načelo: Strangler Pattern i „žive“ integracijske granice

U mnogim uspješnim modernizacijama stoji Strangler Pattern: Nove funkcije ili moduli se grade oko starog sistema i postepeno preuzimaju odgovornost dok se stari dio više ne koristi. Važna je pravilna interpretacija za rad sistema: nije presudan arhitektonski obrazac, već jasne integracijske granice.

Integracijske granice su mjesta na kojima sistemi razmjenjuju podatke ili zajednički pristupaju podacima. To obuhvata interfejse (na primjer REST, datoteke, messaging), zajedničke baze podataka, modele identiteta i ovlaštenja kao i pozadinske poslove. Modernizacija postaje upravljiva kada se te granice svjesno oblikuju:

• Stabilan ugovor prema van: Partneri ili sistemi u okruženju trebaju obrađivati što manje promjena istovremeno.
• Mjerljivost: Tokovi podataka moraju biti promatrani (logovi, metrike, stope grešaka), kako bi operacija i vodstvo projekta rano prepoznali rizike.
• Sposobnost povratka (Rollback): Ako neka etapa stvori probleme, sistem mora moći vratiti se u stabilno stanje bez stvaranja ‚haosa u podacima‘.

Migracijski plan u 6 etapa

Etape su namjerno formulisane tako da prisiljavaju na donošenje pouzdanih odluka uzastopno. Pojedine tačke se mogu paralelizirati – ali se ne smiju preskočiti, bez kasnijih većih troškova.

Etapa 1: Inventarizacija koja objedinjuje operativu i poslovnu stranu

Modernizacija rijetko zakaže zbog ‚premalo tehnologije‘, nego zbog pogrešnih pretpostavki o zavisnostima. Dobra inventarizacija stoga nije puko arhitektonsko dokument, već pragmatičan set mapa i rizika koji svi sudionici mogu pročitati.

Provjereni sadržaji za etapu 1:

• Mapa aplikacija: Koje aplikacije, servisi, poslovi i pomoćni sistemi ovise o jezgru sistema? Koji su od njih poslovno kritični, a koji su samo ’nice to have‘?
• Integracijska mapa: Koji interfejsi postoje (Dateiexport, EDI, REST, SOAP, Datenbankzugriff, SFTP)? Tko je vlasnik, koji se podaci razmjenjuju, koja je frekvencija?
• Inventar podataka: Koji su skupovi podataka primarni (System of Record), a koji izvedeni (Reports, Exporte)? Kako su regulisani čuvanje i brisanje?
• Operativna realnost: Kako se izvode deploymente? Postoje li prozori za održavanje? Kako izgleda backup-koncept? Koja su realna vremena za restore?
• Prioritetizacija bolnih tačaka: Ne ’sve je staro‘, nego: Gdje su promjene rizične? Gdje postoje performansna uska grla? Gdje nedostatak mogućnosti interfejsa blokira?

Važno: Ova etapa se idealno završava zajedničkom prioritetizacijom. IT i poslovna strana odrede koje procesne oblasti treba modernizirati prve (na primjer unos naloga ili portal za korisnike), i koje oblasti stabilizirati (na primjer logika knjiženja), kako bi se izbjegli sporedni konflikti.

Etapa 2: Definirati ciljnu viziju — ali kao okvir za odluke, ne kao krajnje stanje

U srednjim preduzećima ciljna vizija brzo postane ‚lista želja‘. Korisnije je gledati ciljnu viziju kao okvir za odluke koji skraćuje kasnije diskusije. To uključuje eksplicitne vodilje: Šta ostaje on-prem, šta može u Cloud? Koja baza podataka je određena? Kako se identiteti integrišu? Kako će se nove komponente eksploatisati?

Praktično to znači:

• Arhitektonska načela: npr. „interfejsi na prvom mjestu“, „bez direktnih pristupa bazi podataka od strane trećih sistema“, „verzionisanje API-ja“.
• Principi poslovanja: npr. „svaki novi komponent ima monitoring i Runbook“, „deployments su reprodukovljivi“, „Patch‑fenster se mogu planirati“.
• Principi podataka: npr. „System of Record za svaki podatkovni objekt je jedinstven“, „istorijski podaci se prema definisanim pravilima migriraju ili arhiviraju“.

Jedna ključna odluka u ovoj etapi je buduća strategija integracije. Mnogi timovi podcjenjuju da integracijski rad (sučelja, modeli podataka, rukovanje greškama) često čini većinu složenosti. Ko ovdje rano postavi standarde, smanjuje kasnije trzaje u operacijama.

Ako želite naknadno uvesti ili stabilizovati sučelja za postojeći softver, pomaže tretirati to kao zaseban tok modernizacije – ne kao sporedni zadatak na kraju.

Etapa 3: Razdvajanje sučelja i podataka – „Preinaka na sistemu krvotoka“

U mnogim naslijeđenim okruženjima baza podataka je tajni medij integracije: izvještaji direktno pristupaju, sporedni sistemi zapisuju u tabele, pozadinski jobovi zaobilaze poslovna pravila. To čini izmjene opasnima, jer niko ne može sa sigurnošću reći koji će upiti ili vanjski procesi sutra prestati raditi.

U Etapi 3 radi se stoga o kontroliranom razdvajanje. Tipične komponente:

• API‑fasada: Definisan interfejs (na primjer REST), preko kojeg nove i postojeće komponente čitaju i zapisuju podatke. REST ovdje znači: HTTP‑baziran interfejs sa jasnim krajnjim tačkama i strukturiranim JSON‑podacima; važni su verzionisanje i konvencije za greške.
• Adapter za stare sučelja: Gdje direktna zamjena nije moguća, grade se tranzicioni adapteri (konverter fajlova/EDI, Message‑Bridge, Proxy).
• Ugovori o podacima: Koja polja su obavezna, koja su opcionalna? Koji kodovi/statusi su dozvoljeni? Ta pravila moraju biti dokumentovana i testabilna.

Organizacijski je Etapa 3 trenutak u kojem timovi trebaju lagani set za upravljanje API‑jem: konvencije imenovanja, verzionisanje, pravila deprecacije, testna strategija, proces odobravanja. Bez upravljanja nastaje „haos sučelja“: mnogo sličnih krajnjih tačaka, nejasna odgovornost, nekompatibilne promjene bez upozorenja.

Još jedan fokus: kvalitet podataka. Modernizacija otkriva probleme s podacima koji su se ranije „tumačili“ ili ignorirali. Zato biste već ovdje trebali uspostaviti jednostavne provjere: stopu duplikata, kršenja stranih ključeva, nevažeće vrijednosti statusa, neočekivane NULL vrijednosti. To je manje BI‑tema, a više operativni i migracijski rizik: loši podaci povećavaju obim testiranja, opterećenje podrške i stopu grešaka u paralelnom radu.

Etapa 4: Funkcionalna modernizacija u vertikalnim rezovima

Najčešća pogrešna procjena pri faznoj migraciji: modernizuju se tehnički slojevi, ali bez funkcionalno korisnih međurezultata. To dovodi do dugih perioda u kojima poslovne jedinice „ne vide ništa“, dok se troškovi i rizik povećavaju.

Umjesto toga se pokazuju efikasnima vertikalni rezovi: jasno ograničen proces se modernizuje end‑to‑end – uključujući korisničko sučelje, poslovna pravila, pristup podacima i sučelja. Primjeri su definirani podprocesi poput unosa reklamacije, modul korisničkog portala ili workflow odobravanja.

Na što bi IT i vodstvo projekta trebali obratiti pažnju:

• Kriteriji prihvatanja: Ne samo „radi“, već: Koji koraci procesa su pokriveni? Koje uloge? Koji slučajevi grešaka? Koji pragovi performansi?
• Upravljanje izdanjima: Kako se isporučuje bez preopterećenja korisnika? Jasan ritam, uredne Release Notes, definirane opcije povrata (Rollback) i jedan komunikacijski kanal smanjuju vrhove opterećenja podrške.
• Konfiguracija umjesto posebnih slučajeva: Ako proces ima deset varijanti, velika je iskušenja svaku varijantu „tvrdo“ implementirati. Često se isplati prvo definirati konfigurabilni model (npr. model statusa, pravila validacije), kako bi buduća proširenja ostala planirana.

U ovoj etapi također postaje jasno je li ciljna slika održiva: Odgovara li model ovlašćenja? Radi li Logging tako da su slučajevi podrške rekonstruabilni? Jesu li Timeouts, Retries i tekstovi grešaka dizajnirani tako da pomažu u radu umjesto da samo proizvode „Fehler 500“?

Faza 5: Paralelni rad, planiranje Cutovera i migracija podataka bez iznenađenja

Paralelni rad je sigurnosna mreža modernizacije – ali samo ako je svjesno koncipiran. Paralelni rad ne znači nužno „dva sistema rade sve dvostruko“. U većini slučajeva to znači: neko vrijeme postoje stari i novi dijelovi paralelno, dok se podaci sinkronizuju ili su odgovornosti jasno razdvojene.

Presudno je pitanje: Koji podaci su gdje vodeći? „Vodeći“ znači: gdje nastaje istina za neki objekt (na primjer kupac, nalog, artikl, račun)? Bez te jasnoće nastaju nekonzistentnosti koje plaćaju podrška i poslovna jedinica.

Za fazu 5 pokazuju se tri tehničke i organizacijske smjernice:

• Strategija sinhronizacije: Event-bazirana (Events/Messaging), API-bazirana (novi sistem poziva staru logiku ili obrnuto) ili vremenski upravljana (Jobs). Svaka varijanta ima operativne posljedice: nadzor (Monitoring), toleranciju grešaka i naknadnu obradu.
• Cutover-Runbook: Sekvenca koraka za prelazak: Datafreeze (koji se podaci od kada više ne smiju mijenjati?), importni prolazi, izvještaji validacije, prebacivanje sučelja, komunikacijski plan, kriteriji za rollback.
• Izvještaji za usklađivanje: Ne „migriramo i nadamo se“, nego: provjere suma/komada, uzorci, referentne liste. Ti izvještaji trebaju biti pokrenuti više puta u testnim okruženjima prije Cutovera.

Migracija podataka rijetko je jednokratni import. Često je potrebno više probnih pokretanja s očišćenim mapiranjima, jer se anomalije u realnim podacima tek tada pokažu: duplikati ključeva, historijski nastale posebne vrijednosti, nedostajuća obavezna polja. Ko to prihvati i planira kao proces učenja, izbjegava hektične „Hotfix-Migrationen“ vikendom.

Ein unterschätzter Punkt: Audit und Nachvollziehbarkeit. Bei geschäftskritischen Prozessen reicht es nicht, dass Daten „da“ sind. Man braucht nachvollziehbare Buchungs- und Änderungswege (Audit Trail), vor allem wenn Rechte, Preise, Freigaben oder Abrechnung betroffen sind. Das muss in Parallelbetrieb und Cutover mitgedacht werden.

Etappe 6: Stabilisierung, Betriebsübergabe und kontrolliertes Abschalten

Mnoge modernizacije se zvanično završavaju sa Go-live – a operativno započinju tek nakon toga. Etappe 6 je faza u kojoj se odlučuje da li je novo rješenje dugoročno održivo ili su se tehnički dugovi samo premjestili.

Kernthemen in dieser Etappe:

• Hypercare mit klaren Regeln: Eine definierte Stabilitätsphase nach Produktivsetzung, mit festen Kommunikationswegen, Fehlerklassifizierung und Priorisierung. Wichtig: nicht jeder Wunsch ist ein Incident.
• Runbooks und Monitoring: Runbooks sind Betriebsanleitungen für wiederkehrende Aufgaben und Störungen (Start/Stop, typische Fehlerbilder, Logs, Wiederanlauf). Monitoring umfasst Metriken und Alarmierung; Ziel ist nicht „alles überwachen“, sondern „relevante Signale“ ohne Alarmmüdigkeit.
• Patch- und Update-Routinen: Wer moderne Komponenten einführt, muss Updates planbar machen: Wartungsfenster, Rollback, Sicherheitsupdates, Abhängigkeiten von Laufzeitumgebungen und Datenbanken.
• Abschaltplan fürs Altsystem: Abschalten ist ein Projektteil: Datenarchivierung, rechtliche Aufbewahrung, Stilllegung von Jobs, Entfernen alter Schnittstellen, Anpassung von Betriebshandbüchern.

Ein guter Indikator für erfolgreiche Etappe 6: Das Team kann nach einigen Wochen nicht nur „Feuer löschen“, sondern wieder planbar liefern. Das gelingt, wenn Betrieb und Projekt in der Hypercare-Phase gemeinsam priorisieren und Ursachen nachhaltig abstellen (zum Beispiel durch bessere Validierungen, klare Fehlermeldungen, robuste Schnittstellen-Timeouts).

Entscheidungspunkte, die den Fahrplan tragen

Über alle Etappen hinweg gibt es wiederkehrende Entscheidungen, die in mittelständischen Projekten besonders wirksam sind. Sie betreffen weniger die Technologie an sich, sondern die Betriebs- und Migrationsfähigkeit.

1) Identität und Berechtigungen früh klären

Wenn neue Module entstehen, prallen oft unterschiedliche Berechtigungskonzepte aufeinander: historisch gewachsene Rollen im Altsystem, Active Directory-Gruppen, Applikationsrollen, externe Partnerzugänge. Hier lohnt eine frühe Richtung: zum Beispiel Single Sign-on über SAML 2.0 (ein Standard für zentrale Anmeldung) oder ein konsolidiertes Rollenmodell mit Rezertifizierung (regelmäßige Überprüfung von Rechten).

Bez jasnog plana za identitete, u paralelnom radu troškovi brzo rastu: dvostruka administracija korisnika, nejasne odgovornosti, prijave podrške zbog „pogrešne uloge“. To nije marginalna tema, već gubitak produktivnosti u svakodnevnom radu.

2) Standardizirati okruženja i Deployments

Mnogi legacy sistemi rade stabilno zato što „više niko ništa ne dira“. Modernizacija povećava frekvenciju promjena – i time potrebu za reproducibilnim Deployments. Ključno je da Dev/Test/Prod ne divergiraju (razlike u konfiguracijama, nedostajući certifikati, različiti parametri baze podataka). U praksi to znači: verzionisati konfiguracije, sigurno upravljati Secrets, releasove paketirati i dokumentovati na način koji je moguće pratiti.

3) Beobachtbarkeit als Betriebsanforderung definieren

Observabilnost znači: u slučaju greške se može rekonstruisati šta se dogodilo – kroz Logs, Metriken i Korrelation. Korrelation znači da se pripadajući koraci mogu povezati preko sistema (na primjer preko einer Request-ID). To štedi sate u podršci, jer se uzroci više ne moraju „pogađati“.

4) Change- und Kommunikationsplan nicht unterschätzen

Postepena migracija funkcionira ako korisnici promjene doživljavaju više puta. Bez komunikacijskog i plana obuke to vodi otporu ili skrivenim procesima (Excel-Listen, ručni zaobilazni putevi). Korisne su pilot-grupe, jasne povratne petlje i definiran kanal za pitanja. To nije „marketingaufgabe“, već smanjuje opterećenje podrške i greške u podacima.

Wie Sie den Fahrplan im Projektalltag verankern

Plan pomaže samo ako se prevede u upravljanje i suradnju. Tri praksične mjere:

• Etappen-Gates mit Checklisten: Svaka etapa završava jasnim kriterijima: Šta je isporučeno (Artefakte, Entscheidungen), šta je otvoreno, koji je rizik prihvaćen?
• Decision Log: Jednostavna, kontinuirano vođena dokumentacija odluka (Was wurde entschieden? Warum? Welche Auswirkungen?). To sprječava da timovi mjesecima kasnije ponovno otvaraju temeljna pitanja.
• Gemeinsames Risiko-Board: Ne samo tehnički rizici, nego i operativni i organizacijski rizici (nedostajuće uloge, nejasna odgovornost za podatke, testne praznine). Svaki rizik ima vlasnika i mjeru.

Pogotovo u srednjim poduzećima, gdje timovi paralelno održavaju više sustava, transparentnost je važnija od perfekcije. Plan treba ubrzati odluke, a ne stvarati dodatnu birokraciju.

Schlussfazit: Modernisierung als kontrollierter Umbau statt Wette auf den Stichtag

Modernizacija legacy sistema bez Big Bang nije kompromis, već metodički pristup za objedinjavanje rizika, operativne sigurnosti i stručnosti. Plan od 6 etapa osigurava da integracije i podaci ne nastaju „usput“, da paralelni rad ne postane haos i da je prijelaz u operativu svjesno planiran.

Ako želite modernizirati zrelu aplikaciju, isplati se prvo mapirati plan na vaše ključne procese i integracije: Šta je zaista vodeće, koja su sučelja poslovno kritična i koja etapa sljedeća donosi najveće smanjenje rizika?

Ako želite izraditi konkretan, na vašu infrastrukturu prilagođen plan migracije, temu možete strukturirati s nama u uvodnom razgovoru: Kontakt aufnehmen.

Razgovarati o projektu ili planu modernizacije sa Net-Base.