Замена наслеђених система корак по корак: Strangler Pattern, паралелни рад и конзистентност података при пуштању у производњу

Zamena nasleđenog sistema retko puca na „izgradnji“ nove rešenja, već na prelazu: podaci moraju ostati ispravni, interfejsi ne smeju puknuti, a rad sistema mora se nastaviti tokom migracije. U mnogim kompanijama zato Big-Bang-Cutover nije opcija – zavisnosti su prevelike, troškovi zastoja previsoki, a povratak na prethodno stanje pretežak.

U praksi se pokazuje kao delotvoran postepeni pristup sa Strangler Pattern (funkcionalni delovi se postepeno „preusmeravaju“), paralelnim radom (stari i novi sistem privremeno rade paralelno) i jasnim pravilima za doslednost podataka. Ovaj članak pokazuje kako da ove komponente kombinujete tako da budu održive u svakodnevnom radu IT‑uprave, administracije i projektne odgovornosti – uključujući tipične greške, posledice za operacije i tačke donošenja odluka tokom roll‑out‑a.

Zašto je korak‑po‑korak pristup često realistična zamena legacy sistema

Nasleđeni sistemi retko predstavljaju „samo jednu aplikaciju“. Obično su vezani za: batch poslove, interfejse za datoteke (SFTP fascikle, mrežni diskovi), procese štampe i skeniranja, lokalne alate, BI ekstrakte, E‑Mail‑relée, specijalizovani hardver, izvode Shadow‑IT i ručna zaobilazna rešenja. Kod Big‑Banga svi ti tokovi moraju raditi istog vikenda – i to uključujući prava pristupa, osnovne podatke, istorije i izuzetke.

Korak‑po‑korak pristup smanjuje rizik, ali ga ne pomera automatski „na niže“. Čini rizike vidljivijim i upravljivijim, ali zato zahteva čiste arhitektonske i operativne odluke: gde se routuje? ko je nosilac podataka? koja doslednost je poslovno obavezna, a gde je prihvatljivo vremensko kašnjenje? i kako sprečiti da paralelni rad ne postane trajna gradilišna zona?

Strangler Pattern u poslovnoj realnosti: ne „mikroservisi“, već jasne granice interfejsa

Strangler Pattern znači: gradite nove funkcije pored starog sistema i postepeno preusmeravate saobraćaj dok stari deo ne postane suvišan. Bitno: ovo nije arhitektonski verski rat („monolit protiv mikroservisa“), već migracioni obrazac. Funkcioniše i kada ciljna arhitektura ostane monolit – samo modernizovan, održiviji i bolje integrisan.

Najvažnija odluka: delite po procesima, ne po tabelama

U mnogim zamenama se seče prema podacima („Prvo uzimamo tabele za kupce i naloge“). To često vodi bolnom paralelnom radu jer procesi prelaze preko tih podataka. Bolje je procesno orijentisano odvajanje, npr. „izrada ponude“, „prijem robe“, „obrada reklamacija“ ili „ticket podrška do fakture“.

Praktično pravilo: Strangler-etapa treba da pokrije stručno zatvoren tok koji se u novom sistemu može da se pokreće i nadgleda od kraja do kraja. To obuhvata ulaze (UI, API, uvoz), obradu (poslovna pravila) i izlaze (štampa, izvoz, knjiženje, obaveštavanje).

Strangler zahteva „preusmerivač“: Gateway, Proxy ili sloj za rutiranje

Da korisnici i povezani sistemi ne bi svaki put morali da uče nove krajnje tačke, često se uvodi sloj za rutiranje. U zavisnosti od početne situacije to može biti: reverse proxy ispred web-aplikacija, API-Gateway za servisne krajnje tačke ili integracioni sloj koji objedini fajl-interfejse i događaje. Presudna je upravljivost u radu: centralna konfiguracija, jasni logovi, monitoring i kontrolisani rollback.

Za administratore je važno da taj sloj ne postane crna kutija. Potrebni su im razumljiva rutiranja (koji zahtev je otišao gde), korelacija kroz logove (npr. Request-ID) i definisani timeout-i/pravila za retry, da se greške ne bi „zalepile“.

Paralelni rad je operativno stanje – nije „projekat-trik“

Paralelni rad znači: stare i nove komponente neko vreme rade istovremeno u produkciji. To je normalno, ali skupo – naročito u pogonu. Imate više pokretnih delova, više monitoring-a, veći potencijal incidenata i složenije odgovornosti. Zato paralelni rad mora biti planiran kao vremenski ograničen režim rada, uključujući kriterijume za prekid.

Tipični modeli paralelnog rada (i kada su primenljivi)

• Prebacivanje po grupama korisnika (pilot-grupa → talasi): pogodno kada su korisničke uloge jasno razdvojive i procesi ne prelaze između grupa.
• Prebacivanje po mandantima/lokacijama: dobro za filijalske/pogonske strukture, kada su tokovi podataka između lokacija ograničeni.
• Prebacivanje po koracima procesa: npr. „novo prikupljanje, obračun još u starom“ – rizično ako postoji mnogo povratnih veza, ali ponekad neizbežno.
• Prebacivanje po tipovima objekata: npr. nova dugotrajna sredstva u novom sistemu, postojeće stare stavke u starom – može funkcionisati ako postoje jasna pravila za istoriju/izveštavanje.

Iz operativnog ugla treba da projektujete paralelni rad tako da domene grešaka ostanu mali: kvar u novoj komponenti ne sme da povuče legacy sistem (npr. kroz blokirajuće interfejse ili zaključavanja baze podataka), i obrnuto, legacy ne sme da sabotira sve nove tokove kroz nestabilne izvoze.

Feature Flags i pravila rutiranja: kontrola umesto „puštamo i nadamo se“

Feature Flags su prekidači kojima ciljano uključujete/isključujete funkcionalnosti – bez novog deploy-a. Za IT-upravljanje i odgovorne u projektu ključ nije tehnički detalj, već upravljanje: ko sme da prebacuje? Kako se dokumentuje razlog promene? Koliko brzo se možete vratiti? Kakve zavisnosti nastaju (npr. ako su podaci već generisani u novom formatu)?

Smisleno je voditi mali zapisnik promena (Decision Log) po svakoj akciji prebacivanja: vreme, vlasnik, pogođena grupa korisnika, očekivani efekat, monitoring-indikatori, uslov za rollback. To sprečava klasično „Niko više ne zna zašto je tako rutirano“.

Konzistentnost podataka pri uvođenju: jezgro od kojeg zavisi mnogo zamena

Доследност података значи да су подаци стручно тачни, потпуни и доступни у очекиваном редоследу. У паралелном раду то постаје тешко, јер два система истовремено уписују или барем оба тврде да су „Wahrheit“. Овде се одлучује да ли ће замена Legacy система деловати стабилно или ћете месецима водити Delta-усклађивања.

Прво разјасните: ко је „System of Record“ за сваки домен података?

Потребан вам је за сваки домен података (нпр. дужници, артикли, цене, поруџбине, складишне трансакције, документи) договор који систем је водећи. То није само архитектонско питање, већ оперативно:

• Где се врше корекције у случају подршке?
• Где је процес одобравања (принцип два пара очију, SoD/одвајање функција)?
• Који audit трагови су потребни (ко је када шта изменио)?
• Како се избегавају накнадне интервенције при месечном затварању?

У раним Strangler-етапама често има смисла прво оставити Legacy као вођу података, а нову компоненту „само“ конзумирати. Касније окренете вођство. Та промена вођства је посебна прекретница и захтева јасан Cutover-прозор као и план комуникације и пријема.

Обрасци синхронизације: Dual Write, CDC и Events – са реалним очекивањима

Постоји неколико начина да се подаци синхронизују између старог и новог. Ниједан није „бесплатан“.

• Dual Write: једна акција уписује у оба система (нпр. креирање поруџбине → Legacy и нови систем). Предност: брза доступност. Недостатак: у случају грешке је комплексно (шта ако систем A упише, а систем B не?), поред тога настају зависности и често ризици по перформансе.
• Change Data Capture (CDC): измене се екстрахују из дневника базе података или преко тригера/репликације као delta. Предност: одваја апликацију и синхронизацију. Недостатак: репликујете и „техничке“ измене и морате реконструисати пословне догађаје; такође, промене шеме у Legacy-у изненада постају интеграциони ризик.
• Event-basierte Integration: систем публикује пословне догађаје (нпр. „Auftrag freigegeben“), које други системи конзумирају. Предност: јасна пословна семантика. Недостатак: захтева прецизне дефиниције догађаја, идемпотенцију (вишеструка обрада без штете) и поуздан оперативни концепт за messaging.

За одлучујуће је кључно: доследност података није бинарна. Неки процеси захтевају јаку доследност (одмах тачно, нпр. одобрења плаћања), други толеришу eventual consistency (кратко кашњење, нпр. индекс претраге, извештавање, обавештења). Ову категоризацију треба рано усагласити са пословним одељењем и ревизијом/audit-ом.

Конфликти и дупликати: експлицитно планирајте „ружни пут“

У паралелном раду конфликт обично настаје овако: два система мењају исти објекат, али по различитим правилима. Или импорт се покреће два пута јер је retry био „прерано“. Или корисник исправља податке у legacy систему, док је нови интерфејс већ пребачен.

За то су вам потребна обавезна правила:

• Решење конфликта: „Last write wins“ ретко је стручно тачно. Боље су приоритети (водећи систем побеђује) или стручна правила за спајање (нпр. матични подаци контакта против услова).
• Идемпотенција: Свака интеграција треба да подноси вишеструку обраду без дупликата (нпр. иста бројка документа, иста спољна референца).
• Dead-Letter/Quarantäne: Необрађиви делта-записи морају бити пронађиви, са јасном надлежношћу и могућношћу поновног покретања.

Без ових правила конзистенција података спада у „Excel-упоређивање“ и ручну дораду – са одговарајућим фрустрацијама и тешко мерљивим накнадним трошковима.

Rollout-Design: Wellen, Abnahmen und Rückfall, ohne den Betrieb zu überlasten

Добар Rollout је више од „Deployment + обука“. У паралелном раду морате повезати Rollout и операције: ко ради први ниво при грешкама? Који логови су одмах доступни? Како се врши ескалација? Који процеси не смеју бити пребачени у оквиру једног таласа (нпр. месечни закључак, инвентаризација, промена цена)?

Wellenplanung mit harten Kriterien

Испоставило се да је ефикасно планирање таласа са јасним улазним критеријумима, не само са датумима. Примери строгих критеријума:

• Monitoring-Dashboards и Alerting за нову компоненту су активни и тестирани (укључујући смањење „шума аларма“).
• Runbooks за типичне инциденте постоје (Timeouts, Queue-загушења, неуспели импорти, грешке везане за дозволе).
• Delta-усклађивање је аутоматизовано и испоручује разумљиве извештаје (разлике по типу објекта, временском прозору, класи узрока).
• Rollback-механизам је увежбан (бар у Staging/Pre-Prod реалистично проведен).

Посебно се потцењује последња тачка: Rollback није „само ћемо вратити назад“. Ако нови систем већ генерише податке, морате знати како ће ти подаци бити видљиви у legacy систему или како ћете генерисане податке правилно мигрирати/неутралисати.

Cutover-Mini-Cutovers statt Big Bang

Чак и у Strangler Pattern постоје Cutover-и – само мањи. Типично су мини-cutover-и при промени корака у процесу или при пребацивању водећег извора података. Сваки мини-cutover захтева:

• Замрзавање података (кратко, али обвезујуће): ко сме шта мењати током тога?
• Усклађивање: шта је промењено од последње синхронизације?
• Пребацивање: рутирање/Feature Flags, job-ови, распореди, дозволе.
• Верификација: стручни smoke-тестови (нпр. креирање налога → отпремница → рачун), плус техничке провере (queues, стопе грешака, оптерећење БД).

За IT-руководство је важно да су ти кораци документовани као поновљив процес и кадровски осигурани. У супротном, успех пројекта зависи од појединаца који „знају како се ради“.

Schnittstellen zuerst stabilisieren: Das unterschätzte Fundament der Legacy-Ablösung

Многи legacy системи комуницирају преко еволуираних интерфејса: CSV-извози у фолдере, ноћни job-ови, директни приступи бази података од стране трећих алата, e-mail-базирани workflow-ови. Постепена замена биће значајно лакша ако у почетку инвентаришете ландшафт интерфејса и консолидујете га на неколико тачака.

Praktično to znači: identifikujte sistemski kritične tačke integracije (npr. finansijsko knjigovodstvo, otprema, povratne informacije iz proizvodnje, identiteti/ovlašćenja) i uspostavite tamo jasne ugovore. „Ugovor“ ovde ne znači pravno, već tehničku stabilnost: verzionisanje, nedvosmislena polja, stabilni ID-jevi, dokumentovano rukovanje greškama, definisani SLA-ovi za isporuku podataka.

Ako pritom uspostavite interno API-/integracijsko governance-model (Owner, Deprecation-Regeln, Test-/Staging-Pfade), smanjuje se rizik da neka promena u legacy sistemu iznenada onemogući vašu novu komponentu. Prikladna tematska tačka za internu povezanost bila bi, na primer, objava o API-governance i deprecations strategijama.

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

U paralelnom radu često postoje dupli modeli korisnika i uloga. To vodi do senčnih privilegija: korisnik je u novom sistemu pravilno ograničen, ali u legacy-ju i dalje ima široka prava – i na kraju koristi „lakši put“. Pored toga postoje tehnička korisnička naloga (servisni nalozi) za sinhronizaciju, import, queue-e i batch poslove.

Konkretne tačke koje treba rano razjasniti:

• Izvor identiteta: Odakle dolaze korisnici i grupe? AD/Entra ID? Sopstveni IAM? Važno je da je provisionisanje sledljivo.
• Mapiranje uloga: Ako se uloge ne poklapaju 1:1, potrebno je uspostaviti prelazne uloge koje su vremenski ograničene i podložne recertifikaciji.
• Servisni nalozi: Minimalna prava, rotacija tajni, uredno logovanje. Posebno su sinhronizacioni nalozi često ulazna tačka za napade i teško ih je auditovati.
• Audit-zapisi: Kada prava nad podacima prelaze, mora biti jasno gde se nalazi dokaz o promenama i kako se on može istražiti kroz oba sistema.

Važno za donosioce odluka: Security ovde nije „dodatni scope“, već utiče na izvodljivost roll-outa. Naknadno dovođenje prava u paralelnom radu obično je skuplje od ranog, pragmatičnog preseka uloga i servisnih naloga.

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

U paralelnom radu obrasci grešaka su često indirektni: delta stoji, retry se izvršava u krug, queue se zagušava ili vremenski kritičan job kolidira sa zaključavanjem baze. Ako to vidite tek kroz korisničke tikete, kasnite. Zbog toga vam od početka treba minimum observability-ja: Monitoring (stanje), Logging (događaji) i – gde ima smisla – Tracing (lanac kroz sisteme).

Praktični, dobro održivi signali su, na primer:

• Backlog sinhronizacije (koliko promena „čeka“), plus starost najstarijeg unosa.
• Stope grešaka po interfejsu i klasi greške (validacija, timeout, autentikacija, konflikt podataka).

За предају у оперативу мање је важно који се алат користи, важније је да су одговорности и Runbooks јасни. Ако имате On-Call или дежурство, оперативни рад мора при типичним кваровима остати оперативан без детективског рада програмера.

Када Strangler Pattern не одговара (или само уз јасна ограничења)

Постоје ситуације у којима постепена замена функционише само ограничено:

• Екстремно тесна транзакциона повезаност: Ако скоро сваки поступак пролази кроз све модуле и захтева строгу конзистентност, паралелни рад брзо постаје неконтролисан.
• Директни приступи бази података од стране трећих система: Ако више алата директно пише/чита у/из legacy-табела, тај дивљи приступ мора прво бити заустављен или контролисан.
• Нејасно вођство података: Ако се не може јасно одредити ко води податке, конфликт је загарантован – и замена постаје политичко, а не техничко питање.
• Недостатак оперативне дисциплине: Без чистих окружења, репродуцибилних деплоева и мониторинга, сваки међукорак постаје ризик.

То не значи да сте присиљени на Big Bang. Али онда морате променити редослед: прво стабилизовати интеграционе тачке, централисати приступе подацима, разјаснити улоге и власништво – и тек онда применити Strangler Pattern.

Праксно применљив план за постепену замену legacy система

Као оријентир за пројектно одговорне, показало се да је радни ток у јасним фазама погодан. Прецизан облик зависи од система и индустрије, али логика је робусна:

1. Инвентар и зависности: интерфејси, Jobs, токови података, групе корисника, критични временски прозори (затварање, инвентаризација).
2. Дефинисање спојних ивица: модули процеса, вођење података по области, интеграциони уговори.
3. Изградња рутирања и прекидача: Gateway/Proxy, Feature Flags, централно логовање.
4. Утврдити путању података: CDC/Event/Dual Write, правила конфликата, карантин, извештаји о усаглашавању.
5. Пилот са стварним оптерећењем: не само демо, већ са реалним случајевима, укључујући изузетке.
6. Роллаут у таласима: критеријуми уласка, cutover чек-листе, вежбе rollback-а.
7. Искључивање и чишћење: деактивирати старе путеве, уклонити Jobs, одузети права, ажурирати документацију.

Последња тачка је есенцијална: Многе организације остављају legacy компоненте да „за сваку случајност“ наставе да раде. Резултат: двоструки трошкови, нејасно ризично стање, нико се не усуђује да искључи. Планирајте Decommissioning као део пројекта са роком, одговорним лицима и доказима (нпр. „нису било приступа у последњих X недеља“, „сви експорти пребачени“, „захтеви ревизије испуњени“).

Закључак: Постепена замена значи третирање конзистентности и операција као производа

Постепена замена legacy система корак по корак није аутоматски једноставнија – али у многим предузећима је једина реалистична опција. Strangler Pattern функционише ако за сваку фазу дефинишете јасне процесне спојне ивице, планирате паралелни рад као стварно оперативно стање и не препустите конзистентност података случају. Кључне су ране одлуке о вођству података, робусни шаблони синхронизације са правилима конфликта као и дизајн роллаута са таласима, пријемима и увежбаним плановима за повратак.

Ако планирате замену и желите да структурирано размотрите интеграционе тачке, паралелни рад или концепт доследности података, можете нас контактирати преко .

Разговарајте о пројекту или плану модернизације са Net-Base.