Legacy-kiváltás lépésről lépésre: Strangler Pattern, párhuzamos üzemeltetés és adatkonzisztencia a bevezetés során

Egy Legacy-rendszer lecserélése ritkán azért bukik meg, mert az új megoldást „megépítik”, hanem az átmenetnél: az adatoknak helyesnek kell maradniuk, az interfészeknek nem szabad megszakadniuk, és az üzemnek az átállás alatt is folyamatosan kell működnie. Sok vállalatnál ezért a Big-Bang-Cutover nem opció – túl nagyok a függőségek, túl magasak a kiesési költségek, túl nehéz a visszaállítás.

A gyakorlatban beválik egy lépésenkénti megközelítés a Strangler Pattern (a funkcionális részeket fokozatosan „átirányítják”), a párhuzamos üzem (a régi és az új rendszer ideiglenesen párhuzamosan fut) és egyértelmű szabályok az adatkonzisztencia biztosítására. Ez a cikk bemutatja, hogyan kombinálhatja ezeket a komponenseket úgy, hogy azok az IT‑vezetés, az üzemeltetés és a projektfelelős mindennapi gyakorlatában is terhelhetőek legyenek – beleértve a tipikus hibaképeket, működési következményeket és döntési pontokat a rollout során.

Miért a lépésről lépésre megközelítés gyakran a reális megoldás a Legacy-rendszer leváltására

A legacy rendszerek ritkán „csak egy alkalmazás”. Többnyire kapcsolódnak hozzájuk: batch‑futtatások, fájlinterfészek (SFTP‑mappák, hálózati meghajtók), nyomtatási és beolvasási folyamatok, helyi eszközök, BI‑kivonatok, e‑mail relay‑ek, speciális hardver, Shadow‑IT kivezetések és manuális megkerülések. Egy Big‑Bang során ezeknek az útvonalaknak mind ugyanazon a hétvégén működniük kell – beleértve a jogosultságokat, törzsadatokat, historikus adatokat és különleges eseteket.

A lépésről lépésre megközelítés csökkenti a kockázatot, de nem tolja azt automatikusan „alacsonyabb” szintre. Láthatóbbá és kezelhetőbbé teszi a kockázatokat, ugyanakkor tiszta architekturális és üzemeltetési döntéseket követel: Hol történik az útirányítás? Ki az adatgazda? Milyen konzisztencia kötelező szakmailag, és hol elegendő időbeli késedelem? És hogyan kerülheti el, hogy a párhuzamos üzem tartós építkezéssé váljon?

Strangler Pattern in der Unternehmensrealität: nicht „Microservices“, sondern klare Schnittkanten

Az Strangler Pattern azt jelenti: az új funkciókat a régi rendszer mellé építik, és a forgalmat lépésről lépésre átirányítják, amíg a régi rész feleslegessé nem válik. Fontos: ez nem egy architekturális vallásvita („Monolith vs. Microservices”), hanem egy migrációs minta. Működik akkor is, ha a célarchitektúra továbbra is monolitikus – csak modernebb, karbantarthatóbb és jobban integrálható lesz.

A legfontosabb döntés: vágjon a folyamatok mentén, ne a táblák szerint

Sok leváltásnál túl adatalapúan történik a felosztás („Először a ügyfél‑ és megrendelés‑táblákat vesszük”). Ez gyakran fájdalmas párhuzamos üzemhez vezet, mert a folyamatok átfutnak ezeken az adatokon. Jobb egy folyamatorientált vágás, például „Ajánlatkészítés”, „Áruátvétel”, „Reklamációkezelés” vagy „Szervizjegy a számlázásig”.

Gyakorlati szabály: Egy Strangler‑fázisnak szakmailag zárt folyamatot kell lefednie, amely az új rendszerben végponttól-végpontig üzemeltethető és felügyelhető. Ide tartoznak a bemenetek (UI, API, Import), a feldolgozás (üzleti szabályok) és a kimenetek (nyomtatás, export, könyvelés, értesítés).

Strangler braucht einen „Umlenker“: Gateway, Proxy oder Routing-Schicht

Annak érdekében, hogy a felhasználóknak és a csatlakoztatott rendszereknek ne kelljen minden alkalommal új végpontokat megtanulniuk, gyakran alkalmaznak egy routing‑réteget. A kiinduló helyzettől függően lehet ez: egy reverse proxy webalkalmazások előtt, egy API‑gateway a szolgáltatásvégpontokhoz, vagy egy integrációs réteg, amely fájlinterfészeket és eseményeket egyesít. Döntő a működtethetőség: központi konfiguráció, tiszta logok, monitoring és kontrollált rollback.

Az adminisztrátorok számára fontos, hogy ez a réteg ne váljon blackbox‑szá. Szükségük van nyomon követhető routingokra (melyik request ment hova), logok közötti korrelációra (pl. Request‑ID) és definiált timeout/újrapróbálkozási szabályokra, hogy a hibák ne „összeragadjanak”.

Parallelbetrieb ist ein Betriebszustand – kein „Projekttrick”

Párhuzamos üzem azt jelenti: a régi és az új komponensek egy ideig párhuzamosan, élesben működnek. Ez normális, de költséges – különösen az üzemeltetésben. Több mozgó elem van, több monitoring, nagyobb incidenskockázat és összetettebb felelősségi viszonyok. Ezért a párhuzamos üzemet időben korlátozott üzemmódként kell tervezni, megszakítási kritériumokkal együtt.

Typische Parallelbetriebs-Modelle (und wann sie passen)

• Átkapcsolás felhasználói csoportok szerint (Pilotgruppe → Wellen): alkalmas, ha a felhasználói szerepek egyértelműen elkülöníthetők és a folyamatok nem futnak át csoportokon.
• Átkapcsolás bérlők/telephelyek szerint: jó fiók-/telephely‑struktúrák esetén, ha a helyszínek közötti adatfolyások korlátozottak.
• Átkapcsolás folyamatlépések szerint: pl. „új a rögzítés, a számlázás még régi” – kockázatos, ha sok visszacsatolás van, de néha elkerülhetetlen.
• Átkapcsolás objektumtípusok szerint: pl. új vagyontárgyak az új rendszerben, régi állomány a régi rendszerben – működhet, ha egyértelmű szabályok vannak az előzményekre/riportálásra vonatkozóan.

Üzemeltetési szempontból a párhuzamos üzemet úgy kell megtervezni, hogy a hibadomének kicsik maradjanak: egy hiba az új komponensben ne rántsa magával a legacy rendszert (pl. blokkoló interfészek vagy adatbáziszárak miatt), és fordítva, a legacy ne szabotálja az összes új folyamatot bizonytalan exportokkal.

Feature Flags und Routing-Regeln: Kontrolle statt „wir rollen aus und hoffen”

A feature flag‑ek olyan kapcsolók, amelyekkel funkciókat célzottan lehet aktiválni/deaktiválni – új deploy nélkül. Az IT‑vezetés és a projektfelelősök számára nem a technikai részlet a döntő, hanem a Governance: ki kapcsolhat? Hogyan dokumentálják, miért történt a váltás? Milyen gyorsan lehet visszafordítani? Milyen függőségek keletkeznek (pl. ha az adatok már új formátumban készültek)?

Hasznos gyakorlat egy kis change‑protokoll (Decision Log) minden kapcsolási művelethez: időpont, Owner, érintett felhasználói csoport, várt hatás, monitoring‑jelzők, rollback‑feltétel. Ez megelőzi a klasszikus „senki sem tudja már, miért így van irányítva” helyzetet.

Datenkonsistenz im Rollout: Der Kern, an dem viele Ablösungen hängen

Adatkonzisztencia azt jelenti, hogy az adatok szakmailag helyesek, teljesek és a várt sorrendben elérhetők. Párhuzamos működésben ez nehézzé válik, mert két rendszer egyszerre ír, vagy legalábbis mindkettő a „valóságot” igényli. Itt dől el, hogy a legacy kiváltása stabil lesz-e, vagy hónapokig fogják a delta-egyeztetéseket futtatni.

Először tisztázandó: melyik rendszer az adott adatkörben a „System of Record”?

Minden adatkörre (pl. vevők, cikkek, árak, megrendelések, raktármozgások, bizonylatok) szükség van annak meghatározására, melyik rendszer a vezető. Ez nem csak architektúrális kérdés, hanem operatív:

• Hol történnek a javítások support esetén?
• Hol van a jóváhagyási folyamat (kettős jóváhagyás / SoD/funkciók szétválasztása)?
• Milyen audit-nyomokat kell rögzíteni (ki, mikor mit módosított)?
• Hogyan kerülhetők el az utómunkák a havi zárásnál?

A Strangler-minta korai szakaszaiban gyakran érdemes a legacy-t átmenetileg adatszolgáltatónak hagyni, és az új komponens „csak” fogyasztóként működjön. Később a vezetést megfordítják. Ennek a vezetőváltásnak külön mérföldkőnek kell lennie, egyértelmű Cutover-ablakkal, valamint kommunikációs és átadás-átvételi tervvel.

Szinkronizációs minták: Dual Write, CDC és eseményalapú megoldások – reális elvárásokkal

Több út létezik az adatok szinkronban tartására az öreg és az új rendszer között. Egyik sem „ingyenes”.

• Dual Write: Egy művelet mindkét rendszerbe ír (pl. megrendelés létrehozása → Legacy és az új rendszer). Előny: gyors elérhetőség. Hátrány: hibakezelés összetett (mi történik, ha A rendszer ír, B nem?), továbbá függőségek és gyakran teljesítménykockázatok keletkeznek.
• Change Data Capture (CDC): A változásokat az adatbázis-logból vagy trigger/ replikáció révén deltákként kinyerik. Előny: szétkapcsolja az alkalmazást és a szinkronizációt. Hátrány: replikálja a „technikai” jellegű változtatásokat is, és az üzleti eseményeket vissza kell építeni; továbbá a legacy rendszerben bekövetkező sémaváltozások hirtelen integrációs kockázatot jelentenek.
• Eseményalapú integráció: A rendszer üzleti eseményeket publikál (pl. „megrendelés jóváhagyva”), amelyeket a többi rendszer fogyaszt. Előny: tiszta üzleti szemantika. Hátrány: megköveteli a pontos eseménydefiníciókat, idempotenciát (ismételt feldolgozás kár nélkül) és egy terhelhető üzenetkezelési üzemeltetési koncepciót.

Döntéshozóknak fontos: az adatkonzisztencia nem bináris. Egyes folyamatok erős konzisztenciát igényelnek (azonnal helyesnek kell lenniük, pl. fizetési jóváhagyások), míg mások végső konzisztenciát (eventual consistency) tolerálnak (rövid késleltetés megengedett, pl. keresési index, riportok, értesítések). Ezt a besorolást korán egyeztetni kell az üzleti területtel és a revízióval/audittal.

Konfliktusok és duplikátumok: tervezzék kifejezetten a „hibás eset” (ugly path) kezelését

Párhuzamos üzem esetén a konfliktusok tipikusan így keletkeznek: két rendszer ugyanazt az objektumot módosítja, de eltérő szabályok szerint. Vagy egy import duplán fut le, mert egy retry „túl korán” történt. Vagy egy felhasználó a Legacy-ben javít adatokat, miközben az új felület már átállt.

Ehhez kötelező érvényű szabályokra van szükség:

• Konfliktfeloldás: a „Last write wins” ritkán helyes szakmai szempontból. Jobbak a prioritások (a vezető rendszer nyer) vagy szakmai merge-szabályok (pl. kapcsolattartó alapadatok vs. kondíciók).
• Idempotencia: Minden integrációnak képesnek kell lennie többszöri feldolgozásra duplikátumok nélkül (pl. azonos bizonylatszám, azonos külső referencia).
• Dead-Letter/karantén: A feldolgozhatatlan delta-üzeneteknek megtalálhatónak kell lenniük, egyértelmű felelősséggel és újrafuttatási folyamattal.

Ezek nélkül az adatok konzisztenciája „Excel-egyeztetésbe” és kézi utómunkába csúszik — ami megfelelő frusztrációt és nehezen mérhető következményköltségeket eredményez.

Rollout-tervezés: hullámok, átvételek és visszaállítás anélkül, hogy túlterhelnék az üzemet

Egy jó rollout több, mint „Deployment + Schulung”. Párhuzamos üzemmódban össze kell fonni a bevezetést és az üzemeltetést: ki végzi az első szintű hibakezelést? Mely logok érhetők el azonnal? Hogyan történik az eszkaláció? Mely folyamatokat tilos egy hullámban átállítani (pl. havi zárás, leltár, árváltoztatás)?

Hullámtervezés szigorú kritériumokkal

Bevált a hullámtervezés egyértelmű belépési kritériumokkal, nem csak dátumokkal. Kemény kritériumok példái:

• Monitoring-dashbordok és alerting az új komponenshez élőben működnek és teszteltek (beleértve a „riasztási zaj” csökkentését).
• Léteznek runbookok tipikus incidensekre (timeoutok, sorfelhalmozódás, hibás importok, jogosultsági hibák).
• A delta-egyeztetés automatizált és érthető jelentéseket ad (eltérések objektumtípus szerint, időablak, hibaok-kategória szerint).
• A rollback-mechanizmus begyakorolt (legalább Staging/Pre-Prod környezetben realisztikusan végigjátszva).

Az utolsó pontot különösen alulértékelik: a rollback nem az, hogy „visszakapcsolunk”. Ha az új rendszer már előállított adatokat, tudniuk kell, hogyan lesznek ezek az adatok láthatók a Legacy-ben, vagy hogyan migrálják/semlegesítik helyesen a létrehozott adatokat.

Cutover-miniváltások a Big Bang helyett

Még a Strangler Pattern esetén is vannak Cutoverek — csak kisebbek. Tipikusak a mini-cutoverek egy folyamatlépés váltásánál vagy az adatok vezetésének átváltásánál. Minden mini-cutoverhez szükséges:

• Adatfagyasztás (rövid, de kötelező): Ki mit módosíthat ez idő alatt?
• Egyeztetés: Mi változott az utolsó szinkron óta?
• Átkapcsolás: routing/feature flag-ek, jobok, ütemezések, jogosultságok.
• Verifikáció: szakmai smoke-tesztek (pl. megrendelés létrehozása → szállítólevél → számla), valamint technikai ellenőrzések (queue-ok, hibaarányok, DB-terhelés).

Az IT-vezetés számára fontos, hogy ezeket a lépéseket ismételhető folyamatként dokumentálják és személyi szempontból biztosítsák. Ellenkező esetben a projekt sikere egyes személyeken múlik, akik „tudják, hogyan kell csinálni”.

Interfészek stabilizálása először: a legacy-leváltás alulértékelt alapja

Sok legacy rendszer növekedésből adódó interfészeken keresztül kommunikál: CSV-exportok mappába, éjszakai jobok, harmadik féltől származó eszközök közvetlen adatbázis-hozzáférései, e-mail alapú munkafolyamatok. A fokozatos leváltás sokkal könnyebb, ha először a felületeket feltérképezik és néhány ponton konszolidálják azokat.

Gyakorlatilag ez azt jelenti: azonosítsa a rendszerkritikus integrációs pontokat (pl. számvitel, szállítás, gyártási visszajelzések, identitások/jogosultságok), és építsen ki ott egyértelmű szerződéseket. A „szerződés” itt nem jogi értelemben vett dokumentum, hanem technikai stabilitás: verziókezelés, egyértelmű mezők, stabil azonosítók, dokumentált hibakezelés, meghatározott SLA-k az adatszolgáltatásra.

Ha ehhez egy belső API-/integrációs governance-modellt vezet be (tulajdonosok, deprekációs szabályok, teszt-/staging-útvonalak), csökken annak a kockázata, hogy egy legacy-változtatás hirtelen megbénítja az új komponensét. Jó belső hivatkozási pont lehet például egy bejegyzés az API-governance-ről és a deprekációs stratégiákról.

Biztonság, jogosultságok és audit: a párhuzamos üzem felerősíti a témát

A párhuzamos üzem során gyakran duplikált felhasználó- és szerepkörmodellek alakulnak ki. Ez árnyékjogokhoz vezet: egy felhasználó az új rendszerben megfelelően korlátozott, de a legacy-ben még kiterjedt jogosultságokkal rendelkezik – és végül a „könnyebb úton” jár. Emellett műszaki fiókok (Service Accounts) is működnek a szinkronizációhoz, importokhoz, üzenetsorokhoz és batch-feladatokhoz.

Konkrét pontok, amelyeket korán tisztázni kell:

• Identitásforrás: Honnan származnak a felhasználók és a csoportok? AD/Entra ID? Saját IAM? Fontos, hogy a provisionálás nyomon követhető legyen.
• Szerepkör-térképezés: Ha a szerepkörök nem illeszkednek 1:1, szükség van átmeneti szerepkörökre, amelyek időben korlátozottak és újraigazolást igényelnek.
• Service Accounts: Minimális jogosultságok, titkok rotációja, tiszta naplózás. Különösen a szinkronizációs fiókok jelentenek bejutási kaput és nehezen auditálhatók.
• Audit-nyomvonalak: Ha az adatvezetés átvált, világosnak kell lennie, hol található a módosítások bizonyítéka és hogyan kutatható át mindkét rendszerben.

Döntéshozóknak fontos: a biztonság itt nem „plusz Scope”, hanem befolyásolja a bevezetés megvalósíthatóságát. A jogosultságok későbbi, párhuzamos üzemben történő utólagos igazítása általában drágább, mint egy korai, pragmatikus szerep- és szolgáltatásfiók-szeparáció.

Monitoring, naplózás és üzemátadás: megfigyelhetőség nélkül a párhuzamos üzem vak lesz

A párhuzamos üzemben a hibaképek gyakran indirektek: egy delta fennakad, egy újrakísérlet végtelenül fut, egy queue feltorlódik, vagy egy időkritikus munka ütközik egy adatbázis-zárral. Ha ezt csak felhasználói hibajegyekből látja, késő. Ezért már az elejétől szüksége van egy megfigyelhetőség minimumra: monitoring (állapot), logging (események) és – ahol indokolt – tracing (rendszereken átnyúló lánc).

Gyakorlati, jól üzemeltethető jelzők például:

• Szinkronizációs backlog (hány módosítás „várakozik”), valamint a legrégebbi bejegyzés kora.
• Hibaarányok interfészenként és hibakategóriánként (validáció, timeout, hitelesítés, adatkonfliktus).
• Késleltetés egy folyamatlépésre vonatkozóan (pl. megrendelés jóváhagyásától a szállítási megrendelés létrehozásáig).
• Adatminőségi mutatók (duplikációs arány, hiányzó kötelező mezők, váratlan null-értékek).

A működés átadásánál kevésbé az számít, melyik eszközt használják, mint az, hogy a felelősségek és a Runbooks egyértelműek-e. Ha ügyeleti vagy készenléti szolgálat van, a működésnek tipikus meghibásodásoknál fejlesztői nyomozás nélkül is képesnek kell lennie intézkedni.

Wann Strangler Pattern nicht passt (oder nur mit klaren Einschränkungen)

Vannak olyan helyzetek, amikor a lépésenkénti kiváltás csak korlátozottan működik:

• Extrem enge Transaktionskopplung: Ha gyakorlatilag minden művelet átlépi az összes modult és szigorú konzisztenciát követel meg, a párhuzamos üzem hamar kezelhetetlenné válik.
• Direkte DB-Zugriffe durch Drittsysteme: Ha több eszköz közvetlenül ír/olvas legacy táblákba, ezt a rendezetlen állapotot először meg kell szüntetni vagy kontrollálni kell.
• Unklare Datenhoheit: Ha nem határozható meg, ki az adatok felelőse, konfliktusok garantáltak – és a kiváltás politikai, nem technikai kérdéssé válik.
• Fehlende Betriebsdisziplin: Tiszta környezetek, reprodukálható deployok és monitoring nélkül minden köztes lépés kockázattá válik.

Ez nem azt jelenti, hogy Big Bang-re kényszerülne. De ilyenkor meg kell változtatni a sorrendet: először stabilizálni az integrációs pontokat, központosítani az adat-hozzáféréseket, tisztázni a szerepeket és az ownershipet – és csak ezután alkalmazni a stranglert.

Ein praxistauglicher Ablaufplan für die Legacy-Ablösung in Etappen

Projektfelelősök számára támpontként egy, világos etapokra bontott folyamat vált be. A pontos megvalósítás rendszertől és iparágtól függ, de a logika robusztus:

1. Inventar & Abhängigkeiten: Interfészek, jobok, adatfolyamok, felhasználói csoportok, kritikus időablakok (zárás, leltár).
2. Schnittkanten definieren: Folyamatmodulok, területenkénti adatvezetés, integrációs szerződések.
3. Routing & Schalter bauen: Gateway/Proxy, Feature Flags, központi naplózás.
4. Datenpfad festlegen: CDC/Event/Dual Write, konfliktuskezelési szabályok, karantén, egyeztető jelentések.
5. Pilot mit echter Last: nem csak demo, hanem valós esetekkel és valódi terheléssel, kivételek bevonásával.
6. Wellenrollout: Belépési kritériumok, cutover-ellenőrzőlisták, rollback-gyakorlatok.
7. Abschalten & Aufräumen: Régi útvonalak deaktiválása, jobok eltávolítása, jogosultságok visszavonása, dokumentáció frissítése.

Az utolsó pont kulcsfontosságú: sok szervezet a „biztonság kedvéért” továbbfuttatja a legacy komponenseket. Eredmény: duplikált költségek, tisztázatlan kockázat, és senki sem meri lekapcsolni őket. Tervezze meg a dekommissziót mint külön alprojektet határidővel, felelősökkel és bizonyítékokkal (pl. „X hét óta nincs hozzáférés”, „minden export átállítva”, „audit követelmények teljesítve”).

Fazit: Schrittweise ablösen heißt, Konsistenz und Betrieb als Produkt zu behandeln

A legacy lépésenkénti kiváltása nem feltétlenül egyszerűbb – de sok vállalatnál ez a reális opció. A Strangler Pattern működik, ha etapokra bontva egyértelmű folyamat-schnittkanten-t definiálnak, a párhuzamos üzemet mint tényleges üzemállapotot tervezik, és az adatkonzisztenciát nem bízzák a véletlenre. Döntő jelentőségű a korai adatvezetési döntés, robusztus szinkronizációs sémák konfliktusszabályokkal, valamint hullámokban történő bevezetés, átvételek és begyakorolt visszaesés (fallback) terve.

Ha rendszercserét tervez, és az interfészeket, a párhuzamos üzemet vagy az adatkonzisztencia-koncepciót egyszer strukturáltan át szeretné beszélni, elérhet minket a .

Projekt vagy modernizációs kezdeményezés megbeszélése a Net-Base segítségével.