Přepis legacy aplikace do nového systému

Legacy aplikace většinou nepraskne v jeden dramatický moment. Spíš pomalu brzdí tým, prodlužuje každou změnu a zvyšuje riziko pokaždé, když je potřeba přidat novou funkci. Právě tehdy začíná být přepis legacy aplikace do nového systému reálné téma, ne jako technické cvičení, ale jako obchodní rozhodnutí.

Kdy přepis legacy aplikace do nového systému dává smysl

Ne každá starší aplikace potřebuje kompletní přepis. Nejdřív stojí za to ověřit, jestli nepostačí postupná modernizace. Někdy stačí zpevnit architekturu, oddělit kritické části nebo vyměnit několik problematických modulů. Pokud ale systém stojí na zastaralém stacku, nikdo se v něm nechce hrabat a každá úprava trvá násobně déle, přepis začíná být levnější než nekonečné záplaty.

Typický signál je, když business ví, co potřebuje dělat dál, ale systém to prakticky neumožní. Nový onboarding zákazníků, změna workflow, integrace na účetnictví, automatizace nebo mobilní rozhraní, všechno je teoreticky možné, ale pokaždé za cenu vysokého rizika. V takové chvíli není problém jen v technologii. Problém je, že software přestal být oporou byznysu.

Dalším důvodem bývá provozní závislost na jednom člověku nebo malé skupině lidí. Pokud aplikaci rozumí jen původní dodavatel, který už systém nerozvíjí, nebo interní senior, který odchází, firma se dostává do slabé pozice. Přepis pak není luxus, ale způsob, jak získat zpět kontrolu.

Nejdražší chyba: přepsat všechno najednou

Nejhorší varianta je rozhodnutí typu „postavíme to znovu, ale lépe“ bez přesného určení, co vlastně musí nový systém umět od prvního dne. To zní rozumně jen do chvíle, než se otevře deset let stará logika, ruční výjimky, speciální role uživatelů a vazby na další nástroje. Starý systém často obsahuje více obchodních pravidel, než si firma uvědomuje.

Proto se vyplácí začít mapováním reality, ne představ. Co aplikace skutečně dělá, kdo ji používá, které části jsou kritické pro provoz a které jen přežívají ze zvyku? U starších systémů bývá rozdíl mezi zadáním a skutečným chováním výrazný. Kdo tenhle krok přeskočí, obvykle později platí za opravy špatných předpokladů.

Z naší zkušenosti je lepší uvažovat po vrstvách. Nejdřív pochopit doménu, potom data, potom integrační body a až nakonec obrazovky a workflow. Přesně opačný postup bývá lákavý, protože UI je vidět nejdřív. Jenže hezké nové rozhraní neřeší špatně navržené datové modely ani skrytou provozní logiku.

Co je potřeba zjistit před první řádkou nového kódu

Přepis legacy aplikace do nového systému nezačíná frameworkem. Začíná odpověďmi na několik nepříjemných, ale praktických otázek.

První je, co se nesmí pokazit. U někoho je to fakturace, u jiného schvalovací proces, reporting nebo práva uživatelů. Když víme, které scénáře jsou kritické, můžeme kolem nich stavět migraci i testování. Bez toho tým snadno věnuje energii okrajovým částem a mine to, co drží provoz.

Druhá otázka se týká dat. Staré systémy mívají nekonzistence, duplicitní záznamy, historické sloupce bez významu a vazby, které existují jen proto, že je kdysi někdo potřeboval. Migrace dat není technická formalita. Je to moment, kdy se ukáže skutečný stav systému. Čím dřív se tenhle stav otevře, tím méně překvapení přijde později.

Třetí oblast jsou integrace. Legacy aplikace bývá napojená na e-mailing, ERP, účetnictví, platební brány, API partnerů nebo interní nástroje. Někdy dokumentace neexistuje, někdy integrace funguje jen díky sérii tichých předpokladů. Pokud se tyto vazby neověří včas, nový systém se může tvářit hotově, ale v provozu narazí.

A pak je tu otázka provozu. Kdo bude nový systém používat první den? Půjde o paralelní běh vedle staré aplikace, nebo ostrý přechod? Jak se bude řešit rollback? Tohle nejsou detaily na konec projektu. To jsou rozhodnutí, která ovlivní architekturu od začátku.

Jak obvykle vypadá rozumný postup

Ve většině případů se nevyplácí velký jednorázový přechod. Rozumnější je rozdělit projekt do etap, které mají samostatnou hodnotu a snižují závislost na starém systému postupně. Ne proto, že by to bylo módní, ale protože to dává větší kontrolu nad rizikem.

První etapa bývá analyticko-technická. Ne ve smyslu dlouhého dokumentu do šuplíku, ale jako praktické rozebrání systému. Potřebujeme pochopit doménu, ověřit kritické scénáře, navrhnout cílovou architekturu a pojmenovat místa, kde budou kompromisy. Občas se už tady ukáže, že plný přepis není nejlepší cesta a že část systému dává smysl ponechat nebo dočasně obalit novým rozhraním.

Druhá etapa řeší základ nového systému, doménový model, přístupy uživatelů, klíčové workflow, integrační vrstvu a technický základ pro další rozvoj. Cílem není mít všechno, ale mít pevné jádro, na kterém se dá stavět bez chaosu. Když je základ špatně, rychlost vývoje se zpomalí znovu, jen v novější technologii.

Třetí etapa bývá migrace konkrétních modulů a dat. Tady se ukazuje, jak moc byl starý systém opravdu používán. Narazí se na výjimky, historické procesy i ruční obezličky. To je normální. Důležité je, aby projekt měl prostor tyto věci řešit průběžně a nehrál si na to, že realita bude čistá.

Přepis legacy aplikace do nového systému bez zbytečných výpadků

Firmy se často bojí hlavně jedné věci, že nový systém sice vznikne, ale přechod ochromí provoz. Tenhle strach je oprávněný. Špatně naplánovaná migrace dokáže znehodnotit i technicky dobrý projekt.

Proto dává smysl navrhnout přechod tak, aby se starý a nový svět nějakou dobu překrývaly. Někdy to znamená paralelní provoz vybraných funkcí, jindy synchronizaci dat nebo postupný rollout na konkrétní týmy. Záleží na typu aplikace, objemu dat i toleranci k riziku. Univerzální recept neexistuje.

U interních systémů může být přechod tvrdší, pokud jsou uživatelé dostupní a procesy pod kontrolou. U zákaznických portálů nebo SaaS produktů bývá potřeba větší opatrnost. Tam je každé selhání vidět okamžitě a důvěra se vrací pomalu. Proto má smysl oddělit technickou hotovost od skutečné připravenosti na produkci.

Velký rozdíl dělá i monitoring a logování od prvního dne. Ne jako doplněk po spuštění, ale jako součást návrhu. Když po nasazení nevidíte, co se v systému děje, řešíte problémy naslepo. A u migrace je naslepo drahý způsob práce.

Na čem projekty nejčastěji padají

První problém je nejasný rozsah. Vedení firmy chce nahradit starý systém, ale tým nemá shodu na tom, co musí být v první verzi a co může počkat. Pak se do projektu průběžně vrací vše, co kdy stará aplikace uměla, bez ohledu na skutečnou hodnotu. Rozsah bobtná a priorita se rozostří.

Druhý problém je podcenění dat. Kód se dá přepsat, ale špinavá data se sama nesrovnají. Pokud se migrace bere jako jednorázový export a import, většinou to nestačí. Potřebujete pravidla, validace a hlavně rozhodnutí, co do nového systému vůbec patří.

Třetí problém je snaha kopírovat starý systém pixel po pixelu. To může být potřeba u některých pracovních rolí, které jsou zvyklé na konkrétní proces. Ale často jde jen o setrvačnost. Přepis je příležitost odstranit zbytečné kroky a zjednodušit části, které vznikly historicky. Ne vše staré je potřeba zachovat.

A čtvrtý problém je chybějící partner, který umí nejen vyvíjet, ale i rozhodovat technicky v kontextu byznysu. Samotné programování na takových projektech nestačí. Potřebujete tým, který umí říct, kde má smysl investovat, co odložit a kde by perfekcionismus jen prodražil cestu k výsledku.

Co čekat od dodavatele, který má systém opravdu převzít

Pokud vám někdo hned na první schůzce slíbí rychlý a hladký přepis bez komplikací, je to spíš varování. U legacy systémů komplikace přijdou. Rozdíl je v tom, jestli se objeví pozdě a chaoticky, nebo brzy a pod kontrolou.

Dobrý partner se ptá na provoz, data, ownership a rizika. Nesoustředí se jen na obrazovky, ale i na to, jak se bude systém nasazovat, testovat a předávat. Umí navrhnout postup po částech a otevřeně říct, co zatím neví. To není slabost. To je normální u projektů, kde část reality odhalí až samotná práce.

My takové projekty bereme jako převzetí odpovědnosti za budoucí provoz, ne jen za napsání nové verze. To mění způsob, jak navrhujeme architekturu, jak přemýšlíme o maintainability a proč nechceme obcházet nepříjemné otázky na začátku.

Přepis staré aplikace málokdy působí atraktivně. Je v něm hodně technického dluhu, starých rozhodnutí a neviditelné práce. Když se ale udělá poctivě, firma nezíská jen novější kód. Získá systém, o který se může opřít při dalším růstu.