Pillér oldal

Legacy rendszerek modernizálása

Q: Mi van a rendszer dokumentációjával, amely nem létezik?

Gyakori probléma a legacy esetén. A projekt első szakasza: dokumentáció reverse engineering. Az MI-ügynökök elemzik a kódot, az adatbázissémát, a produkciós logokat és generálják: az architektúraábrát, a végpontok listáját, a függőségi térképet, az üzleti folyamatok leírását. Ezt a dokumentációt aztán üzleti emberekkel ellenőrizzük (úgy néz-e ki a folyamat, ahogy a kódból értjük). Eredmény: teljes dokumentáció a refaktorálás megkezdése előtt, ami nemcsak a modernizációs projekt számára hasznos, hanem a termékfejlesztő csapat számára is.

Q: Mennyibe kerül a modernizáció a régi rendszer karbantartásához képest?

Rövid távon a modernizáció drágább a karbantartásnál (befektetés a refaktorálásba + a régi rendszer párhuzamos fenntartása). A break-even pont (ahol az új rendszer karbantartása olcsóbb lesz a réginél) tipikusan 12-18 hónap után érkezik. Ezután az új rendszer: kevesebbe kerül karbantartani (kevesebb fejlesztő, több automatizáció), lehetővé teszi a változások gyorsabb bevezetését (rövidebb time-to-market), csökkenti a kockázatot (jobb megfigyelhetőség, több teszt, a hibák izolálása).

Monolit inkrementális refaktorálása mikroszolgáltatásokra, migráció elavult technológiákról modern stackekre, áthelyezés felhőbe — üzleti leállás nélkül, rollback tervvel és teljes audit trail-lel.

Legacy rendszer auditja Minden szolgáltatás

Minden cégnek van valamilyen legacy rendszere. Egyeseknek több is. A 2008-as könyvelési alkalmazás, ami valahogy működik. A CRM, amelyet olyan tanácsadók írtak, akikre már senki sem emlékszik. A raktár Access-ben. Mindegyiket egyszer ki kell majd váltani — a kérdés nem az, hogy vajon, hanem hogy mikor és hogyan.

A legacy rendszerek modernizálása az egyik legnehezebb IT-projekttípus. Három erő egyensúlyozását igényli: az üzleti folytonosság megőrzése (a rendszernek folyamatosan működnie kell), modern technológiák bevezetése (mikroszolgáltatások, felhő, MI) és a kockázat kontrollja (minden refaktorálás elronthat valamit, ami évek óta működik).

Miért nem elegendő a „nulláról újraírni"?

Tapasztalatunk szerint 10-ből 9 sikeres modernizáció inkrementális refaktorálás, nem rewrite. A rewrite csábít fogalmi egyszerűségével („tiszta lappal kezdünk"), de a gyakorlatban három alapvető problémája van:

Láthatatlan üzleti logika. A régi rendszer évek üzleti szabályait tartalmazza — speciális feltételek a legnagyobb ügyfeleknek, adómentességek bizonyos iparágaknak, 2015-ös szabályozások megkerülései. A többségük nincs dokumentálva. A rewrite-nak mindezt vissza kell állítania emberek emlékezetéből vagy kódelemzésből.
Duplikált munka. Az új rendszer írása közben az üzlet még mindig változtatásokat igényel a régiben (szabályozások, új ügyfelek, apró hibák). A csapat vagy duplikálja a munkát (változtatás két helyen), vagy befagyasztja a régi rendszert (üzleti kockázat).
Big bang deployment. Egy év munka után az új rendszer „majdnem készen van". Az összes felhasználó egy éjszaka alatti átkapcsolása monumentális kockázatot generál. Bármely váratlan probléma a régi rendszerhez való visszatérést, a csapat moráljának elvesztését, az üzleti bizalom megkérdőjelezését jelenti.

Az inkrementális refaktorálás (leggyakrabban a Strangler Fig minta szerint) mindhármat megoldja: az üzleti logika fokozatosan tárul fel, egy igazságforrás van minden entitásra, szakaszos deployment feature flagekkel.

A modernizáció hat mintája

Mindegyik konkrét kockázatot old meg. A legtöbb projektben többet kombinálunk, az adott modulhoz illesztve a mintát.

Strangler Fig

A régi rendszer fokozatos „körülvétele" új komponensekkel. A régi kód továbbra is működik, de minden új funkcionalitás új mikroszolgáltatásba kerül, a meglévő modulokat pedig egyenként cseréljük. 12-24 hónap után a régi monolit kikapcsolható.

Anti-corruption layer

Adapter, amely védi az új kódot a régi rendszer furcsaságaitól (érthetetlen mezőnevek, furcsa dátumformátumok, inkonzisztens típusok). Az egész „csúnya" logika egy helyen izolálva — az új kód tiszta domain modellen dolgozik.

Database refactoring

A Refactoring Databases könyv (Ambler/Sadalage) mintái: expand-and-contract a sémamigrációhoz, adatvalidáció a régi oszlopok törlése előtt, mindkét séma párhuzamos fenntartása az alkalmazásmigráció során.

Branch by abstraction

Absztrakciós réteg bevezetése a régi komponens köré, az új komponens párhuzamos implementálása, fokozatos átkapcsolás 0%-ról 100%-ra (feature flag). „Big bang" deploy nélkül.

Shadow mode

Az új kód a régivel párhuzamosan fut — mindkettő ugyanazokat a kéréseket dolgozza fel, de csak a régi eredménye jut el a felhasználóhoz. Az eredmények offline összehasonlítva. Az egyezés megerősítése után (tipikusan 2-4 hét) átkapcsoljuk a forgalmat az új kódra.

Event sourcing migrációhoz

Rögzítjük az üzleti események folyamát a régi rendszerből és lejátsszuk az újban. Lehetővé teszi az új architektúra előzetes validálását produkciós kockázat nélkül, valamint a visszatérést bármely historikus állapotba.

Tipikus modernizációs ütemterv

Egy közepes rendszerre (monolit ~200 ezer kódsor, 5-10 üzleti modul):

1. hónap: Discovery és dokumentáció. Architektúra reverse engineering, függőségek feltérképezése, adatáramlások azonosítása, üzleti folyamatok dokumentálása az üzleti emberek segítségével.
2. hónap: Cél-architektúra és pilot. Új architektúra tervezése, technológiaválasztás, pilot a legegyszerűbb modulra (proof of concept). A megközelítés első validálása.
3-4. hónap: Az első produkciós modul kiemelése. Strangler Fig pattern, shadow mode 2-3 héten át, forgalom átkapcsolása, hypercare. Az első valós üzleti érték.
5-12. hónap: További modulok iteratív kiemelése. Mindegyik 4-6 hetes ciklusban: refaktorálás → tesztek → shadow → produkció → hypercare. A folyamat folyamatos tökéletesítése, az újabb modulok időigényének csökkentése.
12-18. hónap: Adatmigráció és a monolit kivonása. Amikor minden kritikus modul ki van emelve, befejezzük a historikus adatok migrációját, kikapcsoljuk a régi rendszert, archiváljuk. Ünneplünk.

Régi rendszer vs. modernizált

Szempont	Legacy rendszer (tipikusan)	Modernizáció után
Új funkció bevezetésének ideje	4-8 hét (magas regressziós kockázat)	3-7 nap (automatikus tesztek minimalizálják a kockázatot)
Tesztek lefedettsége	5-15% (vagy semmi)	>80%, CI/CD pipeline-ban
Fejlesztők elérhetősége	Alacsony (elavult technológia)	Magas (népszerű, modern stackek)
Biztonság	Régi könyvtárak CVE hibákkal	OWASP, gitleaks szkennelés, automatikus frissítések
Skálázás	Vertikális (több erőforrás a monolitnak)	Horizontális (konkrét mikroszolgáltatások skálázása)
Megfigyelhetőség	Logok fájlokban, metrikák nélkül	Prometheus + Grafana + Sentry + SIEM
Compliance (GDPR, EU AI Act, ISO 27001)	Igényes, költséges bizonyítani	Beépítve az architektúrába, auditra készen

Hat tipikus kockázat — és hogyan kezeljük őket

Kockázat: Tesztek hiánya a legacy rendszerben

Mitigáció: Először karakterisztikus teszteket építünk (capture tests) — rögzítjük a rendszer jelenlegi viselkedését produkciós logok és forgalom rögzítések alapján. Csak ezután kezdjük a refaktorálást, a tesztekkel mint biztosítékkal.

Kockázat: Egy emberben koncentrálódó tudás („truck factor 1")

Mitigáció: A tudásátadás a projekt első hetében kezdődik. A rendszert ismerő személlyel folytatott összes megbeszélést rögzítjük és átirattal látjuk el, a kulcsfontosságú folyamatokat dokumentáljuk, az architekturális döntéseket indokoljuk. A projekt után az egész csapat érti a rendszert.

Kockázat: A csapat ideiglenes lassulása

Mitigáció: Az első 2-3 hónapban a csapat fenntartja a régi rendszert + építi az újat. Természetes lassulás a változások ütemében. Mitigáljuk ezt: prioritás azoknak a változásoknak, amelyek csak az új rendszerbe kerülnek, freeze az alacsony prioritású változásokra a régi kódban.

Kockázat: Adatmigráció

Mitigáció: Minden adatmigráció három fázisú: dry-run (produkciós másolaton), staging (tesztkörnyezetben valós adatmennyiséggel), produkció (szervizablakban vagy inkrementálisan). Rollback terv készen a start előtt.

Kockázat: Szervezeti ellenállás

Mitigáció: Kommunikáció az üzlettel az első naptól: miért modernizáció, mi változik a felhasználónak, milyen ütemterv, hogyan mérjük a sikert. Az első iterációt úgy választjuk, hogy gyorsan kézzelfogható értéket mutasson (pl. új UI vagy gyorsabb riport).

Kockázat: Költségek alulbecslése

Mitigáció: Discovery (1-2 hét) a projekt árazása előtt. 2-3 hetes iterációk konkrét szállítható eredményekkel — könnyebb a kurzust korrigálni, mint egy hosszú „mindent egyszerre" típusú projektben. Költségvetés 20-30%-os tartalékkal előre nem látható helyzetekre.

Gyakran ismételt kérdések

Mi az a legacy rendszer?

A legacy rendszer olyan szoftver, amely még működik a szervezetben, de elavult technológiákra épül, nagy a technikai adóssága, hiányoznak a tesztek, dokumentáció vagy a fejlesztő, aki írta. Klasszikus példák: monolitikus PHP 5.x vagy .NET Framework 4.0 alkalmazás, migrációk nélküli adatbázis, jQuery frontend, FTP-n keresztüli deploy. Működik, de minden változás magas kockázat és költség.

Miért érdemes modernizálni, ha a rendszer működik?

Három fő ok. Először: a karbantartási költség exponenciálisan nő a rendszer korával — egyre kevesebb fejlesztő ismeri a technológiát, minden változás tovább tart, minden bug nagyobb hatású. Másodszor: biztonsági kockázat — a régi keretrendszereknek vannak nem javított sebezhetőségeik, nincs gyártói támogatás, nem felelnek meg a GDPR/ISO 27001-nek. Harmadszor: az üzletfejlődés blokkolása — az új követelmények (mobile, API, integrációk, MI) nehezen vagy egyáltalán nem hozzáadhatók.

Nem könnyebb mindent újraírni?

Klasszikus dilemma: „rewrite vs refactor". A rewrite csábít fogalmi egyszerűségével, de a gyakorlatban: 2-3-szor tovább tart a tervezettnél, a projekt belerokkan a láthatatlan üzleti logika visszaállításába, közben a régi rendszert tovább kell fejleszteni (munkaduplikálás). Tapasztalatunk szerint: 10-ből 9 sikeres modernizáció inkrementális refaktorálás (Strangler Fig pattern) — a régi rendszer elemeinek fokozatos cseréje, az üzleti folytonosság megőrzésével. A rewrite csak nagyon kis rendszereknek van értelme.

A modernizációhoz üzleti leállás kell?

A projektek túlnyomó többségében nem. Olyan mintákat alkalmazunk, amelyek lehetővé teszik a komponensek „élesben" történő cseréjét: blue-green deployment, feature flags, dark launches, a régi és új kód párhuzamos futtatása az eredmények összehasonlításával (shadow mode). Rövid szervizablakok szükségesek lehetnek az adatbázis migrációjához jelentős sémamódosítással, de ezeket előre tervezzük (tipikusan éjszaka, hétvégén) teljes rollback tervvel.

Mennyi időt vesz igénybe egy tipikus modernizáció?

A mérettől függ. Egyetlen monolit modul mikroszolgáltatásként való kiemelése: 1-2 hónap. Nagyobb modernizáció (5-10 modul, új adatbázis, új API): 6-12 hónap 2-3 hetes iterációkban. Egy enterprise osztályú monolit teljes transzformációja: 18-36 hónap, de az üzleti érték már az első iteráció után megjelenik — minden kiemelt modul azonnal előnyökkel jár (gyorsabb változások, alacsonyabb kockázat, jobb megfigyelhetőség).

Milyen technológiákról migrálunk leggyakrabban?

A leggyakoribb utak: PHP 5/7 → PHP 8 vagy Python (FastAPI) vagy Node.js (Express/Fastify). .NET Framework 4.x → .NET 8 vagy Java/Spring Boot. Java EE (JBoss/WebSphere) → Spring Boot vagy Quarkus. jQuery + monolithic templates → React/Vue/Astro. Oracle DB → PostgreSQL (jelentős licencmegtakarítás). On-premise → felhő (AWS, Azure, GCP, helyi privát felhő).

Mi lesz a meglévő integrációkkal más rendszerekkel?

Minden meglévő integrációt feltérképezünk a discovery fázisban. A migrációs terv tartalmazza: a meglévő szerződések megőrzését (a belső és külső ügyfelek nem veszik észre a változást), a verziózás bevezetését (v1 régi szerződés, v2 új), a fogyasztók fokozatos átállítását v2-re, csak ezután a v1 kivonását. Teljes visszafelé kompatibilitás a migráció alatt.

Hogyan csökkentik az üzleti kockázatot?

Öt réteg: 1) inkrementalitás — egyszerre egy modult cserélünk, nem mindent egyszerre; 2) karakterisztikus tesztek — a refaktorálás előtt rögzítjük a rendszer jelenlegi viselkedését (capture tests), amelyek aztán ellenőrzik, hogy semmi nem romlott el; 3) feature flags — az új funkcionalitás fokozatosan kerül indításra (1% felhasználó → 10% → 50% → 100%); 4) rollback terv minden deployhoz (<5 perc); 5) hypercare az üzembe helyezés után (intenzív monitoring 2-4 héten át).

Mi van a rendszer dokumentációjával, amely nem létezik?

Gyakori probléma a legacy esetén. A projekt első szakasza: dokumentáció reverse engineering. Az MI-ügynökök elemzik a kódot, az adatbázissémát, a produkciós logokat és generálják: az architektúraábrát, a végpontok listáját, a függőségi térképet, az üzleti folyamatok leírását. Ezt a dokumentációt aztán üzleti emberekkel ellenőrizzük (úgy néz-e ki a folyamat, ahogy a kódból értjük). Eredmény: teljes dokumentáció a refaktorálás megkezdése előtt, ami nemcsak a modernizációs projekt számára hasznos, hanem a termékfejlesztő csapat számára is.

Mennyibe kerül a modernizáció a régi rendszer karbantartásához képest?

Rövid távon a modernizáció drágább a karbantartásnál (befektetés a refaktorálásba + a régi rendszer párhuzamos fenntartása). A break-even pont (ahol az új rendszer karbantartása olcsóbb lesz a réginél) tipikusan 12-18 hónap után érkezik. Ezután az új rendszer: kevesebbe kerül karbantartani (kevesebb fejlesztő, több automatizáció), lehetővé teszi a változások gyorsabb bevezetését (rövidebb time-to-market), csökkenti a kockázatot (jobb megfigyelhetőség, több teszt, a hibák izolálása).

Kezdjük audittal

Egyhetes műszaki audit: a jelenlegi állapot feltérképezése, a legsürgősebb modernizációs területek azonosítása, szakaszos terv konkrét üzleti eredményekkel az első iterációban.

Rendszeraudit egyeztetése Fejlesztési folyamat