Pillar page

Modernizácia legacy systémov

Q: Čo s dokumentáciou systému, ktorá neexistuje?

Bežný problém pri legacy. Prvá etapa projektu: reverse engineering dokumentácie. AI agenti analyzujú kód, schému databázy, produkčné logy a generujú: schému architektúry, zoznam endpointov, mapu závislostí, opis obchodných procesov. Táto dokumentácia je následne overená s biznis ľuďmi (či proces vyzerá tak, ako rozumieme z kódu). Výsledok: úplná dokumentácia pred začiatkom refaktoringu, užitočná nielen pre modernizačný projekt, ale aj pre produktový tím.

Q: Aké sú náklady na modernizáciu v porovnaní s údržbou starého systému?

Krátkodobo je modernizácia drahšia ako údržba (investícia do refaktoringu + údržba starého systému paralelne). Bod break-even (kedy sa nový systém stáva lacnejším na údržbu ako starý) typicky nastáva po 12-18 mesiacoch. Po tomto čase nový systém: stojí menej na údržbu (menej vývojárov, viac automatizácie), umožňuje rýchlejšie zavádzať zmeny (kratší time-to-market), redukuje riziko (lepšia observabilita, viac testov, izolácia výpadkov).

Inkrementálny refaktoring monolitu na mikroslužby, migrácia zo zastaraných technológií na moderné stacky, presun do cloudu — bez obchodného výpadku, s plánom rollback a úplným audit trailom.

Audit legacy systému Všetky služby

Každá firma má nejaký legacy systém. Niektoré majú viacero. Účtovná aplikácia z roku 2008, ktorá nejako funguje. CRM napísané konzultantmi, ktorých si už nikto nepamätá. Sklad v Accesse. Každý z nich bude treba raz vymeniť — otázka nie je či, ale kedy a ako.

Modernizácia legacy systémov je jeden z najnáročnejších typov IT projektov. Vyžaduje vyvažovanie troch síl: udržanie obchodnej kontinuity (systém musí fungovať nepretržite), zavádzanie moderných technológií (mikroslužby, cloud, AI) a kontroly rizika (každý refaktoring môže pokaziť niečo, čo fungovalo roky).

Prečo nestačí „prepísať od nuly"?

Z našej skúsenosti 9 z 10 úspešných modernizácií je inkrementálny refaktoring, nie rewrite. Rewrite lákajú konceptuálnou jednoduchosťou („začneme s čistým listom"), ale v praxi majú tri zásadné problémy:

Neviditeľná obchodná logika. Starý systém obsahuje roky obchodných pravidiel — špeciálne podmienky pre najväčších klientov, daňové úľavy pre konkrétne odvetvia, obchádzky regulácií z roku 2015. Väčšina nie je dokumentovaná. Rewrite ich musí všetky obnoviť z pamäte ľudí alebo analýzy kódu.
Duplikácia práce. Počas písania nového systému biznis stále vyžaduje zmeny v starom (regulácie, noví klienti, drobné chyby). Tím buď duplikuje prácu (zmena na dvoch miestach), alebo zmrazí starý systém (obchodné riziko).
Big bang deployment. Po roku práce je nový systém „takmer hotový". Prepnutie všetkých používateľov v jednu noc generuje monumentálne riziko. Akýkoľvek neočakávaný problém znamená návrat k starému systému, stratu morálky tímu, podkopanie dôvery biznisu.

Inkrementálny refaktoring (najčastejšie podľa vzoru Strangler Fig) rieši všetky tri: obchodná logika sa odhaľuje postupne, jeden zdroj pravdy pre každú entitu, deployment v etapách s feature flagmi.

Šesť vzorov modernizácie

Každý z nich rieši konkrétne riziko. Vo väčšine projektov kombinujeme viaceré, vzor vyberáme podľa konkrétneho modulu.

Strangler Fig

Postupné „opasovanie" starého systému novými komponentmi. Starý kód stále funguje, ale každá nová funkcionalita ide do novej mikroslužby a existujúce moduly sa vymieňajú jeden po druhom. Po 12-24 mesiacoch sa starý monolit vypne.

Anti-corruption layer

Adaptér chrániaci nový kód pred zvláštnosťami starého systému (nečitateľné názvy polí, čudné formáty dátumov, nekonzistentné typy). Celá „škaredá" logika izolovaná na jednom mieste — nový kód pracuje s čistým doménovým modelom.

Database refactoring

Vzory z knihy Refactoring Databases (Ambler/Sadalage): expand-and-contract pre migráciu schémy, validácia dát pred odstránením starých stĺpcov, paralelná podpora oboch schém počas migrácie aplikácie.

Branch by abstraction

Zavedenie abstraktnej vrstvy okolo starého komponentu, paralelná implementácia nového komponentu, postupné prepínanie od 0 % do 100 % prevádzky (feature flag). Bez „big bang" deployu.

Shadow mode

Nový kód spúšťaný paralelne so starým — oba spracúvajú tie isté požiadavky, ale len výsledky starého idú k používateľovi. Výsledky porovnávané offline. Po potvrdení zhody (typicky 2-4 týždne) prepneme prevádzku na nový kód.

Event sourcing pre migráciu

Nahrávame stream obchodných udalostí zo starého systému a prehrávame ho v novom. Umožňuje predbežnú validáciu novej architektúry bez produkčného rizika a návrat do ľubovoľného historického stavu.

Typický harmonogram modernizácie

Pre stredný systém (monolit ~200 tisíc riadkov kódu, 5-10 obchodných modulov):

Mesiac 1: Discovery a dokumentácia. Reverse engineering architektúry, mapovanie závislostí, identifikácia dátových tokov, dokumentácia obchodných procesov s pomocou biznis ľudí.
Mesiac 2: Cieľová architektúra a pilot. Návrh novej architektúry, voľba technológií, pilot na najjednoduchšom module (proof of concept). Prvá validácia prístupu.
Mesiace 3-4: Vyčlenenie prvého produkčného modulu. Strangler Fig pattern, shadow mode 2-3 týždne, prepnutie prevádzky, hypercare. Prvá reálna obchodná hodnota.
Mesiace 5-12: Iteratívne vyčleňovanie ďalších modulov. Každý v cykle 4-6 týždňov: refaktoring → testy → shadow → produkcia → hypercare. Neustále zlepšovanie procesu, redukcia času na ďalšie moduly.
Mesiace 12-18: Migrácia dát a vyradenie monolitu. Keď sú všetky kritické moduly vyčlenené, dokončujeme migráciu historických dát, vypíname starý systém, archivujeme. Oslavujeme.

Starý systém vs. modernizovaný

Aspekt	Legacy systém (typicky)	Po modernizácii
Čas nasadenia novej funkcie	4-8 týždňov (vysoké riziko regresie)	3-7 dní (automatické testy minimalizujú riziko)
Pokrytie testami	5-15 % (alebo žiadne)	>80 %, v CI/CD pipeline
Dostupnosť vývojárov	Nízka (zastaraná technológia)	Vysoká (populárne, moderné stacky)
Bezpečnosť	Staré knižnice s CVE zraniteľnosťami	Skenovanie OWASP, gitleaks, automatické aktualizácie
Škálovanie	Vertikálne (viac zdrojov pre monolit)	Horizontálne (škálovanie konkrétnych mikroslužieb)
Observabilita	Logy v súboroch, žiadne metriky	Prometheus + Grafana + Sentry + SIEM
Compliance (GDPR, EU AI Act, ISO 27001)	Náročná, nákladná na preukázanie	Zabudovaná v architektúre, pripravená na audit

Šesť typických rizík — a ako ich riešime

Riziko: Žiadne testy v legacy systéme

Mitigácia: Najprv staviame charakterizačné testy (capture tests) — nahrávame aktuálne správanie systému na základe produkčných logov a záznamov prevádzky. Až potom začíname refaktoring, s testami ako zabezpečením.

Riziko: Vedomosti sústredené v jednej osobe („truck factor 1")

Mitigácia: Transfer vedomostí začína v prvom týždni projektu. Všetky stretnutia s osobou poznajúcou systém sú nahrávané a transkribované, kľúčové procesy dokumentované, architektonické rozhodnutia odôvodnené. Po projekte celý tím rozumie systému.

Riziko: Dočasné spomalenie tímu

Mitigácia: V prvých 2-3 mesiacoch tím udržiava starý systém + buduje nový. Prirodzené spomalenie tempa zmien. Mitigujeme to: priorita pre zmeny, ktoré idú len do nového systému, freeze pre nízkoprioritné zmeny v starom kóde.

Riziko: Migrácia dát

Mitigácia: Každá migrácia dát má tri fázy: dry-run (na kópii produkcie), staging (na testovacom prostredí s reálnou škálou dát), produkcia (v servisnom okne alebo inkrementálne). Plán rollback pripravený pred štartom.

Riziko: Organizačný odpor

Mitigácia: Komunikácia s biznisom od prvého dňa: prečo modernizácia, čo sa zmení pre používateľa, aký harmonogram, ako meriame úspech. Prvá iterácia vybraná tak, aby rýchlo ukázala hmatateľnú hodnotu (napr. nové UI alebo rýchlejší report).

Riziko: Podhodnotenie nákladov

Mitigácia: Discovery (1-2 týždne) pred ocenením projektu. Iterácie 2-3 týždňové s konkrétnymi dodávanými efektmi — ľahšie skorigovať kurz ako v dlhom projekte typu „všetko naraz". Rozpočet s 20-30 % rezervou na nepredvídané.

Najčastejšie otázky

Čo je legacy systém?

Legacy systém je softvér, ktorý stále beží v organizácii, ale opiera sa o zastarané technológie, má dlhý technický dlh, chýbajú mu testy, dokumentácia alebo vývojár, ktorý ho napísal. Klasické príklady: monolitická aplikácia v PHP 5.x alebo .NET Framework 4.0, databáza bez migrácií, frontend v jQuery, deploy cez FTP. Funguje, ale každá zmena znamená vysoké riziko a náklady.

Prečo modernizovať, keď systém funguje?

Tri hlavné dôvody. Po prvé: náklady na údržbu rastú exponenciálne s vekom systému — čoraz menej vývojárov pozná technológiu, každá zmena trvá dlhšie, každý bug má väčší dosah. Po druhé: bezpečnostné riziko — staré frameworky majú nezáplatované zraniteľnosti, žiadnu podporu výrobcu, nesúlad s GDPR/ISO 27001. Po tretie: blokáda rozvoja biznisu — nové požiadavky (mobile, API, integrácie, AI) je ťažké alebo nemožné pridať.

Nie je jednoduchšie napísať všetko od nuly?

Klasická dilema „rewrite vs refactor". Rewrite lákajú konceptuálnou jednoduchosťou, ale v praxi: trvajú 2-3-krát dlhšie ako sa plánovalo, projekt zaniká pod ťarchou obnovy neviditeľnej obchodnej logiky, medzitým je potrebné starý systém ďalej rozvíjať (duplikácia práce). Z našej skúsenosti: 9 z 10 úspešných modernizácií je inkrementálny refaktoring (Strangler Fig pattern) — postupná výmena prvkov starého systému so zachovaním obchodnej kontinuity. Rewrite má zmysel len pre veľmi malé systémy.

Vyžaduje modernizácia obchodný výpadok?

Vo veľkej väčšine projektov nie. Používame vzory, ktoré umožňujú vymieňať komponenty „za chodu": blue-green deployment, feature flags, dark launches, paralelné spustenie starého a nového kódu s porovnaním výsledkov (shadow mode). Krátke servisné okná môžu byť potrebné pri migrácii databázy s podstatnou zmenou schémy, ale plánujeme ich s predstihom (typicky v noci, cez víkend) a s úplným plánom rollback.

Ako dlho trvá typická modernizácia?

Závisí od rozsahu. Jediný modul monolitu vyčlenený ako mikroslužba: 1-2 mesiace. Väčšia modernizácia (5-10 modulov, nová databáza, nové API): 6-12 mesiacov v iteráciách 2-3 týždne. Plná transformácia enterprise monolitu: 18-36 mesiacov, ale obchodná hodnota sa objavuje už po prvej iterácii — každý vyčlenený modul okamžite prináša výhody (rýchlejšie zmeny, nižšie riziko, lepšia observabilita).

Z akých technológií migrujeme najčastejšie?

Najčastejšie cesty: PHP 5/7 → PHP 8 alebo Python (FastAPI) alebo Node.js (Express/Fastify). .NET Framework 4.x → .NET 8 alebo Java/Spring Boot. Java EE (JBoss/WebSphere) → Spring Boot alebo Quarkus. jQuery + monolitické šablóny → React/Vue/Astro. Oracle DB → PostgreSQL (výrazné licenčné úspory). On-premise → cloud (AWS, Azure, GCP, lokálny privátny cloud).

Čo s existujúcimi integráciami s inými systémami?

Každá existujúca integrácia je zmapovaná vo fáze discovery. Migračný plán zahŕňa: zachovanie existujúcich kontraktov (interní a externí klienti nezaznamenajú zmenu), zavedenie versioningu (v1 starý kontrakt, v2 nový), postupnú migráciu konzumentov na v2, až potom vyradenie v1. Plná spätná kompatibilita počas migrácie.

Ako obmedzujete obchodné riziko?

Päť vrstiev: 1) inkrementálnosť — vymieňame po jednom module, nie všetko naraz; 2) charakterizačné testy — pred refaktoringom nahrávame aktuálne správanie systému (capture tests), ktoré potom overujú, že nič nebolo pokazené; 3) feature flags — nová funkcionalita spúšťaná postupne (1 % používateľov → 10 % → 50 % → 100 %); 4) plán rollback pre každý deploy (<5 min); 5) hypercare po nasadení (intenzívny monitoring 2-4 týždne).

Čo s dokumentáciou systému, ktorá neexistuje?