Pillar page

Modernizace legacy systémů

Q: Co s dokumentací systému, která neexistuje?

Častý problém u legacy. První etapa projektu: reverse engineering dokumentace. AI agenti analyzují kód, schéma databáze, produkční logy a generují: schéma architektury, seznam endpointů, mapu závislostí, popis obchodních procesů. Tato dokumentace je následně ověřena s lidmi z byznysu (zda proces vypadá tak, jak jej rozumíme z kódu). Výsledek: úplná dokumentace před zahájením refaktoringu, užitečná nejen pro modernizační projekt, ale i pro produktový tým.

Q: Jaké jsou náklady modernizace ve srovnání s údržbou starého systému?

Krátkodobě je modernizace dražší než údržba (investice do refaktoringu + paralelní údržba starého systému). Bod break-even (kde se nový systém stává levnějším na údržbu než starý) typicky nastává po 12-18 měsících. Po této době nový systém: stojí méně na údržbu (méně vývojářů, více automatizace), umožňuje rychleji zavádět změny (kratší time-to-market), redukuje riziko (lepší pozorovatelnost, více testů, izolace selhání).

Inkrementální refaktoring monolitu na mikroslužby, migrace z přestárlých technologií do moderních stacků, přesun do cloudu — bez výpadku byznysu, s plánem rollback a kompletním audit trailem.

Audit legacy systému Všechny služby

Každá firma má nějaký legacy systém. Některé jich mají několik. Účetní aplikace z roku 2008, která nějak funguje. CRM napsané konzultanty, na které si už nikdo nepamatuje. Sklad v Accessu. Každý z nich bude jednoho dne potřeba vyměnit — otázka nezní zda, ale kdy a jak.

Modernizace legacy systémů patří mezi nejnáročnější typy IT projektů. Vyžaduje vyvažování tří sil: udržení obchodní kontinuity (systém musí celou dobu fungovat), zavádění moderních technologií (mikroslužby, cloud, AI) a kontroly rizika (každý refaktoring může rozbít něco, co fungovalo léta).

Proč nestačí „přepsat od nuly"?

Z naší zkušenosti je 9 z 10 úspěšných modernizací inkrementální refaktoring, ne rewrite. Rewrite lákají konceptuální jednoduchostí („začneme s čistým štítem"), ale v praxi mají tři fundamentální problémy:

Neviditelná byznys logika. Starý systém obsahuje roky obchodních pravidel — speciální podmínky pro největší klienty, daňové výjimky pro konkrétní obory, obejití regulací z roku 2015. Většina není zdokumentována. Rewrite musí všechna pravidla odtvořit z paměti lidí nebo z analýzy kódu.
Duplikace práce. Během psaní nového systému byznys nadále požaduje změny ve starém (regulace, noví klienti, drobné chyby). Tým buď duplikuje práci (změna na dvou místech), nebo zmrazí starý systém (obchodní riziko).
Big bang deployment. Po roce práce je nový systém „skoro hotový". Přepnutí všech uživatelů za jednu noc generuje monumentální riziko. Každý nečekaný problém znamená návrat ke starému systému, ztrátu morálky týmu, podlomení důvěry byznysu.

Inkrementální refaktoring (nejčastěji podle vzoru Strangler Fig) řeší všechny tři: byznys logika odkrývána postupně, jeden zdroj pravdy pro každou entitu, deployment ve fázích s feature flagy.

Šest vzorů modernizace

Každý z nich řeší konkrétní riziko. Ve většině projektů kombinujeme několik a volíme vzor podle konkrétního modulu.

Strangler Fig

Postupné „obrůstání" starého systému novými komponentami. Starý kód stále funguje, ale každá nová funkcionalita směřuje do nové mikroslužby a stávající moduly jsou vyměňovány jeden po druhém. Po 12-24 měsících je starý monolit vypnut.

Anti-corruption layer

Adaptér chránící nový kód před zvláštnostmi starého systému (nečitelné názvy polí, divné formáty dat, nekonzistentní typy). Veškerá „ošklivá" logika izolována na jednom místě — nový kód pracuje s čistým modelem domény.

Database refactoring

Vzory z knihy Refactoring Databases (Ambler/Sadalage): expand-and-contract pro migraci schématu, validace dat před smazáním starých sloupců, paralelní udržování obou schémat během migrace aplikace.

Branch by abstraction

Zavedení abstrakční vrstvy kolem staré komponenty, paralelní implementace nové komponenty, postupné přepínání z 0 % na 100 % provozu (feature flag). Bez „big bang" deploymentu.

Shadow mode

Nový kód běží paralelně se starým — oba zpracovávají stejné požadavky, ale pouze výsledky starého směřují k uživateli. Výsledky porovnávány offline. Po potvrzení shody (typicky 2-4 týdny) přepínáme provoz na nový kód.

Event sourcing pro migraci

Nahráváme stream obchodních událostí ze starého systému a přehráváme jej v novém. Umožňuje předběžnou validaci nové architektury bez produkčního rizika a návrat k libovolnému historickému stavu.

Typický harmonogram modernizace

Pro střední systém (monolit ~200 tis. řádků kódu, 5-10 obchodních modulů):

Měsíc 1: Discovery a dokumentace. Reverse engineering architektury, mapování závislostí, identifikace datových toků, dokumentace obchodních procesů ve spolupráci s byznysem.
Měsíc 2: Cílová architektura a pilot. Návrh nové architektury, výběr technologií, pilot na nejjednodušším modulu (proof of concept). První validace přístupu.
Měsíce 3-4: Vyčlenění prvního produkčního modulu. Strangler Fig pattern, shadow mode po dobu 2-3 týdnů, přepnutí provozu, hypercare. První reálná obchodní hodnota.
Měsíce 5-12: Iterativní vyčleňování dalších modulů. Každý v cyklu 4-6 týdnů: refaktoring → testy → shadow → produkce → hypercare. Kontinuální zlepšování procesu, redukce času na další moduly.
Měsíce 12-18: Migrace dat a vyřazení monolitu. Když jsou všechny kritické moduly vyčleněny, finalizujeme migraci historických dat, vypínáme starý systém, archivujeme. Slavíme.

Starý systém vs. zmodernizovaný

Aspekt	Legacy systém (typicky)	Po modernizaci
Čas nasazení nové funkce	4-8 týdnů (vysoké riziko regrese)	3-7 dní (automatické testy minimalizují riziko)
Pokrytí testy	5-15 % (nebo žádné)	>80 %, v CI/CD pipelinu
Dostupnost vývojářů	Nízká (přestárlá technologie)	Vysoká (populární, moderní stacky)
Bezpečnost	Staré knihovny s CVE zranitelnostmi	Skenování OWASP, gitleaks, automatické aktualizace
Škálování	Vertikální (více prostředků pro monolit)	Horizontální (škálování konkrétních mikroslužeb)
Pozorovatelnost	Logy v souborech, žádné metriky	Prometheus + Grafana + Sentry + SIEM
Compliance (GDPR, EU AI Act, ISO 27001)	Náročná, nákladná k prokázání	Zabudovaná v architektuře, připravená k auditu

Šest typických rizik — a jak je adresujeme

Riziko: Chybějící testy v legacy systému

Mitigace: Nejprve stavíme charakterizační testy (capture tests) — nahráváme současné chování systému na základě produkčních logů a záznamů provozu. Teprve poté začínáme refaktoring, s testy jako pojistkou.

Riziko: Znalosti soustředěné v jedné osobě („truck factor 1")

Mitigace: Transfer znalostí začíná v prvním týdnu projektu. Všechny schůzky s osobou znající systém jsou nahrávány a transkribovány, klíčové procesy dokumentovány, architektonická rozhodnutí odůvodněna. Po projektu celý tým systému rozumí.

Riziko: Dočasné zpomalení týmu

Mitigace: V prvních 2-3 měsících tým udržuje starý systém + staví nový. Přirozené zpomalení tempa změn. Mitigujeme to: prioritou pro změny směřující jen do nového systému, freeze pro nízkopriorit změn ve starém kódu.

Riziko: Migrace dat

Mitigace: Každá migrace dat má tři fáze: dry-run (na kopii produkce), staging (na testovacím prostředí s reálným objemem dat), produkce (v servisním okně nebo inkrementálně). Plán rollback připraven před startem.

Riziko: Organizační odpor

Mitigace: Komunikace s byznysem od prvního dne: proč modernizovat, co se pro uživatele změní, jaký harmonogram, jak měříme úspěch. První iterace zvolena tak, aby rychle ukázala hmatatelnou hodnotu (např. nové UI nebo rychlejší report).

Riziko: Podcenění nákladu

Mitigace: Discovery (1-2 týdny) před odhadem ceny projektu. 2-3 týdenní iterace s konkrétními dodávanými výstupy — kurz lze snadněji korigovat než v dlouhém projektu typu „všechno najednou". Rozpočet s rezervou 20-30 % na nepředvídatelnosti.

Často kladené otázky

Co je legacy systém?

Legacy systém je software, který v organizaci stále funguje, ale opírá se o přestárlé technologie, má dlouhý technický dluh, postrádá testy, dokumentaci nebo vývojáře, který jej napsal. Klasické příklady: monolitická aplikace v PHP 5.x nebo .NET Framework 4.0, databáze bez migrací, frontend v jQuery, deploy přes FTP. Funguje, ale každá změna představuje vysoké riziko a náklad.

Proč modernizovat, když systém funguje?

Tři hlavní důvody. Za prvé: náklady na údržbu rostou exponenciálně s věkem systému — stále méně vývojářů technologii zná, každá změna trvá déle, každá chyba má větší dopad. Za druhé: bezpečnostní riziko — staré frameworky mají nezáplatované díry, chybí podpora výrobce, neshoda s GDPR/ISO 27001. Za třetí: blokáda rozvoje byznysu — nové požadavky (mobile, API, integrace, AI) jsou obtížné nebo nemožné přidat.

Není snazší napsat všechno od nuly?

Klasické dilema „rewrite vs refactor". Rewrite lákají koncepční jednoduchostí, ale v praxi: trvají 2-3× déle než plánováno, projekt zaniká pod tíhou rekonstrukce neviditelné byznys logiky, mezitím je třeba dál rozvíjet starý systém (duplikace práce). Z naší zkušenosti: 9 z 10 úspěšných modernizací je inkrementální refaktoring (Strangler Fig pattern) — postupné vyměňování prvků starého systému, se zachováním obchodní kontinuity. Rewrite má smysl pouze u velmi malých systémů.

Vyžaduje modernizace výpadek byznysu?

Ve většině projektů ne. Používáme vzory, které umožňují vyměňovat komponenty „za běhu": blue-green deployment, feature flags, dark launches, paralelní spuštění starého a nového kódu s porovnáváním výsledků (shadow mode). Krátká servisní okna mohou být potřebná u migrace databáze s podstatnou změnou schématu, ale plánujeme je s předstihem (typicky v noci, o víkendu) a s plným plánem rollback.

Jak dlouho trvá typická modernizace?

Záleží na rozsahu. Jednotlivý modul monolitu vyčleněný jako mikroslužba: 1-2 měsíce. Větší modernizace (5-10 modulů, nová databáze, nové API): 6-12 měsíců v 2-3 týdenních iteracích. Plná transformace enterprise monolitu: 18-36 měsíců, ale obchodní hodnota se objevuje již po první iteraci — každý vyčleněný modul okamžitě přináší výhody (rychlejší změny, nižší riziko, lepší pozorovatelnost).

Z jakých technologií nejčastěji migrujeme?

Nejčastější cesty: PHP 5/7 → PHP 8 nebo Python (FastAPI) nebo Node.js (Express/Fastify). .NET Framework 4.x → .NET 8 nebo Java/Spring Boot. Java EE (JBoss/WebSphere) → Spring Boot nebo Quarkus. jQuery + monolitické šablony → React/Vue/Astro. Oracle DB → PostgreSQL (značné úspory licencí). On-premise → cloud (AWS, Azure, GCP, lokální privátní cloud).

Co se stávajícími integracemi s jinými systémy?

Každá stávající integrace je zmapována ve fázi discovery. Plán migrace zahrnuje: zachování stávajících kontraktů (interní i externí klienti změnu nezpozorují), zavedení verzování (v1 starý kontrakt, v2 nový), postupnou migraci spotřebitelů na v2, teprve poté vyřazení v1. Plná zpětná kompatibilita během migrace.

Jak omezujete obchodní riziko?

Pět vrstev: 1) inkrementálnost — vyměňujeme po jednom modulu, ne všechno najednou; 2) charakterizační testy — před refaktoringem nahráváme současné chování systému (capture tests), které poté ověřují, že se nic nerozbilo; 3) feature flags — nová funkcionalita spouštěná postupně (1 % uživatelů → 10 % → 50 % → 100 %); 4) plán rollback pro každý deploy (<5 min); 5) hypercare po nasazení (intenzivní monitoring 2-4 týdny).

Co s dokumentací systému, která neexistuje?